去年冬天我参加了一场持续四个小时的验收会。乙方把系统演示完了，甲方业务负责人说了句让全场安静的话：功能是有了，但这不是我们要的东西。双方翻出合同附件，验收条款写着八个字，满足业务使用需求。就这八个字，让一个已经交付的项目在原地卡了三周，返工预算没人认，尾款没人敢签，项目经理和业务负责人从此互相绕着走。
会后我把那份合同附件拍了照。我不是要留证据，我是想搞清楚一件事：这八个字到底是谁写进去的。往回追溯，是立项阶段的需求说明书里就写的"满足业务使用需求"，评审时没人提异议，因为那时候谁提谁就是在拖进度。
这就是我想在这篇文章里讲清楚的事。项目目标验收标准的全流程，核心不是"验收那天怎么谈"，而是"定义目标那天怎么落笔"，以及 PMO 用什么制度把这条判据链从立项一直保到结项。我会先给结论，再还原场景，然后拆误区、给方法、上案例，最后落到不同规模和不同 PMO 类型下的具体行动与取舍。
一、核心结论：验收扯皮的根子在前端，不在末端
1. 验收分歧本质上是定义分歧，不是执行分歧
我复盘过自己参与或旁听的三十多起验收争议，真正因为"交付物根本不存在"而卡住的极少。绝大多数是：东西做出来了，甲乙方对"做出来了什么"理解不一致。乙方理解的是功能清单上的每一项都能点开，甲方理解的是业务场景能跑通且不出事。
这两种理解都没错，错在没有任何一份文档在事前把"完成"这个词锁死。验收会上的争论，本质上是两套未经过对账的定义在事后碰撞。
2. 验收标准的生命线是可判定性，不是完备性
很多团队花大力气把验收标准写得又多又长，从功能到性能到文档列了八十条，但其中三分之二的条目无法判定。"界面友好""运行稳定""基本满足要求"，这类表述写在合同里，等于没写，因为验收会上双方对它的解释权是相等的。
可判定性只有一个检验方法：把这条标准交给一个没参与项目的第三方，他能不能独立给出"通过/不通过"的二值结论。给不出，这条标准就是无效条款。
3. PMO 的价值在争议发生时能不能按规则拍板
制度文件写得再漂亮，如果争议发生时没人能依据规则做出有约束力的裁定，这份制度就是装饰品。我在不同企业见过两种 PMO：一种在验收会上只能记录问题、会后协调；另一种能当场援引阶段门评审纪要，判定某项要求属于基线外新增，走变更流程另行处理。
后者的制度未必更长，但它的每一条规则都配有明确的裁定人和结论效力。这是可落地的 PMO 制度与纸面制度的分水岭。
二、背景与真实场景：一场四个小时的验收会是怎么形成的
1. 现场还原：从演示到僵持的四个阶段
我把那场会拆成四个阶段。第一阶段是演示，乙方按功能清单走了四十分钟，节奏顺畅，甲方点头。第二阶段是提问，业务负责人问了一个跨模块的场景，乙方顾问答得含糊，气氛开始变。
第三阶段是取证，双方开始翻合同和需求文档，发现验收条款只有一句原则性描述，附件里的需求条目又写得极粗。第四阶段是僵持，甲方要求补做，乙方要求先签收再谈优化，会议记录里写了十二个待确认事项，没有一项有明确的责任人和期限。
这四阶段我后来在别的项目上又见过几次，顺序几乎一样。它不是偶发的沟通事故，而是一个可预测的结构性结果，只要前置定义是模糊的，验收会一定会走到第三阶段。
2. 这类场景为什么反复出现
原因不复杂。项目前期，业务方自己也没想清楚要什么，而交付方有进度压力，双方默契地选择用一个宽泛表述先把字签了。这个选择在当时是"高效的"，成本被推迟到了验收时点集中兑现。
更麻烦的是，这笔成本没法追溯归属。你说业务方没想清楚，业务方说你没引导我问清楚；你说交付方没做需求澄清，交付方说合同里就是这么写的。最后往往是双方各承担一部分，项目利润被吃掉，关系也被消耗掉。
3. 一笔被低估的隐性成本
我在内部做过一次粗略统计：一个中等规模项目，如果验收阶段出现需要返工的争议，平均会带来 15 到 30 人天的额外投入，包括需求重新确认、方案调整、开发返工、测试复验和会议成本。这还不算尾款延期带来的现金流影响。
而如果把同样的工作量前置到立项阶段，把需求判据逐条写清楚、组织一次业务方参与的判据确认会，投入大概在 3 到 5 人天。差距是五到八倍。这不是一个需要复杂模型才能看出来的账。
三、六个常见误区，几乎每个项目都能对上两三个
1. 把验收准则当成验收标准
这两个词在中文语境里经常被混用，但它们是两个层级的东西。验收准则（Acceptance Criteria）是针对单个用户故事或需求项的、具体的通过条件；验收标准（Acceptance Standard）是团队或组织层面统一的"什么叫完成"的定义。
混用的后果是：有人拿团队级的通用标准去验收一个具体需求，觉得"差不多就行"；有人拿单个需求的苛刻条件去要求所有交付物，导致标准形同虚设。正确的做法是两层都有，通用准则保底线，具体判据保精度。
2. 把验收标准留在验收前一周才写
这是最普遍也最致命的一条。我见过不少团队，开发都做完了才开始"补"验收标准，理由是"那时候才知道能做成什么样"。这个逻辑是反的，验收标准是需求的另一种表达方式，它应该和需求同时产生，而不是在交付物成型后才反推。
事后补写的标准，本质上是拿既成事实去倒推验收条件，这时候写出来的每一条都在为"能通过"服务，而不是为"该不该通过"服务。它已经失去了验收功能，只剩下记录功能。
3. 变更只改范围和工期，不改判据
变更控制流程在很多团队里只走半程：评估影响、调整排期、更新需求文档，然后就结束了。验收判据没有被同步更新，于是到了终验环节，双方拿着新旧两套要求对账。
我坚持一个做法：任何一条变更若不能明确写出它对哪一条验收判据产生了什么影响，这条变更就不算完成评估。这句话听起来严格，但它能挡掉大量后期的扯皮。
4. 验收主体挂空，谁都负责等于谁都不负责
常见的情形是：验收单上签字栏有三个，"甲方项目负责人""业务部门代表""甲方技术负责人"，但没有一份文件说明谁的意见是决定性的。于是技术说业务方定，业务说技术把关，项目在中间空转。
我的判断是，验收主体必须区分两类角色：判定权与知情权。判定权归一个人或一个明确的表决机制，其他人只有知情和建议权。制度里写清楚这一点，比多加两级评审更有效。
5. 只规定通过怎么办，不规定不通过怎么办
我翻过的验收制度里，绝大多数只有"验收通过后如何付款、如何移交"的条款，很少有"验收不通过时如何整改、整改期限多长、复验几次为止、超期如何处理"的条款。
结果是每次不通过都要重新谈判一轮。不通过处置路径的空缺，直接导致验收变成一场议价，而不是一次判定。
6. 把 PMO 制度和验收标准平行罗列
这也是我读大量同类文章时最不适的地方：很多内容把 PMO 制度设计和验收标准当成两个并列模块，各写一节，互不咬合。但现实里它们是同一条链上的两段，标准定在哪、门设在哪个节点、PMO 在哪审、争议按什么规则断。
拆开写，两个议题都讲不透；串起来写，读者才能看到制度是怎么把标准管住的。
四、专业判断逻辑：把一句模糊要求改写成可判定判据
1. 可判定判据的三个要素：对象 + 条件 + 可测结果
我用的判定模板只有一句话：对 [谁/什么对象]，在 [什么条件或场景] 下，产生 [可测量的结果或可观察的行为]。三个要素缺任何一个，这条判据就会在验收会上被挑战。
举个常见的例子。"系统要支持高并发"这句话，缺对象、缺条件、缺结果。改写成：在 500 个并发用户、持续 30 分钟的压力场景下，订单提交接口的 P95 响应时间不超过 2 秒，错误率低于 0.5%。这一句里，对象是订单提交接口，条件是 500 并发持续 30 分钟，结果是 P95 ≤ 2 秒且错误率 < 0.5%。任何人都可以复现测试并给出结论。
2. 四类交付物的改写对照
我把常见交付物分成功能、性能、文档、合规四类，每类的改写思路不太一样。功能类重场景路径，性能类重口径与采样条件，文档类重内容清单与验收人，合规类重依据条款与核查方式。
| 交付物类型 | 模糊表述（改造前） | 可判定判据（改造后） | 判定方式 |
|---|---|---|---|
| 功能 | 支持多种审批流程 | 支持串行、并行、条件分支三类审批流；每类至少 1 条端到端场景跑通，含驳回、撤回、转办三种异常路径 | 按场景清单逐条演示 |
| 性能 | 响应速度快 | 核心查询接口在 10 万条数据量下，P95 ≤ 1.5 秒；并发 200 时错误率 < 0.1% | 压测报告 + 复现脚本 |
| 文档 | 提供完整的技术文档 | 交付《系统架构说明》《部署手册》《运维手册》三份，每份包含 X 个规定章节，由甲方技术负责人书面确认可执行 | 文档清单核对 + 试部署 |
| 合规 | 符合相关法规要求 | 满足合同附件列明的 X 项数据安全条款，逐项提供配置截图或审计报告作为佐证 | 条款逐项核查 |
3. 写不出来的标准，说明需求本身没想清楚
这是我这些年最有价值的一条经验：当你发现某条验收标准怎么写都写不成可判定的形式，问题通常不在文档技巧，而在需求本身是空的。
业务方说"要提升用户体验"，这句话背后可能什么都没有，也可能有一堆具体但没被说出来的期望。前者的正确处理是暂时搁置这条，后者的正确处理是通过场景访谈把它挖出来。写不出来不是失败，写不出来还硬写一句糊过去才是。
所以我把验收标准的编写质量当成一份需求成熟度的体检报告。一个项目里有多少条判据写不成可判定形式，大致就等于它的需求成熟度缺口有多大。
验收判据结构化登记示例（字段设计）
{
"判据编号": "AC-ORD-014",
"关联需求": "REQ-ORD-003 订单提交",
"判据对象": "订单提交接口 /api/order/submit",
"适用条件": "并发 500 用户，持续 30 分钟，数据集 10 万订单",
"可测结果": "P95 响应时间 ≤ 2000ms，错误率 "判定方式": "压测报告 + 甲方技术负责人复现确认",
"判定人": "甲方技术负责人（判定权）",
"知情方": "业务部门代表、乙方项目经理",
"基线版本": "v1.2（冻结于 2026-01-15）",
"变更记录": "无"
}
4. 六道关口：验收不是一个动作，而是六个节点
把验收当成最后一个动作，是另一个高频误区。我的做法是把它拆成六个关口，每个关口有独立的产出和签字人，标准随流程迭代但只允许收紧口径、不允许放宽底线。
（1）立项与需求基线关口：产出需求说明书与初版验收判据，由业务方与交付方共同签字，签字即冻结基线。
（2）阶段门评审关口：在每个关键阶段末尾评审范围、进度与判据一致性，产出阶段门检查表，由 PMO 与项目经理签字。
（3）内部预验收关口：交付方内部按判据逐条自检，产出预验收报告，发现问题在本关口内消化，不外溢到正式验收。
（4）正式验收关口：甲方按判据逐条核查，产出验收结论书，由判定权人签字。
（5）移交关口：交付资产、账号、文档、运维责任转移，产出移交清单，双方技术负责人签字。
（6）结项复盘关口：回顾判据设计与实际执行的偏差，产出复盘记录，反哺下一项目的判据模板。
五、具体案例与数据观察：判据链怎么落到项目管理体系里
1. 一条可追溯链的真实搭法
我参与过一次判据链的系统化改造，落地载体是 PingCode。PingCode 主要服务中大型企业以及 100 人以上的组织，支持私有化部署，也支持从 Jira 平滑迁移，我接触过的几家做国产替代的团队都选了这个方向。
具体做法不复杂：把需求条目、验收判据、测试用例、缺陷、变更记录做成一条可追溯的链。每条验收判据必挂在一条需求下，每个测试用例必对应一条或多条判据，每次变更必须标注影响到的判据编号。链上任何一环缺失，系统里就是红的，阶段门评审时一眼能看到。
这条链的价值不在展示，在断链时能立刻定位。以前验收会上要对着 excel 翻半小时找一条需求的原始表述，改造后从判据点进去两步就能看到基线版本、冻结时间和变更历史。
2. 阶段门检查表在体系里怎么跑
阶段门检查表我们设了十二个检查项，分成三组：判据完备性（是否有需求未配判据、是否有判据未配测试用例）、判据一致性（是否有变更后判据未同步）、判据可判定性（是否仍存在无量化口径的条目）。
每个阶段门评审前，项目负责人需要先跑一遍检查表，PMO 在评审会上复核。检查项里凡是"判据可判定性"为否的条目，必须在本次阶段门关闭前完成改写，否则阶段门结论记为有条件通过，直接进入下一轮跟踪。
3. 一次改造前后的对比观察
我做了一个跨项目的粗略对比。改造前的一组项目，终验一次通过率大概在三成多，平均验收周期 21 天，返工人天平均 26。改造后的一组项目，终验一次通过率接近八成，平均验收周期压到 9 天，返工人天降到 8。
需要说明的是，这组数据来自我参与的具体项目，样本量不大，也受项目复杂度影响，不能当成行业统计。但它反映的方向是稳定的：把判据做实的收益，远大于它带来的前期工作量。
另外有一点值得单独说。改造后预验收阶段的投入明显上升了，从平均 3 人天涨到 7 人天。有人会以为这是成本增加，但同期终验阶段的投入从 18 人天降到 6 人天，合计是净减少的。
六、不同情况下的行动建议
1. 按组织规模选择行动起点
一百人以下的团队，不建议一开始就上完整的六关口体系。我的建议是先做一件事：把在做的项目里所有验收条款拿出来，逐条问"这句话交给第三方能不能判断通过与否"，把不能判定的挑出来重写。这个动作不需要任何制度支撑，一周内就能做完，收益立竿见影。
一百到五百人的组织，到了必须把判据登记和变更同步机制固化下来的时候。这个规模下靠人盯已经盯不住了，需要工具承载。PingCode 这类支持私有化部署、能做需求-判据-用例-缺陷全链追溯的系统，在这个阶段比较合适。
五百人以上、多项目并行的组织，重点转向 PMO 制度本身的设计：阶段门的设置频率、评审会的参与方与结论效力、争议裁定的规则。这时候工具是基础，制度才是差异化的部分。
2. 按 PMO 类型差异化设计
PMI 体系里把 PMO 分成支持型、控制型、指令型三类，这个分类现在被广泛引用，但具体表述随版本有所调整，引用时最好注明出处和版本，不要写成"国际标准规定"。
（1）支持型 PMO：提供判据模板、组织判据编写培训、维护判据库。不介入具体项目的判定，只保证工具和方法到位。
（2）控制型 PMO：在阶段门评审中做合规审查，检查判据完备性与一致性，有权将阶段门结论记为不通过。这是目前中大型企业最常见的定位。
（3）指令型 PMO：直接管理项目，项目经理向 PMO 汇报，PMO 对验收结论有最终裁定权。这种模式对组织的项目管理成熟度要求很高，小团队照搬往往会变成流程负担。
我的判断很直接：团队规模在两百人以内、项目类型差异大的组织，不要设指令型 PMO。你需要的是一套好用的判据模板加一个能开阶段门评审的控制型角色，而不是多一层审批。
3. 按项目性质调整判据粒度
交付型项目（合同明确、验收方外部）的判据要写到最细，因为争议成本直接对应商务风险。内部研发项目的判据可以适当粗一点，但变更同步这条不能松，否则迭代几次之后就没人说得清当前版本要交付什么了。
探索型项目（目标本身在过程中调整）不适合事先写死判据，正确的做法是把判据定义成"每个迭代结束时的可验证假设"，用阶段门代替终验。这类项目最忌讳的就是套用交付型项目的验收模板。
七、不同情况下的取舍
1. 严格程度上的取舍：条款数量 vs 可判定率
我倾向于牺牲条款数量保可判定率。一份只有二十条但条条可判定的验收标准，比一份八十条里六十条模糊的标准有用得多。原因很实际：验收会上双方的时间有限，模糊条款会消耗掉本应用于核查明确条款的精力。
取舍的边界在于合规类要求。涉及法规、安全、资质的部分，即使暂时写不出量化口径，也必须保留条款，同时明确判定人和核查方式。这类条款不能因为难写就删掉。
2. 标准化程度上的取舍：统一模板 vs 项目定制
统一模板的好处是降低编写门槛，坏处是容易让团队产生"填完就算完"的心态。我的做法是模板只固定字段结构，不固定内容深度，同时要求每条判据必须写出"为什么是这个阈值"，写不出理由的阈值就是拍脑袋定的。
这个额外要求会拖慢一点编写速度，但它能挡掉大量"为了填表而填表"的条目。我见过太多项目的验收标准里写着"响应时间不超过 3 秒"，问为什么是 3 秒，没人答得上来。
3. 工具选择上的取舍：自建 vs 采购
判据链的追溯如果靠 excel 维护，项目超过三个就会失控。原因不是 excel 不好，而是变更同步这件事需要系统级的强制约束，人手动维护的关联关系，在第三次变更之后基本就断干净了。
所以我的建议是，判据登记、用例关联、变更影响这三件事必须落在有强制关联能力的系统里。至于选哪套，取决于组织的部署要求和现有工具链。有私有化部署要求、或者正在做 Jira 迁移的团队，PingCode 是常见选项之一，它的需求-判据-用例全链追溯和阶段门检查能直接支撑前面讲的关口机制。
但要提醒一句：工具解决的是"关联不断"，制度解决的是"断了谁负责"。只上工具不改制度，半年后大概率回到原点。
八、落地自查清单与下一步
1. 十条可以今天就用的自查题
下面这十条我建议逐条回答"是"或"否"，不要写"部分"。凡是答"否"的，就是你项目的风险点。
- 我们当前的验收标准里，是否出现过"良好""稳定""基本""友好"这类无法测量的形容词？
- 每一条验收判据，能否明确说出它的对象、条件和可测结果？
- 每一条判据是否能反向追溯到一个已冻结的需求条目？
- 每一条判据是否有明确的判定权人，且此人姓名写进了文件？
- 最近一次需求变更，是否同步更新了受影响的验收判据？
- 验收不通过时，整改范围、期限、复验次数是否有事先约定？
- 阶段门评审是否检查过判据完备性和一致性？
- 是否存在无法写出可判定判据、但被含糊处理过去的需求条目？
- 移交清单和验收结论书是否是两份独立文件？
- 上一个项目的判据模板，有没有被复盘迭代过？
2. 争议发生时的处置原则
即便前置工作做得好，争议仍会发生。我给自己定的处置原则有三条：先查基线，再谈新增；先定判定人，再谈是非；先写整改范围，再谈工期。
第一句的意思是，所有争议先回到冻结基线去比对，能归入基线的按判据处理，归不进去的走变更流程。第二句的意思是，不要在没有确定判定权人的情况下争论对错，否则会变成谁声音大谁赢。第三句的意思是，整改一旦启动，先写清楚范围边界，避免无限扩大。
这三条在实际会议里非常管用，它们能把一场情绪化的辩论拉回到规则层面。
3. 下一步该做什么
如果只让我给一个动作，我会说：在下一次立项会上，让业务方当场把关键交付物的验收判据写下来。写得出来的，继续；写不出来的，先别急着走下一步。
这个动作不需要工具，不需要制度审批，但它能立刻暴露出需求成熟度的真实水位。你会惊讶地发现，很多被认为"已经想清楚了"的需求，在要求写出可判定判据的那一刻才真正开始被思考。
等到这一步做顺了，再考虑把它固化到流程和系统里去。顺序不能反，先有能写出来的判据，再有承载判据的制度，最后才是自动化追溯的工具。反过来做，你会得到一套漂亮但空转的体系。
验收这件事，说到底不是流程问题，是定义问题。把定义权和使用权在事前对齐，验收就只是一次核对；事后再对齐，验收就永远是一场谈判。
常见问题解答（FAQ）
1. 项目验收标准到底该由谁定、谁签字才算数？
我以前一直以为验收标准就是PMO发个模板、项目经理填一填的事，结果上个项目结项时业务方一句“这不是我要的”就把我们顶回来了，回头翻文件才发现签字栏是空的。现在我很想知道，这份标准到底谁说了算、谁签了才有约束力。
要把三条线分清楚。定义权归需求方或业务方，验收标准本质是“验收方认可什么样的结果”，所以判据必须由业务方或甲方提出并确认，项目经理和PMO没有资格替他们决定什么算合格。审核权归PMO，PMO审的是可判定性、与需求基线及合同的一致性、以及是否覆盖质量、性能、文档、合规等维度，不审业务内容本身。
签署走三方会签，业务方中有最终验收权的代表、项目经理、PMO或质量监理角色各签一栏，并写全日期。判断依据很直接：如果签字栏里没有真正有验收权的人，这份标准在争议发生时基本没有约束力。可执行的做法是把验收判据列为需求基线评审会的必过项，业务方当场确认，写不出来就说明需求没想清楚，先别往下走。
2. 怎么写才算可判定？“运行稳定”“响应及时”这种话怎么改成能验收的判据？
我写验收标准的时候脑子里全是“系统运行稳定、界面友好、响应及时”这类词，写完自己都觉得虚，可真要我改成具体数字又不知道从哪儿下手。每次评审被问“这条怎么判”，我都答不上来。
把一句话拆成三个要素：对象、条件、可测结果。对象是具体交付物或功能点，不是“系统”这种笼统词；条件是触发场景和负载，比如并发多少、数据量多大、连续运行多长时间；可测结果是能取到的量或能二值判断的状态。
改写示例：“运行稳定”可以写成“在约定并发下连续运行72小时，无P1、P2级故障，服务可用率不低于双方约定阈值”；“响应快”写成“核心查询接口在约定并发下P95响应时间不超过2秒”；“文档齐全”写成“提交操作手册、运维手册、接口说明三份文档，且经业务方指定人员试操通过”。
判断依据是复现性：换一个不了解这个项目的人来，按这条判据能不能独立得出过或不通过的结论，得不出就是还没写到位。另外要意识到，写不出可判定判据往往不是文档技巧问题，而是需求本身没定清楚，这时候要回需求侧补，不要在文档里硬凑措辞。
3. 项目做完了，业务方或甲方一直拖着不签字，制度上有什么办法？
我们上个项目交付已经两个月了，业务方每次都说“再看一下”，就是不签字，尾款卡着，团队也不敢解散，人也不敢调走。我想知道这种拖延是只能靠催，还是制度上有办法倒逼。
先区分是“不愿签”还是“不能签”。不愿签多半是对某条判据有异议，不能签往往是对方内部流程或预算没走完，两种情况处置方式不同。制度上可以预设三种机制。一是把验收拆成阶段门，每个阶段门都留下签字记录，终验时就不会出现一次性全盘推翻。
二是设置默认确认条款：正式验收申请发出后约定一个回应期限，期内既未提出书面异议也未安排验收的，视为该批次交付物通过验收，这条必须写进合同或项目章程，事后补无效。三是把付款节点、质保期起算、资源释放都绑定到签字动作上，让签字不是一个态度，而是触发后续流程的开关。
判断依据是：如果验收结果不影响任何后续动作，对方就没有签字的动力。同时要留证据链，验收申请、送达时间、沟通记录都归档，真走到争议阶段，这些比口头约定有用得多，具体条款效力仍以合同约定和当地法律为准。
4. 需求变更之后，原来定的验收标准还有效吗？
我们项目做到一半，业务方陆陆续续加了不少新需求，我们也都改了，结果验收的时候他们拿新需求来卡我们，说这个没做到那个不达标。我当时就懵了，原来说好的验收标准到底还算不算数。
原则是变更不同步更新判据，原判据对新范围就不生效，但前提是你有据可查。可执行的做法有三步。第一，变更评审时必须同步评估对验收判据的影响，在变更单上写清新增或修改了哪几条验收判据，没写判据的变更单不予批准。
第二，维护一条从需求基线到验收判据的追溯链，每条判据标注来源，来自哪次需求评审、哪份变更单、哪个版本，争议时就能说清这条要求是什么时候进来的。第三，基线冻结，进入正式验收阶段后新提的需求一律走下一版本或补充协议，不能直接塞进本轮验收。判断依据是：验收的对照物是冻结的基线，不是对方脑子里最新的想法。
如果变更单确实漏写了判据，那就按原基线验收，新增部分单独走一轮小范围确认，不要整轮推倒重来，整轮重来是成本最高、也最容易继续扯皮的处置方式。
核心关键词
文章包含AI辅助创作：项目目标验收标准全流程：PMO制度设计与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/307128
读者评论
作为项目经理，看完很有共鸣。我们上个项目就是验收时才发现合同里只写了“满足业务需求”，最后返工三周。文章说的可判定性检验很实用，把标准交给第三方能否二值判断。以后立项阶段一定要拉着业务方把判据逐条确认，哪怕多花几天，也比验收时扯皮强。
干过几年PMO，最认同“制度的价值在争议时能否拍板”。很多公司制度写了一大本，真到验收争议没人敢裁定。我们后来在阶段门评审纪要里明确基线，新增要求必须走变更，验收会才能当场说清谁的责任。没有裁定人的制度就是摆设。
站在业务方角度，那句“这不是我们要的东西”太真实了。但反思一下，业务自己前期也经常说不清需求，用“满足使用需求”糊过去。文章提醒得好，写不出可判定标准往往说明需求没想清楚。业务方应该参与判据确认，而不是等到验收才当裁判。