第3章：RICE评分方法总览
适用场景
RICE评分方法适用于版本节奏控制中，对多个需求或特性进行客观优先级排序的场景。特别适合以下情况：
- 需求池条目过多，需要统一量化标准筛选；
- 团队需要跨职能对齐优先级判断；
- 希望减少主观偏见对决策的影响；
- 需要为高层管理者提供明确的排序依据。
前置条件
- 已整理出待评估的需求列表，每个需求有简要描述和预期用户；
- 产品或数据团队可提供用户规模/触达频率的估算数据（用于 Reach）；
- 技术负责人能给出工作量预估（人天或故事点，用于 Effort）；
- 团队已有历史数据或行业基准，用于校准 Impact 和 Confidence；
- 所有参与者认同 RICE 计算模型 的权重逻辑。
操作步骤
RICE 评分分为四个维度的独立评估和一个综合计算，具体步骤如下：
| 步骤 | 维度 | 含义 | 评分量级（推荐值） |
|---|---|---|---|
| 1 | Reach | 一个版本周期内该特性将触达的独立用户数（或交易/会话数） | 0 = 无人, 1 = 极少(≤100), 10 = 少量(1k~10k), 100 = 大量(≥100k) |
| 2 | Impact | 对单个用户的影响程度，通常用转化率、满意度、效率提升衡量 | 0.25 = 极低, 0.5 = 低, 1 = 中, 2 = 高, 3 = 极高 |
| 3 | Confidence | 对 Reach 和 Impact 估算的相信程度（基于数据/经验） | 0.2 = 无数据支撑, 0.5 = 部分数据/专家判断, 0.8 = 强数据模型, 1.0 = 精确历史数据 |
| 4 | Effort | 团队完成该特性所需的总工作量（人天/故事点） | 0.5 = 非常小(≤0.5周), 1 = 小(1周), 2 = 中(1-2周), 3 = 大(1月), 5 = 极大(≥2月), 8 = 巨大 |
| 5 | RICE 综合计算 | RICE = (Reach × Impact × Confidence) / Effort | |
计算示例：
某需求 Reach=100 (大量用户), Impact=2 (高), Confidence=0.8 (数据充分), Effort=2 (中)。
某需求 Reach=100 (大量用户), Impact=2 (高), Confidence=0.8 (数据充分), Effort=2 (中)。
RICE = (100 × 2 × 0.8) / 2 = 160 / 2 = 80输入/输出物
| 类型 | 内容 | 责任方 |
|---|---|---|
| 输入 | 需求列表（含标题、描述、预期用户群）；各维度初始估算数据 | 产品经理、技术负责人、数据分析师 |
| 输出 | RICE 评分排序表（包含每个需求的 Reach, Impact, Confidence, Effort 评分及最终 RICE 值） | 产品经理汇总并发布 |
责任边界
- 产品经理（PM）：主导 RICE 评分过程，确保每个需求都经过讨论并录入评分；对 Consistency 和排序结果负责。
- 技术负责人（TL）：提供 Effort 评估（精确到故事点或人天），必要时拆解技术子任务。
- 数据分析师（DA）：提供 Reach 和 Impact 的量化数据来源，支持 Confidence 的校准。
- 全体评审成员：对 Confidence 评分进行投票或共识确认。
记录材料
每个版本迭代的 RICE 评分结果应记录在以下载体中：
- 共享表格（如 Airtable, Notion, 飞书多维表格）
- 版本需求看板（每个需求卡片上标注四个维度的评分及最终 RICE 值）
- 决策日志：记录评分讨论中的关键假设和异常点
异常处理
| 异常场景 | 处理策略 |
|---|---|
| Reach/Impact 数据缺失 | 使用类比估算（参考同类历史功能），并降低 Confidence 至 ≤0.5 |
| Effort 估算分歧大（＞2倍差距） | 组织技术预研或拆分为更小任务，再重新评估 |
| Confidence 持续低于 0.5 | 暂时不纳入版本计划，标记为“待验证”，等有数据后再评分 |
| 多个需求 RICE 值非常接近（±5%） | 使用辅助指标（如战略对齐、依赖关系）进行二次排序 |
验收标准
- 每个需求均已完成四个维度的独立评分，且评分在推荐量级范围内；
- RICE 计算公式正确执行，无人工算错；
- 最终排序结果可回溯：每个维度的评分理由记录在案；
- 异常场景被识别并处理（如需补充数据则标记完成）；
- 产品经理确认排序结果，并录入版本 backlog。
💡 关键提示： RICE 评分并非绝对精确，它的核心价值在于强制团队对每个维度进行显式估算和讨论，从而暴露假设、对齐认知。评分量级可根据团队经验调整，但需保持一致。
⚠️ 常见偏差： 高 Confidence 容易被高估（因为熟悉的项目），低 Confidence 容易被低估。建议对 Confidence<0.5 的需求单独标记，并作为风险项处理。