第4章：Impact维度——定义与度量方法
4.1 适用场景
Impact维度用于评估某个候选需求或功能上线后，对产品核心业务目标的预期贡献程度。适用以下场景：
- 新功能设计阶段，需要量化该功能对OKR/KPI的拉动作用。
- 多个需求争夺同一开发资源时，通过Impact评分区分优先级。
- 上线复盘时，将实际数据与预估Impact对比，校准团队估算能力。
4.2 前置条件
- 已明确当前季度/版本的产品核心指标（如：日活跃用户、付费转化率、7日留存）。
- 已获取或可推导各项指标的基线数据。
- 团队对“影响等级划分”的定义达成书面共识（见4.6记录材料）。
4.3 操作步骤
- 确定受影响的指标：明确本功能直接改变哪个北极星指标或一级指标。
- 定性标注影响类型：正向提升、负向抑制（通常是正向）、仅流程优化不涉及指标。
- 定量预估变化幅度：基于A/B测试历史数据、行业基准或专家判断，给出最可能的相对变化百分比。
- 映射等级并赋分：依据影响等级划分表将百分比转化为RICE标准分（如0.5、1、2、3）。
- 记录依据：在需求卡片中写明预估假设，供后续复盘验证。
4.4 输入与输出
| 类型 | 内容 | 格式/来源 |
|---|---|---|
| 输入1 | 产品核心指标清单及当前基线值 | 数据看板 / OKR文档 |
| 输入2 | 需求文档（包含预期效果描述） | PRD / 产品需求卡片 |
| 输出 | 每个候选需求的 Impact 标准分 | RICE评分表字段 |
4.5 责任边界
| 角色 | 职责 | 决策权 |
|---|---|---|
| 产品经理 | 提出Impact假设，与数据团队对齐 | 拥有最终估分权 |
| 数据分析师 | 提供基线数据，评审预估合理性 | 一票否决权（数据严重不符时） |
| 开发负责人 | 确认技术可实现性对影响的影响（如影响范围受限） | 建议权 |
4.6 记录材料
团队必须预先定义并维护以下影响等级划分表示例：
| 等级 | 评分 | 定义 | 定量示例（转化率） |
|---|---|---|---|
| P0·巨大 | 3 | 对核心指标产生变革性提升，进入行业头部水平 | 提升 > 20% |
| P1·高 | 2 | 显著正向影响，可被用户和报表明显感知 | 提升 10% ~ 20% |
| P2·中 | 1 | 指标有可测量的提升，但幅度较小 | 提升 2% ~ 10% |
| P3·低 | 0.5 | 仅影响用户路径体验，对指标无直接统计显著影响 | 提升 < 2% |
| 无影响 | 0 | 纯重构、迁移、技术债务清理 | 0% |
定性定量结合原则：
当缺乏历史数据时，允许使用 德尔斐法（多轮匿名打分）或 T恤尺码法（S/M/L/XL）进行定性判断。
但定性判断必须附带可回溯的证据链（如竞品对标截图、用户访谈纪要），不得凭空臆断。
4.7 异常处理
冲突指标 / 负向影响： 如果某个功能对A指标（如DAU）有正向影响，但对B指标（如ARPU）有负向影响，则 Impact 评分应取核心指标（北极星指标）的变化为准，并在备注中注明权衡。若影响纯属推测且无法通过小型实验验证，则置信度较低，建议将Impact分数降档处理（如从2降至1）。
4.8 验收标准
- 每个需求均明确关联至少一个核心指标。
- 所有Impact评分均对应到上述统一等级表。
- 高影响（3分）和巨大影响（2分）的需求必须附带数据测算简表或案例对比。
- 评分结果已录入需求优先级看板，可供其他团队成员查阅。