“什么该做，什么能等等”是产品经理的灵魂拷问，而不是简单打个分就能解决的事。 本篇文章将带你跳出“拍脑袋优先级”的陷阱，帮你真正建立一套“既能说服他人也能说服自己”的决策体系。

排需求优先级，本质上其实就是决定做什么、不做什么，先做什么、后做什么。

核心目标就是利用有限的时间、人力和资金等等这些资源，来获得最大的价值。

最终排出来的需求优先级是一种结果，要想达到这种结果，需要产品经理从各个维度来综合考虑，这个过程不管采用什么方法，都充满了主观性。

但是，我们可以通过一些系统化的方法，让这个决定的过程，更加的合理和可控。

毕竟排需求优先级，其实也可以算是更细粒度的产品规划，不管是在哪个层级上，都至关重要。

评估需求优先级的维度

评估需求优先级的维度有很多，下面主要是列举一些比较常见的维度，可以在实践的时候进行参考：

1. 用户影响程度、影响面、出现频率

有多少用户会有这个需求？可以是一个大概的用户数百分比；

这个需求或者是问题，出现的频率如何？

问题是否严重？是严重影响用户使用，还是无关痛痒？

影响面和频率越高，或者问题越严重，需求对应的优先级也要提高。

例如：

登录验证码改版：影响 100% 用户且高频，不改版严重影响用户使用——高优。

企业版专用审批流： 0.3% 用户——低优。

2. 业务价值

需求做了的话，能有多大价值？

价值分为两个方面，一个是能赚多少钱，另一个是能省多少钱；

钱也就是经济效益，这是价值的最终表现形式，但是在转化为钱之前，价值也有可能是一些指标。

比如用户投诉率、留存率，或者是一些风险的降低和规避，这些都可以算是业务价值。

业务价值越高，需求优先级也要越高。

例如：

电商平台的“先用后付”功能需求，预计可以提升5%的支付转化率，年增收大约3000 万——妥妥的高优。

电商运营后台把“导出数据”按钮换个颜色，没有客户会因为这多付钱——下个版本再说，低优。

3. 投入成本

得投入多少成本才能做这个需求？

成本包括人力成本、资金、时间等等各种方面。

成本和价值这两个维度要综合来看，优先做那种投入低价值高的需求。

除了关注投入产出比，也要关注投入产出的绝对值，可能会有那种投入很多，价值也很高的需求，需要慎重考虑是否能够承担前期的成本投入。

例如：

系统重构需求，人力成本投入巨大，虽然能提升用户体验，但现有系统也还可以用——低优；

后台数据列表查询需求，能显著提高用户数据查询的准确率和效率，投入人力较少——可以高优。

4. 紧急程度

需求的紧急程度，是否有明确的时间截点，限期内不做的是否会出大问题？

越是紧急重要的需求，越要高优。

例如：

今天8月1号，但APP在8月30号之前必须上线隐私弹窗，否则就得下架 ——火烧眉毛的需求，还这么大影响，必须高优。

老板随口提了个需求：“我觉得加个暗黑模式挺酷” ——又不是不能用，低优！（老板强硬要求的除外）

5. 战略匹配

需求在领导的OKR里吗？跟老板新年演讲有没有对上？符不符合公司的战略定位？

例如：

公司今年 All in AI，做 AI 客服助手——高优。

边缘业务中的“积分商城”优化——可以暂时靠边站。

6. 风险合规

是否会涉及法律、舆情、安全、财务等各种风险？不做的话，会不会被罚钱、下架、上热搜？

例如：

数据不合规的话会被工信部通报——高优。

数据的展示方式查看起来比较费劲，需要升级优化——该有的数据都有，先凑活儿用吧，低优。

7. 竞品差距

竞争对手是不是都有这个功能了？用户会不会以这个功能来做产品的对比，导致我们的用户流失？

例如：

竞对支持“扫码点餐”，导致我们流失 5% 的用户——高优 。

竞对做了个花里胡哨的签到功能，用户感知不明显——低优。

8. 资源依赖

要做某个需求，是否依赖什么前置条件，否则就没法做，比如需要别的团队支撑、第三方、硬件到位等等。

例如：

要增加优惠券发放功能，内部优惠券系统已经有现成的接口可以使用——前置条件ready，高优。

做需求需要的新接口10月才开放——先排10月，现在低优。

9. 技术债

不做这个需求，会不会导致后续需要回来填坑？会不会对后面其他需求有影响？

例如：

电商平台数据库分表需求，不做的话下个月大促必挂——高优。

某个模块功能升级后，用户体验更好，但是最近没什么风险——低优。

上面这些评估维度，在需求很多的情况下，全部去对照评估一遍，会耗费比较多的时间，可以从用户、成本、价值、紧急程度这四个主要方面来快速评估，提高效率。

常见优先级排序方法

1. 紧急重要四象限法（最常用，适合新手）

把需求分成 4 类 —— 重要且紧急、重要不紧急、紧急不重要、不紧急不重要，按这个顺序排需求优先级。

