一次To B 项目的需求分析总结

来源: | 浏览量:27 次 | 发布时间:2019-02-28 23:24

最近巧合之下需要整理之前ToB项目资料,所以今天也顺带和大家分享一些自己之前在做ToB项目过程当中关于需求分析总结或经验。

首先,什么是需求分析?

可能有人认为需求分析其实就是和客户问一些问题,了解一下情况,然后就可以开始设计产品方案了。额,这样理解也对,但可能并不全面。这里要抛出我这边文章第一个核心点:需求分析和产品设计是两个相互独立部分。

需求分析要解答问题是:

哪些地方要做?哪些地方不需要做? 这个问题到底值不值得做? 怎样去衡量做得成不成功?

而在个人经历中,有过在需求调研阶段发现需求不值得投入而被毙掉情况。因此,产品设计,则是在确定在上述三个问题后再去构思该用何种方式去达到上述成功标准。这个是考验产品经理能力体现。

第二个问题:谁去做需求分析?

对产品经理而言,需求分析只是最基础一项技能。但在某一些提供技术解决方案公司,会由项目经理承担这样工作,在某些细化领域,则会有专门需求分析师负责,例如数据需求分析师,算法需求分析师,安全需求分析师等等。

另外补充个题外话,商业需求分析师也是有专门考试(有兴趣童鞋可以百度一下PMI-PMB)。

第三个问题是,需求分析怎么做?

其实不同公司也会有不同做法,在这里我会分享一下之前我经历过一个项目里面需求分析经过。这个项目背景是一个跨国银行项目,我负责该银行某个地区转账流程优化,不过由于保密原因,我不会在这里透露过多项目信息,同时由于这个项目范围和复杂程度较高。

所以在这个需求调研过程其实是由两个团队负责,我整合了两边资料,希望能够尽量地给大家呈现出一个需求调研完整过程,欢迎有其他想法小伙伴一起交流。

第一步:在初步获得需求信息后,先了解背后故事

在获取到初步需求信息后,了解一下对方组织架构和动态,这样你可以知道这个需求到底怎么来,他们对实现这个需求动力和动机是什么?是否强烈?需求是由谁来拍板?你最终要汇报由是谁?会不会涉及到其他部门等等组织内部关系?

在开始正式进场之前,先把关系理清楚。毕竟需求分析,说白了也是和人在打交道。

第二步:为需求确定一个大概范围

在理清好组织内部关系后,我们就开始着手处理需求了,我们要为这个需求划定一个“大概”范围,其中包括几点:

这个需求涉及到业务范围有哪些? 这个需求涉及到部门和相关人员有哪些?

在我个人经历当中,作为乙方,很多需求是来源于甲方商务人员,有时候甚至是直接面对着公司COO或者是CTO,他们会更偏向于业务角度或者公司全局角度去思考,但是对于需求落地或许有些偏差。因此,去寻找更合适人去了解资讯会更能提高效率。

第三步:把需求翻译成数据指标

在对需求有了一个初步了解后,我们需要根据这个目去进行量化,一般企业内部优化项目会集中体现在效率提高以及成本降低。在我们这个项目背景中,我们使用人力成本降低作为我们数据标准,其公式为:

人力成本=各职能人员单位时间成本*用在该流程总时间数

在这里稍微展开一下说明,有客户他们未必会愿意给你透露如此敏感数据,但对于产品团队内部一定要有一个量化意识。

把需求目量化有几个好处:

量化了目标可以让你知道有哪些维度是需要注意; 当你给用户提供不同产品方案时,可以通过计算不同产品Payback time来看这个方案到底值不值得做(Payback time会在后面解释,当然,如果你只有一种产品方案那当我没说); 在确定产品方案后,通过量化你可以观察是否达到预期效果。

另外笔者在之前经历中看到一个有趣现象,那就是要不要告诉客户我们所用数据指标是什么?

个人认为,当你产品体系已经成熟时,其实可以考虑给客户进行一个潜移默化教育,让彼此都有一个共同评判标准之下,不容易被客户把方向带偏。而如果是你产品还没有成熟时,那最好先在内部进行打磨和验证,不然就可能自己砸自己了。

第四步:制定一个需求调研时间表

需求调研时间表其实是一个相当重要工具,经过了第二步对需求范围大概了解后,我们需要明确到每一天和哪一个人去见面?见面方式是怎样?希望能够达到效果是怎样?整体时间安排是怎样?并且对时间进度进行每日盘点和总结。

