如何做好需求分析

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

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

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

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

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

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

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

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

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

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

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

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