← 词汇表 · 方法论

RICE 与 WSJF 对比

RICE 和 WSJF 是两种量化的优先级排序框架。RICE 按 Reach × Impact × Confidence ÷ Effort 给事项打分，权衡产出潜力与成本。WSJF（加权最短作业优先，源自 SAFe）按 Cost of Delay ÷ Job Duration 打分，明确揭示等待所付出的代价。RICE 适合产品探索；WSJF 适合项目群层面的流动效率。

开始使用——连接你的技术栈查看产品

每个框架是如何运作的

RICE 把一个候选功能拆解为四个组成部分：Reach（每个周期有多少用户受到影响）、Impact（一个量级分数，通常在 0.25 到 3 之间）、Confidence（反映你对估算有多确定的百分比），以及 Effort（人-周）。用分子的乘积除以 Effort，就能得到各事项之间可比较的分数。因为 Confidence 是明确列出的，这个模型会惩罚凭空猜测，而不是把它掩盖起来。

WSJF 由 Scaled Agile Framework 引入，关注的是经济上的紧迫性，而不是产出规模。Cost of Delay 是用户业务价值、时间紧迫性，以及风险降低或机会激活三者之和。除以 Job Duration 意味着，一个延迟成本很高、但能快速交付的小事项，会胜过延迟成本相同、但规模大、交付慢的事项——这直接对抗了那种优先做大项目而忽视高影响力快速见效项目的常见习惯。

何时用 RICE，何时用 WSJF

RICE 最适合产品探索场景，在这类场景中你需要用一套共同的语言，比较各种各样的想法——新功能、实验、缺陷修复。它在较小、自主的产品团队中效果很好，那里由一位 PM 负责打分。Confidence 乘数让它对你实际知道的东西和你只是假设的东西保持诚实。

WSJF 更适合项目群层面的规划，尤其是当多个团队争夺共享的工程产能、你需要证明的是顺序而不仅仅是选择时。因为它量化了延迟的经济成本，所以更容易向工程管理层和财务部门证明其合理性。已经在实践 SAFe PI 计划的团队会发现，WSJF 自然地融入了他们的节奏。如果你的主线把收入、反馈和工作项联通在一处——就像 AIOProductOS 这样的 Product Operating System 所做的那样——你就可以查阅真实的订阅 MRR 和支持请求量，把 Cost of Delay 的估算锚定在真实数字上，而不是纯粹的直觉。这不能消除判断的成分，但能缩小分数与经济现实之间的差距。

两个框架的常见陷阱

当输入的是猜测时，两个框架都会产生虚假的精确性。被过度乐观的 Reach 或 Impact 估算撑高的 RICE 分数，会持续把面子工程式的功能推到前面。被未经衡量的时间紧迫性拉高的 WSJF 分数，会让本来不需要优先交付的事项被赶着推进。补救办法对两者是一样的：把分数锚定在真实数据上——实际用户数、实测的转化影响、观察到的流失信号——而不是委员会式的直觉。

这两个框架都不能替代战略判断。一份纯粹按 RICE 或 WSJF 排序的待办列表，偶尔会与你的产品愿景相矛盾，或者忽略市场时机。把分数当作讨论的起点和偏见检查工具，而不是取消决策过程的算法。最持久的做法是，足够一致地使用一个框架，让团队能够发现异常并展开讨论，而不是每个季度就换一套系统。

常见问题

RICE 与 WSJF 对比——常见问题

我可以在同一份待办列表上同时使用 RICE 和 WSJF 吗？

可以，但如果团队对同样的事项打出不同的分，又无法调和这些结果，就会产生混乱。更干净的做法是选定一个作为待办列表的标准分数，另一个只是非正式地用来对高风险决策做压力测试。

在每个框架中，最难估算的输入是什么？

在 RICE 中，Reach 经常被高估，因为团队计算的是用户总数，而不是真正受该功能影响的那个细分群体。在 WSJF 中，Cost of Delay 最难，因为它要求给紧迫性赋予一个金钱或时间上的价值——这是大多数团队还没有练习过的事。

WSJF 适用于早期创业公司吗？

可以，但在小规模下，它的优势会打折扣。WSJF 的强项在于协调多个团队争夺共享产能时的工作排序；而只有一个小团队时，RICE 的简单性往往更胜一筹。一旦你有了多个小队，或者建立了季度规划节奏，WSJF 就会变得更有价值。

我们应该多久重新给待办列表打一次分？

大多数团队是在规划节点——迭代、季度或 PI——重新打分，而不是持续不断地进行。只有当你的输入数据（收入影响、用户数、支持量）能从一个实时系统中自动更新，而不需要手动输入时，持续重新打分才值得投入这份精力。