在上两篇文章中，笔者就用户调研和竞品分析这两个方面提出了自己的一些见解。接下来，就要到产品分析部分了，而需求分析将会是第一步，接下来让我们看看笔者怎么说的吧：
在各大PM论坛里，C端产品的需求分析指导文章已经很常见了，而B端产品的需求分析也有很多大牛提出了自己有针对性的见解。那么在本文中，笔者结合自己实际的工作经历，分享一下在B端产品设计前期的需求分析方面所收获的经验，以供大家共同学习交流。由于专业及领域限制，难免存在偏差或谬误的地方，还请各位前辈指点一二，笔者感激不尽。
笔者将从三个步骤展开需求分析的相关论述，其分别为需求收集、需求整理、需求转化。
一、需求收集
要想设计一款优秀的B端产品，首先就要广泛的收集需求。B端产品的需求来源要比C端产品的需求来源广泛，简要来说大概有以下几个方面：
针对上述几个方面，简要介绍一下每个需求来源方的情况：
客户：这里主要是通过调研客户时收集需求，包括To B角色链中的决策者、运维人员、最终用户。至于如何有效地调研客户，可以参考笔者的上一篇文章《B端产品经理进行客户调研的三个阶段》。
公司内部：公司内部的来源主要有三个方面：一是与其他产品线合作的需求；二是产品线内其他同事，例如运营、技术服务、定制组等同事提出的需求；三是公司内部对于产品本身合规性的需求，例如软件销售许可证、软件著作权所需要的一些需求点。
PM本身：这里主要是PM自己通过竞品分析或者YY出来的一些需求。
技术突破：这是一个值得关注的点，相对于C端产品来说，行业内技术突破往往会在一定程度上影响B端产品的发展方向。举个例子：笔者曾从事企业数据安全行业，随着中国大陆HTTPS加密技术的普及，越来越多的网站及应用开始使用HTTPS加密自己的流量；那么笔者在设计数据安全产品时，首要考虑的需求就是如何解密HTTPS流量，如果流量无法解密，那么企业数据安全也就无从谈起。
外部环境：这里主要是关注国家政策、法律法规的变化，有时候新的法律法规或政策能催生出一个全新的行业。
老大/老板：这个就不说了，都是PM，大家心里都懂。
好了，我们在通过多方渠道将需求收集完毕后，面对一大堆需求，你肯定会感到头疼，别急，下一步要做的事就是将它们进行整理。
二、需求整理
对于需求整理来说，核心就是要从一大堆需求里挑出该做的需求，然后把这些需求按照优先级进行排列。
关于优先级，笔者有一点想法，曾经在一位前辈的文章中看到一个排优先级的做法，即将需求按照百分制进行打分，分数高的优先级就高，后来试行了这一做法，发现被开发同事拿刀追着砍。后来跪地求饶才知道，对于开发同事而言，无论一个需求的优先级高还是低，最终都是要做的。既然都要做，又何来分数高低一言。因此，笔者之后在排需求优先级的时候，都只是排出了每个需求的最晚完成的迭代版本，而不分一个迭代版本里需求的优先级高低。
当然，不同企业有不同企业的做法，各位PM还是按照自己与开发同事最舒服的相处模式进行即可。
回到文章，我们在收集了一堆需求后，如何从一大堆需求里挑出该做的需求呢？
笔者有如下几点建议：
1. 基于业务场景进行整理
B端产品就关键就在于解决业务场景中遇到的问题。那么，我们可以基于真实的业务场景流程，梳理我们所收集的需求。
举个例子：笔者设计的产品为企业数据安全，那么其针对的最典型的场景就是数据泄密。基于数据泄密的场景，我们可以梳理出在【泄密监控】-【关键数据外发】-【泄密检测】-【泄密告警】-【泄密举证】-【线下处置反馈】-【持续泄密监控】这一泄密流程中所需要的一切功能和需求点，进而整理出该做的需求。
2. 基于决策链进行整理
前面几篇文章也有提到，B端产品的决策链冗长而又复杂。我们在整理需求时，也可以从Key Person的角度出发，去整理一些针对决策链中关键人物的需求。
举个例子：还是企业数据安全产品，这款产品在企业中涉及到的关键人物如下图：
基于这些关键的决策人物，我们就可以去整理产品的需求，例如：针对CTO，我们的产品所使用的技术一定要够前沿，如使用神经网络分析等等；针对IT运维主管，产品的部署和实施要尽可能简单，最好能旁路部署等等。
3. 基于紧急程度进行整理
这里可以采用大名鼎鼎的四象限法则进行整理，举例如下：
（皮一下不要当真）
4. 基于整体性进行整理
基于整体性进行整理的意思是，我们在整理需求的时候，既要能够看到产品的细节，也要能够看到产品的宏观。你可以想象成随时放大/缩小一款产品，这样就不会被局限在某个小细节或者小需求中，能够跟全面地去考虑多个需求之间的关联性。
基于上述四点建议，我们挑选出了一堆需求并确认了其优先级。那么，接下来我们可以将它放到一个需求矩阵中去。需求矩阵的内容包括如下：
其中，有几点需要说明：
需求受益人指的是此需求实现后，最终落实在产品交付层面上的受益人。例如：采用了机器学习技术，那么这里的受益人就是CTO（技术把关者）；采用了旁路部署模式，那么这里的受益人就是运维人员（降低工作量）。
需求实现复杂度和人力估算，最好找个时间和开发经理坐下来，互相沟通一起评估，避免由于对技术不了解而随意评估导致被砍。
变更说明一般在需求变更后，要详细的填写变更原因和直接变更人，避免背锅。
最后还有一点，相信每一位B端产品经理在职业生涯中都会遇到一个永远绕不开的问题——定制化。如何找到产品标准化与定制化之间的平衡——有哪些需求在整理时可以放弃，转而采用定制的方式解决；而又有哪些定制的需求，可以合入通用版本，以降低定制工作量。
这里面有很多坑，而这些坑笔者都踩过，真的是一个都没有落下。后续笔者会单独写一篇文章与各位分享其中的辛酸苦辣，各位可以提前准备好瓜子小板凳。
三、需求转化
在整理好需求矩阵后，我们就可以开始着手需求的转化工作了，说白了就是写文档、画原型。其中需要注意的是，与C端PM所需要编写的PRD不同，在笔者曾就职的企业中，B端PM需要编写两份文档，一份是用户场景需求文档，一份是系统需求文档。
用户场景需求文档，顾名思义，就是基于用户真实的使用场景去编写一份文档。文档的基本编写逻辑如下：
【什么业务场景】-【什么问题】-【客户有什么需求】-【期望操作步骤】
需要注意的是，在编写用户场景需求文档是，要将所有的需求点都纳入进来，而不是只写某一个迭代版本中的需求。对于B端产品来说，这一份文档是最重要的，能不能发掘客户真实的业务需求就看这一份文档写得全不全，有没有写透彻。
因此，在用户场景需求文档编写完成后，需要召集市场、运营、开发同事进行一次需求文档评审会议。怎么开会估计各位PM比我还懂，此处略去会议过程，但是有一点要注意，在用户场景需求文档的评审会议中，要尽可能地避免讨论技术实现的问题。
评审通过后，就可以拿着需求矩阵和用户场景需求文档去找交互设计师了。一般来说，在B端产品企业里，PM都不需要自己动手画原型。所以笔者也只是负责跟交互设计师对接需求即可，专业的事还是交给专业的人靠谱。
在交互设计师给出基础的交互设计图之后，需要组织产品组内同事对交互设计图进行一次评审，评审主要是为了检查产品在交互设计中用户的业务场景流程完不完整，是否存在逻辑不合理的问题。通过后，便可以不断完善交互图中的功能细节。
待交互设计图完善后，还需要写一份系统需求文档。这里就和各位C端PM们的PRD工作差不多了，基于交互图，指出某个功能在某个场景下的操作步骤及结果。但是需要注意的是，系统需求文档中也需要给出一些基本的技术参数，例如查询功能的响应时间要求、底层架构稳定性要求等等，这些参数要尽可能量化，如果不好确定，可以与开发经理一同确认。
最终，需求转化后的结果就是两份文档+一份交互设计图。此时，需要在正式开发前，组织一次外部评审，邀请其他产品线的同事，最后检验一次产品的所有设计细节，当然，这里面也会有很多坑，例如会涉及到需求变更、技术实现难度等等。后续，笔者会单独出一篇文章，讲一讲在B端PM在各类评审会议中遇到的坑。
至此，一次需求分析的过程结束。由于篇幅原因，其中很多细节并未详细描述，例如：交互设计、需求变更、评审等。
正常来说，一次B端产品的需求分析少则数周，多则数月。在其中，你可能会无数次推翻你曾确信的需求，你也可能会改无数次文档，甚至连交互设计小姐姐都改图改到不想再改了。你可能会很痛苦，团队也会很痛苦，但要相信，当你经历过痛苦后，看到自己心心念念的产品一点一点被打磨出来，又被成千上万家企业所使用后，这种成就感是无与伦比的。那一刻，你会觉得这一切都值得。所以，保持强大的内心，才能坚定的走在To B的道路上。
B端产品不易，且行且珍惜。
