第1章 RICE评分法概述
1.1 适用场景
RICE评分法适用于以下典型场景，帮助团队在资源有限的条件下做出客观、可追溯的需求优先级决策：
- Backlog 梳理与排序：产品待办事项列表中需求数量超过团队交付能力，需快速筛选高价值项。
- 产品路线图规划：制定中短期路线图时，量化衡量每个需求的综合收益与成本。
- 跨团队需求 PK：多个业务方同时提出需求，需要统一标尺横向对比。
- 资源冲突调解：研发、设计、测试资源紧张时，用数据支撑“先做谁、后做谁”的决策。
- 版本迭代范围定稿：确定下一个版本要交付的需求清单，避免主观拍脑袋。
💡 提示：RICE 最适用于“中长周期、有一定数据积累”的产品场景。对于极早期 0→1 项目，可将 Confidence 调低以反映不确定性。
1.2 前置条件
在正式开展 RICE 评分之前，团队需满足以下条件：
- 已完成需求收集与初步分析，每项需求有清晰的描述文档。
- 具备基本用户数据或业务指标（如 MAU、转化率、开发人天估算）。
- 参与评分的核心成员（产品经理、技术负责人、业务方）对评分标准达成初步共识。
- 准备好 RICE 评分模板（电子表格或协作工具），确保可多人协同填写。
⚠️ 注意：若需求缺乏任何数据支撑，建议先标记为“待补充数据”后再评分，避免 Confidence 虚高导致排序失真。
1.3 核心四要素
RICE 得分由四个要素共同决定，其关系可用以下公式表示：
RICE Score = (Reach × Impact × Confidence) / Effort下表对四要素进行详细对比：
| 要素 | 英文 | 定义 | 常用度量方式 | 对得分的影响 |
|---|---|---|---|---|
| 触达范围 | Reach | 在给定时间内该需求能影响到的用户数或业务实体数 | 每季度覆盖用户数 / 交易笔数 / 设备数 | 分子（越大越好） |
| 影响程度 | Impact | 需求上线后对核心业务指标的提升幅度 | 转化率提升百分比 / 收入增量 / 满意度得分 | 分子（越大越好） |
| 信心指数 | Confidence | 团队对 Reach 和 Impact 估算的把握程度 | 百分比（100% = 完全确定，50% = 中等把握） | 分子（越高越好） |
| 投入成本 | Effort | 完成该需求所需的全部资源（开发、设计、测试、部署） | 人月 / 人天 / 研发周期（周） | 分母（越小越好） |
1.4 操作步骤
RICE 评分法整体分为以下五个宏观步骤，后续章节将逐一展开：
- 明确需求与评分目标——确定待评分的需求清单，统一评分周期与度量口径。
- 收集四要素数据——分别估算每项需求的 Reach、Impact、Confidence、Effort 数值。
- 计算 RICE 得分——代入公式得到每个需求的量化分值。
- 排序并输出优先级列表——按得分降序排列，形成初步优先级建议。
- 评审与确认——召集相关方 review 评分结果，修正明显偏差后定稿。
🔑 关键原则：评分不是一次性的“算术题”，而是团队对齐认知的“沟通工具”。即使数据不完美，也比完全凭感觉排序更可靠。
1.5 输入输出物
| 类型 | 内容 | 格式 / 载体 | 责任方 |
|---|---|---|---|
| 输入 | 需求列表（含简要描述、用户故事、初步估算） | 电子表格 / 协作文档 / 项目管理工具 | 产品经理 |
| 输入 | 用户数据报表、业务指标历史数据、技术评估纪要 | BI 看板 / 数据分析报告 / 技术评估表 | 数据分析师 / 技术负责人 |
| 输出 | RICE 评分明细表（含四要素分值、最终得分、排序） | 电子表格 / 协作工具视图 | 产品经理 |
| 输出 | 优先级排序建议（供决策会讨论） | 文档 / 幻灯片 / 看板列表 | 产品经理 |
1.6 责任边界
| 角色 | 职责范围 | 不承担的责任 |
|---|---|---|
| 产品经理 | 发起评分流程、组织数据收集、维护评分表、输出排序建议 | 不替代技术负责人做 Effort 估算，不单方面决定最终优先级 |
| 技术负责人 | 提供 Effort 估算（人天/人月），评估技术可行性与依赖风险 | 不负责 Reach 和 Impact 的业务数据，不干预业务方打分 |
| 数据分析师 | 提供 Reach 和 Impact 所需的历史数据、用户行为数据 | 不参与 Confidence 打分，不做最终排序决策 |
| 业务方 / 决策者 | 确认业务目标与评分口径，审批最终优先级 | 不直接修改评分数据（可提出异议由产品经理修正） |
1.7 记录材料
每次 RICE 评分需要归档以下材料，确保过程可追溯：
- RICE 评分模板（含公式列、四要素输入列、备注列）
- 原始数据源（导出或截图的用户数据报表、技术评估表）
- 评分会议纪要（记录争议点、修正原因、最终确认人）
- 版本快照（每次评分的最终表格，标注日期与参与人）
📌 建议：使用在线协作表格（如 Airtable / Notion / 飞书多维表格），每次修改自动保留历史版本，便于回溯。
1.8 异常处理
- 数据缺失：某项需求完全无 Reach 或 Impact 数据 → 将 Confidence 设为 ≤ 30%，并在备注中标记“待补充”，优先推进数据采集而不是强行评分。
- 评分分歧：不同成员对同一需求的 Effort 或 Impact 给出差异很大的估值 → 组织 15 分钟对齐会议，以“最熟悉该领域的人提供基准，其他人校准”为原则达成共识。
- 得分相同：两个需求 RICE 得分完全一致 → 比较 Confidence 高低，Confidence 更高者优先；若仍相同，由产品经理结合战略方向裁定。
- 外部依赖风险：需求依赖第三方 SDK 或跨团队共建 → 在 Effort 中额外增加 20% 缓冲，并在备注标注风险等级。
1.9 验收标准
第 1 章（RICE 评分法概述）学习完成后，应达成以下标准：
- 能够准确说出 RICE 的四个要素全称、度量方向及在公式中的位置。
- 能列举至少 3 个适用 RICE 评分的业务场景。
- 理解前置条件的重要性，能判断团队是否具备启动评分的条件。
- 清楚 RICE 评分流程的五个宏观步骤，并知道每个步骤的主要输出物。
- 明确产品经理、技术负责人、数据分析师在评分中的角色边界。
- 掌握数据缺失、评分分歧等常见异常的处理方式。