“接需求”是产品经理（下文简称“PM”）工作中必不可少的一环，文章中笔者会结合自己的亲身经历，讲述做好需求分析的几个关键点，希望能给刚入行和打算入行的朋友们一点儿启发。

需求分析在产品生命周期中占有重要的地位，决定着产品做出后被用户接纳的程度。通过对接触过的PM进行观察，我发现大部分人进行需求分析时做的事情大同小异。故总结出几个关键点，形成一个可以应对大多数需求的操作方法。

说明：由于笔者一直从事ToB产品的工作，故本文所述的方法只针对此类产品，不保证对ToC产品适用。

一、需求从哪里来的

需求是某些用户在特定场景下为了得到某种服务或功能而提出的诉求或建议，它是产品的组成部分，也是产品最终要达到的目的。它可以是老板的一句话，可以是用户使用过程中的一声抱怨，也可以是对一堆数据分析后得出的结论。

根据笔者的观察，需求的来源有以下几种：

1. 老板

对于老板提出的需求，一定要重视，并非因为需求方是老板，而是因为它同时包含着机会和陷阱，而且很难拒绝。

（1）机会

• 通过老板的需求，了解老板的思路，借此一窥公司战略发展方向；
• 将自己对产品的理解和老板的对照，找出其中的区别并思考原因；
• 和老板交流下自己的产品思路，发现自己和老板的差距；
• 把老板交代的事做好了，得到老板的赏识（这个大家都懂）。

（2）陷阱

• 并非所有的老板都了解产品开发流程，了解业务发展，会出现瞎指挥的情况；
• 某些需求会打乱团队的产品规划及开发节奏，PM处理不好将会里外不是人。

2. 用户（内部同事）

笔者面对的用户是公司内部的同事，大部分是使用系统的部门同事，小部分是其他的PM。

从部门同事的需求中看出，他们在意的是系统能否满足他们的某项要求，通常会在提出需求的同时给出他们的解决方案。但是并不意味着就是真实需求，一个很著名的案例是想要快马但是福特提供了汽车（不知道的朋友请自行查询）。因此，PM在沟通中需要引导他们表述出自己的真实需求。

负责其他系统（业务线）的PM也会提出需求，来满足一些需要跨系统实现的功能。这种情况的沟通会比较顺畅，因为彼此对系统、开发流程、技术边界都比较了解。

3. 自我驱动

这类需求通常会基于以下三种原因产生：

1. 通过数据分析得出的。
2. PM在使用系统时发现的问题（通常用户无感知）。例如：笔者做风控系统时发现的问题，需要对推送的进件增加控制开关。作用是在风控模型调整或新功能上线后，控制推送进件的数量，待验证无问题后再打开，允许大量进件。
3. 根据产品感提出的。产品感是指基于PM对产品的理解，对市场的分析，提出了一些对于产品未来发展有益的需求。

二、对需求提出方式做规定是有必要的

每个需求的提出者，通常会站在自己的角度提需求，或基于交互，或基于效率，或基于KPI等。这对PM把握需求的重要程度，了解需求内容的准确性增加了难度。

例如：笔者曾经对接过和我不在一个城市工作的业务部门。对接过程中，出现了同一个部门多人同时提需求且优先级不明确，需求上线后使用者（非需求提出者）反馈需求实用性不高，或者需求上线后很多等待使用的人不知道等问题。

笔者通常会分三步进行操作：

1. 确定接口人并明确其职责

接口人：和需求方部门Leader沟通，让他指定一名接口人，所有人的需求都在接口人处汇总，再提给PM。

职责：

1. 收集部门同事的需求；
2. 过滤掉不合理和不必要的需求；
3. 给出需求的优先级；
4. 将需求提交给PM；
5. 跟进需求进度；

2. 确定需求提出方式

邮件提出，确保周知所有相关人，并能留存记录。

3. 部门Leader进行审批

必须由部门Leader审批，确保他了解并认可需求内容和优先级。

三、需求收集方式

一句话概括，就是多提问、多沟通，了解业务和实际使用场景。

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录入，记录不需要像收集需求及分析时那样细致，重点在于对需求的状态、优先级、排期进行记录。

以下是我的需求池模板：

以上是基于笔者对需求分析的想法，可能存在一定的局限性，仅供参考，欢迎大家多交流学习！

作者：打酱油的熊，公众号（打酱油的白熊）

本文由 @打酱油的熊 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议