1.1 RICE 核心概念与适用场景
1.1.1 定义
RICE 是四个评估因子的首字母缩写，用于对候选任务或需求进行量化优先级排序。与传统单维度方法不同，RICE 通过四个独立维度交叉计算，得出一个可横向比较的分数，从而降低主观偏差，提升决策透明度。
| 因子 | 全称 | 含义 | 测量单位 |
|---|---|---|---|
| R | Reach | 每个时间单位内该任务能触达的目标用户数 | 人数/周期 |
| I | Impact | 完成任务后对单个用户的预期影响程度 | 多级量表（如 0.25、0.5、1.0、3.0） |
| C | Confidence | 对 Reach 与 Impact 估值的确信度 | 百分比（20%、50%、80%、100%） |
| E | Effort | 完成任务所需的总工作量（跨团队协作时需累加） | 人·月 或 人·周 |
最终分数公式：
RICE Score = (Reach × Impact × Confidence) / Effort
示例计算： 优化登录页加载速度 → Reach = 50,000 用户/周，Impact = 2.0（高），Confidence = 80%（0.80），Effort = 4 人·周。
RICE Score = (50000 × 2.0 × 0.80) / 4 = 20,000。
RICE Score = (50000 × 2.0 × 0.80) / 4 = 20,000。
1.1.2 适用范围
- 产品需求积压（Backlog）排序： 当团队面对 20 条以上候选需求，且资源只能覆盖前 30% 时。
- 技术债务修复与功能开发混合排序： 需要统一衡量不同特性类型。
- 跨项目资源分配： 同一产品线下的多个项目预算冲突。
- 战略性 ROI 评估： 用于季度规划会议中筛选高价值、低投入的速赢项。
不适用场景：
· 仅有 1-2 个任务，无需比较。
· 任务依赖关系极强（如必须先做 A 才能做 B），此时 RICE 无法表达串行业务逻辑。
· 严重缺乏基础数据，四个因子全部依赖纯猜测，此时 Confidence 会拉低分数导致失真。
· 仅有 1-2 个任务，无需比较。
· 任务依赖关系极强（如必须先做 A 才能做 B），此时 RICE 无法表达串行业务逻辑。
· 严重缺乏基础数据，四个因子全部依赖纯猜测，此时 Confidence 会拉低分数导致失真。
1.1.3 前置条件
在启动 RICE 计算之前，团队必须完成以下准备，否则分数将失去参考意义：
- 任务已分解到可比粒度： 每项候选任务的工作量跨度不应超过 1 个数量级（例如，不应把“修一个文案错别字”与“重写支付模块后端”直接使用同一套评分模板）。
- Impact 量表已达成共识： 全团队（产品、开发、测试、运营）需要预先定义 0.25（轻微）、0.5（中等）、1.0（高）、3.0（极高）分别对应什么业务表现。
- Confidence 规则已制定： 避免“我非常有信心”这类主观表述；应使用数据来源类型定义：100% = 有完整 AB 测试或历史数据；80% = 有强相关数据（如竞品分析）；50% = 有定性用户调研；20% = 仅凭经验假设。
- Effort 估算口径一致： 必须包含设计、开发、测试、部署、文档编写等全部环节；跨团队协作时应累加。
1.1.4 操作步骤（第 1 章级概览）
- 收集候选任务： 填写任务编号、名称、目标用户群。
- 为每个任务填报四要素估值： 使用本章定义的单位和量表。
- 带入公式计算分数： 使用 $ \frac{Reach \times Impact \times Confidence}{Effort} $（可用 Excel 或脚本批量处理）。
- 按分数降序排列： 分数越高，优先级越高。
最佳实践提示： 在第一步填报 Reach 时，应使用产品分析仪表盘（如 GA、Mixpanel、Pendo）提取真实月活或周活，而不是拍脑袋填写。精确的 Reach 是 RICE 模型有效性的基石。
1.1.5 输入与输出物
| 类型 | 名称 | 格式/载体 | 备注 |
|---|---|---|---|
| 输入 | 候选任务列表 | Excel / 看板卡片 / JSON | 每行一条任务，包含编号与描述 |
| 输入 | Impact 量表共识文档 | Wiki 页面 / 团队约定文档 | 定义 0.25/0.5/1.0/3.0 对应的业务事件 |
| 输出 | RICE 评分排序表 | Excel / 电子表格 / 导出 CSV | 包含四因子原始值与最终分数 |
| 输出 | 优先级排序决议 | 会议纪要 / 看板标记 | 明确 Top N 任务进入下一轮迭代 |
1.1.6 责任边界
- 产品经理（PM）： 负责定义 Impact 量表、审核 Reach 数据来源、组织全团队对齐 Confidence 标准。
- 技术负责人（Tech Lead）： 负责提供 Effort 估算，确认开发、测试、部署环节的消耗。
- 数据工程师/分析师： 负责提取 Reach 所需的数据，确保数字可复现。
- 所有参与者： 需对各自填报的 Confidence 等级提供定性依据（如“此数据来自两周前的用户调研”）。
1.1.7 记录材料
| 材料编号 | 名称 | 保存位置 | 更新频率 |
|---|---|---|---|
| RICE-01 | 候选任务数据源表 | 共享盘 / 数据库 | 每期排序前更新 |
| RICE-02 | Impact 量表定义 v1.x | 团队 Wiki | 按季度复审 |
| RICE-03 | Confidence 等级规则 | 团队 Wiki | 首次发布后定稿 |
| RICE-04 | RICE 评分计算模板 | Excel / 公式脚本 | 每次排序使用最新版 |
1.1.8 异常处理
| 异常情形 | 处理方式 | 责任方 |
|---|---|---|
| 某任务缺少 Reach 数据 | 标记 Confidence 为 20%，并注明“无定量数据” | 数据工程师 / PM |
| 多个任务分数相同 | 附加权重：优先选择 Impact 更高、或与战略目标更匹配的任务 | PM 裁决 |
| Effort 估算偏差 > 30% | 在 Confidence 中考虑该因子，或重新评估 Effort 拆分粒度 | Tech Lead |
| 任务需要外部依赖（如第三方上线） | 在 Effort 中额外计算沟通与集成测试周期 | PM + Tech Lead |
1.1.9 验收标准
- 完整性： 每项候选任务均已填写 Reach、Impact、Confidence、Effort，无空字段。
- 一致性： Impact 量表使用团队共识文档中定义的值（0.25 / 0.5 / 1.0 / 3.0）。
- 可追溯： Confidence 值背后必须有文字备注，说明数据来源或判断依据。
- 可重复： 使用同一份数据源与计算模板，任何人复算都能得到相同排序结果。
- 可决策： 排序结果可直接用于本周/本月迭代规划的前 5 项任务选定。