以车销业务为例，聊聊B端项目需求调研

本文以车销业务为例，向我们分享了B端项目需求调研的前中后期的工作内容以及注意要点。

前言

有段时间整个产品团队频繁支撑SFA项目，但需求调研普遍存在一些问题，导致PRD质量不高。团队成员基本是内部转岗过来的，对B端需求调研的方法论多有不足。故结合过往经验，参考《软件需求开发最佳实践- 基于模型驱动的需求开发过程》一书，以车销业务为例做此分享。

调研前

基础捕获

既然是去项目进行调研，再不济也知道甲方客户名称。有了客户名称，基本能获取到以下方面的资料：

• 主营业务，以及所属行业
• 在行业中的地位
• 经营的产品，以及对应特性
• 资本构成
• 组织架构（尤其是营销组织）
• 营销渠道

下面以益力多为例，讲一下获取信息的途径。

通过启信宝、天眼察、企查查等网站，可以找到益力多的信息。经营业务包括进口、乳制品、保健品等。保健品，就可能有溯源的诉求（主要怕伪劣产品吃出人命）。

公司的相关信息，还可通过官网得到。从官网首页导航栏中，很容易找到“乳酸局巨头”这个信息。

另外，官网显示的产品信息中只有低糖（蓝色装）和正常（红色装）两种。典型的大单品模式，一如红牛定义了牛磺酸功能性饮料。益力多从港台进驻，定义了大陆的乳酸菌饮料。

股权穿透图显示株式会社Yakult本社控股50%，香港益力多控股35%，养乐多10%。看起来似乎是日资+港资+中资，但深追一下发现不那么简单。

追溯历史，Yakult是日本企业，先后进入港台。香港是粤语音译为益力多，台湾则普通话音译为养乐多。2001年左右从香港进入华南地区，成立广州益力多，覆盖华南及海南。2年后在上海设立养乐多公司，覆盖大陆其他地区。所以，日资无误，控股占比相当高。

日资企业的特点不用说了，什么部长、课（科）长之类的岗位是必备了。然后日资注重上下级关系，严格的业务流程&一堆审批流是必须的。

组织架构是比较难从网络上获取到，基本上是用“公司名称+组织架构”在百度文库中查找。益力多没有，康师傅这类倒是有。

营销渠道也是非常难获取到的，用“公司名称+渠道”可以尝试在百度中查找。益力多找不到，同为乳制品的蒙牛有。

进阶捕获

这一块因企业、项目而异，因为各个企业的营销玩法不一样，各个项目的立项方式也有区别。

整体来说，就是从营销线和实施线获取资料。

营销线的资料包括：

• 售前报告
• 合同（细化拆解为部署方式、三方对接系统和SOW，但部分合同SOW几乎等于没有）

实施线的资料包括：

• 计划交付版本（Base的标准产品版本）
• 项目计划（细化拆解整体计划排期和调研计划）
• 负责模块（极少单兵作战，需要分工合作）
• 需求规范（交付物以及对应规范，根据项目等级有个内部规范。调研过程中，再和甲方确认）

这些资料的捕获，就靠自己发挥才能了。部分信息很敏感（如合同金额），企业内部不让随意传阅，可以要求仅截取部分信息。实在没有办法，可以尝试让上级协助。

以售前报告为例，可能从该项目的销售、售前或者PMO（部分项目可能尚未走完立项流程）那边获取。一般售前报告会有Base产品模块的客户诉求描述，并且会突出某部分和现有产品有差距，这就是我们要的关键信息。

再以调研计划为例，可能从销售、售前和项目经理处获取。但是初步的调研计划很粗，通常都是项目经理。一方面调研完成时间根本不可能（Deadline倒排法万岁），另一方面调研的顺序等都不符合你的做事方式。建议立刻和项目经理沟通，看看能否调整（只能调调研先后顺序，deadline是红线）。

另外，根据调研计划和SOW，提前整理出调研准备物，让甲方项目团队提前启动，参与部分调研工作。举个例子，需要甲方先提供好营销组织架构、角色清单、主数据相关字段&审批、接口文档、关键表单信息和报表样式。

高阶捕获

准备一份调研问卷（Base交付版本产品能力），让甲方先进行填写，如“考勤是否包含内勤人员的管理”、“内勤人员打卡，是否要基于定位进行检查，如距离办公楼100米内”。

准备一份计划交付版本的产品功能清单，项目的功能清单将基于这份，进行裁剪和新增。

充分了解产品的内部逻辑，特别是牵一发而动全身的主数据关联。举个例子，终端的某个字段，标准产品里面是必填非空的。但这个项目不需要，那么这个字段不能被删除的，要给个默认值才能正常往下跑，并且后续功能都会受到影响（页面都要隐藏掉这个字段）。

充分了解PaaS能力（无PaaS的就多储备点技术吧），能衡量改动的代价。客户提出诉求（一般已经是具体的UI、UE层面），先判断需求是什么。为达到目标，是否有更低成本的方式。又或者，是否有更通用的方式，为后续该功能点产品化做准备。

最后，是对竞品进行捕获。现有项目基本是两种：

