如何完成B端产品的需求分析？

在各大论坛里，C端产品的需求分析指导文章已经很常见了，而B端产品的需求分析也有很多人提出了自己有针对性的见解，我们今天从三个步骤展开需求分析的相关论述，其分别为需求收集、需求整理、需求转化。

一、需求收集

想设计一款优秀的B端产品，首先就要广泛的收集需求。B端产品的需求来源要比C端产品的需求来源广泛，简要来说大概有以下几个方面：

针对上述几个方面，简要介绍一下每个需求来源方的情况：

客户：这里主要是通过调研客户时收集需求，包括To B角色链中的决策者、运维人员、最终用户。

公司内部：公司内部的来源主要有三个方面，一是与其他产品线合作的需求，二是产品线内其他同事，三是公司内部对于产品本身合规性的需求。

PM本身：这里主要是PM自己通过竞品分析或者YY出来的一些需求。
技术突破：相对于C端产品来说，行业内技术突破往往会在一定程度上影响B端产品的发展方向。
外部环境：这里主要是关注国家政策、法律法规的变化，有时候新的法律法规或政策能催生出一个全新的行业。
老大/老板：这个就不说了，都是PM，懂的都懂。

二、需求整理

对于需求整理来说，核心就是要从一大堆需求里挑出该做的需求，然后把这些需求按照优先级进行排列。关于优先级，不同企业有不同企业的做法，各位PM还是按照自己与开发同事最舒服的相处模式进行即可。

1. 基于业务场景进行整理

B端产品就关键就在于解决业务场景中遇到的问题。那么，我们可以基于真实的业务场景流程，梳理我们所收集的需求。

2. 基于决策链进行整理

我们在整理需求时，也可以从关键人物角度出发，去整理一些针对决策链中关键人物的需求。基于这些关键的决策人物，我们就可以去整理产品的需求，

3. 基于紧急程度进行整理

这里可以采用大名鼎鼎的四象限法则进行整理，举例如下：

4. 基于整体性进行整理

我们在整理需求的时候，既要能够看到产品的细节，也要能够看到产品的宏观。

其中，有几点需要说明：

1. 需求受益人指的是此需求实现后，最终落实在产品交付层面上的受益人。

2. 需求实现复杂度和人力估算，最好找个时间和开发经理坐下来，互相沟通评估，避免由于对技术不了解而随意评估导致被砍。

3. 变更说明一般在需求变更后，要详细的填写变更原因和直接变更人，避免背锅。

三、需求转化

用户场景需求文档，就是基于用户真实的使用场景去编写一份文档，基本编写逻辑如下：

【什么业务场景】-【什么问题】-【客户有什么需求】-【期望操作步骤】

在编写用户场景需求文档时，要将所有的需求点纳入，对于B端产品来说，最重要的是文档全面与否。

正常来讲，一次B端产品的需求分析少则数周，多则数月。在其中，你可能会无数次推翻你曾确信的需求，也可能会改无数次文档，甚至连交互设计小姐姐都改图改到不想再改了。你可能会很痛苦，团队也会很痛苦，但要相信，当你经历过痛苦后，看到自己心心念念的产品一点一点被打磨出来，又被成千上万家企业所使用，那种成就感是无与伦比的。