RICE 评分在研发团队落地，关键在四件事：把 Reach、Impact、Confidence、Effort 四个字段的口径写死，按固定节奏对需求池逐条打分，用 RICE 值排序并划定本期取舍线，再用实际结果回看校准。公式本身很简单，真正决定成败的是字段定义是否统一、打分是否有依据、评审是否有固定角色和节奏。本文按这四步给出可直接使用的字段表、流程分工、排序规则、计算示例和检查清单。
要点总览（TL;DR）
- RICE 落地先统一四个字段口径：Reach 按季度统计受影响人数或单量，Impact 用固定档位，Confidence 用 100%/80%/50% 三档，Effort 按人月估算，并写明数据来源和负责人。
- 按“入池—初评—研发估算—复评会”四步走，产品经理负责 Reach、Impact、Confidence 初值，研发负责人负责 Effort，业务方确认影响判断，每两周完成一轮打分。
- 排序按 RICE 值降序，取舍线结合本期可用人月和需求累计 Effort 确定，低分需求标注关闭原因并保留记录，避免重复讨论。
- 交付后一个季度回看估算与实际结果，重点校准 Confidence 偏差，口径调整形成记录并从下一打分周期生效。
- 用字段口径、角色分工、评审节奏、排序规则、回看机制五项清单季度自查，五项全部通过才算真正落地。
RICE 评分落地先定哪几个字段口径
RICE 的分歧几乎都出在口径上：同一个需求，产品经理估的 Reach 是“影响 200 个用户”，研发理解成“影响 200 家企业”，算出来的分数自然对不上。落地第一步是把四个字段的业务含义、取值档位、时间窗口和数据来源写成一张表，团队按表打分，不再各说各话。
四个字段的基本含义如下：Reach 表示一个时间窗口内受影响的用户或业务对象数量；Impact 表示对单个对象的影响强度；Confidence 表示对前两项估算的把握程度；Effort 表示投入的人力和时间成本。RICE 值 = Reach × Impact × Confidence ÷ Effort，Effort 放在分母，意味着成本越高分数越低。
| 字段 | 业务含义 | 取值档位 | 数据来源 | 负责人 |
|---|---|---|---|---|
| Reach | 一个季度内受该需求影响的用户数或业务单量 | 按实际数量填写，统一用“人/季”或“单/季” | 埋点数据、订单或工单记录、客户名单 | 产品经理 |
| Impact | 对单个对象的影响强度 | 3=决定性、2=显著、1=一般、0.5=轻微、0.25=极小 | 用户访谈、客诉记录、业务方判断 | 产品经理，业务方确认 |
| Confidence | 对 Reach 和 Impact 估算的把握程度 | 100%=有数据支撑、80%=有较强依据、50%=有合理推测 | 数据报表、访谈记录、历史同类需求结果 | 打分人自评，评审会质询 |
| Effort | 完成需求所需的人月投入 | 按人月填写，含设计、开发、测试 | 研发估算、历史同类需求工时 | 研发负责人 |
统一口径有三个常用做法。一是取值档位固定，Impact 和 Confidence 只允许从预设档位中选，不允许填 1.7 这类中间值，减少随意性。二是时间窗口统一，Reach 一律按“一个季度”估算，避免有人按月度、有人按年度。三是单位统一，Reach 用人数还是单量、Effort 用人月还是人天，全团队只保留一种写法，并在字段说明里注明。
口径表定完后要有一个明确的生效动作：字段说明写入需求池的字段描述，打分模板同步更新，新入池需求一律按新口径打分。旧需求如果口径差异较大，标注“旧口径”并注明换算方式，避免新旧分数混排造成误读。
按什么节奏和角色完成一轮打分
口径统一后，需要一条固定的流程把打分跑起来。建议按“入池—初评—复评—定稿”四步走，每步有明确的输入、动作和输出，避免打分变成产品经理一个人的事。
| 步骤 | 输入 | 动作 | 负责人 | 输出 |
|---|---|---|---|---|
| 需求入池 | 业务方提出的需求、客户反馈、数据洞察 | 补齐需求描述、目标用户、期望时间，按模板提交 | 需求提出方 | 待打分需求条目 |
| 初评 | 入池需求 | 填写 Reach、Impact、Confidence 初值，标注依据 | 产品经理 | 带初值的需求条目 |
| 研发估算 | 初评后的需求 | 给出 Effort 估算，说明假设和依赖 | 研发负责人或技术负责人 | Effort 值及估算说明 |
| 复评会 | 完整打分的需求 | 逐条质询依据，调整分歧字段，确认最终分值 | 产品、研发、业务方代表 | 定稿分值及评审记录 |
角色分工上，产品经理对 Reach、Impact、Confidence 的初值负责，需要给出数据或访谈依据；研发负责人对 Effort 负责，估算要写明假设，比如是否包含联调、是否依赖外部团队；业务方代表负责确认 Impact 是否符合业务实际，尤其是涉及收入或客户承诺的需求。三方各管一段，任何一方缺位，打分都会失真。
节奏上，建议每两周完成一轮打分，复评会固定在同一个时间，比如每双周周三下午，时长控制在 60 到 90 分钟，单次评审需求数量控制在 10 到 15 条，保证每条都能被质询到。打分周期与迭代周期对齐，复评会结束后直接进入排序环节，避免打分结果搁置过期。
争议需求的裁决方式要提前约定。常见做法是：Reach 和 Impact 的分歧以数据为准，没有数据时由业务方代表拍板并记录理由；Effort 的分歧由研发负责人最终确认，产品方可以要求拆分需求降低估算不确定性；Confidence 的分歧按“就低不就高”处理，即评审会认为依据不足时下调一档。所有裁决理由写入评审记录，作为后续校准的素材。
打分动作需要有承载的地方。需求池、字段自定义、评审记录如果散落在表格和聊天记录里，口径很容易再次漂移。ONES 的需求管理支持为需求自定义字段并维护状态流转，打分值和评审结论可以随需求条目一起留存，复评会后的排序结果也能在同一处查看，减少多头维护带来的口径不一致。
如何用 RICE 值排序并划定取舍线
打分完成后，按 RICE 值从高到低排序只是第一步，真正要回答的是“本期做哪些”。排序结果必须和产能挂钩，否则分数再精确也无法转化为决策。
计算方式统一为 Reach × Impact × Confidence ÷ Effort，其中 Confidence 用小数表示，比如 80% 写成 0.8。排序时按 RICE 值降序排列，分值相同的需求按战略关联度或交付风险做次级排序，次级规则也要提前写进排序说明，避免临场争论。
取舍线的确定依据主要有三类。一是产能约束，用本期可用的人月总量除以需求平均 Effort，得出本期大致可承接的需求数量，累计 Effort 达到产能上限的位置就是取舍线。二是资源约束，某些需求依赖特定团队或外部系统，即使分数高也可能排到下一期。三是战略约束，管理层明确要求推进的方向性需求，可以设置少量“战略保留名额”，但名额数量和适用条件要公开，避免成为随意插队的通道。
| 排序位置 | 需求池状态 | 处置方式 |
|---|---|---|
| 取舍线以上 | 本期候选 | 进入排期，明确负责人和交付时间 |
| 取舍线附近 | 待定 | 复评会确认是否拆分或调整范围后纳入 |
| 取舍线以下、分数中等 | 下期候选 | 保留分值，下期重新参与排序 |
| 分数持续偏低 | 观察或关闭 | 连续两期排名靠后且无新依据的，关闭并记录原因 |
低分需求不建议直接删除。更稳妥的做法是标注关闭原因，比如“影响面小”“成本过高”“已有替代方案”，并保留原始打分记录。这样后续业务方再次提出类似需求时，可以直接调出历史判断，减少重复讨论。对于因 Effort 过高而低分的需求，可以单独标记为“待拆分”，作为下一轮需求细化的输入。
一个需求池的打分示例
下面用一个演示情景说明四个字段如何取值并算出排序结果。假设某研发团队本期可用产能约为 12 人月，需求池中有 5 条需求，打分口径按前文的字段表执行。
| 需求 | Reach（人/季） | Impact | Confidence | Effort（人月） | RICE 值 | 排序 |
|---|---|---|---|---|---|---|
| A 订单导出优化 | 800 | 2 | 0.8 | 2 | 640 | 1 |
| B 客户标签体系 | 500 | 3 | 0.5 | 4 | 187.5 | 3 |
| C 登录页改版 | 2000 | 1 | 1.0 | 3 | 666.7 | — |
| D 报表订阅推送 | 300 | 2 | 0.8 | 1.5 | 320 | 2 |
| E 权限细粒度控制 | 150 | 3 | 0.5 | 5 | 45 | 4 |
计算过程以需求 A 为例：Reach 800 人/季，Impact 取 2（显著），Confidence 取 0.8（有较强依据），Effort 为 2 人月，RICE 值 = 800 × 2 × 0.8 ÷ 2 = 640。需求 C 的 Reach 最高，达到 2000 人，但 Impact 只有 1，Confidence 为 1.0，Effort 为 3 人月，RICE 值 = 2000 × 1 × 1.0 ÷ 3 ≈ 666.7。这里出现一个需要口径约定的情况：C 的分数高于 A，但 C 的影响强度低、涉及全量用户改版，风险较高。团队在复评时约定，Impact 为 1 且涉及全量用户界面的需求，需要额外做灰度验证，Effort 按含验证工作重新估算为 4 人月，RICE 值调整为 500，排序落到 A 之后。这个调整过程本身就体现了口径约定的作用：不是改公式，而是把遗漏的工作量补进 Effort。
按调整后的分值排序，取舍线画在累计 Effort 接近 12 人月的位置。A（2 人月）、D（1.5 人月）、B（4 人月）、C（4 人月）累计 11.5 人月，E（5 人月）超出产能，进入下期候选。如果团队认为 B 的 Confidence 只有 0.5、依据不足，可以按“就低不就高”原则维持 0.5，并在下期补充用户调研后再复评。这个示例说明：不同取值会直接改变排序，Reach 高但 Impact 低的需求未必排第一，Effort 估算遗漏会显著抬高分数，Confidence 的取值需要有依据支撑。
打分结果如何回看与校准
RICE 分数是估算，不是事实。落地一段时间后必须回看，否则口径会逐渐偏离实际，打分也会退化成形式。
回看的时间点建议设在需求交付后一个季度，对比对象是当初的估算值和实际结果：Reach 对比实际触达用户数，Impact 对比业务指标变化，Effort 对比实际投入人月，Confidence 对比估算与实际的偏差幅度。回看由产品经理牵头，研发负责人提供实际工时，业务方提供业务结果数据。
Confidence 的偏差处理是校准的重点。如果某类需求连续多次出现“Confidence 填 0.8、实际偏差超过 50%”的情况，说明该类需求的估算依据不足，下一轮打分时该类需求的 Confidence 上限应下调，或者要求补充数据后才能按高 Confidence 打分。反过来，如果某类需求长期被低估 Confidence、实际结果稳定，可以适当放宽档位。偏差处理的原则是让 Confidence 反映真实把握程度，而不是让打分人凭感觉填一个好看的数字。
| 回看项 | 对比内容 | 偏差判断 | 校准动作 | 记录人 |
|---|---|---|---|---|
| Reach | 估算触达 vs 实际触达 | 偏差超过 30% | 调整该类需求的估算来源或档位 | 产品经理 |
| Impact | 预期影响 vs 业务指标变化 | 方向不一致 | 复核 Impact 档位定义，补充判断依据 | 产品经理、业务方 |
| Confidence | 自评把握 vs 实际偏差 | 连续两次高估 | 下调该类需求 Confidence 上限 | 评审会 |
| Effort | 估算人月 vs 实际人月 | 偏差超过 20% | 更新估算假设，补充遗漏工作项 | 研发负责人 |
口径调整要有记录和生效方式。每次校准形成一条记录，写明调整的字段、调整前后的取值规则、调整原因和生效日期，由评审会确认后更新字段说明。新口径从下一个打分周期开始执行，已定稿的历史需求保留原分值并标注口径版本，保证排序结果可追溯。校准记录本身也是团队的经验沉淀，新成员接手打分时可以直接参考。
落地完成检查清单
判断 RICE 是否真正落地，可以按下面五项逐条核对。每项都有通过标准和证据要求，未达标时给出对应的处理方式。
| 检查项 | 通过标准 | 证据 | 未达标处理 |
|---|---|---|---|
| 字段口径 | 四个字段均有书面定义、取值档位、时间窗口和数据来源，团队按同一版本执行 | 字段定义表、需求池字段说明 | 组织一次口径对齐会，补齐定义后重新打分 |
| 角色分工 | 产品、研发、业务方各自职责明确，每条需求的分值有对应负责人 | 角色分工表、需求条目上的打分人记录 | 明确缺位角色的替代人，复评会点名确认 |
| 评审节奏 | 打分周期固定，复评会按期召开，单次评审需求数量可控 | 会议记录、评审排期 | 固定会议时间，压缩单次评审范围 |
| 排序规则 | RICE 值计算方式统一，取舍线依据产能和约束确定，低分需求有处置记录 | 排序表、取舍线说明、关闭原因记录 | 补充产能测算，明确次级排序规则 |
| 回看机制 | 按季度回看估算与实际结果，Confidence 偏差有处理，口径调整有记录 | 回看记录表、口径版本记录 | 指定回看负责人，先对一类需求做试点回看 |
五项全部通过，说明 RICE 已经从一张公式变成了团队可重复执行的机制。如果只有公式和分数、没有口径表和评审记录，打分很容易在几轮之后流于形式。建议每季度用这张清单自查一次，把未达标项作为下一阶段改进的具体动作，而不是笼统地要求“加强优先级管理”。
常见问题
团队对 Impact 档位的理解不一致，评审会上经常争不出结果，怎么处理？
先把 Impact 档位和业务指标绑定，而不是只写“决定性、显著、一般”这类形容词。例如“显著”对应某个可观察的业务指标变化幅度，评审时对照指标判断，减少主观争论。仍无法达成一致时，由业务方代表拍板并记录理由，下一轮回看时用实际业务结果检验这次判断，逐步修正档位定义。
需求池里历史需求很多，旧口径和新口径的分数混在一起，排序还能用吗？
建议给旧需求标注“旧口径”并注明换算方式，新入池需求一律按新口径打分。排序时优先看同一口径下的分值；新旧混排的需求，可以在复评会上按新口径重新估算关键字段后再参与排序。口径版本随需求条目留存，保证排序结果可追溯。
研发团队规模较小，没有独立的业务方代表参加复评会，流程怎么简化？
可以合并角色，但不能合并依据。产品经理同时承担业务方确认职责时，Impact 的取值必须附上数据或客户反馈记录，不能只凭判断。复评会可以缩短到 30 分钟，重点质询 Confidence 的依据是否充分。角色合并后要在分工表里写明替代关系，避免后续出现无人负责的字段。
RICE 分数算出来之后，管理层要求插入一个低分需求，怎么处理才不破坏机制？
把这类需求纳入事先约定的“战略保留名额”，明确名额数量、适用条件和审批人，并在排序表中单独标注，与常规排序结果并列展示。插入需求占用的产能要从本期可用人月中扣除，相应调整取舍线。这样既保留了管理层的决策空间，也让团队清楚本期产能的实际分配。
回看时发现 Effort 普遍被低估，应该调整公式还是调整估算流程？
优先调整估算流程。常见原因是估算时遗漏了联调、测试、灰度验证等工作项，或者假设了外部团队可以及时配合。做法是把遗漏的工作项补进估算模板，要求研发负责人在估算说明中写明假设和依赖，再观察下一轮偏差是否收敛。公式本身不需要改，Effort 放在分母的设计仍然成立。
