以车销业务为例,分析B端项目需求前中后工作内容

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

以车销业务为例,分析B端项目需求前中后工作内容

前言

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

调研前

基础捕获

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

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

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

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

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

进阶捕获

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

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

营销线的资料包括:

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

实施线的资料包括:

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

以车销业务为例,分析B端项目需求前中后工作内容

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

高阶捕获

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

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

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

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

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

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

调研中

整体方法

三字诀——问听记。

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

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

业务捕获

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

以车销业务为例,分析B端项目需求前中后工作内容

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

  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)

以车销业务为例,分析B端项目需求前中后工作内容

需求开发

需求分析

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

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

产品需要考虑:

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

业务需要考虑:

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

报表需要考虑:

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

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

业务解决方案

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

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

以车销业务为例,分析B端项目需求前中后工作内容

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

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

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

以车销业务为例,分析B端项目需求前中后工作内容

需求规格说明书

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

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

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

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

补充说明:

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

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

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

作者:道·术 ,邮箱:olivercan.wunban@foxmail.com

本文由用户@菜鸟运营发布于新媒体运营,未经许可,禁止转载。

题图来自Unsplash ,基于 CC0 协议

本文由 新媒体运营 作者:菜鸟运营 发表,其版权均为 新媒体运营 所有,文章内容系作者个人观点,不代表 新媒体运营 对观点赞同或支持。如需转载,请注明文章来源。
1

发表评论