项目需求分析报告怎么写（一次To B 项目的需求分析总结）

首先，什么是需求分析？

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

需求分析要解答的问题是：

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

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

第二个问题：谁去做需求分析？

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

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

第三个问题是，需求分析怎么做？

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

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

第一步：在初步获得需求信息后，先了解背后的故事

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

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

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

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

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

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

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

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

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

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

把需求目的量化有几个好处：

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

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

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