1. RICE 优先级排序法概述
适用场景
RICE 适用于需要跨维度量化评估产品功能、技术债或流程改进请求的优先级排序场景，尤其适合产品 backlog 中待办项数量较多（通常超过 20 项）且团队希望减少主观偏见的团队。典型场景包括：
- 季度/月度产品路线图规划会议前的客观评分环节
- 多个部门同时提出需求，用统一标准裁定先做哪项
- 技术重构与业务新功能之间需要做资源分配对比
适用检查表：如果团队 backlog 中每项都有明确的用户群体、业务目标和可量化的执行周期，RICE 效果最佳。若所有需求都缺少数据基础，建议先补数据再评分。
前置条件
- 准备好至少含“功能标题 + 简要描述”的 backlog 列表，每项对应一条待评分记录。
- 团队已定义“核心用户”范围（例如 MAU 或特定角色用户数），确保 Reach 指标可量化。
- 已建立 Impact 等级量规表（通常 0.25 / 0.5 / 1.0 / 2.0 / 3.0 五档），避免评分人自定义档位造成偏差。
- Confidence 评分需由熟悉该功能上下文的产品经理或技术负责人给出，不接受全团队无差别投票。
- Effort 以“人·天”为统一单位，且须使用团队历史平均速率校准。
核心公式
RICE 得分 = ( Reach × Impact × Confidence ) / Effort
其中：
Reach = 预估在给定时间窗口（通常为季度）内触达的用户数（单位：人）
Impact = 按量规表换算的转化/满意度影响系数（无量纲）
Confidence = 对 Reach 和 Impact 判断的把握程度（百分数，取值 20%/50%/80%/100%）
Effort = 整个团队完成该项所需的总人·天数（单位：人·天）
避坑提醒：Effort 处于分母位置，零值和极小值会使得分异常高。所有 Effort 估算必须 ≥ 0.5 人·天；若估算值小于 0.5 则按 0.5 处理。Reach 为零时整体得分为 0，不参与排序。
与 ICE / WSJF 对比
| 维度 | RICE | ICE | WSJF (SAFe) |
|---|---|---|---|
| 核心因子 | Reach, Impact, Confidence, Effort | Impact, Confidence, Ease | Business Value, Time Criticality, Risk Reduction, Job Size |
| 分母 | Effort (人·天) | 无（ICE 为三项相乘） | Job Size (人·天) |
| Effort 粒度要求 | 高，需要人·天估算 | 低，Ease 为主观 1–10 分 | 高，需要 Story Points 或人·天 |
| 适用组织规模 | 中型互联网/产品团队 | 初创团队或快速验证期 | 大型企业 / SAFe 框架 |
| Confidence 处理 | 百分数乘法衰减 | 直观 1–10 分 | 无显式 Confidence 因子 |
选型建议：团队首次实施优先排序且数据分析能力不足时，建议从 RICE 开始，因为 Confidence 因子能天然控制高风险/高不确定项的分数膨胀。已有稳定 Story Points 估算机制的 SAFe 团队可直接用 WSJF。
交付物清单
完成本章学习后，团队应输出以下交付物以备后续评分会议使用：
- RICE 评分卡模板（.xlsx 或 .csv），包含字段：功能 ID、功能名称、Reach、Impact 系数、Confidence ( % )、Effort (人·天)、RICE 得分、评分人。
- Impact 量规定义表，明确 0.25 / 0.5 / 1 / 2 / 3 各档位的定性描述与示例场景。
- Confidence 判定指南，列出 20% / 50% / 80% / 100% 四档对应的数据支撑条件（如：20% = 仅凭直觉 / 100% = 已有 AB 测试结果）。
- Effort 估算校准记录，记录团队最近 3 个迭代的速率偏差，用于后续 Effort 估算的上下限调整。
操作步骤（本章概览级）
- 准备 backlog：整理待评功能列表，每项确保有明确的用户故事和业务目标。
- 定义量规：输出 Impact 量规表和 Confidence 判定指南（交付物清单中的前两项）。
- 初步估算：由产品经理与核心开发人员分别完成 Reach / Impact / Confidence 的初值标注。
- Effort 核准：技术负责人基于历史速率给出最终人·天数。
- 计算与排序：使用公式生成得分的降序列表，并标记 Confidence ≤ 50% 的待办项为“高不确定性”类别。
责任边界
- 产品经理（Owner）：负责定义 Impact 量规表、提供 Reach 数据、最终确认 Confidence 百分数。
- 技术负责人（Co-Owner）：提供 Effort 估算、复核 Reach 的计算口径。
- Scrum Master / 迭代经理：组织评分会议、记录评分差异项、追踪 Confidence 低于 50% 项的数据补齐计划。
- 否决边界：CEO / 业务线负责人保留 20% 的“战略覆盖”权，即前置排名前 5 的功能可被直接指定为 P0，不受 RICE 得分约束。
记录材料
| 记录文件 | 保存位置 | 保留周期 |
|---|---|---|
| RICE 评分卡（历次版本） | 团队共享云盘 / Confluence 空间 | 至下一次完整优先级重评（最长 2 个季度） |
| Impact 量规定义表 | 产品 Wiki 或 Onboarding 手册 | 永久保存（可由新版本覆盖） |
| Effort 估算校准记录 | 工程团队 Wiki / 迭代复盘文档 | 至少保留 4 个迭代 |
| Confidence 判定指南 | 同上 | 随数据基础设施升级时更新 |
异常处理
- Reach 数据缺失：使用上一季度同类功能的 Reach 中位数作为代理值，并在 Confidence 处标记 ≤ 50%。
- Effort 估算差异超过 100%：暂停该功能评分，由技术负责人组织 30 分钟快速拆解会议，拆解后重新估算。
- 多人评分严重不一致：对 Impact 或 Confidence 相差超过 2 个档位的项，产品经理直接指定值为“平均值 + 0.5 档惩罚偏移”，并在备注说明原因。
- 分母 Effort 为 0：强制替换为 0.5 人·天并写入日志，同时在评分卡中标记“Effort_Zero_Override”。
验收标准
- 所有待评分功能均按 RICE 四要素填写完整，无空单元格。
- Confidence 百分数必须来自预定义的四档（20% / 50% / 80% / 100%），不允许出现 30% 或 70% 等非标准值。
- Effort 列格式统一为浮点数，保留 1 位小数，单位“人·天”。
- RICE 得分列由公式自动计算，不出现手动填写值。
- 评分卡中每个功能均标注评分人姓名，支持事后追溯。
- 所有 Confidence ≤ 50% 的项已单独建立数据补齐跟踪任务。