需求分析流程

合格产品经理
帮助用户、引导用户、分析需求、判断需求、设计方案
不能苛求用户提出合理、严谨的需求，这不是用户的责任和义务，而应该通过自己的专业能力来完成需求的采集工作

角色分析

收到需求的第一步就是分析相关角色，角色分析分为三部分：
提出人：需求的提出人，是指原始需求的提出人，而非需求的传递人员，需求的提出人，并不一定是产品功能的使用人，而需求背后要解决的痛点也并不一定是需求提出人的痛点！
使用人：最终使用产品功能的人，也就是需求的使用人，产品最终要解决使用人的痛点。
受影响人：最终受到产品功能影响的人，可能是多个角色多个人员。

场景分析

5W1H分析框架：即什么人（Who）在什么时间（When）在什么地方（Where）因为什么（Why）原因要做什么事情（What）以及希望如何实现（Hhw）这个目标，最后HOW既是对过去解决方式的描述，也是对未来解决方式的描述，在需求分析过程中，要注意甄别，分别弄清楚。
用户故事分析框架：时间+地点+任务+起因+经过+结果，通过这个框架可以较好还原用户产生需求的场景，讲好用户故事。
通过场景分析，了解需求描述背后的本质——用户的目标之后，还需要了解事件发生的频率。了解事件发生频率有助于排定需求优先级。

动机挖掘

5why分析法：洞察核心诉求的过程也是不断追问的过程，可以采用丰田公司的大野耐一提出的5Why分析法，层层递进，打破砂锅问到底，穷究问题的本质。当然5Why只是模型，现实中不一定是问5次。
多问几个为什么，才能击穿问题，直达本质。
需求强烈程度：挖掘出动机之后，还要判断动机的真实性，这时候要看看需求的强烈程度，如果需求不强烈，那需求很可能是伪需求，两个方法确认：
方法一：正反两问的方法，如果实现了该需求，对方的感受是什么？不实现又怎样？（类似KANO模型：基本/期望/兴奋/无差异/反向）
方法二：询问目前解决问题的方法/思路，如果目前没有方法解决，甚至都不想方法去解决，那这个需求很可能是个伪需求。
B端产品经理，如果对业务理解不够深刻，很难洞察需求本质。

场景发散

横向替代场景：围绕核心诉求可以找到所有可能得解决思路或场景，这些场景彼此之间在某种程度上存在可替代关系，通过解决替代场景达到解决问题的目的。
纵向互补场景：用户提交的需求往往是一个点上的需求，在需求点的上下游或整条用户操作动线上，可能存在的考虑不够全面的机会点和优化空间，通过优化这些点，达到解决问题的目的。（用户地图工具可帮助梳理用户在操作动线上的场景）

设计方案

解决业务问题才是核心目标，需要注意：

1. 针对某些需求，不一定要开发新的功能，现有功能可以直接或间接满足该需求；
2. 解决业务问题，软件只是手段之一，有的业务问题是软件不能解决的；
3. 当研发资源有限的时候，采用其他方式来解决问题反而是更具性价比的方案；
4. 在设计解决方案之前，不仅要关注功能需求，还要关注性能、并发、接口响应时间、安全等非功能层面的需求。

B端产品成功需求分析的前提永远是理解业务，如果自身业务知识底子不够厚实，学习再多的需求分析技巧也是枉然。

---

用户故事地图

用户故事地图是帮助产品经理进行分析的手段，横向表示时间线纵向表示用户故事分解，大级别的用户故事排在头排，根据时间顺序描述用户需求。对每个头排用户故事成纵向分解，通过地图方式可以让产品经理和同事能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。
制作用户故事地图的4个步骤：

1. 确定用户和业务目标
2. 梳理用户完成业务目标的工作场景
3. 纵向分解每个工作场景的业务路径
4. 纵向分解用户故事的具体功能点

通过用户故事地图，产品经理可以更好地理解用户在每个环节的处境和想法，从而设计出既满足用户需求，又能给用户带来优质体验的产品。

示例

基础版本

功能优先级版本

用户体验版本

用户体验版本2

更多有趣示例详见：boardmix