第1章 RICE评分法概述与适用场景
1.1 核心四要素概述
RICE评分法是由Intercom产品团队提出的一套量化优先级框架，通过四个独立维度对需求或项目进行打分，最终计算出可横向比较的优先级得分。四个要素分别是：
| 要素 | 英文 | 定义 | 典型衡量方式 | 常用范围 |
|---|---|---|---|---|
| 覆盖度 | Reach | 在给定时间窗口内，该功能触达的用户或事件数量 | 用户数/季度，事件数/月 | 100 – 10 000+ |
| 影响力 | Impact | 对用户行为或业务结果产生的效果强度 | 非线性分级（0.25, 0.5, 1, 2, 3） | 0.25 – 3 |
| 信心度 | Confidence | 对 Reach 和 Impact 估算的把握程度 | 百分比 | 20% – 100% |
| 投入度 | Effort | 完成该功能所需的总工作量 | 人周 / 人月 | 1 – 20+ |
四个要素通过公式 RICE Score = (Reach × Impact × Confidence) / Effort 合并为一个数值，得分越高优先级越高。
1.2 适用场景与需求类型
RICE评分法最适合有历史数据积累、需要跨团队对齐优先级的中后期产品阶段。以下场景推荐使用：
- 新功能评估 — 在多个候选功能中选出投入产出比最高的方案。
- 产品优化排期 — 对体验优化、性能改进类需求做量化排序。
- 技术基础设施决策 — 评估重构、迁移、工具链升级等工程类项目。
- 季度/月度规划 — 将 backlog 中的需求统一打分，形成透明优先级列表。
不适用的场景：缺乏用户数据的新项目（信心度极低）、紧急合规/安全修复（应直接高优）、纯创意探索阶段（建议先用轻量方法筛选）。
💡 最佳实践：RICE 对“Effort”维度敏感，适合团队对工作量估算有成熟经验时使用；若 Effort 估算偏差过大，建议搭配置信区间或敏感性分析。
1.3 与其他优先级方法对比
| 方法 | 维度 | 核心优势 | 主要局限 | 适用阶段 |
|---|---|---|---|---|
| RICE | 4维量化 | 覆盖度+信心度，结果可复现 | 需要历史数据，计算成本较高 | 中后期 / 数据充足 |
| MoSCoW | 分类定性 | 极简，沟通成本低 | 主观性强，难以跨需求比较 | 早期 / 战略对齐 |
| Kano 模型 | 用户满意度 | 区分基本/期望/兴奋型需求 | 调研设计复杂，样本偏差大 | 调研期 / 用户洞察 |
| ICE | 3维量化 | 简洁，适合快速筛选 | 缺少覆盖度维度，易遗漏广度 | 快速实验 / 假设验证 |
| 价值 vs 努力矩阵 | 2维 | 直观可视化，适合高层决策 | 过于粗粒度，无法处理大量需求 | 战略层 / 组合管理 |
关键区别：RICE 是唯一同时考虑“覆盖度”和“信心度”的主流框架，因此特别适合用户基数大、需要量化评估 ROI 的产品团队。
1.4 前置条件
- 用户行为数据可用— 能获取活跃用户数、功能使用率等基础指标。
- 团队有工作量估算经验— 能给出相对稳定的人周/人月数值。
- 需求描述已结构化— 每个待评分项都有明确的功能边界和预期收益。
- 评分标准已统一— 团队对 Impact 分级、Confidence 百分比定义达成共识。
1.5 操作步骤：RICE 评分典型流程
- 步骤 1：准备需求列表 — 将待排期的需求按统一模板描述（目标、用户群、预期效果）。
- 步骤 2：估算 Reach — 基于历史数据或预估模型，填写每个需求的触达用户数/事件数。
- 步骤 3：评定 Impact — 使用团队约定的非线性标尺（如 0.25、0.5、1、2、3）打分。
- 步骤 4：设定 Confidence — 根据数据来源的可靠性赋予 20%–100% 的信心值。
- 步骤 5：评估 Effort — 由技术负责人估算人周/人月，并注明估算依据。
- 步骤 6：计算并排序 — 代入公式得出 RICE 得分，按降序排列形成优先级看板。
RICE Score = (Reach × Impact × Confidence) / Effort
示例计算：
功能A：Reach=2000用户/季度, Impact=3, Confidence=80%, Effort=4人周
RICE_A = (2000 × 3 × 0.80) / 4 = 1200
功能B：Reach=500用户/季度, Impact=5, Confidence=50%, Effort=2人周
RICE_B = (500 × 5 × 0.50) / 2 = 625
→ 功能A 优先级高于 功能B1.6 输入输出物
| 类型 | 内容 | 格式 / 载体 |
|---|---|---|
| 输入 | 待评分需求列表、用户数据报表、工作量估算记录 | 产品需求文档 / 电子表格 / Jira 条目 |
| 输出 | RICE 优先级排序表、评分过程记录、决策说明 | 排序看板 / Confluence 页 / 共享表格 |
1.7 责任边界
- 产品经理：负责 Reach 与 Impact 的估算，确保评分标准对齐业务目标。
- 技术负责人：提供 Effort 估算，对技术复杂度与风险给出书面说明。
- 数据分析师：提供 Confidence 所需的数据源与置信度建议。
- 团队负责人 / 总监：最终审批排序结果，对异常需求进行裁决。
1.8 记录材料
- 每轮评分的 原始数据表（含每个需求的四要素数值、得分、评分人）。
- 置信度依据备注（如“基于上周 A/B 测试数据，Confidence=90%”）。
- 变更日志：当需求范围或数据更新时，记录版本变动与重新评分结果。
1.9 异常处理
| 异常情况 | 处理方式 |
|---|---|
| Reach 数据缺失 | 使用同类功能历史均值或最小可行值代替，并在 Confidence 中下调至 ≤50% |
| Impact 评分争议 | 由产品+技术+设计三方投票取中位数，记录少数派意见 |
| Effort 估算偏差 >50% | 拆分为更细粒度的子需求重新评估，或使用 T-shirt sizing 作为交叉验证 |
| 多个需求得分相同 | 优先考虑 Confidence 更高的需求；若仍相同，由负责人决策 |
⚠️ 常见陷阱：不要为了让某个需求排到前面而人为调整 Confidence 或 Impact 数值；每次评分必须保留原始估算记录以备审计。
1.10 验收标准
- 所有待评分需求均已填入四个要素的数值，且每个数值都有来源或备注。
- RICE 得分计算无误（建议用公式批量校验，避免手工计算错误）。
- 排序结果经过至少一次团队评审，异议已记录并处理。
- 评分过程文档归档，可供后续复盘或重新评分时追溯。