需求分析是层层递进的关系：过滤原始需求、舍弃无用需求、最后整合分类，确定需求优先级。

各位产品经理，时间已经来到2020年，今年突如其来的黑天鹅的打得人类措手不及，任何事情都不确定，未来的环境唯一不变的就是变化。我想唯一可以做的就是不断总结和积累，增加自己唯一握在手上可以确定的部分，在做产品经理的这两年，经常面对需求分析，也经常翻看各大博主的需求分析策略。本文将结合实际工作的经验，试图总结出一套完整的2B需求分析思路和方法，希望给看到这篇文章的产品经理带来一些启发，在需求的不确定中获得确定。

一、需求获取

要分析需求，首要要弄清楚需求的来源，也就是你的需求从哪里来？

1. 获取方式

总的来说获取需求的方式有两种：

1. 主动获取（1、市场环境整体调研；2、竞品分析3、问卷调研）
2. 被动接受，对于被动接受的需求，往往是     用户直接提出的需求，通过意见反馈渠道或主动联系产品沟通。

原则：明确目的采取不同的获取需求方式

在实际过程中采用哪种方式来获取需求？往往跟我们本身想要达到什么目的有关，时刻牢记一切从目的出发，当然获取需求的方式不是3选1，也不是2选1，可以结合。

一般来说本身产品的迭代规划往往采用竞品调研分析、问卷调研的方式。产品的原始规划往往采用市场环境调研、同类产品调研的方式在在每一项的具体方式中，根据自身的目的，调研的具体方式也不尽相同：拿问卷访谈来说，明确此次调研主要是为了产品优化的体验项，那么你设计的调研问卷更偏向于体验的问题，对象也更多是实际操作者，如果此次调研的目的是为了整个产品的二次功能迭代，那么调研问卷更倾向于产品功能的延展或改善上的问题（一个原则“问卷调研更多的是调研”，所以在设计问卷的问题更多的是开放和引发思考的问题）

2. 明确调研对象

原则：穷尽你的调研对象—针对主动调研的方式

B端产品的访谈对象不同于C端，B端涉及到的用户角色代表不一样，同一套产品一般不止一个角色使用，他们有可能往往包含着矛盾的需求，为了使需求更全面更合理，那么根据调研的目的要尽可能的选择包含相关所有的对象。

3. 明确需求

原则：多问为什么

无论是被动获取还是主动获取，在面对所有的需求时，都需要问自己或者问你的对象“为什么“，据说有一个产品经理思考问题的法则，就是无论任何事情，都连问6个为什么，要多问为什么？直到说清楚原因、讲清楚逻辑，搞清楚环境、搞清楚原因的过程。

二、需求分析

当我们获得了这些需求后，是不是马上就开干了？答案当然是否定的，从产品经理视角看用户：用户不是自然人，而是用户背后的需求合集，这有两层意思：1是产品经理的最终对象是需求，2是需求的承载是人，它们具有异质性（特点千差万别）、情境性（用户的行为和反应会受情境影响）、可塑性（用户的偏好和认知会随着外界不同信息刺激发生变化和演化）、自利性（用户追求个人总效用最大化）、有限理性（用户虽追求理性，但能力是有限的），这就意味着，我们还要从已经获得的原始需求里抽象分析、梳理整合出真正需要满足的需求，然后找到产品可以做的地方，这才构成了我们作为产品经理和产品设计者的核心价值。

那么如何去做需求分析？需求的分析也是层层递进的关系。

1. 需求过滤

面对原始需求，哪些才是我们需要去解决的，哪些不需要？ 而最终留下来的需求才是我们要去解决的需求。

需要解决的问题：需求要最终解决的是什么样的问题？需求是正确的吗？需求是真实的吗？需求可以解决吗？需求值得解决吗？这几个问题层层递进，弄清楚这几个问题，基本上我们的需求就能决定其去留了。

需求最终解决什么样的问题？–需求定义

未经过训练的人都不是抽象问题的专家，所以在提出他们的需求的时候，往往直接说出感受，或者给出解决方案。

如：小A对于听歌软件使用体验感不好，提出了颜色不好看，这个地方字太小了，听不到我想听的歌，能不能把这个地方的颜色换成蓝色呢？这往往是用户直接表达的需求和使用体验，这时候如果刻意做抽象，才能意识到用户会在说布局不符合使用习惯；在用户搜索要听的歌时，连续翻了好几页都找不到，因此前几页的关键字匹配代表能否更快速的找到结果，所以产品要解决的是用户关键字快速匹配的问题。

