B端需求调研方法论--调研中

整体方法

三字诀

永恒的三字诀–问听记。

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

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

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

5W1H分析法

这个是很成熟的方法不做展开,简介如下:

img

需求调研过程中,往往会出现甲方问诸如“列表页面,要有标签或Icon区分出来XX信息”这种问题。这其实是跨阶段了,需求调研阶段要解决的是业务是什么,为什么这么做,怎么协作完成。怎么设计UI页面,那是后面原型验证&解决方案阶段的事情。

遇到这种情况,调研人员不能简单考虑可行性,要先内心自问:

  • 为什么要区分?

  • 不区分有什么影响吗?

  • 为什么在这里区分?

  • 是不是可以在其他地方区分?

如果自己无法回答,要问清楚为止,再给出自己的方案进行协商。如果可以回答,倒是可以简单的说“OK,这个我们到时候会有的”。

业务捕获

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

组织架构

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

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

img

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

img

业务架构

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

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

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

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

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

业务实务

岗责清单,会细分为岗责清单和业务表单。

岗责清单,即每个岗位的职责,注意事项如下:

  • 岗位的具体职责

  • 什么时候履行职责,是事件触发,还是时间触发(如月底做报表)

  • 工作的要求,时间节点限制、质量要求

  • 工作成果如何提交,是否有工作报告,有没有统计诉求

  • 经手哪些数据

  • 向哪些对象汇报,这涉及到数据、流程

业务表单,即实际业务发生中录入信息or统计信息。需要注意以下几点:

  • 编号

  • 分类(归档的,审批流转的,自动产生的,创建的)

  • 旧数据如何处理(同比环比的问题)

  • 具体字段和内容

  • 涉及的流程(多节点流转的审批流?还是单步审批)

  • 节假日处理

  • 请假的处理(替班?)

  • 业务周期(晚上繁忙?)

  • 统计周期(日报表、周报表、月报表)

技术捕获

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

遗留系统方面,注意以下三点:

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

外部系统方面,注意以下4点:

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

剩下的是一些非功能性需求,一般有:

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

调研汇报

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

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

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

img


  目录