编辑导语：每一个用户端的需求，到了用产品方案来实现的时候，往往对应着多个产品需求，用户需求越多，产品需求也会越多。那么怎么来进行评估和判断呢？作者给出了以下建议，一起来看看吧！

需求处理5步法：

1. 收集需求：从各种渠道收集原始需求
2. 还原需求：对需求的关键要素进行还原
3. 挖掘需求：对需求进行深入挖掘，找到深层次的需求
4. 补充需求：举一反三，对相似、相关的需求进行补充，避免遗漏
5. 评估需求：评估需求的优先级、开发工作量，帮助制定项目迭代计划

我们从前面4个步骤中，收集到了很多待开发的需求，这些需求看起来都很重要，但我们不可能一下子全部都开发出来，毕竟，在任何企业中，资源不足永远是常态，即使像华为这样有十几万员工的大公司，投入到一个产品线的资源也总是有限的。

正是这种资源不足的常态，导致在产品经理的日常工作中，需要经常面临一个问题，那就是如何评估需求，如何合理安排需求优先级。

关于评估需求，我们先从一个故事开始。

应用于企业内部的知识管理系统项目启动后，产品经理老王经过一番调研，得到了一个长长的需求列表，接下来他想制定项目迭代计划，于是约了业务代表来沟通需求的优先级。

产品经理：通过前期对你们的调研，我们对你们的需求有了大致的了解，现在我们要制定项目迭代计划，所以我们想从已经识别出来的需求中，选择一些需求放在最开始的版本中。

业务代表：啊？我们提的那些需求，我们全都要！

产品经理：我们打算先做重要的那些需求。

业务代表：我们提的那些需求都很重要！！没有不重要的，否则我们也不会向你提那些需求。

产品经理：我明白，这些需求都很重要。这么多需求不可能一下子全部做完的，还是得分清先后顺序。我们需要你们来帮助区分优先级，我们把这些需求按照优先级分成几批，优先上线那些你们最想要的功能，其他次要的功能在后续的版本中陆续上线。

业务代表：说到上线，这个知识管理系统大老板很重视，下个月能不能上线？

产品经理：今天约你就是想沟通一下需求的优先级，我这边好制定项目迭代计划。这是前期识别出来的需求清单，接下来我们对这些需求先进行粗略的优先级排序，以便我们能够了解哪些需求是你们最想要、最希望在第一个版本看到的。这也可以帮助我们更准确理解你们的期望。

业务代表：哦，这样啊，那我们先做一个像百度百科那样的知识库，把知识沉淀先开展起来。至于问答系统、在线视频课堂、知识交流社区可以先稍微缓一缓。

产品经理：那知识库相关的功能，哪些你最想先用到呢？

业务代表：文章编辑、文章提交、给文章评论、点赞、收藏这些功能是最基本的，肯定得有。还需要单点登录功能，也就是说员工可以利用OA系统的账号直接登录，不需要在知识管理系统里面再注册一个账号。另外，文章搜索功能先做标题搜索就行，全文搜索可以等以后再做。我刚才说的这些需求，什么时候能够上线呢？

产品经理：谢谢你向我们提供这些有价值的信息。接下来我还要找开发人员与项目经理来评估一下工作量，再根据您刚才说的需求优先级，我来制定一个初步的项目迭代计划跟你确认，预计明天上午可以给你反馈，你看可以吗？

业务代表：好，那我们明天再沟通。

以上描述的故事是产品经理在需求工作中的一个典型场景。

“都很重要”、“全部都要”、“马上就要”，是很多甲方爸爸的口头禅。

通过沟通，产品经理要让业务代表认识到，每个项目的资源特别是时间资源是有限的，不可能一下子全部交付他们想要的全部功能，对需求进行优先级排序，把最高优先级的归为一类，可以在第一批尽早实现，其他可以迟些在后续的版本中实现。

作为产品经理，要通过评估需求优先级、估算开发工作量来制定项目迭代计划，并在这个过程中与业务代表达成共识。