在需求调研执行过程中沟通成本往往很大且容易被忽略,因此,我们会事先做出一个调研时间表和客户那边进行沟通,并且在内部进行一个时间监控机制,不断总结经验提升效率。

第五步:需求拆解,从了解现状开始

无论是新业务产生还是就业务优化,都是依靠现有流程为基础,新功能出现,对于ToB而言,往往会伴随着职能甚至是组织变化。如果说第二步只是了解需求范围大概,那么到了这里,就是到了真正开始落地地方。

首先我们要了解这个需求涉及到具体业务是什么?

每个具体业务里面又包含了哪些细分种类,通常我会要求客户提供一下他们关于这些种类资料。如果客户对这些资讯有所顾忌不愿提供,或者根据我们自身行业知识和理解,对业务类型进行划分并给到客户确认,并对每个业务中各个流程进行穷尽记录和描述。

然后,把这些众多种类业务中挑选出核心业务,这时候还有一个很重要工作,就是知道有哪些需求我们不做?以及有一些地方我们一定不能做?

最后,把核心业务流程图描绘出来(我通常会用泳道图),包括中间涉及到部门人员,每一个步骤操作详细,权限和角色设置等等。完成这些之后,就可以开始构思解决方案切入点了。

第六步:尽可能地提出多种解决方案

在了解完现状和切入点之后,我们开始进行一个解决方案设计,如果你团队在之前并没有一个成熟产品,基本上从0开始话,那么我会比较建议你去构思设计至少三套以上产品方案,这样会让你对这个业务有更快地了解,而且最好发动你团队和你一起构思,这样大家能够一起学习,并且提高学习速度。

在找出集中解决方法后要找出他们优劣点,并且尝试计算出他们Payback time,Payback time即回本时间,在我之前项目是这样计算

Payback time=开发成本/(现阶段人力成本-系统运行后人力成本+维持系统运行额外成本)

通过计算这个时间长度,我们也可以用于评估哪个方案更值得去做。

如果你团队有一个成熟产品,但可能只会提供一种产品解决方案,那么你和你团队需要清晰现有这个产品它产品边界和代价是什么?任何产品都会有边界和代价,要留意现在产品是不是说真符合客户需求动机。

复盘

无论是项目成功与否,在一个阶段之后一定要在团队内部进行一次复盘,同时复盘所希望能够达到一定要心理有数,而且有理有据,能够用数据说话。注意复盘不是问责,而是团队之间直接沟通和学习过程,在我经历过项目复盘中,我们会围绕以下几个目去进行复盘:

(1)检查内部效率

我们也会为我们内部工作流程分解几个步骤,然后记录每个步骤所用时间,在复盘时候会观察哪个环节用时最多,加班最多,然后分析原因和优化方法

(2)检查产出质量

这个主要是从最后结果数据效果和期望之间差距有多大,主要是检查在当初设计产品时候是否有遗漏,推导产品结论所用模型是否还未完善。

(3)知识分享

我们会分享一些关于竞品或者是同行资讯研究,也有一些同行会把翻盘中间加上一些读书会分享,但无论如何,其目也是为了提醒团队不能仅仅顾着眼前事情,也要留意外界事物。

最后,不要忘了把每次项目文档进行检查和归类,作为团队知识库进行储存,这也是提升团队效率重要工具之一。

在文章最后,我们重温一下这篇文章几个重点:

需求分析和产品设计是两个相互独立部分,需要在需求调研阶段去判断这个产品是否值得去做; 在接触需求后先了解背后故事和动机; 为需求确定大概范围,找到合适人去了解正确信息; 量化你需求目以及评判标准; 制定需求调研阶段时间表,把准备工作做好,工欲善其事必先利其器; 需求拆分,了解需求中包含每一个具体业务和流程,找出核心点,并且文档化,同时要明确哪些不做,哪些禁止做; 尝试寻找多种解决方案,并通过计算Payback time评估哪种方案更合适,对于某些已经成熟产品则需要分析产品界限,以检查是否满足需要背后动机; 每隔一段时间进行内部复盘,不断提升效率同时做好内部知识管理。

 

作者:Leo,一个喜欢研究产品汪,一个新晋猫奴,在创业公司待过,也在500强外资咨询公司待过,我相信人一生应该是为了做成某一件事而活,希望可以结识更多同样喜欢产品这条路朋友。

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

题图来自Unsplash,基于CC0协议



本文永久链接:http://www.sh-zt.com/h/p/620705.shtml

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;
2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;
3.作者投稿可能会经我们编辑修改或补充。