需求分析是产品经理工作中重要的一环，也是关键的一环；在涉及功能时需要有意识的提醒自己，我是否对这个功能给用户带来的价值足够了解，需求分析是否做充分了。

需求分析在产品研发链条中属于前端环节，也是产品经理工作中的重要一环。我认为它是难点也是关键的一环。

产品的目的就是通过满足用户（或企业）需求来获得回报的，如果需求分析做不好意味着产品功能的无效，浪费时间和资源，用户使用下来也会有挫败感和困惑，对于一些toB的产品，架构复杂的系统，如果功能无效要回退那成本是非常高的。

我过去犯过一些错，需求的分析仅基于功能满足，而忽略了用户的使用场景和流程，回想下当初这样做是顺人性的，为什么说顺人性？因为从用户使用场景出发是难的，你需要通过很多不同的方式去了解用户是怎么用的，特别是toB场景里还会涉及到用户和用户之间的协作，可以说能弄清这层信息可能需要花很长时间，某些时候和自己的认知还有冲突，而在自己现有的认知里决策和行动是简单的自洽的，所以就更容易这么做。

还有一个原因是业务为了追求效率，产品为了在短期内输出成果这是一个快捷的办法，拍脑袋决策，看数据后调整就行了，这种方式可能C端可行，B端复杂的系统可不能拍脑袋。

脱离了用户分析就是脱离了用户，需求分析缺乏足够的用户及用户场景信息，产品很难做好，所以不妨在涉及功能的时候有意识的提醒自己，我是否对这个功能给用户带来的价值足够了解，需求分析是否做充分了。

一、需求分析是考虑需求是什么而不是怎么实现

在进行需求分析的环节中常常出现的一个问题：需求方给的不是需求而是解决方案，这么一来就很有可能掩盖了用户真实的诉求。

我记得我在做toB产品的时候经常会对接客户成功（需求方），而他们在提需求时几乎80%情况下都是不由自的说想要一个XX功能甚至把功能描述的很全面，按钮放在哪里都给你想好了，作为产品经理你得反复问他才能‘按照他的理解’把功能产生的由来给你描述出来，而他的场景的描述可能也有偏差。

这个环节我认为对产品经理要求蛮高的，你需要在已知的知识背景下去推断场景是否成立，需求是否合理，需求方描述的逻辑是否自洽，若不自洽要主动邀约客户进行沟通，所以往往在toB领域有一个中间人：售前，起到对需求和解决方案承上启下的作用。

但之前我和一个做外呼系统的老板聊，他提到了设售前也可能会增加需求流转的摩擦，当然也可能是出于企业节省人力成本才有这样的举措。

二、需求分析是一个从微观到宏观的梳理过程

我始终觉得产品经理会讲故事是衡量一个产品是否能从用户视角出发很重要的一点，很多人说产品经理需要抽象能力，抽象能力从哪里来？从用户场景中来，如果缺乏用户场景全盘和细微的认知，抽象出的宏观结论可能会出现样本偏差。

比如一杯20度的水在40度的天气下用户觉得是杯冰水，而在10度的天气下就可能是杯温水，但事实是它就是一杯20度的水在不同的场景下会带来不同的感受。

再比如一个胖子需要减肥吗？并不一定，如果没有内外在动机，每天宅在家里喝肥宅快乐水吃炸鸡很舒坦？只有在身体可能因肥胖出现高血压高血脂问题时才会减肥或春心荡漾时会想到减肥。在做需求分析的时候可以把自己带入用户角色、集合时间、所在场域、干什么、用户动机、遇到的问题等带入到具体的微观的场景中，找到问题点在抽象总结出一些宏观的结论。

三、需求分析也是向上管理的重要一环

我很多时候会接收到一些自己认为不合理或优先级不高但老板或业务方认为很重要的需求，这时候很多人会说要说服他们，但说服是目的，不是方法，那怎么才能说服？这里又要回到讲故事。

把什么人在什么场景下干什么事情遇到什么问题描述清楚且结合产品目标一般情况下描述的是事实且逻辑没问题，我相信业务方老板方会被你说服的。

但能做到这一点其实是不容易的，要对用户很了解，而在toB领域要对客户的业务很了解，这就更复杂了，而这种了解一定是细致入微的，你跟老板描述的时候其实是在讲一个故事给老板听。

所以你看，向上管理也需要做好需求分析。

四、做需求分析一些实用技巧

1.分析需求的价值可以参考这种方法：满足和不满足差别是什么？

如果有意味着能够有可能提升营收，解决一个比较大的痛点那这个需求的优先级就高很多；

如果有仅仅是体验的提升，甚至并非主价值流程的提升，那这个需求的优先级就低很多。

2.借助有可能忽略的有效信息源：企业内部业务侧员工

业务人员例如像运营、销售、客户成功这种角色特别是公司年限较长的员工，他们是离用户最近的，时常会听到一线的炮声，了解用户的无奈和需求且他们也是相对最懂业务的。

3.讲故事

在了解了场景和痛点且有一些解决方案的设想时不妨和需求方表述下自己的理解，讲故事是表述的形式，他能够检验产品经理对用户场景的了解是否细致入微还是泛泛而谈。

五、需求分析之优先级

在需求分析的时候通常需要产品经理判断需求的优先级，这里分享下我在toB产品中如何判断优先级的，优先级按照需要从高到低：

1. 业务流程断点：某场景下员工们用了新发布的功能但中间有断点无法推进下去了，通常是优先级最高的。
2. 增值需求：能看到短期或中长期能产生一些用户增长、收益增长的需求。
3. 核心流程能走通但不好用：产品核心价值涉及的功能流程是需要反复打磨的，如果功能不好用就需求优化，通常这里优先级也高的。
4. 非核心流程能走通但不好用的：这里不好用也可以分等级，有些本来要3个步骤但现在的设计要6个步骤，相比本来要3个步骤但目前设计要4个步骤优先级要高一些。
5. 交互样式：在toB领域交互样式的优先级是最低的，因为对业务产生的价值度就没那么高。

需求分析我认为就是一个发现【好问题】的过程，而发现一个好问题通常比解决方案来得更珍贵。