重要且紧急：必须马上要做的需求，比如支付功能崩了，用户想付钱却付不了。

重要不紧急：需要规划来做的需求，比如优化用户注册的流程，降低新用户的流失率。

紧急不重要：很紧急，但是影响不大的需求，比如老板临时要一个数据报表模块，但是报表模块有没有其实没啥区别。这类需求大部分都是一些临时性的需求，不做不行，但是做了也没啥实际太大的价值。

不紧急不重要：这种需求直接往后排，比如APP主题换个更亮眼的颜色，但是实际没什么用户提这个需求。

2. MoSow法

跟紧急重要四象限法类似，MoSow法也是将需求分为四类，分别是：

Must have（必须做）

从紧急程度、重要程度、需求价值等各个方面上来说，都必须要做的需求，一般比较核心的需求，或者是风险合规类的需求，总之就是不做不行的需求。

比如社交APP加好友的需求。

Should have（应该做）

时间或人力等资源具备的情况下，就要做的需求，这种需求很重要，但是没有重要到不做不行的地步，不做也不影响核心功能的使用。

可以理解为是次核心需求，比如社交APP的动态点赞功能。

Could have（可以做）

做了会让产品更好，但是不做的话，也不影响用户使用的需求。

比如朋友圈动态中发动图的需求，微信也是刚做了这个需求没多久呢。

Won’t have（暂时不做）

明确先不做的需求，后续版本可能再考虑。一般是一些开发成本很高，或者是当下做了没啥实际用处的需求，也有可能是一些不太重要的需求

比如在用户量很少的时候，增加社区动态功能的需求，成本高，用户少，就不适合立即就做。

3. RICE 评分法 (Reach, Impact, Confidence, Effort)

这个方法相对MoSow法和紧急重要四象限法，会显得更客观一点，因为加入了数字评分，但是客观只是表象，核心还是一种主观性的方法。

这个方法有四个指标，每个指标都有相应的分数、百分比或者是其他单位。

Reach（覆盖面）

需求的影响面。

比如新功能预计3个月内影响10000名用户，那么Reach就等于10000。

Impact（影响力）

影响力有多大，有多严重。

影响力这个指标不像覆盖面那样有大概的数量，所以可以通过定性分档量化。比如分为高（3分）、中（2分）、低（1分）三档分数。

confidence（信心度）

对以上Reach和Impact有多大程度的信心，一般用百分比来表示。

比如以上两个指标的结果，来源于市场调研，但是数据有限，信心程度可以打个80%。

Effort（工作量/投入成本）

完成需求需要多少人力资源，一般都是说多少人天，大需求的话，可能会说多少人月。

比如2人天，就是2个人干一天，也可以是一个人干2天。

但2个人干一天有个前提，就是工作量得能明确拆分，并且不会有额外太多的协作成本，要不然不如一个人干2天效率高。

以上四个指标的数据都明确之后，就可以套入公式了：

RICE Score = (Reach × Impact × Confidence) ÷ Effort

得分越高，说明单位投入带来的综合价值越大，所以得分高的需求要把优先级排的更高。

4. Kano 模型

将需求分为五类，有助于理解其对用户满意度的不同影响：

基本型需求: 必须要有，满足时用户其实并不会觉得特别满意，但不满足时会极度不满。优先级最高（比如登录这种基础且必须的功能）。

期望型需求: 越多越好，满足这种需求用户满意度会有比较明显的提升。优先级次高（比如性能提升、搜索功能增强这些优化的需求）。

兴奋型需求: 用户没有明确预期的需求，提供时能带来惊喜和很高的满意度，但不提供也不会不满。优先级可以看资源情况来定，要是排期不紧张可以纳入排期。

无差异型需求： 做不做用户都不关心的需求。优先级排低。

反向型需求： 不做没事，但是做了用户反而会不满意。这种需求不能做，避免挨喷。

5. 加权打分法

加权打分法比RICE评分法更加的复杂，需要确定的维度更多，但再怎么量化，实际上也是基于主观评价的方法。

第一步，首先需要定义几个比较重要的维度，比如影响面、严重程度、需求价值、投入成本等等。

第二步，为每个维度赋予权重，权重总和等于100%。

第三步，给每个维度打分，比如总分1-5分。

第四步，计算加权总分，这里也有个公式：

(维度1分数 * 权重1) + (维度2分数 * 权重2) + …

第五步，最后再按总分排序，按分数高低排出优先级。

这个方法相对其他方法来说，太复杂了，不太适合快速决策。如果是比较重要的规划，可以考虑使用。

写在最后

其实在实际需求排期过程中，大部分情况下还是依赖产品经理的主观评价，上面说的这些方法，只是不同的工具而已。

建议在实际排期时，可以把这些方法结合着使用。既要快速决策，也要保证排期的合理性。

当你这些工具用的多了以后，慢慢的就会成为一种思维习惯，就不再需要每次都得对照着各种方法、维度来判断优先级了。

记住：没有 “绝对正确” 的排序，只有 “当前最合理” 的排序，根据数据和反馈随时调整就行。