第4章 影响维度评分标准
影响维度（Impact）是 RICE 框架中量级最重的一环，它回答一个核心问题：如果这个功能/修复/优化成功落地，能在多大程度上改变现状？ 本章给出从定义到评分的完整流程，确保不同成员对“影响”的打标口径一致，避免凭感觉、凭资历、凭嗓门定分。
核心原则：影响评分只看“预期效果大小”，不看“实现难度”和“投入工时”。把难度和成本留给 Effort 和 Confidence 维度处理。
4.1 适用场景
- 产品需求列表（Backlog）优先级排序前的批量评分
- 缺陷/事故修复的紧急程度判定
- 技术债务偿还项的业务价值论证
- A/B 测试候选方案的预期效果对比
- 季度 OKR 中关键结果的目标值设定
4.2 前置条件
- 已明确待评估项的交付物定义（如 PRD、Issue 描述、Change Request）
- 已获取最近 30 天核心业务数据：DAU、MAU、GMV、转化率、留存率
- 团队已完成“影响”概念的共识对齐（见 4.3.1 定义共识会）
- 已选定 3–5 个历史项目作为影响锚点（用于校准打分）
4.3 操作步骤
4.3.1 定义共识会（20 分钟）
召集产品、技术、运营三方代表，对齐本组织当前阶段的影响定义。定义一旦确定，一个评估周期内不再更改。
| 角色 | 对齐内容 |
|---|---|
| 产品经理 | 影响是用户行为改变还是收入指标改变 |
| 技术负责人 | 影响是否包含系统稳定性/性能提升 |
| 运营代表 | 影响是否包含运营效率/人工成本降低 |
4.3.2 识别影响类型
将待评估项归入以下四类之一，不同类型对应不同的参考锚点：
- 用户影响型 —— 覆盖用户数、留存率、NPS
- 收入影响型 —— GMV、客单价、付费转化率
- 效率影响型 —— 内部人效、处理时长、自动化覆盖率
- 风险影响型 —— 安全漏洞、合规风险、数据丢失概率
4.3.3 评估影响程度（范围 × 深度）
使用双因子判断法：影响范围（多少用户/交易受影响） × 影响深度（每个受影响对象的改变幅度）。
| 因子 | 低（1–3） | 中（4–7） | 高（8–10） |
|---|---|---|---|
| 影响范围 | ≤5% 核心用户 | 5%–30% 核心用户 | >30% 核心用户 或 全量 |
| 影响深度 | 边际改善（<5% 指标变化） | 中等改善（5%–20% 指标变化） | 显著改善（>20% 指标变化） |
4.3.4 对照参考锚点打初分
将待评估项与预先选定的 5 个历史锚点进行对比，找到最接近的锚点分数，再根据差异微调 ±1 分。
4.3.5 交叉校验与最终定分
由 2 名以上评分者独立打分后取均值，若差值 >2 分则进入讨论仲裁。
4.4 影响评分标准表（0–10）
| 分数 | 定义 | 典型示例 | 判断依据 |
|---|---|---|---|
| 0 | 几乎无可观测影响 | 文案排版调整、内部管理后台字段改名 | 无任何核心指标变化预期 |
| 1–2 | 极小影响，覆盖 <1% 用户或边际体验改善 | 某个二级页面按钮颜色优化 | 用户行为漏斗中该步骤转化率 <1% |
| 3–4 | 较小影响，覆盖 1%–5% 用户，或指标改善 <5% | 非核心路径的表单字段减少 | 受影响用户占比 <5%，且变化幅度 <5% |
| 5–6 | 中等影响，覆盖 5%–15% 用户，或指标改善 5%–10% | 购物车页面加载速度提升 300ms | 影响 5%–15% 核心用户，转化率提升可量化 |
| 7–8 | 较大影响，覆盖 15%–40% 用户，或指标改善 10%–20% | 登录流程简化、支付成功率优化 | 影响大部分日常用户，指标提升跨季度可见 |
| 9–10 | 极大影响，覆盖 >40% 用户，或指标改善 >20% | 推荐算法重构、核心业务流程 BPR | 影响全量或接近全量用户，指标跃升一个量级 |
锚点校准技巧：在每个分数段（1–2、3–4、5–6、7–8、9–10）各选一个团队公认的历史项目作为永久锚点。新项目做影响评分时，先问“它更像锚点 A 还是锚点 B？”，再定分。
4.5 输入输出物
| 类型 | 名称 | 格式 / 载体 | 责任人 |
|---|---|---|---|
| 输入 | 待评估项列表 | Jira / Excel / Notion 行 | 需求提交方 |
| 输入 | 核心业务指标快照 | 数据看板截图 / CSV | 数据分析师 |
| 输入 | 历史锚点参考表 | 团队 Wiki 页面 | 产品负责人 |
| 输出 | 影响评分记录表 | 结构化表格（字段见 4.7） | 评分执行人 |
| 输出 | 评分争议仲裁纪要 | 评论 / 附件 | 仲裁主持人 |
4.6 责任边界
- 产品经理（评分执行人） —— 按 SOP 完成评分，保证打分可回溯
- 技术负责人（审核人） —— 从实现角度复核影响范围假设是否合理
- 数据分析师（数据支撑） —— 提供影响范围与深度的量化数据
- 仲裁委员会（争议裁定） —— 当双人分数差值 >2 时，由三方代表（产品+技术+运营）合议终裁
4.7 记录材料
每次评分必须留存以下字段到影响评分记录表：
| 项目ID | 项目名称 | 影响类型 | 影响范围(%) | 影响深度(%) | 初分 | 终分 | 评分人 | 审核人 | 锚点参考 |
|--------|----------|----------|-------------|-------------|------|------|--------|--------|----------|
| RICE-041 | 登录流程简化 | 用户型 | 38% | +12% | 7 | 8 | 张三 | 李四 | 锚点-05 |
4.8 异常处理
常见异常 1：评分人认为影响很大但数据无法支撑范围/深度量化。
处置：降级为“待验证影响”，先打暂定分（最大 5 分），并标记为需 A/B 验证，Confidence 维度同步下调。
处置：降级为“待验证影响”，先打暂定分（最大 5 分），并标记为需 A/B 验证，Confidence 维度同步下调。
常见异常 2：两个评分人的终分差值 >2。
处置：强制进入仲裁流程。仲裁前双方各自写出 50 字以内的“影响论证摘要”，由仲裁委员会 15 分钟内合议出最终分。
处置：强制进入仲裁流程。仲裁前双方各自写出 50 字以内的“影响论证摘要”，由仲裁委员会 15 分钟内合议出最终分。
常见异常 3：待评估项属于全新类型，无法匹配任何历史锚点。
处置：临时创建“新锚点预打分”，该条目的影响分上限设为 7 分，待上线后根据实际数据修正锚点库。
处置：临时创建“新锚点预打分”，该条目的影响分上限设为 7 分，待上线后根据实际数据修正锚点库。
4.9 验收标准
- 每一个待评估项都有明确的影响类型分类
- 评分表中影响范围 + 影响深度均填写了具体数值（百分比或用户数）
- 终分与初分的差值 ≤2，或已有仲裁记录
- 所有评分记录保存至项目交付后 3 个月，可供追溯审计
- 历史锚点库在本章使用后至少更新 1 次（新增或修正锚点）
本章要点：影响评分不是“拍脑袋”，而是通过影响类型 → 范围×深度 → 锚点对比 → 双人校验四步流水线，把主观判断压缩到最低。0–10 分的每一分都必须能在记录材料中找到对应的数据或锚点证据。