第1章 RICE评分初识：评分维度、核心价值、适用场景
1.1 适用场景
在资源有限、需求无限的产品环境中，RICE 评分被广泛用于以下关键决策场景：
- MVP 范围界定：面对大量候选功能，快速筛选出对核心指标贡献最大、投入产出比最高的功能组，锁定不可跳过的 MVP 边界。
- 版本路线图排序：将功能点按 RICE 总分降序排列，直接形成下一季度或里程碑的交付优先级。
- 跨团队资源分配：作为统一语言，向开发、设计、运营等角色解释“为什么先做 A 而不是 B”，减少主观争议。
- 创意 / 假设验证：在早期阶段（数据稀疏时）通过 RICE 框架量化预期，避免团队陷入“高努力、低信心”的无底洞。
场景选择红绿灯： 当面临功能排期冲突、版本容量受限、或跨部门资源争夺时，应立即启动 RICE 评估流程。
1.2 前置条件
在正式使用 RICE 评分之前，团队需完成以下准备工作：
- 功能清单已到位：至少拥有一份颗粒度均匀的候选功能列表或用户故事。
- 评估对齐会议已召开：产品经理、技术负责人、运营负责人已达成共识——我们将统一使用 RICE 作为优先级排序的唯一标准，并承诺尊重评分结果。
- 基础数据源可用：至少能获取或合理估算每个功能的 Reach（触达范围）和 Effort（努力程度），避免完全凭感觉打分。
⚠ 注意： 如果团队尚未就“核心指标”达成一致（例如“什么是成功”的标准都不明确），建议先对齐北极星指标，否则 Impact（影响程度）的评分将产生严重分歧。
1.3 核心价值
RICE 的本质是将产品直觉转化为可复检、可辩论的数据模型。它与传统矩阵排序的核心差异在于：
| 对比维度 | 传统直觉决策 | RICE 评分决策 |
|---|---|---|
| 决策依据 | 职位高低 / 嗓门大小 / 最近发生的事 | 统一的加权计算 |
| 可回溯性 | 低（事后无法精确还原理由） | 高（每个维度得分都可追溯） |
| 团队对齐成本 | 高（容易陷入无休止辩论） | 低（焦点集中在四个维度的估算差异上） |
| MVP 界定精度 | 模糊的“感觉太多了 / 太少了” | 精确的“前 N 个功能即为 MVP” |
通过这套框架，产品经理可以从“和稀泥的排序员”转变为“数据驱动的主架构师”。
1.4 操作步骤（战略引入层）
- 初始化： 在团队内公布 RICE 评分规范，确认 Reach / Impact / Confidence / Effort 的取值标准。
- 数据填充： 针对每个候选功能，由责任人填写 R、I、C、E 的预估值。
- 校准与讨论： 召开同步会，重点讨论 Confidence 低于 80% 的功能点，消除信息不对称。
- 计算与排序： 使用统一的公式输出优先级列表。
- 截断与交付： 根据团队交付能力（Velocity），从排序列表顶部向下截取，形成 MVP 范围。
1.5 评分维度详解
四个维度缺一不可，任何一个维度归零或过低都会严重拖后总分。
| 维度 | 符号 | 定义 | 典型取值参考 |
|---|---|---|---|
| 触达范围 | R | 每季度（或每个版本周期）该功能将覆盖多少用户或交易量 | 100 / 1000 / 10000+ |
| 影响程度 | I | 该功能对核心指标（如转化率、留存率、收入）的提升倍数或量级 | 0.25 / 0.5 / 1.0 / 2.0 / 3.0 |
| 信心指数 | C | 团队对 Reach 和 Impact 预估的确信程度 | 100%（高） / 80%（中） / 50%（低） |
| 努力程度 | E | 团队完成该功能所需的总人月数（含设计、开发、测试、部署） | 1 / 2 / 3 / 5 / 8+ |
实践技巧： 在第一次使用时，建议强制要求
Confidence不得高于 80%，除非该功能已有 A/B 测试数据支撑。这有助于在早期阶段保持评分的客观性。
1.6 输入与输出物
| 项目 | 具体内容 | 格式 / 载体 |
|---|---|---|
| 输入物 | 原始功能点清单（含功能名称、简短描述、关联用户故事） | Excel / 在线表格 / 项目管理工具 |
| 输出物 | RICE 评分排序表（包含四个维度得分、总分、排名、推荐决策） | 排序列表 / 燃尽图 / 版本范围容器 |
1.7 责任边界
- 产品经理（PM）： 担任评分主持人，负责制定标准、组织评估、校准分歧、公布结果。对最终的 MVP 范围界定负全责。
- 技术负责人（Tech Lead）： 负责提供 Effort（努力程度）的评估，对技术实现的可行性和人月估算负责。
- 运营 / 业务负责人： 负责提供 Reach（触达范围）和 Impact（影响程度）的业务侧预估数据。
- 团队全员： 有权在 Confidence（信心指数）环节提出质疑，并要求数据所有人补充论据。
1.8 记录材料
每一次 RICE 评估都应留下完整的评分档案，以便后续复盘。推荐使用以下字段建立记录：
功能名称 | 触达范围(R) | 影响程度(I) | 信心指数(C) | 努力程度(E) | RICE总分 | 评估日期 | 评估参与人
功能A | 2000 | 2.0 | 0.8 | 5 | 640 | 2024-01-15 | 张三/李四
功能B | 800 | 1.0 | 0.5 | 2 | 200 | 2024-01-15 | 张三/李四1.9 异常处理
⚠ 常见问题：
- 数据缺失： 某个维度完全无法获取数据（如全新领域）。
对策： 将该功能的 Confidence 强制设为 50%，并标记为“需验证”。若最终排名靠前，则列入探索期 Sprint 进行快速验证。 - 分数相等： 两个功能 RICE 总分相同。
对策： 优先比较 Confidence 分值；若仍相同，则优先排序 Impact 较高的功能。 - 估算膨胀： 团队出于“揽活”或“推活”心态故意扭曲 Effort。
对策： 引入匿名投票机制，并在最终公布时公示每个维度的填写人。
1.10 验收标准
完成本章学习后，团队或学员应达到以下状态：
- 能够脱稿说出 R、I、C、E 四个维度的全称与定义。
- 能够区分 RICE 评分与普通加权矩阵的区别，并解释其核心价值。
- 能够独立执行一次 RICE 评估流程，从创建表格到输出排序结果。
- 能够在团队内担任 RICE 评分的引导者，处理常见的争议和异常。