# 需求总比产能多：优先级到底在排什么

用机会成本解释为什么“值不值得做”没有绝对答案，讲清 RICE 四个因子怎么用、分数为什么不能当结论，以及为什么排不出也排不出总榜

> 优先级排序 · RICE · 机会成本 · 约 9 分钟 · 09 月 21 日

## 本篇要点

1. 因为团队在固定时间里的产能是固定的，所以“这件事值不值得做”没有脱离比较对象的答案：一件需求真正的价格，是被放弃的那件最有价值的需求的价值，也就是机会成本。
2. RICE 用 Reach（触及多少人）、Impact（影响多大）、Confidence（把握多大）、Effort（花多少人月）四项估计合成一个分数，公式是 Reach × Impact × Confidence ÷ Effort。
3. RICE 分数没有单位，它既不代表钱也不代表人数，只能在同一批候选内做相对比较，不能跨团队比，也不能回答“这件事值多少钱”。
4. 名次翻转往往不是因为某条需求变重要了，而是它某个估计被证据替换掉了；所以排序工作的大半是在核对那四个数的来源，而不是算分。
5. 排不出总榜有三个原因：候选集一变比较对象就变；价值随时间流走（Cost of Delay）；以及估计的精度撑不住名次的精度，第 7 名和第 9 名的差别没有决策意义。
6. 有决策价值的只在产能边界附近，所以正确做法是排“接下来做什么”并附一份明确不做的清单，而不是给 200 条需求排出 1 到 200。
7. 取舍应该按节奏发生（比如每两周一次），因为中途切换本身有成本；同时要给紧急事项留出插队容量，否则排序就退化成谁喊得响。
8. 合规要求、硬依赖、已签合同的承诺属于“不做”不成立的项，不需要打分；如果所有候选的把握都低于 50%，说明缺的是信息而不是排序方法。

---

假设你入职三个月，第一次参加季度规划会。摆在你面前的池子里有 200 条需求：运营要批量导出，客服要工单合并，老板说该接企微了，销售已经答应客户一个审批流，还有一条你自己觉得重要的搜索体验优化。

很自然的反应是把它们排成一张 1 到 200 的总榜，然后从上往下做。

这张榜排不出来，排出来也没用。原因不复杂，但想清楚之后，你会发现自己对“优先级”这三个字的理解会变。

## 产能是固定的，所以“值不值得做”是一个比较问题

一个五人的产品小组，一个季度真正能落地的中等规模改动，往往只有三到五件。这不是态度问题，也不是加班能解决的——做完还要测试、灰度、修 bug、处理线上问题。

如果这个季度你手上是 20 人月的产能，而池子里的需求加起来要 200 人月，那么你每答应一件事，就自动否决了别的事。**一件事的真实价格不是它自己花掉的那点人力，而是为了它被放弃的那件最有价值的事。** 经济学里把这个叫机会成本。

这带来一个反直觉但很关键的结论：**“这件事值不值得做”没有离开比较对象的答案。** “批量导出值 80 分”本身不构成判断依据——80 分对上一个 50 分的候选，它值得做；对上一个 200 分的候选，它是浪费。而你手上的 200 分是什么，取决于这个季度池子里还有什么、产能还剩多少。换个季度，同一件事的答案可能反过来。

所以优先级工作真正在做的，不是给每条需求贴一个分值，而是**在产能的边界上反复回答同一个问题：接下来这几件里，做哪件最不亏？** 这也是为什么“给所有需求排一张榜”这个念头一开始就偏了——总榜假设每条需求有一个固定的、可以脱离上下文的分量，而实际存在的是关系。

## 把“我觉得重要”换成可以被核对的话

先说工具，再说它的局限。目前最通行的量化排序方法之一，是 Intercom 的产品团队在 2016 年前后公开的 RICE，作者是 Sean McBride[1]。它用四个因子给每条需求打分：

- **Reach，触及多少人**：在一个固定时间段里，这条需求会影响到多少人，单位比如“人/季度”。要尽量用产品埋点或真实计数，而不是拍脑袋。
- **Impact，影响有多大**：对每个被影响到的人，改变有多大。Intercom 用的是只有五档的固定刻度：3＝极大、2＝高、1＝中等、0.5＝低、0.25＝几乎可以忽略。刻度故意做得这么粗，就是为了不让人纠结到小数点后面。
- **Confidence，有多大把握**：你对上面两个估计的信心，100%＝有硬数据、80%＝有一些证据、50%＝基本靠猜。
- **Effort，要花多少**：从产品、设计到工程、测试的全口径投入，通常用“人月”。它是分母，越费劲分数越低。