1. 替换已有系统；
2. 新上系统。

一般1的话，能提前拿到UAT环境，进去看看能知己知彼。2的话，大部分项目公开招标。招标过程中基本试用或POC过，客户一定是想要最优秀的体验。所以会存在某个功能对方有，我们也要。又或者某个功能别人的好用，你改一改这种。如果能借机能拿到竞品的环境，就是很好的竞品分析机会，也能提前准备。

举个例子，以下是随便找的车销解决方案，可以看出大体流程和业务支撑能力。

调研中

整体方法

三字诀——问听记。

刚接触调研，可能觉得记是最困难的。一般带新人，也是让他从记开始。客户讲了很多，到底记什么。客户讲的很快，记不过来等等。建议开始调研的时候带上纸笔，这种时候写字比反而可能比打字快。然后可以开启录音，记不清的（先记录个时间）可以回去再听。

经历个一两次，会知道问是最困难的。调研的过程，基本就是一问一答，基于已有的知识和听到甲方的回答进行提问。整体的节奏被提问人员控制，只有自己感觉获取足够多的信息，能将业务流程串联起来，足够输出需求规格，才会停止发问。建议在问完一个大的问题后，提出归纳类问题“那我说下我目前关于X的理解，看看对不对”。这样才能确保你的信息是足够的，且甲乙双方的认知是统一的。

这里要特别强调下——少一点套路。B端调研往往，过于期望“引导”客户。无论你在这行混了多少年，奋斗在企业营销一线的才是专家。即便同行业规模类似的企业，渠道的模式和具体的玩法上都会有差异。所以不要尝试从业务合理性上去否决诉求，最多只能是技术代价比较高（也有先有技术无法实现的，请直接否决掉）。能做的引导，是保证实现目标的前提下，往现有产品靠拢，选择简单的实现方式。

总体捕获的方法，是5W1H分析法。这个是很成熟的方法不做展开，简介如下：

需求调研过程中，往往会出现甲方问诸如“客户列表页面，投放冰柜的要有标签或Icon区分出来”这种问题。这其实是跨阶段了，需求调研阶段要解决的是业务是什么，为什么这么做，怎么协作完成。怎么设计UI页面，那是后面原型验证&解决方案阶段的事情。遇到这种情况，调研人员不能简单考虑可行性，要先问自己“为什么要区分，不区分有什么影响吗？为什么在这里区分，是不是可以在其他地方区分？”。如果自己无法回答，要问清楚为止，再给出自己的方案进行协商。如果可以回答，倒是可以简单的说“OK，这个我们到时候会有的”。

业务捕获

业务捕获分为三块，分别是组织架构、业务架构和业务实务。这里面有非常繁杂的逻辑，就列一些要点大纲，不做展开。

先讲组织架构，这个基本上最核心的。而绝大部分人员脑海中，组织结构图就是一棵树。导致甲方给的资料是这样，乙方提供的系统也是如此。

实际在营销CRM系统中，至少要被拆分为两棵树。一颗是企业的机构树，企业下面分了多少个部门。

另一颗是各部门的树，继续分拆。这样能实现，财务部老总看到所有营销部门的销售数据，财务部某个财务主管看到营销部南方战区的销售数据。组织架构基本和权限设计绑定，是CRM系统的基石，要仔细考虑。

然后是业务架构，细分为部门业务和岗位设置。关于部门业务，需要注意以下几点：

1. 哪些部门和项目相关
2. 这些部门各自分管哪一块，怎么考核
3. 对照的职责是否都在系统上落实，工作流全部跑通
4. 了解推力和阻力，尽量让每个部门都有所获益
5. 各组织节点，部门设置是否一致。或者整体职责是否一致，只是有所合并拆分（最怕遗漏了某个部门，而且这个部分流程全部特殊）

关于岗位设置，从下述的几个方面提问：

1. 岗位的大概目标，考核的大概方法（KPI）
2. 岗位间的协作和上下级关系
3. 哪些岗位需要对外（区分内外勤人员）
4. 哪些岗位会启动新流程
5. 各层次岗位是否能统一
6. 是否出现一人多岗的情况（业务人员兼主管是很常见的）
7. 是否已有内部系统编码，领导是否要显示最前面

这里面，强调下岗位的问题。如果一人多岗，会影响整体系统的设计，包括权限那块。

技术捕获

技术捕获，主要是技术层面的诉求，也存在很大的风险。

遗留系统方面，注意以下三点：

1. 是否并存，并存到何时，职责切分
2. 能否替代，替代节奏和方案
3. 数据能否迁移，迁移方案

外部系统方面，注意以下4点：

1. 是否并存
2. 能否替代
3. 接口
4. 数据

剩下的是一些非功能性需求，一般有：

1. 可靠性
2. 可用性（注意体验）
3. 有效性
4. 可移植性

调研汇报

调研节奏普遍较快，密集的1-2周。调研人员每天晚上就是写会议纪要以及跟进问题，很少时间进行需求设计。再加上项目人员一般设计能力有限（大部分项目经理是axure略懂而已），需要请求总部资源，调研结束后一般就回总部。然后1-2周进行需求设计输出原型，项目经理配合产品出解决方案。

