Impact（影响力）评估维度

Impact 衡量的是一个需求或任务完成后对产品、用户、业务及战略产生的可感知、可衡量的正向改变。RICE 框架中的 Impact 并非单一指标，而是由四个子维度构成的复合判断：用户价值、业务目标、战略对齐、可量化指标。只有同时从这四个维度进行权重赋值，才能得出客观、可复用的 Impact 评分。

适用场景

• 对候选需求或用户故事进行优先级排序前，需要量化其影响力。
• 在季度/月度规划会上，统一评审 backlog 中待评估项。
• 需要跨团队对齐“什么是有价值的工作”时，作为沟通框架。
• 验证已上线功能是否达到预期影响力，用于复盘与后续迭代。

前置条件

1. 已定义本团队/产品的当前阶段业务目标（如提升留存率、降低客服成本）。
2. 产品经理或需求负责人已撰写初步的需求描述，包含用户场景和预期收益。
3. 团队已确定当前迭代的“战略主题”（如用户增长、数据合规、架构升级）。
4. 存在至少一种可收集量化数据的渠道（埋点、调研、客服记录等）。

操作步骤

Impact 评估分为四个并行子步骤，建议按顺序逐一完成，但数据采集可同步进行。

1. 评估用户价值：通读需求描述，判断该需求解决的用户痛点有多痛、覆盖用户面有多广。通过用户访谈记录、NPS 反馈、工单频次等辅助判断。打分 1-10。
2. 评估业务目标：该需求直接或间接贡献了哪个业务指标？对照当前 OKR 或 KPI，估算提升幅度。例如：预期转化率提升 0.5% 可打 7 分。
3. 评估战略对齐：判断该需求是否属于公司/部门的年度战略方向。若完全对齐且为战略核心落地项，打 10 分；若仅间接相关，打 4-6 分；若无关甚至偏离，打 1-2 分。
4. 评估可量化指标：该需求上线后能否用数据验证？是否已规划埋点或实验方案？能精确量化（如 A/B 测试）打 8-10 分；只能通过主观反馈量化打 3-5 分；完全无法量化打 1 分。

输入输出物

责任边界

• 产品经理（PO）：负责主导 Impact 评估，提供需求背景、用户数据及战略信息，并填写初始评分。
• 技术负责人：从技术实现角度提供可量化指标的可行性评估（例如是否可埋点、能否做 A/B 测试）。
• 数据分析师（若存在）：协助定义量化指标的数据口径，提供历史基线数据。
• Scrum Master / 敏捷教练：确保评估过程遵守四维度分离原则，记录争议点并推动达成共识。

记录材料

每次 Impact 评估需产出以下记录，建议存储在需求管理工具（如 Jira、ClickUp）中：

• 四维度评分记录：每个子维度分数、评估人签字、评估日期。
• 评分理由备注：简短的定性说明，供后续复盘追溯。
• 加权权重系数：当前团队使用的四维度权重值（例如用户价值 40%、业务目标 30%、战略对齐 20%、可量化指标 10%），以及最后一次调整的会议纪要链接。

{
  "impact": {
    "userValue": { "score": 8, "reason": "解决 70% 活跃用户反馈的加载卡顿" },
    "businessGoal": { "score": 6, "reason": "预期提升次日留存 0.3%" },
    "strategicAlignment": { "score": 7, "reason": "符合 Q2 OKR: 性能治理" },
    "quantifiableMetric": { "score": 9, "reason": "可接入 APM 统计页面加载耗时" },
    "weightedTotal": 7.5,
    "weights": [0.4, 0.3, 0.2, 0.1]
  }
}

异常处理

验收标准

完成本章节内容后，应满足以下条件方可进入下一章节：

• 团队全体成员（至少 PO + Tech Lead + 一名开发代表）能够独立说出 Impact 的四个维度名称。
• 在一个模拟需求上，三人并行打分后，加权总分误差不超过 ±1.5 分（差异过大表明未掌握评估对齐方法）。
• 产出至少一份填写完整的 Impact 四维度评分表（含理由备注），并归档到团队的记录材料中。
• 所有异常情况处理方案已被团队熟知，并记录在团队的“评估 FAQ”文档中。