接下来介绍评估需求优先级、估算开发工作量的方法。

1. 如何评估需求优先级？

排优先级的思想常常被称作“分诊”，来自于医疗领域，最早在拿破仑的战争中得到应用。战场上有大量的受伤士兵，但战地医院的医疗资源显然没办法治疗所有的伤兵。战地医生应用分诊的方法把士兵分为3类：

由于缺少医疗资源，医生只治疗第一类“治疗了可以活下去”的伤兵。

这种分诊的思想同样可以应用于排需求优先级。

即使是一个中等规模的项目，往往也有好几十个用例和几百个功能需求，很少有软件项目能够在预定的日期交付干系人想要的所有功能。毕竟每一个项目的资源都是有限的，特别是时间资源。

对产品团队而言，需求优先级也是一个时间管理的问题，我们可以应用时间管理的方法来评估需求优先级。

先简单介绍时间管理的方法。

我们每天要做的事情很多，总感觉时间不够，所以就要按照轻重缓急对事情进行分类、排优先级，然后按要事优先的原则来处理事情。

按照时间管理四象限这个工具，可以把事情按照“重要”、“紧急”进行分类放到四个象限。

• 重要且紧急：比如产品崩溃，有大量的用户投诉。这样的事情要立即处理。
• 重要不紧急：比如产品规划、参加培训、运动。这样的事情要有计划地做。
• 不重要但紧急：比如出席无关会议、接到骚扰电话。这样的事情可以授权别人做或暂缓。
• 不重要不紧急：比如刷短视频、刷朋友圈。这样的事情尽量少做。

我们可以按照时间管理四象限这个工具来评估需求优先级（如下图所示）：

• 重要且紧急的需求，算高优先级。
• 重要不紧急的需求，算中优先级。
• 不重要但紧急的需求，算低优先级
• 不重要不紧急的需求，算低优先级

那我们怎么判断需求是否“重要”、“紧急”呢？我们可以站在业务视角来进行评估：

• 重要：判断是否重要的依据是业务价值，包括用户价值、商业价值。例如：核心业务相关的需求算重要；核心用户的核心需求算重要；能显著提升产品的竞争优势的话算重要。
• 紧急：广度（涉及的用户数量）；频度（需求相关的场景出现的频率）；竞争（比如跟竞争对手抢时间）

从业务视角安排好优先级之后，还要请开发人员从技术视角、请项目管理人员从项目管理视角对需求优先级进行微调。

（1）技术视角

有的需求在实现层面与其他需求有依赖关系，被依赖的要优先做。

例如，知识管理系统中，有“提交词条”、“登录系统”这两个用例，在提交词条时要验证身份，要求用户要先登录系统才能提交词条。“登录系统”被依赖，所以“登录系统”的优先级要高于“提交词条”。

（2）项目视角

项目经理要考虑需求的实现成本、是否存在技术风险。

同样都是高优先级的需求项，要优先做成本小的，这样更容易见到成效。

同样都是高优先级的需求项，要优先做风险大的，因为提早做风险大的话，风险出现时还有机会与时间来补救。

上面介绍了先从业务视角来评估优先级，再从技术视角、项目视角微调优先级的方法。这个方法属于定性评估，还可以用定量评估的方法来排需求优先级。

定量评估的方法先列出排优先级要考虑的维度（如业务价值、开发成本等），再邀请跨职能代表（业务代表、开发人员、项目经理等）从各个维度对要评估的需求项进行打分，然后就可以根据需求项的得分来排需求优先级。

排优先级要考虑的常见维度如下：

• 业务价值
• 用户量
• 发生频率
• 技术风险
• 开发成本
• 上市时间
• 政策要求
• 合同约定

定量评估的方法参考如下表格：

在中大型项目中，干系人很多，他们对哪些需求更重要往往达不成一致意见，容易产生争吵，可能会根据“音量优先级”来安排需求优先级。这种情况下，可以通过定量评估的方法来打破僵局。通过多人打分的方式更加客观，减少情绪方面的影响，促使团队对需求优先级达成共识。