再举个例子：小B提出每次做采购单都必须要有商品的编码，太麻烦了，没有编码就要去找数据中心的人维护，能不能不要这个编码？直接填说明？从表面上来看小B是想要解决商品编码的问题，而实际上呢？经过询问你会发现要解决小B的问题其实是维护流程繁琐或编码缺失的问题。而不是商品有没有编码的问题。

大多数人的需求和“要解决的问题”都是需要抽象和梳理的，所以我们要将用户提出的需求，进行抽象。

另一个经典的例子就是：用户说我需要一匹马，经过分析抽象才知道用户需求的不是一匹马，而是一个能快速到达目的地的工具。

2. 需求舍弃

在明确定义需求需要解决的问题了，接下来我们要思考的是需求是真实的吗？需求是正确的吗？也就是说有没有“价值风险”需不需要去解决。我们可以试着从以下几个方向去思考：

（1）需求是否存在矛盾？

A要解决的问题和其相关的角色需求或现状是否有冲突：这很重要，尤其是对于B端的需求来说，我们前面提到产品经理面对的需求往往是个人赋予在当前角色和环境下提出来的，人提出的需求都是利己的。比如：以刚刚小A提出这个按钮放在这里太不方便了。那么我们抽象出来是要解决的小A的问题是布局问题，在经过分析小A是个左撇子，所以他这样提，那么他的需求就和普通的一般人的需求是矛盾的，此时就应该平衡价值，是否应该舍弃掉这样的需求。往往B端的产品需求会存在，角色于相关觉得之间的矛盾，与上级需求的矛盾，与整体公司管理需求的矛盾，与商业诉求的矛盾针对矛盾的需求，要理清矛盾关系，分清价值，大胆舍弃。

（2）需求是否只是解决了当时问题？

就是「产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求」的状况，此类需求是否需要我们花力气花成本去满足？还是是否可以需要用户麻烦一点。分清需求的长期价值，大胆舍弃。

（3）是否带来了真实的价值？

有些需求可能是我们创造出来的需求，来源于我们自身认识的不足，比如我们认为用户一条条删除会很麻烦，想做一个批量删除的功能改善一下，但实际上用户批量删除更容易导致错误删除，而删除的情况并不多，所以此类需求就是我们人为创造的需求。充分认识需求是否真实带来了价值，大胆舍弃创造出来的不能带来真实价值的需求。

（4）从需求的成本和价值检视需求

此时需要考虑两个问题：

1. 当前是真实的需求也能带来价值且长期带来价值，但手边并没有解决问题的技术，或技术尚未成熟，就是「我们知道要做什么产品，但是做不出来」的状况，此类需求也只能暂时舍弃
2. 投入的成本是否大大超过带来的价值：需求不是无边界的，满足超过一定边界，边际收益会骤降。绝大多数情况下，超过这个满意的边界，用户的满意度不会一点儿都不变，但变化程度会非常小。因此我们要关注这个边界并且定义这个边界。

3. 需求整理

（1）需求聚合

对于2B的需求往往都是以业务为导向的，着手去解决分散的需求，往往容易陷入点状里面，此时需要以业务为导向指引将零散的需求串联起来，形成一个完整，内容清晰的框架，以免落入拼命应付解决问题的境地。

找出哪些需求是哪些业务，并将其划分不同的板块，例如有些是采购申请的需求，有些事采购单的需求，他们又都属于采购需求。其中需求1，2都归属哪条业务线上。

（2）需求分类

问题不分大小，不分场景，只要是需要解决的问题，都是需求，而需求扽分类有助于我们分清需求的优先级，一般我会将需求分为：功能性需求、体验性需求、二级分类是新增还是优化；他们的重要关系一般是：功能新增>功能优化>体验优化

（3）需求优先级

在需求分类分级的基础上，我们可以在定义其优先级，这里就可以运用“痛点”、“痒点”或者马斯洛模型等作为参考了，它们可以协助我们定义问题的大小即严重程度。对于2B需求来说，往往急需解决的痛点需求是少了这个功能业务无法开展，或者开展的十分困难。

结语

需求分析作为产品经理工作中核心的也是最重要的一环，其需要警示和思考的内容远不止于此，如何运用并不断改进是重中之重。

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

题图来自Unsplash，基于CC0协议