【摘要】
需求治理这条线的最后一篇，讲验收。前五篇的所有动作——分级、文档、变更、拒绝——最终都汇到同一个问题上：这个项目什么时候算做完？
验收扯皮的项目，几乎都能追溯到同一个根源："做完"的标准是在验收前一周才第一次被认真讨论的。标准前置，验收就是走流程；标准后置，验收就是第二次谈判——而第二次谈判永远比第一次贵。
【核心要点】
- 验收条款只有三种合格写法：可测的（数字）、可演示的（场景）、可对照的（与基线比）
- "界面友好""运行稳定"这类形容词不是验收标准，是吵架素材
- UAT 的本质是拿真实数据跑真实场景——测试环境造的数据只能证明代码没写错，证明不了系统可用
- 验收会前必须齐三份文件：范围基线（含变更记录）、验收条款清单、遗留问题清单
- 验收不是终点动作：带遗留问题清单验收是常态，条件谈清楚比"全绿通过"重要
---
一、验收条款的三种合格写法
写验收条款时只有三种句式是合格的：
1. 可测——给出数字和测量方法。
❌ "系统响应快"
✅ "批次追溯查询，输入 LotID 到结果呈现 ≤3 秒（数据量 50 万条，测量方法：连测 20 次取 P95）"
数字必须带测量条件。50 万条数据下的 3 秒和 5 万条下的 3 秒是两个承诺。测量方法也要写死：平均值还是 P95？谁的秒表？这些不写，测试时就各说各话。
2. 可演示——写成场景剧本。
✅ "工程师 A（有异常处理权限）登录 → 看板出现异常批次卡片（批次号/机台/异常码）→ 点击卡片进入处理页 → 填写处置 → 提交 → 该批次从看板消失并出现在'已处理'列表，全程 ≤2 分钟。"
场景剧本的好处是验收当天照着演，演得过去就算过。它逼着双方把"用"这件事拆到动作级——很多分歧在拆动作时就暴露了。
3. 可对照——与基线比，不与想象比。
✅ "异常批次从发生到工程师知悉的时间，从基线 45 分钟降至 5 分钟以内（基线取上线前一个月的 63 起异常实测均值）。"
这条是 Fab 项目验收的黄金句式，因为它把主观感受（"好像快了"）换成了可审计的数字。基线一定要在项目启动期就测——上线之后再想补测基线，旧流程已经没人走了。
三种句式之外的一切写法——"稳定""易用""高效""智能"——都不是验收标准。遇到客户在合同里写了这种词，谈判时就要换成上面三种之一，一个词换一句 measurable 的话。
二、UAT：拿真实数据跑真实场景
很多项目的验收测试是这么做的：测试环境、造一批工整的测试数据、按开发写的用例跑一遍、全绿、通过。然后上线两周，客户发现系统"不能用"。
问题出在测试数据上。Fab 真实数据的特征是：缺字段、有重复、单位混用、时间戳跨时区、枚举值里混着手输的错别字。测试环境里那批漂亮数据把这些脏东西全过滤掉了，所以"全绿"只证明了代码没写错，没证明系统能在客户的现实里活下来。
UAT 数据集的准备规则：
- 来源真实：从客户生产库导出（脱敏后），或直接在测试期对接真实只读数据源。数据量至少覆盖一个月，因为跨月对账是常见场景。
- 脏数据保留：导出时不要清洗。系统在脏数据上的行为（拦住？提示？跳过？）本身就是验收内容——这是 PRD 异常分支那篇的回响。
- 场景由客户选：UAT 的测试场景让客户的资深用户来挑，不让你来挑。他挑的场景就是他心里的验收标准，早知道早好。
- 试跑期算验收期：正式验收前安排 2–4 周试运行，系统在真环境跑，出的问题记录在案。试运行期的每日问题清单，就是验收会上"遗留问题清单"的原料。
三、验收会前的三份文件
验收会的质量是会前决定的。三份文件缺一份，会就会失控：
1. 范围基线（含全部变更记录）。合同原始范围 + 每一张变更单。验收会上第一个争议永远是"这算不算范围里"，这张文件是唯一的裁决依据。这也是第 02-04 篇说"变更记录是验收说明书"的原因。
2. 验收条款清单（含测试结果）。每条需求一行：编号、验收条款、测试方式、测试结果（过/不过/遗留）、备注。会前发客户预审——验收会上不应该出现任何"第一次见"的内容。预审时客户的异议提前消化，正式会走签字流程，40 分钟结束。
3. 遗留问题清单。分三栏：问题描述、影响评估、承诺时间。没有项目是零遗留验收的——五个月工期里攒下两三个非阻断问题太正常了。主动列出来，比被客户在会上挖出来体面一百倍，而且带清单验收说明你对系统状态心里有数。
四、验收会上最常被引用的五句话
验收会上五句高频台词，各有应对：
"这个功能不是这么用的。" → 翻需求文档第 X 条 + UAT 场景确认记录。如果有书面依据，一句话闭环；如果没有，进遗留清单或走变更——当场不开辩论赛。
"我们领导觉得还差点意思。" → "请领导具体指出差距对应的条款，我们按条款处理：范围内修复，范围外走变更。"把模糊不满转回条款语言。
"能不能上线后再完善？" → 可以，写进遗留问题清单，给承诺时间。这话说明客户其实想收——顺着走。
"这个 bug 很明显啊，怎么没测出来？" → 区分两条线：范围内的问题修复并说明漏测原因；范围外（当初没约定）走变更或进遗留。混在一起谈，永远谈不清。
"先签字，问题后面再说。" → 只在遗留清单同时签字的前提下成立。"先签后说"等于放弃全部依据，这句话要么换成立清单，要么不签。
五、验收之后还有一步
验收签字不是终点，还有两个小动作，做与不做差别很大：
1. 48 小时内发验收纪要：通过范围、遗留清单及责任时间点、双方对接人。签字页扫描归档。热乎时写五分钟，冷了之后补要一小时还容易漏。
2. 交接给维护侧：把遗留清单、已知问题与绕行方案、客户对接人风格备注，整理成一页纸交给接手运维的同事。FDE 项目结束就失忆，是很多公司重复踩坑的原因——同样的坑，下个项目换个 FDE 再踩一遍。
六、可复用点
- 验收条款三种合格写法：可测（数字+测量条件）、可演示（场景剧本）、可对照（基线对比）。形容词不是标准。
- 基线数据在项目启动期测，上线后补不了。
- UAT 用真实脏数据、客户挑场景、试运行算验收期。测试环境的全绿证明不了可用。
- 验收会前三份文件：范围基线（含变更）、条款清单（含预审）、遗留清单。会上不出现"第一次见"。
- "先签后说"不成立：签字必须和遗留清单同时。
- 验收后 48 小时：纪要归档 + 维护交接。项目结束不失忆。
至此需求治理卷（卷 2）完结。下一卷（卷 3）进入系统落地：CIM 子系统一个一个上——从数据采集层开始，讲 EAP 对接的第一周会发生什么。