但是这个阶段有个空窗期，且搜集信息未得到确认。最好联系甲方项目经理，组织部分干系人，进行需求调研汇报。汇报的内容主要包含：

• 组织架构图
• 分部门的岗责清单（Excel）
• 重点业务流程&审批流程梳理（Visio）
• 核心业务原型图（axure）

需求开发

需求分析

需求分析的过程，大部分是客户无感知的，只能体现在最终的输出物中。

我个人认为主要分为产品（含PaaS）、业务和报表三块。

产品需要考虑：

• 现有的PaaS配置能力
• 标准产品逻辑（标准产品已有能力要补充到需求规格中）
• 公共需求的抽象（分页、导入导出等）

业务需要考虑：

• 流程和分支节点
• 事件触发（时间or操作）
• 特殊字段维护（如订单类型，是通用字典维护，还是专用页面维护，或者写入数据库不提供UI界面维护，甚至直接代码写死）

报表需要考虑：

• 周期（日报、周报、月报）
• 样式（动态列头？）
• 明细流水
• 统计抽取
• 历史数据处理
• 性能

在需求分析过程中，有很重要的一个点，就是给需求排优先级，尝试切分部分需求。这个在立项时候甲乙双方就有约定，但调研过程往往有变数。所以需要基于调研情况，重新排优先级，切分阶段。

一般都会分成两期上，一期先上某个渠道，搭建好基础。需求的优先级，基本上对内不对外。即便一期的内容，乙方内部也是要排优先级的。每一期的功能清单，都不包含优先级。最终计划怎么排，哪些功能可以如期上，乙方内部要心里有数。

而功能清单是全量的，一般附带在需求规格中。但是会加上标注，区分每一期的内容。这个功能清单基本是页面级别的，颗粒度比较粗。

业务解决方案

售前阶段已有解决方案，是比较靠近标准产品和行业的。而业务解决方案则是落地，贴近企业实务。基本上，是调研汇报内容的总结和升华。

部分项目中，这个由项目经理编写，产品做辅助支撑。产品需要提供各个业务的流程图和设计原型，匹配业务诉求。

另外部分重点项目，这个由产品独立解决。这种方案有点偏咨询，除了本次调研的业务还涉及其他的相关系统。要基于行业营销信息化的认知，去构建大营销系统的蓝图。所以什么AI、数据中台，统统都上。

原型验证基本上是和业务解决方案同时开始的，业务解决方案中包含重点业务的原型图。一旦业务解决方案得到认可，就开始细致的原型验证阶段。这个阶段客户会开始看UE，原型的改动非常多。

举个例子，B端是非常喜欢单据式布局的。一方面是使用习惯，另一方面是单据布局直观紧凑。尤其是APP端，经常出现客户选择表格布局替代卡片布局的情况。

需求规格说明书

CMMI的定义中，交付物包含用户需求规格说明书和产品需求规格说明书。实际项目中的需求规格说明书，基本上是用户需求规格说明书。这是常态，只有基于业务的描述才能和甲方进行确认。但很多研发是没有业务背景的，看这份用户需求很难直接进行概要设计。基于成本考虑，部分细节会一并在这份用户需求规格上。

所以，我们看到的项目的需求规格，大部分时候是四不像的大杂烩。一般包含：用户需求规格说明书+字段细分说明（部分会省略）+接口说明+状态流程说明（审批流、订单业务流等）。却又缺少了关键的需求建模信息（主要是领域建模），研发要频繁的找产品问业务，才能进行概要设计。

项目的需求规格，基本上是和原型同步启动的。但我个人建议是原型验证后，再贴原型图。最好文档基本确认完成，再贴原型图。期间原型图可以生成html打包，邮件给甲方查阅。不这么做，就是以下的情况：

1. 以会议纪要的形式记录改动点，晚上回去后要先原型。原型改好要截图，贴到PRD。但经常出现，原型图和PRD字段不匹配。
2. 以屏幕扩展的方式投屏，客户要修改的，现场标记或者改好。回去匆忙改原型，准备后面的原型验证。后面再补PRD，很容易造成遗漏（因为是密集的原型验证，这期间客户不看PRD，导致PRD和原型脱节）。
3. 原型验证完成，开始评审PRD。开启审阅+批注后，打开和保存文档不是一般的卡（4G内存还能怎样）

补充说明：

产品需求规格中，需求建模主要包含用例图（内部WBS拆解够细，可不出）、类图（可简化为ER图）、序列图（可简化为活动图）、状态图。以订单领域为例：

• 用例图，订单的所有用例，如查看查询、新增、编辑、导入、导出、审核、发货、收货
• 类图，订单类的成员名和字段类型乃至长度，以及审批单、发货单、送货单、收货单等附属单据信息。
• 序列图，订单的全流转过程。
• 状态图，订单的先后状态和触发状态变更的操作

PS：将近一年前的PPT，拿出来分享。从输出倒逼输入，真的是很痛苦，各位将就下。

作者：道·术 ，邮箱：olivercan.wunban@foxmail.com

本文由 @道·术 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash ，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: