最近巧合之下需要整理之前ToB项目的资料，所以今天也顺带和大家分享一些的自己之前在做ToB项目过程当中关于需求分析总结或经验。
首先，什么是需求分析？
可能有人认为需求分析其实就是和客户问一些问题，了解一下情况，然后就可以开始设计产品方案了。额，这样理解也对，但可能并不全面。这里要抛出我这边文章的第一个核心点：需求分析和产品设计是两个相互独立的部分。
需求分析要解答的问题是：
哪些地方要做？哪些地方不需要做？
这个问题到底值不值得做？
怎样去衡量做得成不成功？
而在个人的经历中，有过在需求调研阶段发现需求不值得投入而被毙掉的情况。因此，产品设计，则是在确定在上述三个问题后再去构思该用何种方式去达到上述的成功标准。这个是考验产品经理的能力的体现。
第二个问题：谁去做需求分析？
对产品经理而言，需求分析只是最基础的一项技能。但在某一些提供技术解决方案的公司，会由项目经理承担这样的工作，在某些细化的领域，则会有专门的需求分析师负责，例如数据需求分析师，算法需求分析师，安全需求分析师等等。
另外补充个题外话，商业需求分析师也是有专门的考试的（有兴趣的童鞋可以百度一下PMI-PMB）。
第三个问题是，需求分析怎么做？
其实不同的公司也会有不同的做法，在这里我会分享一下之前我经历过的一个项目里面的需求分析经过。这个项目的背景是一个跨国银行的项目，我负责该银行某个地区的转账流程优化，不过由于保密原因，我不会在这里透露过多的项目信息，同时由于这个项目的范围和复杂程度较高。
所以在这个需求调研过程其实是由两个团队负责，我整合了两边的资料，希望能够尽量地给大家呈现出一个需求调研的完整过程，欢迎有其他想法的小伙伴一起交流。
第一步：在初步获得需求信息后，先了解背后的故事
在获取到初步的需求信息后，了解一下对方的组织架构和动态，这样你可以知道这个需求到底怎么来的，他们对实现这个需求的动力和动机是什么？是否强烈？需求是由谁来拍板？你最终要汇报的由是谁？会不会涉及到其他部门等等的组织内部关系？
在开始正式进场之前，先把关系理清楚。毕竟需求分析，说白了也是和人在打交道。
第二步：为需求确定一个大概范围
在理清好组织内部关系后，我们就开始着手处理需求了，我们要为这个需求划定一个“大概”的范围，其中包括几点：
这个需求涉及到的业务范围有哪些？
这个需求涉及到的部门和相关人员有哪些？
在我个人的经历当中，作为乙方，很多的需求是来源于甲方的商务人员，有时候甚至是直接面对着公司的COO或者是CTO，他们会更偏向于业务的角度或者公司全局的角度去思考，但是对于需求的落地或许有些偏差。因此，去寻找更合适的人去了解资讯会更能提高效率。
第三步：把需求翻译成数据指标
在对需求的目的有了一个初步的了解后，我们需要根据这个目的去进行量化，一般企业的内部优化项目会集中体现在效率的提高以及成本的降低。在我们这个项目的背景中，我们使用人力成本的降低作为我们的数据标准，其公式为：
人力成本=各职能人员单位时间成本*用在该流程的总时间数
在这里稍微展开一下说明，有的客户他们未必会愿意给你透露如此敏感的数据，但对于产品团队内部一定要有一个量化的意识。
把需求目的量化有几个好处：
量化了目标可以让你知道有哪些维度是需要注意；
当你给用户提供不同的产品方案时，可以通过计算不同产品的Payback time来看这个方案到底值不值得做（Payback time的会在后面解释，当然，如果你只有一种产品方案那当我没说）；
在确定产品方案后，通过量化你可以观察是否达到预期效果。
另外笔者在之前的经历中看到一个有趣的现象，那就是要不要告诉客户我们所用的数据指标是什么？
个人认为，当你的产品体系已经成熟时，其实可以考虑给客户进行一个潜移默化的教育，让彼此都有一个共同的评判标准之下，不容易被客户把方向带偏。而如果是你的产品还没有成熟时，那最好先在内部进行打磨和验证，不然就可能自己砸自己了。
第四步：制定一个需求调研的时间表
需求调研时间表其实是一个相当重要的工具，经过了第二步的对需求范围的大概了解后，我们需要明确到每一天和哪一个人去见面？见面的方式是怎样？希望能够达到的效果是怎样？整体的时间安排是怎样？并且对时间进度进行每日的盘点和总结。
在需求调研执行过程中的沟通成本往往很大且容易被忽略，因此，我们会事先做出一个调研时间表和客户那边进行沟通，并且在内部进行一个时间监控机制，不断总结经验提升效率。
第五步：需求拆解，从了解现状开始
无论是新业务的产生还是就业务的优化，都是依靠现有的流程为基础，新功能的出现，对于ToB而言，往往会伴随着职能甚至是组织的变化。如果说第二步只是了解需求范围的大概，那么到了这里，就是到了真正开始落地的地方。
首先我们要了解这个需求涉及到的具体业务是什么？
每个具体业务里面又包含了哪些细分的种类，通常我会要求客户提供一下他们关于这些种类的资料。如果客户对这些资讯有所顾忌不愿提供，或者根据我们自身的行业知识和理解，对业务类型进行划分并给到客户确认，并对每个业务中的各个流程进行穷尽记录和描述。
然后，把这些众多的种类的业务中挑选出核心业务，这时候还有一个很重要的工作，就是知道有哪些需求我们不做？以及有一些地方我们一定不能做？
最后，把核心业务的流程图描绘出来（我通常会用泳道图），包括中间涉及到的部门人员，每一个步骤的操作详细，权限和角色设置等等。完成这些之后，就可以开始构思解决方案的切入点了。
第六步：尽可能地提出多种解决方案
在了解完现状和切入点之后，我们开始进行一个解决方案的设计，如果你的团队在之前并没有一个成熟的产品，基本上从0开始的话，那么我会比较建议你去构思的设计至少三套以上的产品方案，这样会让你对这个业务有更快地了解，而且最好发动你的团队和你一起构思，这样大家能够一起学习，并且提高学习速度。
在找出集中解决方法后要找出他们的优劣点，并且尝试计算出他们的Payback time，Payback time即回本时间，在我之前的项目是这样计算的：
Payback time=开发成本/(现阶段人力成本-系统运行后人力成本+维持系统运行的额外成本)
通过计算这个时间长度，我们也可以用于评估哪个方案更值得去做。
如果你的团队有一个成熟产品，但可能只会提供一种产品的解决方案，那么你和你的团队需要清晰现有的这个产品它的产品边界和代价是什么？任何的产品都会有边界和代价，要留意现在的产品是不是说真的符合客户需求的动机。
复盘
无论是项目成功与否，在一个阶段之后一定要在团队内部进行一次复盘，同时复盘所希望能够达到的目的一定要心理有数，而且有理有据，能够用数据说话。注意复盘不是问责，而是团队之间直接沟通和学习的过程，在我经历过的项目复盘中，我们会围绕以下几个目的去进行复盘：
（1）检查内部的效率
我们也会为我们的内部工作流程分解几个步骤，然后记录每个步骤的所用的时间，在复盘的时候会观察哪个环节用时最多，加班最多，然后分析原因和优化的方法
（2）检查产出的质量
这个主要是从最后的结果数据效果和期望之间的差距有多大，主要是检查在当初设计产品时候是否有遗漏，推导产品结论所用的模型是否还未完善。
（3）知识分享
我们会分享一些关于竞品或者是同行的资讯研究，也有一些同行的会把翻盘中间加上一些读书会的分享，但无论如何，其目的也是为了提醒团队不能仅仅顾着眼前事情，也要留意外界的事物。
最后，不要忘了把每次项目的文档进行检查和归类，作为团队的知识库进行储存，这也是提升团队效率的重要工具之一。
在文章的最后，我们重温一下这篇文章的几个重点：
需求分析和产品设计是两个相互独立的部分，需要在需求调研阶段去判断这个产品是否值得去做；
在接触需求后先了解背后的故事和动机；
为需求确定大概的范围，找到合适的人去了解正确的信息；
量化你的需求目的以及评判标准；
制定需求调研阶段的时间表，把准备工作做好，工欲善其事必先利其器；
需求拆分，了解需求中包含的每一个具体业务和流程，找出核心点，并且文档化，同时要明确哪些不做，哪些禁止做；
尝试寻找多种解决方案，并通过计算Payback time评估哪种方案更合适，对于某些已经成熟的产品则需要分析产品界限，以检查是否满足需要背后的动机；
每隔一段时间进行内部复盘，不断提升效率同时做好内部的知识管理。
