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

　　本文以车销业务为例，向我们分享了B端项目需求调研的前中后期的工作内容以及注意要点。
　　前言
　　有段时间整个产品团队频繁支撑SFA项目，但需求调研普遍存在一些问题，导致PRD质量不高。团队成员基本是内部转岗过来的，对B端需求调研的方法论多有不足。故结合过往经验，参考《软件需求开发最佳实践基于模型驱动的需求开发过程》一书，以车销业务为例做此分享。
　　调研前
　　基础捕获
　　既然是去项目进行调研，再不济也知道甲方客户名称。有了客户名称，基本能获取到以下方面的资料：
　　主营业务，以及所属行业
　　在行业中的地位
　　经营的产品，以及对应特性
　　资本构成
　　组织架构（尤其是营销组织）
　　营销渠道
　　下面以益力多为例，讲一下获取信息的途径。
　　通过启信宝、天眼察、企查查等网站，可以找到益力多的信息。经营业务包括进口、乳制品、保健品等。保健品，就可能有溯源的诉求（主要怕伪劣产品吃出人命）。
　　公司的相关信息，还可通过官网得到。从官网首页导航栏中，很容易找到乳酸局巨头这个信息。
　　另外，官网显示的产品信息中只有低糖（蓝色装）和正常（红色装）两种。典型的大单品模式，一如红牛定义了牛磺酸功能性饮料。益力多从港台进驻，定义了大陆的乳酸菌饮料。
　　股权穿透图显示株式会社Yakult本社控股50，香港益力多控股35，养乐多10。看起来似乎是日资港资中资，但深追一下发现不那么简单。
　　追溯历史，Yakult是日本企业，先后进入港台。香港是粤语音译为益力多，台湾则普通话音译为养乐多。2001年左右从香港进入华南地区，成立广州益力多，覆盖华南及海南。2年后在上海设立养乐多公司，覆盖大陆其他地区。所以，日资无误，控股占比相当高。
　　日资企业的特点不用说了，什么部长、课（科）长之类的岗位是必备了。然后日资注重上下级关系，严格的业务流程amp；amp；一堆审批流是必须的。
　　组织架构是比较难从网络上获取到，基本上是用公司名称组织架构在百度文库中查找。益力多没有，康师傅这类倒是有。
　　营销渠道也是非常难获取到的，用公司名称渠道可以尝试在百度中查找。益力多找不到，同为乳制品的蒙牛有。
　　进阶捕获
　　这一块因企业、项目而异，因为各个企业的营销玩法不一样，各个项目的立项方式也有区别。
　　整体来说，就是从营销线和实施线获取资料。
　　营销线的资料包括：
　　售前报告
　　合同（细化拆解为部署方式、三方对接系统和SOW，但部分合同SOW几乎等于没有）
　　实施线的资料包括：
　　计划交付版本（Base的标准产品版本）
　　项目计划（细化拆解整体计划排期和调研计划）
　　负责模块（极少单兵作战，需要分工合作）
　　需求规范（交付物以及对应规范，根据项目等级有个内部规范。调研过程中，再和甲方确认）
　　这些资料的捕获，就靠自己发挥才能了。部分信息很敏感（如合同金额），企业内部不让随意传阅，可以要求仅截取部分信息。实在没有办法，可以尝试让上级协助。
　　以售前报告为例，可能从该项目的销售、售前或者PMO（部分项目可能尚未走完立项流程）那边获取。一般售前报告会有Base产品模块的客户诉求描述，并且会突出某部分和现有产品有差距，这就是我们要的关键信息。
　　再以调研计划为例，可能从销售、售前和项目经理处获取。但是初步的调研计划很粗，通常都是项目经理。一方面调研完成时间根本不可能（Deadline倒排法万岁），另一方面调研的顺序等都不符合你的做事方式。建议立刻和项目经理沟通，看看能否调整（只能调调研先后顺序，deadline是红线）。
　　另外，根据调研计划和SOW，提前整理出调研准备物，让甲方项目团队提前启动，参与部分调研工作。举个例子，需要甲方先提供好营销组织架构、角色清单、主数据相关字段amp；amp；审批、接口文档、关键表单信息和报表样式。
　　高阶捕获
　　准备一份调研问卷（Base交付版本产品能力），让甲方先进行填写，如考勤是否包含内勤人员的管理、内勤人员打卡，是否要基于定位进行检查，如距离办公楼100米内。
　　准备一份计划交付版本的产品功能清单，项目的功能清单将基于这份，进行裁剪和新增。
　　充分了解产品的内部逻辑，特别是牵一发而动全身的主数据关联。举个例子，终端的某个字段，标准产品里面是必填非空的。但这个项目不需要，那么这个字段不能被删除的，要给个默认值才能正常往下跑，并且后续功能都会受到影响（页面都要隐藏掉这个字段）。
　　充分了解PaaS能力（无PaaS的就多储备点技术吧），能衡量改动的代价。客户提出诉求（一般已经是具体的UI、UE层面），先判断需求是什么。为达到目标，是否有更低成本的方式。又或者，是否有更通用的方式，为后续该功能点产品化做准备。
　　最后，是对竞品进行捕获。现有项目基本是两种：
　　替换已有系统；
　　新上系统。
　　一般1的话，能提前拿到UAT环境，进去看看能知己知彼。2的话，大部分项目公开招标。招标过程中基本试用或POC过，客户一定是想要最优秀的体验。所以会存在某个功能对方有，我们也要。又或者某个功能别人的好用，你改一改这种。如果能借机能拿到竞品的环境，就是很好的竞品分析机会，也能提前准备。
　　举个例子，以下是随便找的车销解决方案，可以看出大体流程和业务支撑能力。
　　调研中
　　整体方法
　　三字诀问听记。
　　刚接触调研，可能觉得记是最困难的。一般带新人，也是让他从记开始。客户讲了很多，到底记什么。客户讲的很快，记不过来等等。建议开始调研的时候带上纸笔，这种时候写字比反而可能比打字快。然后可以开启录音，记不清的（先记录个时间）可以回去再听。
　　经历个一两次，会知道问是最困难的。调研的过程，基本就是一问一答，基于已有的知识和听到甲方的回答进行提问。整体的节奏被提问人员控制，只有自己感觉获取足够多的信息，能将业务流程串联起来，足够输出需求规格，才会停止发问。建议在问完一个大的问题后，提出归纳类问题那我说下我目前关于X的理解，看看对不对。这样才能确保你的信息是足够的，且甲乙双方的认知是统一的。
　　这里要特别强调下少一点套路。B端调研往往，过于期望引导客户。无论你在这行混了多少年，奋斗在企业营销一线的才是专家。即便同行业规模类似的企业，渠道的模式和具体的玩法上都会有差异。所以不要尝试从业务合理性上去否决诉求，最多只能是技术代价比较高（也有先有技术无法实现的，请直接否决掉）。能做的引导，是保证实现目标的前提下，往现有产品靠拢，选择简单的实现方式。
　　总体捕获的方法，是5W1H分析法。这个是很成熟的方法不做展开，简介如下：
　　需求调研过程中，往往会出现甲方问诸如客户列表页面，投放冰柜的要有标签或Icon区分出来这种问题。这其实是跨阶段了，需求调研阶段要解决的是业务是什么，为什么这么做，怎么协作完成。怎么设计UI页面，那是后面原型验证amp；amp；解决方案阶段的事情。遇到这种情况，调研人员不能简单考虑可行性，要先问自己为什么要区分，不区分有什么影响吗？为什么在这里区分，是不是可以在其他地方区分？。如果自己无法回答，要问清楚为止，再给出自己的方案进行协商。如果可以回答，倒是可以简单的说OK，这个我们到时候会有的。
　　业务捕获
　　业务捕获分为三块，分别是组织架构、业务架构和业务实务。这里面有非常繁杂的逻辑，就列一些要点大纲，不做展开。
　　先讲组织架构，这个基本上最核心的。而绝大部分人员脑海中，组织结构图就是一棵树。导致甲方给的资料是这样，乙方提供的系统也是如此。
　　实际在营销CRM系统中，至少要被拆分为两棵树。一颗是企业的机构树，企业下面分了多少个部门。
　　另一颗是各部门的树，继续分拆。这样能实现，财务部老总看到所有营销部门的销售数据，财务部某个财务主管看到营销部南方战区的销售数据。组织架构基本和权限设计绑定，是CRM系统的基石，要仔细考虑。
　　然后是业务架构，细分为部门业务和岗位设置。关于部门业务，需要注意以下几点：
　　哪些部门和项目相关
　　这些部门各自分管哪一块，怎么考核
　　对照的职责是否都在系统上落实，工作流全部跑通
　　了解推力和阻力，尽量让每个部门都有所获益
　　各组织节点，部门设置是否一致。或者整体职责是否一致，只是有所合并拆分（最怕遗漏了某个部门，而且这个部分流程全部特殊）
　　关于岗位设置，从下述的几个方面提问：
　　岗位的大概目标，考核的大概方法（KPI）
　　岗位间的协作和上下级关系
　　哪些岗位需要对外（区分内外勤人员）
　　哪些岗位会启动新流程
　　各层次岗位是否能统一
　　是否出现一人多岗的情况（业务人员兼主管是很常见的）
　　是否已有内部系统编码，领导是否要显示最前面
　　这里面，强调下岗位的问题。如果一人多岗，会影响整体系统的设计，包括权限那块。
　　技术捕获
　　技术捕获，主要是技术层面的诉求，也存在很大的风险。
　　遗留系统方面，注意以下三点：
　　是否并存，并存到何时，职责切分
　　能否替代，替代节奏和方案
　　数据能否迁移，迁移方案
　　外部系统方面，注意以下4点：
　　是否并存
　　能否替代
　　接口
　　数据
　　剩下的是一些非功能性需求，一般有：
　　可靠性
　　可用性（注意体验）
　　有效性
　　可移植性
　　调研汇报
　　调研节奏普遍较快，密集的12周。调研人员每天晚上就是写会议纪要以及跟进问题，很少时间进行需求设计。再加上项目人员一般设计能力有限（大部分项目经理是axure略懂而已），需要请求总部资源，调研结束后一般就回总部。然后12周进行需求设计输出原型，项目经理配合产品出解决方案。
　　但是这个阶段有个空窗期，且搜集信息未得到确认。最好联系甲方项目经理，组织部分干系人，进行需求调研汇报。汇报的内容主要包含：
　　组织架构图
　　分部门的岗责清单（Excel）
　　重点业务流程amp；amp；审批流程梳理（Visio）
　　核心业务原型图（axure）
　　需求开发
　　需求分析
　　需求分析的过程，大部分是客户无感知的，只能体现在最终的输出物中。
　　我个人认为主要分为产品（含PaaS）、业务和报表三块。
　　产品需要考虑：
　　现有的PaaS配置能力
　　标准产品逻辑（标准产品已有能力要补充到需求规格中）
　　公共需求的抽象（分页、导入导出等）
　　业务需要考虑：
　　流程和分支节点
　　事件触发（时间or操作）
　　特殊字段维护（如订单类型，是通用字典维护，还是专用页面维护，或者写入数据库不提供UI界面维护，甚至直接代码写死）
　　报表需要考虑：
　　周期（日报、周报、月报）
　　样式（动态列头？）
　　明细流水
　　统计抽取
　　历史数据处理
　　性能
　　在需求分析过程中，有很重要的一个点，就是给需求排优先级，尝试切分部分需求。这个在立项时候甲乙双方就有约定，但调研过程往往有变数。所以需要基于调研情况，重新排优先级，切分阶段。
　　一般都会分成两期上，一期先上某个渠道，搭建好基础。需求的优先级，基本上对内不对外。即便一期的内容，乙方内部也是要排优先级的。每一期的功能清单，都不包含优先级。最终计划怎么排，哪些功能可以如期上，乙方内部要心里有数。
　　而功能清单是全量的，一般附带在需求规格中。但是会加上标注，区分每一期的内容。这个功能清单基本是页面级别的，颗粒度比较粗。
　　业务解决方案
　　售前阶段已有解决方案，是比较靠近标准产品和行业的。而业务解决方案则是落地，贴近企业实务。基本上，是调研汇报内容的总结和升华。
　　部分项目中，这个由项目经理编写，产品做辅助支撑。产品需要提供各个业务的流程图和设计原型，匹配业务诉求。
　　另外部分重点项目，这个由产品独立解决。这种方案有点偏咨询，除了本次调研的业务还涉及其他的相关系统。要基于行业营销信息化的认知，去构建大营销系统的蓝图。所以什么AI、数据中台，统统都上。
　　原型验证基本上是和业务解决方案同时开始的，业务解决方案中包含重点业务的原型图。一旦业务解决方案得到认可，就开始细致的原型验证阶段。这个阶段客户会开始看UE，原型的改动非常多。
　　举个例子，B端是非常喜欢单据式布局的。一方面是使用习惯，另一方面是单据布局直观紧凑。尤其是APP端，经常出现客户选择表格布局替代卡片布局的情况。
　　需求规格说明书
　　CMMI的定义中，交付物包含用户需求规格说明书和产品需求规格说明书。实际项目中的需求规格说明书，基本上是用户需求规格说明书。这是常态，只有基于业务的描述才能和甲方进行确认。但很多研发是没有业务背景的，看这份用户需求很难直接进行概要设计。基于成本考虑，部分细节会一并在这份用户需求规格上。
　　所以，我们看到的项目的需求规格，大部分时候是四不像的大杂烩。一般包含：用户需求规格说明书字段细分说明（部分会省略）接口说明状态流程说明（审批流、订单业务流等）。却又缺少了关键的需求建模信息（主要是领域建模），研发要频繁的找产品问业务，才能进行概要设计。
　　项目的需求规格，基本上是和原型同步启动的。但我个人建议是原型验证后，再贴原型图。最好文档基本确认完成，再贴原型图。期间原型图可以生成html打包，邮件给甲方查阅。不这么做，就是以下的情况：
　　以会议纪要的形式记录改动点，晚上回去后要先原型。原型改好要截图，贴到PRD。但经常出现，原型图和PRD字段不匹配。
　　以屏幕扩展的方式投屏，客户要修改的，现场标记或者改好。回去匆忙改原型，准备后面的原型验证。后面再补PRD，很容易造成遗漏（因为是密集的原型验证，这期间客户不看PRD，导致PRD和原型脱节）。
　　原型验证完成，开始评审PRD。开启审阅批注后，打开和保存文档不是一般的卡（4G内存还能怎样）
　　补充说明：
　　产品需求规格中，需求建模主要包含用例图（内部WBS拆解够细，可不出）、类图（可简化为ER图）、序列图（可简化为活动图）、状态图。以订单领域为例：
　　用例图，订单的所有用例，如查看查询、新增、编辑、导入、导出、审核、发货、收货
　　类图，订单类的成员名和字段类型乃至长度，以及审批单、发货单、送货单、收货单等附属单据信息。
　　序列图，订单的全流转过程。
　　状态图，订单的先后状态和触发状态变更的操作
　　PS：将近一年前的PPT，拿出来分享。从输出倒逼输入，真的是很痛苦，各位将就下。