第2章 定义评估目标：业务需求、评估范围、成功标准
评估目标定义是 Metric Evaluation 流程的“定向环节”。业务需求决定了评估要回答什么问题，评估范围划定了分析的边界，成功标准则给出了可量化的验收依据。三者缺一不可，任何一方的模糊都会导致后续指标选择失焦、数据采集浪费、结论无法落地。
2.1 适用场景
- 新评估任务启动：首次对某业务线或技术模块开展指标评估，需要从零建立目标框架。
- 评估目标变更：已有评估体系因业务调整、组织重构或外部监管要求变化，需要重新定义评估目标。
- 多团队协同评估>：涉及产品、研发、运营、财务等多部门的复杂评估项目，必须在开始前对齐各方诉求。
- 周期性评估复盘：在季度/年度评估启动前，对上一周期的目标定义进行修订和优化。
2.2 前置条件
- 已获得项目章程或评估授权书，明确评估发起方与决策人。
- 已识别核心干系人清单（业务负责人、技术负责人、数据责任人等）。
- 已收集初步的业务背景资料（业务模型、历史数据、行业基准等）。
- 已确定评估的时间窗口与可用资源（人力、数据源、工具链）。
2.3 操作步骤
- 收集并结构化业务需求
通过干系人访谈、问卷、历史文档分析等方式，获取原始需求。使用需求溯源表将每条需求与提出人、业务场景、期望决策类型关联。 - 需求优先级排序与冲突消解
对需求进行“影响度 × 紧急度”二维评分，识别关键需求（P0/P1/P2）。对冲突需求（如“提升响应速度”与“降低资源成本”）组织专项讨论，记录权衡依据。 - 界定评估范围（In/Out）
明确评估覆盖的业务域、系统模块、时间区间、用户群体，同时书面列出本次评估不包含的内容，避免范围蔓延。 - 制定可量化的成功标准
为每个评估目标匹配 1–3 个量化指标，并设定目标值、容忍区间、测量方法。成功标准须符合 SMART 原则（具体、可测量、可达成、相关、有时限）。 - 评审与正式确认
召开目标定义评审会，邀请全部核心干系人逐条确认业务需求、评估范围和成功标准。签署《评估目标定义表》并归档。
实践要点：步骤 2 中的需求冲突消解是最容易被忽视的环节。建议使用“需求决策矩阵”，将冲突项拆解为“必须满足”“可优化”“可妥协”三档，并明确妥协方案的接受条件。
2.4 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 文档类 | 项目章程、干系人清单、历史评估报告 | 《评估目标定义表》《评估范围说明书》 |
| 数据类 | 业务模型数据、行业基准、历史指标快照 | 需求优先级矩阵、成功标准量化表 |
| 组织类 | 组织架构图、角色职责矩阵 | 签字确认页、评审会议纪要 |
2.5 责任边界
| 角色 | 职责 | 决策权限 |
|---|---|---|
| 评估负责人 | 组织需求收集、主持评审会、撰写目标定义表 | 协调需求优先级，裁决非原则性分歧 |
| 业务方 | 提出业务需求与期望指标，确认成功标准 | 对业务需求的真实性、优先级拥有最终解释权 |
| 技术团队 | 评估数据可用性、系统支撑能力，划定技术边界 | 对评估范围的技术可行性拥有一票否决权 |
| 决策者 | 审批评估目标定义表，确认资源投入 | 对目标定义的整体方向负责，可退回重新修订 |
2.6 记录材料
每次目标定义完成后，须归档以下三份材料。下面给出《评估目标定义表》的推荐模板结构：
# 评估目标定义表 (Template)
## 1. 基本信息
评估任务ID: EVAL-2025-XXX
评估名称: [如：推荐系统CTR评估]
发起方: [部门/团队]
日期: YYYY-MM-DD
## 2. 业务需求清单
| 需求ID | 需求描述 | 提出人 | 优先级(P0/P1/P2) | 关联业务场景 |
|--------|----------|--------|------------------|--------------|
| REQ-01 | ... | ... | P0 | ... |
## 3. 评估范围
In Scope: [业务域、系统模块、时间区间、用户群体]
Out Scope: [明确排除项]
## 4. 成功标准
| 目标编号 | 目标描述 | 量化指标 | 目标值 | 容忍区间 | 测量方法 |
|----------|----------|----------|--------|----------|----------|
| G-01 | ... | ... | ... | ... | ... |
## 5. 签字确认
评估负责人: [签字] 业务方: [签字] 决策者: [签字]
归档提示：所有记录材料需在评审会结束后 2 个工作日内完成电子签章并上传至项目知识库，确保参与方均可追溯。
2.7 异常处理
| 异常场景 | 处理措施 | 升级路径 |
|---|---|---|
| 需求冲突无法消解 | 组织专项决策会，引入“成本-收益”分析数据辅助判断 | 升级至项目指导委员会仲裁 |
| 评估范围持续蔓延 | 启动范围变更请求（PCR）流程，重新评估资源与时间 | 评估负责人 + 决策者联合审批 |
| 成功标准无法量化 | 拆解为可测量的代理指标（proxy metric），并记录局限性 | 引入数据科学家或领域专家协助 |
| 关键干系人缺席评审 | 会后 24 小时内一对一沟通，补充签字确认 | 评估负责人跟进，必要时升级至缺席者上级 |
红线规则：未完成目标定义评审并签署确认的评估任务，不得进入下一阶段（指标选择与数据采集）。任何未经确认的“口头目标”不得作为后续成功标准的依据。
2.8 验收标准
- 所有业务需求均已记录在《需求溯源表》中，且每条需求都标注了优先级和来源。
- 评估范围说明书中“In Scope”与“Out Scope”清单清晰，无模糊表述（如“等”“相关”“可能”等词汇）。
- 每项成功标准均包含：量化指标、目标值、容忍区间、测量方法，且经过至少一位数据责任人复核。
- SMART 检查：随机抽取 3 条成功标准进行 SMART 符合度检验，不符合率须为 0%。
- 《评估目标定义表》已获得全部核心干系人（评估负责人、业务方、决策者）的电子或手写签字。
- 所有记录材料已上传至指定知识库，命名规则为：
评估目标定义_任务ID_日期_v1.0.pdf。