不管用定性评估的方法，还是用定量评估的方法，我们可能会遇到2个需求优先级一样的情况，如果你很纠结该先做哪个需求的时候，要记住：

需求优先级的本质是性价比。

这时候你判断的依据就是哪个性价比高就先做哪个。

对于需求优先级，有以下几点需要提醒：

• 优先级是相对的。用定量评估的方法进行打分的时候，是通过比较来打分。
• 排优先级是一个动态、持续的过程。随着项目条件的变化、需求变更，要及时调整需求优先级。

评估完需求优先级后，还要评估需求的开发工作量，然后来制定版本迭代计划。

2. 如何评估开发工作量？

估算开发工作量时，不能由产品经理拍脑袋估算，然后制定不切实际的项目计划。需要邀请开发团队来一起评估开发工作量。

（1）估算过程

以敏捷项目为例，介绍估算工作量的过程。

1. 先估算项目包含的故事点的数量（用分解法、类比法、扑克牌估算法）
2. 根据以往经验、早期迭代结果估算团队速率（一个迭代能够完成多少故事点）
3. 算出工期（故事点数量÷团队速率）

（2）估算方法

分解法：分而治之

比如，一个手机硬件工程师要估算一款竞争对手新上市的手机的硬件成本，可以用分解法把这款手机的所有零部件都拆解出来，就可以得到这款手机的BOM成本。

对一整个项目的工作量不容易估算，即使估算的话偏差也会比较大，可以利用分解法拆成好估算的模块，然后汇总就可以得到整个项目的工作量。

类比法：历史数据+修正系数

比如，你家里要装修房子，你要估算装修费用。如果你以前有装修过，参考历史数据，再针对面积大小、豪华程度、物价水平等因素进行修正，就可以估算出装修费用了。

如果你是第一次装修没有经验，可以去最近刚装修完房子的朋友家里了解一下，再根据你家的面积大小、豪华程度进行修正，就可以估算出你家房子的装修费用了。

扑克牌估算法

敏捷扑克牌估算法的使用方法：

0、每一名团队成员（产品负责人除外）取一种颜色的卡片（如图所示）。

1、产品负责人描述待预估的Backlog项目，并解答团队成员的提问。

2、团队讨论。

3、每一名团队成员根据自己的判断进行预估，将预估结果倒扣在桌上。

4、当所有团队成员都完成预估，大家同时把卡片估值翻转过来公示。

5、如果所有人的预估值相等或相近，该值即为Backlog项目的故事点。

6、如果团队成员估值差异较大，则需要对预估结果进行讨论。

7、重复上面的过程，直到团队达成一致意见。

8、产品负责人选择下一个Backlog项目进行预估。

注1：一般情况下，建议预估分值为单张纸牌的数值。

注2：问号用于表示对当前项目仍有疑问；咖啡用于提示实在太累了，需要休息一下。

对于工作量估算，有以下几点需要提醒：

• 很多开发人员在估算工作量时会偏乐观，对风险预估不足，经常会看到实际工期远大于预计工期的情况。
• 不要因为外部压力或迎合领导的喜好而做出不切实际的估算，这样的后果往往是两败俱伤，而你最终将成为背锅侠。
• 报给客户的工作量要留余地。比如你预估2天能做完，你报给客户时要说3天。一方面要预留时间以免发生特殊情况，影响交付时间，另一方面要留给客户“砍价”的余地（客户听说要3天，极有可能让你在2天内完成）。
• 度量就是认知。在项目初期做的初步估算都是基于估算者当时的认知及其所做的假设，具有很大的不确定性。随着项目的进展，根据实际进度，以及任务的进一步细化，应该动态调整估算值，估算值应该越来越接近实际值。

还有很多方法可以用来排优先级，比如“入选与落选法”、Kano模型、百元购物法、MoSCoW优先级排序法等，本文介绍的是我认为比较实用的方法，希望对你有帮助。

本文由 @张在旺 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议