假设你入职三个月，第一次参加季度规划会。摆在你面前的池子里有 200 条需求：运营要批量导出，客服要工单合并，老板说该接企微了，销售已经答应客户一个审批流，还有一条你自己觉得重要的搜索体验优化。
很自然的反应是把它们排成一张 1 到 200 的总榜，然后从上往下做。
这张榜排不出来，排出来也没用。原因不复杂，但想清楚之后，你会发现自己对“优先级”这三个字的理解会变。
产能是固定的，所以“值不值得做”是一个比较问题
一个五人的产品小组，一个季度真正能落地的中等规模改动，往往只有三到五件。这不是态度问题，也不是加班能解决的——做完还要测试、灰度、修 bug、处理线上问题。
如果这个季度你手上是 20 人月的产能，而池子里的需求加起来要 200 人月，那么你每答应一件事，就自动否决了别的事。一件事的真实价格不是它自己花掉的那点人力，而是为了它被放弃的那件最有价值的事。 经济学里把这个叫机会成本。
这带来一个反直觉但很关键的结论：“这件事值不值得做”没有离开比较对象的答案。 “批量导出值 80 分”本身不构成判断依据——80 分对上一个 50 分的候选，它值得做；对上一个 200 分的候选，它是浪费。而你手上的 200 分是什么，取决于这个季度池子里还有什么、产能还剩多少。换个季度，同一件事的答案可能反过来。
所以优先级工作真正在做的，不是给每条需求贴一个分值，而是 在产能的边界上反复回答同一个问题：接下来这几件里，做哪件最不亏？ 这也是为什么“给所有需求排一张榜”这个念头一开始就偏了——总榜假设每条需求有一个固定的、可以脱离上下文的分量，而实际存在的是关系。
把“我觉得重要”换成可以被核对的话
先说工具，再说它的局限。目前最通行的量化排序方法之一，是 Intercom 的产品团队在 2016 年前后公开的 RICE，作者是 Sean McBride1。它用四个因子给每条需求打分：
- Reach，触及多少人：在一个固定时间段里，这条需求会影响到多少人，单位比如“人/季度”。要尽量用产品埋点或真实计数，而不是拍脑袋。
- Impact，影响有多大：对每个被影响到的人，改变有多大。Intercom 用的是只有五档的固定刻度：3＝极大、2＝高、1＝中等、0.5＝低、0.25＝几乎可以忽略。刻度故意做得这么粗，就是为了不让人纠结到小数点后面。
- Confidence，有多大把握：你对上面两个估计的信心，100%＝有硬数据、80%＝有一些证据、50%＝基本靠猜。
- 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%：
注意证据同时动了两个方向：触及人数被砍到原来的约七分之一，把握翻了一倍，合起来分数从 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。
第三，排序有节奏，不是每天重排。 已经在做的活中途停下换别的，本身有成本——切换耗神，半成品堆积。所以取舍应该按节奏发生：每两周或每个迭代看一次池子，节奏之内不再重排。这也意味着必须给“真的紧急”留出容量：线上故障、合规要求、时间窗明确的机会可以插队。但如果插队没有上限，你的排序体系就退化成“谁喊得响”。
下面这张图是这条判断链的样子：
什么情况下轮不到你排
有三类事情不需要比较，直接进队列：
- 外部硬约束：法律、合规、安全审计。它们不是“做不做”的问题，只是“什么时候做”。
- 硬依赖：B 再高分也得等 A 做完。比如数据迁移不做完，任何报表改动都没有意义。依赖关系会直接推翻分数顺序。
- 明确承诺：已经写进合同的客户交付。这属于承诺，不是判断。
它们的共同点是“不做”不成立，而打分是用来在可选之间比较的——没有可选，打分就没有意义。
还有一种情况不是“轮不到你排”，而是“现在还不该排”：如果池子里所有需求的 Confidence 都在 50% 以下，说明你缺的不是排序方法，而是信息。这时候更该做的是先把它弄明白——去问用户、去看数据、做个最小验证——而不是把一堆猜测排出一个看起来很精确的名次。
这也接得上前面两篇。第一篇说产品经理认领的是“这件事对用户有没有价值”那一类风险；第二篇说要把用户的原话还原成一个具体处境。到了这里，处境搞清楚了，池子里躺着 200 个这样的处境，而你这个季度只能填掉三五个。这时候你的产出不是一张榜，而是一连串有人负责的取舍——每一次你都得说得出，被放弃的是哪一件。
一个练习，先自己算再看提示
你们团队下个迭代有 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 留给下一轮。排序的作用是决定“先拿哪一块产能”，不是决定“这一轮只做哪一件”——这正是“排下一批”和“排总榜”的区别。