$$\text{RICE}=\frac{\text{Reach}\times\text{Impact}\times\text{Confidence}}{\text{Effort}}$$

举个例子：

| 需求 | Reach | Impact | Confidence | Effort | 分数 |
| --- | --- | --- | --- | --- | --- |
| A：批量导出 | 500 | 1 | 80% | 2 | 200 |
| B：搜索排序优化 | 3000 | 1 | 50% | 3 | 500 |

B 是 A 的两倍多，先做 B。

但这里有个必须看清的坑：**这个分数没有单位。** 分子是“多少人 × 影响多大 × 多大把握”，分母是“人月”，两边约掉“人”之后，剩下的东西既不是钱，也不是人数。所以它只能回答“在这批候选里，哪一条每单位投入换来的东西更多”，回答不了“这件事到底值多少钱”，更不能拿两个团队的分数互相比。

也就是说，公式真正的产出是那四个数，不是最后那个结果。这四个数把“这个更重要”这句没法反驳的话，翻译成“我认为它影响 3000 人、我有 50% 把握、要花 3 人月”——每一句都可以被质疑、被查证。

接着上面那个例子。规划会上有人问了一句：B 的 3000 是从哪来的？翻数据才发现，那是“所有点过搜索的人”，不是“遇到过搜索问题的人”。真正每周至少被搜索坑一次的是 400 人。把 Reach 从 3000 改成 400，Confidence 从 50% 提到 100%：

$$\frac{400\times1\times100\%}{3}\approx133$$

注意证据同时动了两个方向：触及人数被砍到原来的约七分之一，把握翻了一倍，合起来分数从 500 掉到约 133。这时 A 的 200 反而更高，排序换了个方向。

这个例子里值得记住的不是数字，而是**名次翻转的原因**：不是 A 突然变重要了，而是 B 的一个估计被证据替换掉了。优先级工作的很大一部分其实不是算分，是核对那四个数是怎么来的。

## 为什么排不出一张总榜

三个原因，一个比一个更根本。

**第一，比较对象一直在变。** 新需求进来时，它不是“加在队尾”，而是插进候选池重新比一次。同一条“增加两步验证”，在一个只有个人用户的季度里排不上号，在一个刚签下两家银行的季度里可能直接排第一。变的不是这条需求，是它的对手盘。

**第二，价值本身会随时间漏掉。** 同一件事，这个月上线和下个月上线不是一回事。有个专门的词叫 Cost of Delay（延迟成本）：如果这件事晚一个月做，损失掉的价值是多少[2]。Don Reinertsen 在《The Principles of Product Development Flow》里把它称为“如果只能量化一件事，就量化这个”[3]。这也是为什么一份排好的榜过几周就开始失效——它是在某个时点算出来的，而价值在持续流走。SAFe 在讲 WSJF 时说得更直接：在流动的系统里，优先级必须持续更新，**按顺序排（sequencing）比按每条工作各自的投资回报率打分更能带来好的结果**[4]。

顺带解释一个看起来多余的写法。SAFe 的 WSJF 用的是“延迟成本 ÷ 工期”，而不只是延迟成本[4]。道理是：价值相近的两件事，先做短的那件，能更早开始产生收益，一段固定产能里落地的总价值更大。（这里只讲结论的直觉，不做推导。）

**第三，分数的精度撑不住名次的精度。** Impact 只有五档，Confidence 只有三档，Reach 和 Effort 也常常是粗估。两个需求算出来 200 和 195，这五分的差距完全落在估计误差之内。第 7 名和第 9 名的先后，其实不会改变任何人做任何事。

还有一个更实际的提醒：产品团队常见的一种浪费，是花两周争论两个小需求谁先做——这两件加起来的工作量，可能还不到争论花掉的时间。

## 那实际怎么做

**第一，把“排 200 名”换成“接下来做什么”。** 真正有决策价值的只在边界附近：接下来这批要不要带上它。排到第 187 名和第 193 名，对你的行动没有任何区别。所以你要维护的不是一张总榜，而是“接下来四到六周做什么”，加上一份“这一轮明确不做”的清单。

**第二，先做减法，再排序。** 对池子里的每条需求问一句：如果这个季度完全不做它，会发生什么？如果答案接近“没什么人会发现”，它就不该继续留在候选池里消耗你的比较成本。Markovitz Consulting 有一篇短文叫《The Priority Trap》，里面的观察很贴切：给待办打 A、B、C 三级几乎是无效的，因为 C 级永远轮不到被做；真正要做的判断是“做，还是不做”，决定了要做再定什么时候做[5]。

