第2章 RICE框架核心概念：R(Reach)、I(Impact)、C(Confidence)、E(Effort)定义与权重说明
2.1 适用场景
本章适用于以下场景：
- 产品经理、业务分析师首次学习 RICE 优先级排序模型，需要理解各维度的确切含义。
- 审批流需求评审会上，团队成员对某个需求的 RICE 评估产生歧义时，作为统一术语和权重解释的参考。
- 新加入项目组的工程师或测试人员，需要快速掌握 RICE 评分标准以便参与需求优先级讨论。
2.2 前置条件
- 已阅读第1章《RICE优先级排序概述与价值》章节。
- 团队已确认使用 RICE 模型作为审批流需求的统一优先级排序方法。
- 参会者具备基本的需求分析能力，了解“影响范围”“业务价值”“实现风险”等通用概念。
2.3 操作步骤
本步骤分解 RICE 四个维度的定义、度量方式及默认权重。每个维度需在需求评分时独立评估，最终计算综合得分 = (R × I × C) / E。
步骤1：定义并评估 Reach（覆盖范围）
定义：在指定时间周期内（通常为1个月、1个季度），该需求预计能触达到多少用户或业务流程实例数。
| 典型场景 | 示例描述 | 建议评分范围 |
|---|---|---|
| 全平台所有用户 | 审批流入口改造，所有员工（10,000+）每日访问 | 1000 ~ 10000+ |
| 特定部门/角色 | 仅财务部参与的新报销流程 | 100 ~ 1000 |
| 少数关键用户 | 仅审批管理员使用的配置页面优化 | 1 ~ 100 |
权重系数：Reach 分数直接使用原始值（不设额外权重），但建议团队根据业务规模统一量级（如映射为1-10分制，此处为原始值/1000后再计算）。
步骤2：定义并评估 Impact（影响度）
定义：该需求对业务关键指标（如审批通过率、处理时长、合规率）的改善程度。
| 影响力级别 | 典型指标提升 | 评分参考 |
|---|---|---|
| 极高 | 解决重大安全违规、避免合规罚款 | 5 |
| 高 | 审批效率提升30%以上 | 4 |
| 中 | 审批时长缩短15%~30% | 3 |
| 低 | 审批流程体验优化，无核心指标改善 | 1 |
| 极小 / 无 | 仅界面文字修改 | 0.5 |
权重系数：Impact 数据直接用评分值；若团队需要对 Impact 做更细粒度加权，可在跨项目比较时乘以固定系数（例如安全类需求统一乘以1.5），但后续章节会统一处理。
步骤3：定义并评估 Confidence（信心指数）
定义：你对 Reach 和 Impact 预估结果的确定程度，反映数据来源的可靠性。
| 信心等级 | 典型依据 | 分数 |
|---|---|---|
| 高 | 已有明确历史数据、A/B测试结果或对标行业标杆 | 100% |
| 中 | 产品专家估算、类似功能走查结果 | 80% |
| 低 | 基于个人假设、粗略估算 | 50% |
| 极低 | 完全未知、依赖强烈不确定性假设 | 20% |
权重系数：Confidence 评分直接以百分比形式参与乘法计算（即 C 值域 0.2、0.5、0.8、1.0）。
步骤4：定义并评估 Effort（投入工作量）
定义：完成该需求所需的总工作量（人天或人月），包括开发、测试、部署、配置及文档。
| 工作量级别 | 典型人天范围 | Effort 建议值 |
|---|---|---|
| 极低 | ≤2人天 | 2 |
| 低 | 3~5人天 | 5 |
| 中 | 6~15人天 | 15 |
| 高 | 16~30人天 | 30 |
| 极高 | >30人天 | 60（可拆解） |
权重说明：Effort 作为分母，得分越低优先级越高。注意 Effort 必须 使用实际人天数或相对规模值，不得使用反向评分（如1-5）。
核心提示：RICE 综合得分计算公式为 (Reach × Impact × Confidence) / Effort。所有维度均需有数据或可靠估算支撑，不允许凭空赋值。
常见误区：Confidence 用于抑制高估；若 Reach 和 Impact 估算非常乐观但 Confidence 很低，最终得分会被压缩，避免资源投到不确定的需求上。
2.4 输入与输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入 | 待评分需求列表（含需求ID、描述、初步估算） | 从需求池或 Jira/禅道等工具导出，每个需求必须包含初步的业务影响和规模猜想 |
| 输入 | 历史数据 / 业务报表 | 用于支撑 Reach 和 Impact 的客观估算（如用户行为统计、审批平均耗时） |
| 输出 | RICE 评分卡片（每个需求一张） | 包含四个维度的分值及总分，格式见 附录A-模板 |
| 输出 | 优先级排序列表 | 按总分降序排列，标记高、中、低优先级档位 |
2.5 责任边界
- 需求提出方（业务/产品）：提供 Reach 和 Impact 的初步估算及置信度依据。
- 技术负责人（Tech Lead）：负责 Effort 的工作量评估，确认技术可行性并给出 Confidence 的技术部分判断。
- 数据/分析团队（可选）：当 Confidence 需要历史数据支撑时，提供分析报告。
- 流程管理员：审核各维度评分是否合理，确保评分文档归档。
2.6 记录材料
- RICE 评分模板（Excel/在线表格），包含每个需求的四个维度和计算出的总分。
- 评分会议纪要（记录争议点及最终理由）。
- 每次评审后的优先级排序截图（用于追溯变更）。
2.7 异常处理
| 异常场景 | 处理方式 |
|---|---|
| Effort 估算偏差超过50% | 暂时标记为“高不确定性”，将 Confidence 值设为0.5，待技术评审后再修正 |
| 多个需求 Reach 重叠（用户重复计数） | 以独立用户数（去重）为准；若无法去重，取最小值 |
| 团队对 Impact 评分争议（如有人认为3分，有人认为4分） | 取中位数，并记录争议焦点；最终由产品负责人决策 |
| Confidence 完全未知 | 强制设为0.2，并将该需求降为“调研任务”，先验证再重评 |
2.8 验收标准
- 每个需求已完成四个维度的独立评分（Reach、Impact、Confidence、Effort）且无空值。
- Confidence 评分必须附带简要的“证据来源”描述（如：历史数据统计、专家访谈、行业报告）。
- Effort 评分以人天为单位，整数或带0.5的半整数，不得使用“工作量小/大”等模糊词。
- 最终排名清单中，得分最高优先级与前序章节定义的业务目标（如“提升审批合规率”）匹配性一致。
- 所有评分记录已归档至指定共享目录（如 /project/rice_scores/）。