RICE 评分法是一种给需求排序的量化方法，用触达范围、影响程度、信心水平和投入成本四个字段算出一个相对得分，得分越高通常越优先。它把“我觉得这个重要”转成可以横向比较的数字，适合在需求池里排先后；功能怎么设计、开发任务按什么顺序执行，属于另外的问题。下面按定义、取值口径、边界、算例和常见误解逐项说明。
要点总览（TL;DR）
- RICE 是 Reach、Impact、Confidence、Effort 四个字段的缩写，公式为（Reach × Impact × Confidence）÷ Effort，得分越高通常越优先。
- 四个字段需要事先约定取值口径：Reach 写明统计周期，Impact 用分级，Confidence 用百分比或分级折算，Effort 统一单位并包含协作投入。
- RICE 用于需求池中同类需求的相对排序，不用于决定产品功能布局，也不用于安排开发任务的执行顺序。
- 得分是辅助判断，得分接近时需结合季度目标、客户承诺、合规时限和依赖关系综合决定。
- 常见误用包括把得分当绝对结论、忽略统计周期、信心水平随意填满分，以及需求变化后不重新评分。
RICE 评分法一句话说清是什么
RICE 是 Reach（触达范围）、Impact（影响程度）、Confidence（信心水平）、Effort（投入成本）四个英文词的缩写。它输出的是一个相对得分，用来回答“需求池里先做哪个”，不回答“这个功能怎么设计”。
理解这个定义要抓住两点。第一，RICE 的比较对象是需求条目，得分只在同一批需求之间有意义，跨团队、跨季度直接比分数往往失真。第二，RICE 是辅助判断工具，它把讨论从主观偏好拉回到可核对的估计值上，最终做不做、什么时候做，仍要结合业务目标、合规要求和资源约束来决定。
四个字段的中文含义可以先用一句话记住：触达范围看“有多少对象受影响”，影响程度看“对单个对象影响多大”，信心水平看“前两项估计有多可靠”，投入成本看“要做这件事得花多少”。
四个字段的含义与计算口径
RICE 的公式是：RICE =（Reach × Impact × Confidence）÷ Effort。分子衡量这件事带来的价值总量，分母衡量取得这份价值要付出的代价。四个字段的取值口径需要团队事先约定并写进评分说明，否则不同人填出的数字无法比较。
| 字段 | 含义 | 常用取值方式 | 填写要点 |
|---|---|---|---|
| Reach 触达范围 | 一段时间内受影响的对象数量 | 按统计周期内的用户数、订单数、客户数等计数 | 必须写明周期，如“每季度”“每月”，不同周期的数字不能直接混用 |
| Impact 影响程度 | 对单个对象的影响强度 | 分级取值，常见做法是 3（极大）、2（高）、1（中）、0.5（低） | 分级标准要写成可判断的描述，避免凭感觉打分 |
| Confidence 信心水平 | 对 Reach 和 Impact 估计的可靠程度 | 用百分比表示，如 100%、80%、50%；也可用高、中、低折算 | 信心来自数据、调研还是猜测，应有依据可查 |
| Effort 投入成本 | 完成该需求所需投入 | 常用人月或人周，也可用故事点等团队统一单位 | 单位全团队统一，包含设计、开发、测试等必要环节 |
取值时有几个容易出错的细节。Reach 统计的是受影响的独立对象数量，同一用户多次触发只算一次，否则会虚高。Impact 的分级不宜过细，四到五档足够区分，档位太多反而增加争议。Confidence 反映的是估计质量，有历史数据支撑可以给高值，仅凭直觉应给低值。Effort 要把协作成本算进去，只算开发工时容易低估实际投入。
公式中 Confidence 用百分比时，计算前需换算成小数，例如 80% 记为 0.8。Effort 作为分母，取值不能为零，投入极小的需求也应给出一个最小估计单位，避免出现无法比较的异常高分。
边界：RICE 能排什么、不排什么
RICE 的适用对象是需求池中的需求条目，用途是在同一批需求之间做相对排序。它给出的是“先做哪个”的参考顺序，不负责决定产品功能如何布局与取舍，也不用于安排开发任务的先后执行顺序。
把边界说清楚，能避免三类误用。第一类是把 RICE 得分当成功能规划结论，看到某个需求分高就认为产品必须做这个功能，忽略了产品定位和整体结构。第二类是拿 RICE 去排开发任务，任务之间有依赖关系、有并行条件，排序逻辑与需求价值评估并不相同。第三类是把得分当绝对结论，分数只是辅助判断，业务决策还要考虑战略方向、合规要求、客户承诺等得分之外的因素。
可以这样区分：RICE 处理“值不值得做、先做哪个”的问题；功能布局处理“产品长成什么样”的问题；任务排期处理“谁在什么时候做什么”的问题。三者对象不同，方法和输出也不同。
当需求池里的条目积累到几十条、讨论开始依赖嗓门和职级时，把 RICE 字段固定下来会更有价值。团队可以在需求管理工具中为每个需求条目维护触达范围、影响程度、信心水平和投入成本字段，按公式算出得分并排序，评审时直接对照字段讨论取值是否合理，把争论从“我觉得”转到“这个数怎么来的”。ONES 支持在需求工作项上配置自定义字段并组织需求池视图，排序和评审记录可以留在同一处，便于后续复盘取值口径。是否采用这类工具承载，取决于团队已有的需求管理流程和字段规范是否稳定。
一个完整算例：三条需求怎么排出先后
下面用三条演示需求说明计算过程。以下数值均为情景假设，用于展示算法，不代表任何真实产品或团队的数据。
假设团队统计周期为一个季度，Impact 采用 3、2、1、0.5 四档，Confidence 用百分比，Effort 用人周。
| 需求 | Reach（人/季度） | Impact | Confidence | Effort（人周） | 计算过程 | RICE 得分 |
|---|---|---|---|---|---|---|
| 需求 A：优化注册流程 | 8000 | 2 | 80% | 4 | (8000 × 2 × 0.8) ÷ 4 | 3200 |
| 需求 B：增加导出功能 | 1200 | 3 | 50% | 2 | (1200 × 3 × 0.5) ÷ 2 | 900 |
| 需求 C：调整消息通知 | 5000 | 1 | 100% | 3 | (5000 × 1 × 1.0) ÷ 3 | 约 1667 |
按得分排序，需求 A 最高，需求 C 次之，需求 B 最低。解读这个结果时要注意几点。需求 A 得分高，主要来自触达范围大且投入适中；需求 B 的 Impact 最高，但触达范围小、信心水平低，说明它影响强却缺少数据支撑，适合先做小范围验证再重新评分；需求 C 信心水平满分，因为改动明确、影响可预期，但影响强度低，得分居中。
得分接近时，比如两条需求相差不到 10%，单看数字不足以分出先后，可以结合业务判断：是否与季度目标直接相关、是否有客户承诺或合规时限、是否存在依赖关系需要先做前置需求。算例中的假设条件包括统计周期统一为一个季度、Impact 分级标准一致、Effort 已包含设计与测试投入；条件变化时得分会随之变化，排序结论也应重新核对。
容易混淆的相邻概念与常见误解
RICE 与几种常见排序思路的区别，可以用同一口径对照来看。
| 概念 | 比较的对象 | 核心逻辑 | 与 RICE 的关系 |
|---|---|---|---|
| 按价值排序 | 需求 | 只看收益大小 | RICE 在价值侧加入触达范围和信心水平，并用投入做分母 |
| 按成本排序 | 需求 | 只看投入多少，优先做便宜的 | RICE 把成本放在分母，避免低成本低价值的需求排到前面 |
| 价值成本比 | 需求 | 收益除以成本 | 思路接近，RICE 的差别在于把收益拆成触达、影响、信心三项分别估计 |
| 任务优先级 | 开发任务 | 按截止时间、依赖关系、阻塞情况排序 | 对象不同，RICE 排需求，任务优先级排执行 |
| 功能取舍 | 产品功能 | 依据产品定位和整体结构决定做不做 | RICE 提供参考输入，不替代功能规划决策 |
常见误解集中在几处。把得分当绝对结论是其一，得分高只说明在这批需求里相对更值得先做，换一批需求或换一个统计周期，排序可能变化。忽略统计周期是其二，Reach 不写周期，数字就失去含义，季度数据和月度数据混在一起算，结果没有可比性。信心水平随意填是其三，所有需求都填 100%，Confidence 就退化成常数，公式失去区分作用，填之前应说明依据来自数据、调研还是假设。
用 RICE 决定功能布局是另一个典型误用。得分能告诉你哪个需求更值得投入，不能告诉你产品应该有几个模块、入口放在哪里、功能之间如何组织。这类问题需要产品结构和用户路径的分析，RICE 只是输入之一。还有一种误解是把 RICE 当成一次性动作，需求池变化后不重新评分，旧分数继续沿用，排序就会逐渐偏离实际情况。比较稳妥的做法是固定评分口径、定期复核字段取值，并在评审记录中保留每次调整的理由。
常见问题
RICE 得分可以直接跨团队或跨季度比较吗？
通常不建议直接比较。RICE 得分是相对值，只在同一批需求、同一套取值口径下才有可比性。不同团队的 Reach 统计对象、Impact 分级标准、Effort 单位可能不同，跨团队比分数容易得出误导性结论。跨季度比较时，如果统计周期或业务规模发生变化，也应重新核对字段取值，而不是沿用旧分数。
Confidence 应该怎么填才不至于形同虚设？
Confidence 反映的是 Reach 和 Impact 两项估计的可靠程度，填写时要能说清依据。有历史数据或调研结果支撑，可以给较高值；仅凭经验判断或客户口头反馈，应给较低值。团队可以约定几个档位并写明对应条件，例如有数据验证、有小范围调研、仅有假设。如果所有需求都填 100%，这一项就失去区分作用，公式结果会偏向触达范围大或影响分级高的需求。
需求池里的需求数量不多时，还有必要用 RICE 吗？
需求条目较少、争议不大时，RICE 的收益有限，直接按业务目标讨论也能得出结论。当需求积累到几十条、评审时难以形成一致意见，或者不同角色对“哪个更重要”判断差异明显时，固定四个字段并计算得分更有价值，它能让讨论聚焦在取值依据上。是否采用取决于需求池规模和评审效率，没有统一的数量门槛。
需求做到一半发现估计偏差很大，RICE 分数要重算吗？
建议重算并记录调整原因。Effort 明显超出原估计，或 Reach、Impact 因业务变化不再成立时，旧分数已经不能反映当前情况。重算时保留原取值和调整理由，便于后续复盘估计偏差来自哪里。定期复核比一次性评分更稳妥，尤其是在需求池持续变化、季度目标调整之后。
RICE 和 Kano 模型、MoSCoW 方法能一起用吗？
可以配合使用，但各自回答的问题不同。Kano 模型关注需求满足后对用户满意度的影响类型，MoSCoW 按必须做、应该做、可以做、暂不做分级，RICE 给出可比较的数值排序。实践中可以先用分级方法筛掉明显不做或必须做的条目，再对剩余需求用 RICE 排相对先后。组合方式由团队流程决定，关键是避免同一批需求套用多套口径却互不对照。
