第1章:RICE评分概述:定义、应用场景、与Roadmap衔接的价值
1.1 章节定位与核心概念
RICE 评分是产品管理领域用于需求优先级排序的定量决策框架,由 Intercom 团队提出。它将每个需求或项目从四个维度打分,最终以单一数值量化优先级,解决传统直觉决策中“主观性强、维度单一、难以横向比较”的问题。本章作为全课程的基础,为后续的评分实操、Roadmap 衔接技巧建立统一认知。
1.2 适用场景
| 场景类型 | 典型描述 | 是否推荐使用RICE |
|---|---|---|
| 需求积压(Backlog)清理 | 积压超过 20 条需求,需要定期排序筛选 | ✅ 强烈推荐 |
| 跨团队资源竞对 | 多个部门提出需求,统一标准裁定先后 | ✅ 强烈推荐 |
| 季度 Roadmap 规划 | 从候选池中选出下季度要交付的 3~5 个项目 | ✅ 推荐 |
| 紧急 Bug 修复决策 | 突发线上故障需立即投入资源 | ⚠️ 需结合严重性矩阵 |
| 战略级项目立项 | CEO 或高层指定的必须落地项目 | ❌ 不适用(直接纳入 Roadmap) |
💡 关键判断:当需求数量多、决策影响大、需要跨角色对齐时,RICE 评分最能发挥价值;若需求 ≤ 3 条或存在不可抗力因素,跳过评分直接进入 Roadmap。
1.3 前置条件
在启动 RICE 评分之前,团队必须准备好以下条件,否则评分结果可能失真或无法落地:
- 需求候选清单:每条需求有唯一的 ID 和一句话描述。
- 基础数据源:至少能获取用户量级(MAU/DAU)、功能使用率、历史同类需求上线数据。
- 评分角色明确:至少指定 1 名评分负责人(PM)和 2~3 名参与评分的利益相关方(技术、设计、运营)。
- Effort 估算基准:团队已定义“1 人天 ≈ 多少 Story Point”或“1 人周”的换算口径。
- Roadmap 模板:已明确当前 Roadmap 的周期长度(如季度)和容量上限(如 120 人天)。
1.4 RICE 四维定义与计算标准
| 维度 | 全称 | 定义 | 量化区间 | 数据来源建议 |
|---|---|---|---|---|
| R | Reach(触达) | 该功能在给定时间内(通常 3 个月)能触达多少独立用户 | 0~100,000+(按数量级) | 埋点系统、MAU 报告、用户访谈样本量 |
| I | Impact(影响) | 对核心目标(留存、转化、收入、满意度)的拉动程度 | 0.25(极低)、0.5(低)、1(中)、2(高)、3(极高) | A/B 测试历史效果、行业基准 |
| C | Confidence(信心) | 团队对 R 和 I 估算的把握程度 | 0.2(无数据,纯猜测)、0.5(有间接证据)、0.8(有直接数据)、1(有实验结论) | 证据链检查表 |
| E | Effort(投入) | 完成该功能所需的总人·周数(设计 + 开发 + 测试 + 部署) | 1~52 人·周(按周计) | 技术方案评审、历史同类工时 |
RICE 评分公式:
RICE Score = (Reach × Impact × Confidence) / Effort
分数越高,优先级越高。分母 Effort 的存在使得“小投入高产出”的需求更容易排在前面,避免资源被大项目全部占用。
⚡ 实操建议:首次使用时,团队可以先统一 R 的单位(如“千人”),并固定 Impact 的标尺案例(如“1 = 提升 5% 周留存”),减少主观偏差。
1.5 与 Roadmap 衔接的价值
RICE 评分不是终点,而是 Roadmap 规划的数据输入层。衔接价值体现在三个层面:
- 客观排序,减少政治博弈:评分结果作为单一数字,让“谁的声音大谁先做”转变为“数据说话”。
- 容量匹配,防止过度承诺:将候选需求的 Effort 累加,与 Roadmap 可用容量对比,自动筛除超载项。
- 假设可追溯,便于复盘:每次评分的 R/I/C/E 值均可记录,事后与实际效果对比,持续校准团队判断力。
1.6 输入输出物
| 类型 | 名称 | 格式/载体 | 责任人 |
|---|---|---|---|
| 输入物 | 需求候选列表 | Excel / 项目管理工具 | PM |
| 输入物 | 用户量级 & 行为数据 | 数据分析平台(如 Amplitude) | 数据分析师 |
| 输入物 | Effort 估算模板 | Jira / 工时登记表 | Tech Lead |
| 输出物 | RICE 评分表(含四维得分) | 共享表格 / Airtable | PM |
| 输出物 | Roadmap 候选排序看板 | 看板工具 / 演示文档 | PM |
| 输出物 | 评分复盘日志 | Wiki / Notion | PM |
1.7 责任边界
| 角色 | 职责 | 不负责(边界) |
|---|---|---|
| 产品经理(PM) | 主持评分流程、汇总分数、输出排序结果 | 不代替团队提供 Impact 估算;不强制执行评分结果 |
| 技术负责人 | 提供 Effort 估算,评估技术风险 | 不负责 Reach/Impact 数据采集 |
| 数据分析师 | 提供 Reach 量级和 Confidence 证据 | 不参与 Impact 主观标尺设定 |
| 运营/业务方 | 提供用户场景和业务目标对齐 | 不直接修改评分数字(可提出异议) |
| 决策委员会 | 审核评分结果,批准最终 Roadmap | 不介入评分过程的具体数值 |
⚠️ 常见边界模糊:PM 容易“代劳”所有维度的评分,导致 Confidence 虚高。务必坚持“各角色贡献自己的维度数据”,PM 只做汇总和流程推进。
1.8 记录材料
每轮评分必须存档以下材料,作为后续复盘的原始依据:
- RICE 评分原始记录表(含每条需求的 R/I/C/E 分值和计算过程)
- 评分会议纪要(记录争议点、标尺调整理由、特殊备注)
- Effort 估算明细(按人·周拆分,标注假设条件)
- Roadmap 版本快照(评分前后的 Roadmap 对比,记录落选需求)
# RICE 评分原始记录表示例(CSV 格式)
需求ID,R,I,C,E,Score,备注
REQ-001,12000,2,0.8,12,1600.00,核心用户路径优化
REQ-002,5000,1,0.5,4,625.00,运营后台导出功能
REQ-003,80000,0.5,0.2,20,400.00,全量用户推送触达(置信度低)
1.9 异常处理
| 异常场景 | 表现 | 处理措施 |
|---|---|---|
| 数据缺失严重 | R / C 无法估值 | 标记为“低置信度”,先做调研再评分;或直接放入“待调研池” |
| Effort 估算差异>2 倍 | 技术团队内部对工时分歧大 | 拆解为更小颗粒度的子任务,分别估算后求和 |
| 评分结果与直觉严重冲突 | 所有人都认为该做 A,但 RICE 分数推荐 B | 先检查 Confidence 是否合理;若无误,以数据为准,但保留 1 个“战略预留”名额 |
| Roadmap 容量不足 | 前 5 名总 Effort 远超可用容量 | 按分数截断后,对临界需求进行“二次定性讨论” |
| 多个需求分数相等 | Score 相同无法取舍 | 比较 Impact 维度分,优先选择 Impact 更高的需求 |
1.10 验收标准
完成第 1 章学习后,学员应能独立通过以下检查项:
- ✅ 能够用自己的语言解释 RICE 四个维度的含义和单位。
- ✅ 能够根据给定数据正确计算 RICE 评分。
- ✅ 能够判断一个需求是否适合使用 RICE 评分(对照 1.2 适用场景)。
- ✅ 能够列出评分前必须准备的 4 项前置条件。
- ✅ 能够画出 RICE → Roadmap 的衔接流程图(与本章 SVG 结构一致)。
- ✅ 能够识别 2 种以上异常场景及其处理方案。
🏁 本章关键交付物:一份包含至少 3 条需求的 RICE 评分练习表(含四维数值和得分),以及对应的 Roadmap 候选排序截图。