第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 四维定义与计算标准

维度全称定义量化区间数据来源建议
RReach(触达)该功能在给定时间内(通常 3 个月)能触达多少独立用户0~100,000+(按数量级)埋点系统、MAU 报告、用户访谈样本量
IImpact(影响)对核心目标(留存、转化、收入、满意度)的拉动程度0.25(极低)、0.5(低)、1(中)、2(高)、3(极高)A/B 测试历史效果、行业基准
CConfidence(信心)团队对 R 和 I 估算的把握程度0.2(无数据,纯猜测)、0.5(有间接证据)、0.8(有直接数据)、1(有实验结论)证据链检查表
EEffort(投入)完成该功能所需的总人·周数(设计 + 开发 + 测试 + 部署)1~52 人·周(按周计)技术方案评审、历史同类工时

RICE 评分公式:

RICE Score = (Reach × Impact × Confidence) / Effort

分数越高,优先级越高。分母 Effort 的存在使得“小投入高产出”的需求更容易排在前面,避免资源被大项目全部占用。

⚡ 实操建议:首次使用时,团队可以先统一 R 的单位(如“千人”),并固定 Impact 的标尺案例(如“1 = 提升 5% 周留存”),减少主观偏差。

1.5 与 Roadmap 衔接的价值

RICE 评分不是终点,而是 Roadmap 规划的数据输入层。衔接价值体现在三个层面:

  1. 客观排序,减少政治博弈:评分结果作为单一数字,让“谁的声音大谁先做”转变为“数据说话”。
  2. 容量匹配,防止过度承诺:将候选需求的 Effort 累加,与 Roadmap 可用容量对比,自动筛除超载项。
  3. 假设可追溯,便于复盘:每次评分的 R/I/C/E 值均可记录,事后与实际效果对比,持续校准团队判断力。
RICE评分与Roadmap衔接流程 RICE → Roadmap 衔接流程 R: Reach 触达 0~100k+ I: Impact 影响 0.25~3 C: Confidence 信心 0.2~1 E: Effort 投入 1~52 人周 RICE Score (R×I×C)/E 排序候选池(降序) 交付 Roadmap 容量约束 Effort 累加 ≤ 可用人天 复盘校准 实际 vs 预估

1.6 输入输出物

类型名称格式/载体责任人
输入物需求候选列表Excel / 项目管理工具PM
输入物用户量级 & 行为数据数据分析平台(如 Amplitude)数据分析师
输入物Effort 估算模板Jira / 工时登记表Tech Lead
输出物RICE 评分表(含四维得分)共享表格 / AirtablePM
输出物Roadmap 候选排序看板看板工具 / 演示文档PM
输出物评分复盘日志Wiki / NotionPM

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 候选排序截图。