需求分析法

1. 5W1H分析法

很多需求提出者不了解系统，他们只关心当前问题是否能够解决，PM必须详细了解需求的来龙去脉，以便能提出解决方案。在此推荐5W1H分析法，用来收集需求内容。

（1）What（描述）

需求是什么？

（2）Why（原因）

为什么会有这样的需求？之前的替代方案是什么？

（3）Who（使用者）

需求的使用者是谁，或者说是哪个部门？

（4）Where（场景）

需求的使用场景是什么？

（5）When（时机）

需求什么时候会被用到？被用到的频率是怎样的？

（6）How（检验）

如何确认需求已经被满足？

上述问题要求需求方描述清楚，可通过邮件，也可通过面谈。需求的收集方法可按照自己的习惯选择，重点在于对需求信息的收集。

2. 和需求方的沟通频次

负责ToB产品的PM必须了解业务，笔者曾经负责过财务系统的设计，由于不了解需求方对于结算、对账、提现等操作使用场景的要求（需求方也不了解），导致设计出现问题，需要进行二次开发。

要想深入了解业务，就需要和需求方保持沟通。笔者认为，在接到需求后，至少应该有三次沟通。

• 第一次是在接到需求后。要遵循5W1H分析法，围绕其中的问题进行沟通，收集需求详细信息。
• 第二次是在收集信息并对需求进行分析后。PM会结合自己对系统的了解，挖掘出一些细节问题，其中有一些需要和需求方确认。这期间可能会有多次沟通。
• 第三次是在PRD完成后。要将文档内容讲给需求方听，在评审前最后一次确认自己是否准确理解需求。至于需求背景这类问题，必须在评审会前了解清楚，以便在会上讲给所有人。

1. 需求分析的步骤

判断需求的真伪–>分析需求的业务价值–>评估需求的可行性–>给出需求的优先级。

笔者将以自己的经历为例，说明如何进行这四步操作：

（1）判断需求的真伪

该需求的5W1H分别为：

1. What：需求方是财务部门，需求内容是在财务系统中新增列表，用来展示某项费用的明细，且该列表可以下载。
2. Why：之前的替代方案是从系统中另一个列表下载，由于并不是专门展示此类数据（数据量较大），所以需要人为进行筛选和计算。筛选计算时间不长，笔者亲测约为15分钟。
3. Who：使用者是财务部门的一名同事（只有一人），系统的其他使用者不会用到该列表。
4. Where：使用场景是每月与合作方对账时，需要下载该列表，然后在excel中对某几项金额进行计算。
5. When：每个月月初使用，统计上一个月各资金类型的交易量，使用频率一个月一次。
6. How：列表中能够按时提供准确、完整的数据，即满足需求。

根据笔者的判断，该需求目前有替代方法且不难操作，需求使用频率低（一月一次），使用人数少（一人）。故该需求的业务价值不高，是伪需求。

笔者向需求方阐明了需求的不合理处，并建议在已有列表处，增加下载入口，可下载每月需要对账的金额总和，这样既节省了下载后再计算的工作量，同时也降低了数据量，减少下载时对资源的占用。

因为需求方坚持按照最初提的方案进行，同时不能给出合理的解释，故最终砍掉该需求。

（2）分析需求的业务价值

这一条可以和判断需求真伪互补，通常业务价值很低的需求，即便做出来也很少会被用到。

依照上述事例，虽然是投入人力、耗费时间都很少的需求，但其业务价值只是为了每个月节约一个人15分钟时间，得不偿失。

另外，PM还需要对系统的发展方向、包含的功能、服务的人群有明确定位。对于后台系统来说，在增加功能、列表时必须要有规划和节制，否则系统很快就会功能冗余、查找困难、使用不便。

（3）评估需求的可行性

这一步的目的在于判断需求的开发难度，进而给出大致的实现方案，需要PM和开发共同完成。

上述事例中的需求页面功能简单，所需数据在数据中有记录，接口也有提供，故从可行性来说没有问题。

PM需要对自己负责的系统、对接的技术人员的能力、代码开发中的技术边界有一定了解，才能更好的做出可行性评估。因此建议PM多学习技术，以免提出“根据手机壳颜色变换APP主题色”这类的需求。

（4）给出需求的优先级

笔者一般会运用四象限法则和KANO模型来判断优先级。这两个方法在确定优先级中是比较常用的，在此过多介绍，感兴趣的朋友可以自行查询（优秀的PM需要具备查询能力和自学能力）。

四象限法则：

• 重要性：指需求是否符合公司战略发展、是否是产品线上的战略项目、是否和公司的收益挂钩、是否满足产品的基础服务等等。总之，在时间上不具有紧迫性，但是会对未来的发展产生重大影响。
• 紧急性：指需求是否必须立即解决，如不解决会持续产生或将要产生不良影响。这类需求不一定很重要，但是在时间上有紧迫性。

如下图所示，重要紧急的需求需要立即放下手中的事情，集中精力去解决，例如：笔者接到的风控系统需求，要在合规备案检查前上线，以满足合规备案的需要。重要不紧急的，要在了解并分析完需求后，制定出方案，然后按部就班的执行。紧急不重要的，能不做就不做，做的话也尽量采用省时省力的方法解决。不紧急也不重要的，这类多为伪需求，参照上述财务部门的事例，果断拒绝掉。

KANO模型：

• 必备因素：在业务流程中必须具备的功能，用以保证流程能正常进行。功能缺失时，使用者会发现流程不能走通。故这类需求需要优先考虑。例如：风控系统中跑反欺诈模型时，如果调用失败后没有重启流程这个功能，就会存在调用失败的进件卡在反欺诈模型环节，造成流程中断。
• 期望因素：这类需求通常能节省使用者的时间，提升效率。存在的目的是为了让系统操作起来更流畅。优先级一般没有必备因素高。例如：财务系统每月做报表时，如果系统能够将需要从多处查找并计算的数据，统一到一处并展示计算后的结果，那样能提高使用效率。
• 魅力因素：通常是一些使用者没有想到的功能，能大幅提升使用者效率、优化体验和解决使用者线下难以解决的问题的需求。这类需求在ToB产品中不常见，通常是必备因素和期望因素占据主导地位。

无差异因素和反向因素：这两类需求我认为是伪需求，是耗费时间、精力后却不能提升使用者体验、效率的，遇到后应予以拒绝。

2. 需求整理

需求的收集与整理需要用到需求池。需求池没有固定的模板，建立的目的是为了帮助PM进行需求的评估和管理，模板内容依照个人习惯建立即可。

需求池中的需求由PM录入，记录不需要像收集需求及分析时那样细致，重点在于对需求的状态、优先级、排期进行记录。

以下是我的需求池模板：