**第三，排序有节奏，不是每天重排。** 已经在做的活中途停下换别的，本身有成本——切换耗神，半成品堆积。所以取舍应该按节奏发生：每两周或每个迭代看一次池子，节奏之内不再重排。这也意味着必须给“真的紧急”留出容量：线上故障、合规要求、时间窗明确的机会可以插队。但如果插队没有上限，你的排序体系就退化成“谁喊得响”。

下面这张图是这条判断链的样子：

```mermaid
flowchart LR
  A["新需求进来"] --> B{"是硬约束、硬依赖或已承诺的吗？"}
  B -->|"是"| C["进队列，只定什么时候做"]
  B -->|"否"| D["进候选池，补齐四个估计"]
  D --> E["和当前候选比：做它要放弃什么？"]
  E --> F{"比被放弃的那件更值吗？"}
  F -->|"是"| G["放进下一批"]
  F -->|"否"| H["明确写下不做"]
  G --> I["下个节奏再重排一次"]
  H --> I
```

## 什么情况下轮不到你排

有三类事情不需要比较，直接进队列：

- **外部硬约束**：法律、合规、安全审计。它们不是“做不做”的问题，只是“什么时候做”。
- **硬依赖**：B 再高分也得等 A 做完。比如数据迁移不做完，任何报表改动都没有意义。依赖关系会直接推翻分数顺序。
- **明确承诺**：已经写进合同的客户交付。这属于承诺，不是判断。

它们的共同点是“不做”不成立，而打分是用来在可选之间比较的——没有可选，打分就没有意义。

还有一种情况不是“轮不到你排”，而是“现在还不该排”：如果池子里所有需求的 Confidence 都在 50% 以下，说明你缺的不是排序方法，而是信息。这时候更该做的是先把它弄明白——去问用户、去看数据、做个最小验证——而不是把一堆猜测排出一个看起来很精确的名次。

这也接得上前面两篇。第一篇说产品经理认领的是“这件事对用户有没有价值”那一类风险；第二篇说要把用户的原话还原成一个具体处境。到了这里，处境搞清楚了，池子里躺着 200 个这样的处境，而你这个季度只能填掉三五个。**这时候你的产出不是一张榜，而是一连串有人负责的取舍**——每一次你都得说得出，被放弃的是哪一件。

<details>
<summary>一个练习，先自己算再看提示</summary>

你们团队下个迭代有 6 人月产能。三条候选：A 拍照识别单据（Reach 150 人/季度，Impact 2，Confidence 50%，Effort 3）；B 修复导出乱码（Reach 80，Impact 3，Confidence 100%，Effort 0.5）；C 新首页（Reach 3000，Impact 0.5，Confidence 50%，Effort 5）。

提示：算出来分别是 50、480、150，分数排序是 B > C > A。但真实结论不是“这一轮只做 B”，而是：B 只花 0.5 人月，加上 C 的 5 人月一共 5.5，两者正好装进 6 人月，A 留给下一轮。排序的作用是决定“先拿哪一块产能”，不是决定“这一轮只做哪一件”——这正是“排下一批”和“排总榜”的区别。

</details>

## 术语表

- 机会成本：做一件事的真实价格，不是为了它花掉的人力，而是被放弃的那件最有价值的事的价值。产能固定时，值不值得做只能靠比较回答。
- RICE：把一条需求翻译成四个可以核对的估计——触及多少人、影响多大、有多大把握、要花多少人月——再合成分数，用于同一批候选之间的相对比较。
- 延迟成本（Cost of Delay）：这件事晚一个月做会损失多少价值。它把“时间”变成排序时的一项，也解释了为什么一份排好的榜会过期。
- 假精确：Impact 只有五档、Confidence 只有三档，估计本身就很粗；把这样的估计算到小数点后，得到的名次差别其实落在误差里。

## 来源

1. [Intercom 官方博客：RICE 四个因子、刻度与公式的原始出处](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)
2. [Cost of Delay：延迟成本的定义与常用表达方式](https://en.wikipedia.org/wiki/Cost_of_delay)
3. [Reinertsen《The Principles of Product Development Flow》第一章：如果只能量化一件事，就量化延迟成本](http://lpd2.com/wp-content/uploads/2013/06/ReinertsenFLOWChap1.pdf)
4. [SAFe：WSJF 用延迟成本除以工期，以及流动系统中优先级需要持续更新](https://framework.scaledagile.com/wsjf/)
5. [Markovitz Consulting《The Priority Trap》：按 A、B、C 分级几乎无效，真正要判断的是做还是不做](https://www.markovitzconsulting.com/blog/blog/the-priority-trap)

---

原文：https://pangzhengboyin.com/articles/what-prioritization-actually-decides-b6d79547

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com