RICE 评分法：公式、计算示例与常见误区

RICE 评分法用一个数字给产品想法排序：覆盖面乘以影响力再乘以信心，然后除以工作量。分数越高，意味着每单位工作换来的预期价值越大。这个方法出自 Intercom 的产品团队，现在已成为比较功能请求的常用方式，适用于凭直觉分不出高下的情形。它最适合用在一份很短的、认真候选的清单上，而且它的好坏完全取决于输入的估算。

RICE 评分的公式是什么？

分数 = 覆盖面 × 影响力 × 信心 ÷ 工作量。覆盖面、影响力和信心之所以相乘，是因为每一项都在放大收益；工作量之所以做除数，是因为同样的收益，花的工作越多就越不划算。覆盖面要选定同一个时间窗口，比如一个季度，并用于所有条目，否则分数就无法比较。

Intercom 的原始文章定义了上表中的取值标准，大多数团队都原样沿用，这样不同人给出的分数才能互相比较。

如何给 RICE 的每个因素打分？

覆盖面来自你已有的数据。对一条功能请求来说，先从提出请求的不同账户数量入手，再加上那些不用开口要求也会去用它的账户的估计数。影响力是最不精确的一项，所以使用五档取值，不要自己编出小数。信心是对猜测的折扣：只有在有使用数据或经过测试的原型时才用 100%，信号很强时用 80%，基本靠猜时用 50%。工作量是所有相关人员的时间，包括设计和测试，单位是人月。

两个人给同一个条目打分，每个因素上的差距都应在一档之内。如果做不到，说明这个条目还没有被理解到足以排序的程度，而这种分歧本身就是发现。

RICE 评分示例是什么样的？

从已跟踪的待办列表里取四条请求，按一个季度来打分。

来算第一行：400 × 1 × 0.8 ÷ 1 = 320。深色模式的覆盖面是导出功能的三倍，但每个人得到的好处很小，所以分数略低于导出功能。Slack 集成的影响力得分不错，却被信心砍掉了一半，这说明下一步该做的是调研，而不是开发。

单点登录排在最后，这一点值得再看一眼。六十个账户的覆盖面很小，但如果这些是较大的账户，而且有几份续约取决于这个功能，那么这个分数就漏掉了方法本身看不到的东西。

RICE 有哪些常见错误？

第一个是虚假的精确。1,247 的覆盖面和 1.3 的影响力看起来很严谨，所包含的信息却不比 1,200 和 1 多。要大胆地取整。

第二个是给已经决定要做的东西打分。这样分数会被一点点调整，直到心仪的那个胜出，这个过程只是在制造遮掩。

第三个是忽略了是谁提的需求。RICE 数的是人，所以来自十个小账户的请求，会胜过来自一个价值超过这十个账户总和的账户的请求。当收入很重要时，加一列收入，把它和分数放在一起看。按账户加权的做法，见如何给功能请求排优先级。

第四个是拿不同时间窗口的分数，或者不同团队各自的取值标准来互相比较。要保持一张表、一个窗口、一套定义。

什么时候该用 RICE 之外的方法？

当你没有覆盖面数据时，可以用 ICE（影响力、信心、易行度），它去掉了覆盖面，并用易行度评分取代工作量，要接受它更粗略。当问题是一个功能带来哪一种价值，而不是价值有多大时，卡诺模型会把请求分为必备型、期望型或魅力型功能，两者搭配得很好。当要决定的是顺序和时间，而不是排名时，路线图的形式更合适，如何制定产品路线图就讲了这一点。

如何让 RICE 分数长期保持可信？

把输入值和分数一起保存，而不只是保存结果，这样任何人都能看出是哪个假设推动了排名。当一个条目的事实发生变化时，要重新评估它，比如新一批请求抬高了覆盖面，或者有工程师发现工作量翻了一倍。发布之后，把预测的覆盖面和影响力与实际发生的情况做对比，并调整团队下一次的估算方式。覆盖面的原始材料，是功能请求追踪中讲到的那份分好组、打好标签的请求清单，而结果则应该写进你回复给提出请求的人的那封回信里。

FAQ

多少分算是好的 RICE 分数? 没有通用的门槛，因为这个数字取决于你的覆盖面窗口和工作量单位。分数只在同一张表内比较，把排名而不是绝对值当作输出。

RICE 和 ICE 评分有什么区别? ICE 把影响力、信心和易行度相乘，不包含覆盖面。它填写起来更快，但当各功能影响的用户数差别很大时就不够准确，而这正是 RICE 要解决的情形。

如何估算一条功能请求的覆盖面? 先数一数提出该请求的账户数，再加上活跃账户中会主动使用它的比例，然后换算成每季度的数字。如果估得很粗，就调低信心因素，而不要编造精确度。

每条功能请求都要用 RICE 打分吗? 不用。打分只值得用在那少数几个接近到需要分出胜负的条目上。明显该做的和明显该拒绝的，不用它也能决定。

本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。

changeloop 相关页面： 开发者文档, changelog 工具对比