第1章：验收标准的业务价值与核心原则
业务对齐 · 明确可测 · 避免歧义
本章定位：掌握验收标准（Acceptance Criteria）在交付链条中的枢纽作用，学会用三条核心原则判断验收标准是否合格，为后续章节的指标可衡量性实战奠定认知基础。
适用场景
- 产品需求从“概念”向“可执行”转化时（用户故事拆分、功能规格编写）。
- 开发 / 测试团队需要统一的“完成边界”以避免返工。
- 跨角色（产品、开发、QA、业务方）对同一交付物进行验收签章前。
- 遗留系统功能重构或迁移时，需与旧行为对齐的验收基线。
前置条件
| # | 条件 | 检查点 |
|---|---|---|
| 1 | 需求描述已通过业务方初步确认 | 用户故事 / 功能需求文档已签署草稿 |
| 2 | 技术可行性已由架构师/技术负责人初步评估 | 无重大技术障碍记录 |
| 3 | 测试环境 / 数据准备至少完成规划（非必须在此时就绪） | 测试方案草案已包含可测试性分析 |
| 4 | 参与验收标准定义的角色清单已确定 | 产品经理、开发代表、测试代表、业务代表 |
操作步骤
依照“三条核心原则”依次检查每个候选验收条款。每步输出可复用的判别清单。
- 业务对齐校验：将每条验收标准与原始业务目标（KPIs / 用户故事顶点）逐条比对。若与业务目标无直接关联或关联模糊，则退回需求方澄清或删除。
- 明确可测性评估：对未通过“是否可以用具体数值 / 状态 / 布尔判断验证”的条款，进行量化改写。必要时引入阈值、边界值或采样规则。
- 歧义性检查：使用“换人换语境”法——让不在当前上下文的人读同一句话，记录并消除所有可能的多义解释（如“响应快”→“95%的请求在200ms内返回”）。
- 三方复核：产品、开发、测试各指派一人，对最终版本背对背投票，表决是否满足上述三条原则。全票通过则锁定验收标准。
常见陷阱：不要将“实现方式”写入验收标准（如“使用Redis缓存”），应只描述外部可观察的行为结果。验收标准是测什么，不是怎么造。
输入输出物
| 类型 | 物名 | 格式/示例 |
|---|---|---|
| 输入 | 需求描述（用户故事 / 功能规格） | Jira Story、Confluence 文档 |
| 业务目标 / 关键结果 (OKRs) | 如：订单转化率提升2%，客服工单减少15% | |
| 输出 | 验收标准列表（带优先级） | 示例： |
| 验收标准复核矩阵（原则检查记录） | 三列：条款、是否业务对齐、是否明确可测、有无歧义 |
责任边界
- 产品经理：提供业务目标解释，对“业务对齐”负主要责任。
- 技术负责人 / 架构师：评估“明确可测”的技术可行性，补充边界条件。
- 测试工程师：主导“明确可测”与“避免歧义”检查，编写可复用测试断言。
- 项目 / 迭代经理：确保三方复核按步骤执行，组织争议裁决。
记录材料
推荐使用以下表头存储每项验收标准（可放在 Confluence、Notion 或测试管理工具中）：
验收标准条目模板
ID | 需求来源 | 验收描述 | 业务对齐证据 | 可测性描述（含阈值） | 歧义风险等级 | 状态
ID | 需求来源 | 验收描述 | 业务对齐证据 | 可测性描述（含阈值） | 歧义风险等级 | 状态
异常处理
| 异常场景 | 处理方式 | 升级路径 |
|---|---|---|
| 验收标准与业务目标冲突 | 暂停定义，由产品经理与业务方重新对齐需求 | 优先级P0时直接升级至产品总监 |
| 某验收条款无法量化 | 采用“可接受范围+抽样验证”方案，记录在备注中 | 若涉及合规要求，需法务/风控介入 |
| 三方复核无法达成一致 | 由技术负责人或迭代经理进行仲裁，仲裁结果写入风险日志 | 仍不一致则升级至CTO/CPO联合裁决 |
| 验收标准频繁变更 | 设立“验收标准变更锁”，要求变更必须重新过步骤1-4 | 同一需求超3次变更则触发需求评审复盘 |
本流程验收标准
完成本章定义的验收标准后，需自检以下四项全部达标，方可进入下一章节：
- 所有验收条款均经过业务对齐核查，且存在对应业务目标关联。
- 无任何条款存在“模糊描述”（如“快速”“友好”“足够”等主观词汇）。
- 每条验收标准均可使用自动化或手工测试在15分钟内完成一次验证。
- 三方复核记录完整，无遗留争议。
核心原则口诀：业务没跑偏，可测没商量，歧义全杀光，验收才健康。