2023 年 9 月，我带一个 60 人的研发团队做核心交易链路重构，里程碑定在 9 月 30 日。当天项目群刷屏“里程碑达成”，演示走完、纪要发出、成员互道辛苦。三个月后正式上线，首周爆出 17 个 P0/P1 缺陷，其中 9 个精确落在那个“已达成”的里程碑范围里。复盘时我翻出当天的验收材料，只有三行字：功能开发完成，测试通过，验收通过。没有一条可量化标准，没有任何人对“通过”的定义达成过共识，也没有一个人签过字、认过账。
那次事故之后我花了两年时间，在三个规模不同的研发组织里反复重做节点验收机制。结论有点反直觉：节点验收做不好，八成不是执行力问题，而是定义问题。团队并不懒，他们只是从来没有被告知“完成”长什么样。这篇文章不讲方法论名词，只讲我踩过的坑、改过的模板、以及最后真正跑起来的东西。
一、先给结论：节点验收的本质是“可验证的交付契约”
1. 验收不是签字仪式，是风险闸门
大部分团队把节点验收理解成一次会议：人到齐、PPT 讲完、领导点头、散会。这种理解下，验收的唯一产出是一份会议纪要，没有任何风险被真正拦截。
我更愿意把它定义为一次有明确输入、明确标准、明确责任人、明确结论类型的状态转移。里程碑之前是一个状态，之后是另一个状态，中间必须有东西被验证、被确认、被签字承担。如果这一步做完，团队的行为和资源分配没有任何变化，那这次验收就是零价值。
我常用的判断标准很粗暴：验收会后，有没有至少一项工作被否决、被延期、被追加条件？如果一个季度内所有节点验收都是“全员通过、零异议”，那这套机制基本已经退化成仪式。
2. 里程碑从 0 到 1，其实分三个阶段
我见过太多团队只做第三阶段，然后抱怨验收没用。完整的节点验收生命周期应该拆成三段：
- 定义期（里程碑开始前）：确定验收对象、验收标准、验收人、验收时点。这一段决定后面 80% 的效果。
- 执行期（里程碑进行中）：按约定频率做增量检查，把问题在中途暴露，而不是堆到最后一刻。
- 验收期（里程碑节点当天及前后）：按既定标准判定结论，输出结论类型和后续动作。
大部分团队直接跳到第三段，结果就是验收当天第一次看到真实状态，此时距离交付只剩几个小时，能做的只有“通过”或者“吵架”。
3. 我的三条核心判断
判断一：验收标准必须在开工前写死，而不是验收前商量。标准一旦可以在验收现场讨价还价，它就不再是标准，而是博弈筹码。我在第二个团队推行过一条规矩：里程碑启动会上，没有签署验收准则的里程碑不允许开工。
判断二：验收人必须是能从交付物中获益或受损的人，而不是旁观者。开发给开发验收、项目经理给全组验收，都是无效验收。谁承担后果，谁签字。
判断三：验收结论不能只有二值。“通过 / 不通过”会逼着所有人撒谎。我后来统一改成三档：通过、有条件通过（带明确整改项和截止时间）、不通过。“有条件通过”这一档，是让验收机制活下来的关键，它给了团队面子，同时把风险显性化。
二、背景与真实场景：为什么里程碑总是“看起来完成了”
1. 一次延期复盘的完整还原
回到 2023 年那次事故。我在复盘会上让每个人匿名写一句“9 月 30 日那天，你认为里程碑达成到什么程度”。收上来 14 份答案，分布是这样的：3 人认为 100% 完成，5 人认为“主体完成、细节待补”，4 人认为“大概 70%，但不敢说”，2 人认为“其实没完成，只是没人问”。
同一个里程碑，14 个人有四种认知。这就是节点验收失控的真实形态：不是没人发现问题，而是问题没有被结构化地收集和对齐。验收会开了，但没有人被要求用同一把尺子回答同一个问题。
更麻烦的是，这四种认知在验收会上全部被“沉默”抹平了。认为只有 70% 的人不说话，是因为没有安全的表达通道；认为没完成的人不说话，是因为不想当那个“扫兴的人”。
2. 为什么“看起来完成”是默认状态
研发协同有一个结构性特征：交付物的完成度是连续的，而汇报语言是离散的。代码写了 80%、联调通了 60%、边界场景覆盖了 40%，这些都能被一句“开发完成”概括掉。
再加上三层放大：进度百分比天然偏乐观（人倾向于高估自己的完成度）、跨职能团队对“完成”的定义不同（开发看代码，测试看用例，产品看体验）、以及汇报链条上的逐级润色。三者叠加，一个真实完成度 60% 的里程碑，传到决策层就变成了 95%。
我用一个真实的漏斗模型记录过这个过程。在一个 12 周的中型项目里，从计划范围到业务真正可验收，每一层的衰减非常惊人：
3. 跨职能协同中的三个断层
我后来把验收失败的原因归到三个断层上，这三个断层在几乎所有研发组织里都存在。
断层一：语言断层。产品说“流程跑通”，测试说“主流程通过”，开发说“接口全部实现”。三句话听起来一样，实际覆盖范围差了十万八千里。验收会上没人追问“跑通”的边界条件是什么。
断层二：时间断层。验收被安排在里程碑最后一天，此时任何发现的问题都已经没有修复窗口。验收变成了记录问题，而不是拦截问题。
断层三：责任断层。验收人通常是项目经理或技术负责人，但他们既不是交付物的使用者，也不承担线上事故的直接责任。没有利益绑定，验收判断自然宽松。
三、拆解常见误区：五个让验收失效的坑
1. 误区一：用进度百分比代替验收标准
“这个模块完成 90%”是我听过最没有信息量的一句话。90% 是什么口径？剩下的 10% 是哪些工作？它们需要多少时间？会不会牵出新的依赖？
百分比的问题在于它可以被任意解释，而且天然让人乐观。我更推荐的方式是用验收准则清单替代百分比：一条准则只有两种状态，满足或不满足，没有中间地带。如果确实处于中间态，那就说明这条准则定义得太粗，需要再拆。
我在第三个团队做过一个对照：同一个模块，A 组按百分比汇报，B 组按准则清单汇报。结果是 B 组在里程碑当天暴露出的未完成项比 A 组多出 2.3 倍，但上线后的缺陷逃逸率低了 61%。多暴露不是问题变多了，而是问题提前被看见了。
2. 误区二：把验收压缩到一天甚至一小时
我参加过一次只有 40 分钟的里程碑验收会，议程是：演示 15 分钟，答疑 10 分钟，领导讲话 15 分钟。这种节奏下，验收只能覆盖“能不能演示”，覆盖不了性能、异常、回滚、数据一致性这些真正会出事的地方。
我的做法是把验收拆成三个检查点：T-3 天做预验收（材料和数据准备情况）、T-1 天做技术验收（指标、缺陷、演练）、T 日做业务验收（场景、体验、结论）。三个检查点分摊下来，每个环节的会议时间反而更短，但覆盖率提升明显。
3. 误区三：验收人只有项目经理
项目经理没有能力验收技术指标，也不应该为业务效果签字。让他做唯一验收人，等于把所有风险押在一个既无专业判断权、又无后果承担的人身上。
我的原则是按验收对象指派验收人：技术类交付物由架构或技术负责人验收，业务类交付物由产品负责人或业务方验收，稳定性类交付物由运维或 SRE 验收。项目经理的角色是组织和记录，不是判定。
4. 误区四：验收结论只有“通过 / 不通过”
二值结论会制造两个后果：一是验收人倾向于选择“通过”以避免冲突，二是被验收方把精力花在说服而不是补缺上。
我后来统一使用三档结论，并强制要求“有条件通过”必须写明整改项、责任人、完成时间。这一档的存在，让验收会从对抗变成了分工。数据显示，引入三档结论后，我们团队的验收异议提出率从 11% 上升到了 47%，而里程碑准时率反而提高了，因为问题被提前写进了待办，而不是烂在肚子里。
5. 误区五：验收完成即归档
验收不是终点，是下一个里程碑的输入。我在早期团队犯过的错是：验收会开完，纪要发出去，然后没人再看。三个月后同样的问题在下一个模块重演。
现在的做法是把验收结论直接转成下一阶段的输入项：整改项进任务列表、未覆盖场景进测试用例库、风险项进风险登记表，并且在下一个里程碑的启动会上强制回顾。闭环不是一句口号，是三个具体的流转动作。
四、专业判断逻辑：一套可落地的节点验收方法
1. 第一步：定义验收对象，先列清单再谈标准
验收对象不是“这个模块”，而是可以被单独判定的交付物条目。我会要求团队在里程碑启动时产出一份交付物清单，每一条都必须是名词加可观测状态。
比如“支付链路重构”这个里程碑，交付物清单至少包含：支付接口文档、灰度发布方案、回滚脚本、监控看板、压测报告、异常场景测试报告。清单列不出来，说明这个里程碑本身定义不清。
2. 第二步：定义验收标准，写成可判定的准则
标准的核心要求是可判定，即任何人拿着它都能得出同样的结论。我通常用三段式描述：触发条件、判定阈值、证据形式。
下面是我实际在用的验收准则模板，直接放在工具里跟着里程碑走：
milestone: M3-支付链路重构
acceptance_criteria:
id: AC-01
item: 支付成功率
condition: 灰度 5% 流量，持续运行 24 小时
threshold: 成功率 >= 99.5% 且无 P0 异常
evidence: 监控看板截图 + 埋点导出报表
owner: 后端负责人
type: hard
id: AC-02
item: 缺陷状态
condition: 里程碑范围内全部需求
threshold: P0/P1 清零，P2 evidence: 缺陷列表导出
owner: 测试负责人
type: hard
id: AC-03
item: 回滚能力
condition: 演练环境
threshold: 回滚耗时 evidence: 演练记录 + 执行日志
owner: SRE
type: soft
review_gates: [T-3 预验收, T-1 技术验收, T+0 业务验收]
conclusion_options: [通过, 有条件通过, 不通过]
注意 type 字段：hard 项不满足则不允许通过，soft 项不满足可以进入“有条件通过”。这个区分非常重要，它让验收有弹性但不失底线。
3. 第三步：定义验收角色，明确谁签字谁担责
我用一个简化的权责表来固化这件事，比 RACI 更好落地：谁提供材料、谁判定、谁签字、谁善后。四个角色必须落到具体人名，不能落到岗位名。
| 角色 | 职责 | 典型人选 | 失职后果 |
|---|---|---|---|
| 材料提供方 | 按准则准备证据，提前 24 小时提交 | 开发 / 测试负责人 | 材料缺失则验收顺延，计入里程碑延期 |
| 判定方 | 对照准则逐条判定，给出结论与理由 | 技术负责人 / 产品负责人 / SRE | 判定失误导致线上事故需共同复盘 |
| 签字方 | 确认结论，承担资源协调责任 | 业务负责人 / 研发总监 | 承担后续资源追加决策责任 |
| 善后方 | 跟踪整改项直至关闭 | 项目经理 / 指定责任人 | 整改项逾期未关闭则升级处理 |
4. 第四步：定义验收时点，用三个检查点覆盖全程
T-3 预验收的重点是材料完整性：证据是否齐、数据是否是真实环境跑出来的、有没有拿演示环境数据充数。这个检查点能刷掉大部分“临时拼凑”。
T-1 技术验收的重点是指标与风险：性能、稳定性、回滚演练、异常场景覆盖。这一步通常由技术负责人主导，业务方可以不到场，但结论必须书面同步。
T+0 业务验收的重点是场景与体验：按真实用户路径走一遍，确认业务方能接受当前状态。这三步走完，验收会本身只需要 30 到 45 分钟。
5. 第五步：定义结论类型，把结论变成行动
三档结论必须配套三套动作，否则结论还是空的。
- 通过：里程碑关闭，交付物进入下一阶段，验收材料归档到知识库。
- 有条件通过：里程碑标记为“带条件关闭”，整改项自动生成任务并指派责任人，设定截止时间，逾期自动升级到上级。
- 不通过：里程碑延期，重新确定验收时点，同时必须做一次根因分析，明确延期责任归属和资源调整方案。
我特别强调“有条件通过”的整改项必须有截止时间和升级路径。没有截止时间的整改项等于没有整改项，这是我用无数次教训换来的结论。
五、具体案例与数据观察：从表格到工具的落地过程
1. 载体演进：从共享表格到研发管理平台
我们最开始用共享表格管验收准则，前两个季度还能撑住，到第三个季度就崩了。问题出在三个地方：准则和需求不联动，需求一变准则不同步；证据散落在聊天记录和网盘里，找不到；整改项没人跟踪，全靠人肉催。
这类问题的本质是验收数据和研发过程数据割裂。验收标准写在表格里，需求写在另一个系统里，缺陷写在第三个系统里，三份数据对不上，验收就变成了人工核对，成本高且容易漏。
后来我们把节点验收整体搬到了研发管理平台里。以一个服务中大型企业、面向 100 人以上组织的研发管理平台为例，比如 PingCode，它的优势恰好覆盖了我们踩过的坑：里程碑可以绑定具体需求范围、验收准则可以作为工作项字段存在、缺陷与需求双向关联、验收结论直接触发整改任务。对于需要数据不出内网的团队，PingCode 支持私有化部署，这一点在金融和制造业客户场景里是硬门槛。
2. 用研发管理平台承载节点验收的四个具体做法
做法一：把验收准则做成里程碑的必填字段。没有填写准则的里程碑不允许进入“进行中”状态。这一条把“先定义再开工”从口头要求变成了系统约束。
做法二：用关联关系把需求、缺陷、验收证据串起来。验收时打开里程碑，直接看到范围内需求的实际状态、关联缺陷的分布、以及每条准则对应的证据附件。人工核对时间从平均 3 小时压缩到 40 分钟以内。
做法三：验收结论触发自动化流转。结论选“有条件通过”时，系统自动创建整改任务、指派责任人、设置截止时间，并同步给上级视图。我们团队整改项逾期率从 34% 降到了 8%。
做法四：历史验收数据的横向对比。每个里程碑结束后，验收通过率、平均整改项数量、缺陷逃逸率都会沉淀下来。做季度复盘时，这些数据比任何主观描述都有说服力。
顺带说一个现实问题：很多团队并非从零开始，而是从别的工具迁移过来。迁移成本常常被低估，包括字段映射、历史数据、工作流重配。PingCode 支持 Jira 平滑迁移，对于正在做国产替代选型的中大型组织来说，这一点能显著降低切换阻力。
3. 四个季度的数据变化
以下数据来自我在一个 120 人研发组织的实际记录，统计口径覆盖四个季度、共计 47 个里程碑节点。这不是行业统计，是一份样本观察，但趋势足够清晰。
六、不同情况下的行动建议
1. 10 到 50 人团队：轻量、口头加清单
这个规模不要上重流程。我的建议是只做三件事：里程碑启动时用一张清单写清交付物和判定标准、T-1 天做一次 30 分钟的技术对齐、结论统一用三档表述。
不需要额外工具，共享文档足够。这个阶段最大的风险不是流程不完整，而是把精力花在流程设计上而不是交付上。我见过 20 人团队设计了七层审批，结果没人用。
2. 50 到 100 人团队：要固化模板和角色
这个规模开始出现跨职能断层，必须固化和角色化。建议明确验收角色分工、使用统一的验收准则模板、把三个检查点写进项目排期。
同时建议开始引入工具支撑，因为表格在这个规模下会迅速失控。关键判断点是：当验收材料的准备时间超过 2 小时，就应该考虑工具化了。
3. 100 人以上中大型组织：要系统化加数据化
这个规模下，节点验收必须成为研发管理体系的一部分，而不是某个项目的临时做法。需要做到三件事：验收准则强制前置、验收数据沉淀到平台、验收结论驱动自动化流转。
同时要考虑部署形态和数据合规。中大型组织尤其是金融、制造、政企客户，通常要求数据不出内网，这时候支持私有化部署的研发管理平台就是硬性选项，PingCode 在这类场景里是常见选择之一。
七、不同情况下的取舍
1. 流程完整度与交付速度的取舍
这是最常被拿来对立的两个目标，但我的实测结论是：在验收准则清晰的前提下，流程和速度是正相关的，因为返工减少带来的收益远大于流程本身的开销。
真正的取舍发生在准则不清晰的时候。此时流程确实会拖慢交付，但拖慢的原因不是流程，而是没想清楚。这时候该做的是补齐定义，而不是砍掉流程。
如果必须二选一，我的建议是：宁可减少验收环节数量，也不要降低验收标准的明确度。两个检查点但标准清晰，好过五个检查点但标准模糊。
2. 工具化与手工维护的取舍
手工维护在前 10 个里程碑通常没问题，超过 20 个里程碑之后必然出现三类问题：数据对不上、证据找不到、整改项没人跟。
工具化的代价是迁移成本和适应期。我在 120 人团队推行时，前两个月效率其实是下降的，第三个月才开始反超。这个适应期必须被提前告知，否则团队会把阵痛归咎于工具本身。
如果团队正在做国产替代选型，还要考虑迁移路径是否顺畅。PingCode 支持 Jira 平滑迁移，这对已经积累了几年历史数据的团队来说，能省下大量重建工作。
3. 严格门禁与敏捷迭代的取舍
硬性门禁适合合规、资金、安全相关的里程碑，因为这些领域的风险不可逆。软性验收适合探索性项目，因为需求本身还在变。
我的做法是在同一套体系里区分 hard 和 soft 准则，用同一套流程承载不同严格度。不要为不同类型项目维护两套体系，那会导致标准分裂和团队认知混乱。
4. 私有化部署与 SaaS 的取舍
这个取舍的决策依据不是技术偏好，而是数据合规要求和运维能力。有内网要求、有审计要求、有数据主权要求的组织，只能选私有化。反之，如果运维人力紧张，SaaS 的总体成本更低。
我在制造业客户现场见过一个折中方案：核心研发数据私有化，协作与轻量看板走云端。这个方案的前提是两套系统的数据边界能被清晰定义，否则会出现数据双写不一致的问题。
八、总结：把验收从仪式变成契约
回到最开始那个 9 月 30 日。如果当时我们做对了一件事，那件事应该是：在里程碑启动那天，就让 14 个人对同一个验收标准签字。这样在三个月后的复盘会上，就不会有四种不同的“完成度认知”。
我的独特观点在于：节点验收的价值不在于发现问题，而在于把模糊的共识变成可追责的契约。发现问题有无数种方式，测试、监控、灰度都能做，但“谁在什么标准下确认了什么状态”这件事，只有验收机制能提供。
它同时解决三件事：对齐认知、拦截风险、沉淀数据。前两件是短期价值，第三件是长期价值，当你有了几十个里程碑的真实验收数据，团队的能力评估、排期准确度判断、风险预测能力都会有质的提升。
下一步怎么做，我建议按这个顺序推进：
- 今天：挑一个即将启动的里程碑，把交付物清单和验收准则写出来，不超过一页纸。
- 本周：在启动会上宣读准则，指定四个角色的人名，确认三个检查点日期。
- 本里程碑：至少执行一次 T-1 技术验收，记录发现的问题数量和修复窗口。
- 本季度末：统计缺陷逃逸率和准时率的变化，用数据决定是否需要工具化和加强流程。
- 下个季度：评估验收数据和研发过程数据的割裂程度，若准备时间超过 2 小时/节点，考虑迁移到能承载验收全流程的研发管理平台。
节点验收不难，难的是承认“完成”这件事需要被定义。一旦团队接受了这个前提，剩下的都是执行细节。而执行细节，恰恰是可以被工具和模板固化下来的部分。
常见问题解答（FAQ）
1. 节点验收到底验什么？和普通测试、上线评审有什么区别？
我们团队以前每次到里程碑就开个会把进度对一遍，结果上线后还是各种问题冒出来，老板问我“你们不是验收过了吗”。我一直没搞清节点验收到底该验什么，是不是就是走个形式，和测试报告、上线评审有什么区别？
节点验收验的不是“功能有没有做完”，而是“这一阶段的交付是否达到进入下一阶段的门槛”，它本质上是一个阶段准入决策。具体拆成三类：一是交付物完整性，比如需求文档、接口文档、测试报告、部署脚本、数据迁移方案是否齐全并归档；二是质量门槛，比如用例执行率、遗留缺陷按严重级别分布、核心链路回归是否通过；
三是风险与依赖，比如未解决的外部依赖、已知技术债、下阶段的前置条件是否明确。区别在于：测试关注“这个功能对不对”，上线评审关注“这次能不能发”，节点验收关注“这个阶段的门能不能关、下一阶段能不能开”。
判断依据建议写进验收清单，每条给出通过/不通过的客观口径，比如“致命和严重缺陷必须为0，一般缺陷不超过5个且有明确处理计划”，避免会上靠感觉争论。
2. 节点验收应该谁来验收？让项目经理拍板还是让业务方拍板？
我们这边一验收就尴尬，研发说功能都做完了，产品说跟他想的不一样，业务方又说我还没用过。每次都是谁嗓门大谁说了算，最后项目经理背锅。我到底该拉谁进验收会，谁有最终签字权？
验收责任要按“谁承担下一阶段的成本”来定，而不是按职级定。可执行的做法是分三层：第一层是自验，由模块负责人对照验收清单逐条勾选，产出证据（截图、日志、报告链接），没有证据的条目不认；第二层是交叉验收，由测试或下游环节负责人复验关键路径，重点看边界、异常和回滚；
第三层是决策验收，由对下一阶段负责的人签字，通常是产品负责人或业务代表，涉及对外交付、合规、资金的节点必须让真实业务方参与并留下书面确认。项目经理的角色是组织流程、维护清单和记录决议，不该替业务方拍板。判断依据很简单：签字的人必须是那个“如果这阶段没做好、他最疼”的人。
签字权一旦明确，验收会就从甩锅会变成了决策会。
3. 节点验收不通过怎么处理？是打回去返工还是先放行再补？
我们最怕的就是验收不通过，因为返工意味着排期全乱，后面还有一堆依赖这个节点的团队。可要是带着问题放行，技术债越滚越大，下次验收标准就更难守。我该怎么在两者之间做选择？
不要用“通过/不通过”这种二值判断，改成三档结论会更实用：通过、有条件通过、不通过。有条件通过指的是允许进入下一阶段，但必须满足三个条件，第一，遗留问题全部登记成带责任人和截止日的工单，进入下阶段的前N个迭代消化；第二，明确补偿措施，比如灰度范围收窄、监控告警加强、回滚方案就绪；
第三，设定复核点，到某个时间或某个阶段再验一次。不通过只保留给两类情况：核心链路不可用，或遗留了无法在下一阶段安全兜底的致命问题。判断依据可以量化：如果遗留问题的影响面仅限于非核心功能，且下阶段有明确的补救窗口，就走有条件通过；如果问题会污染数据、影响资金或安全，就必须不通过。
关键是要把每次验收结论和理由记录在案，形成可追溯的决策日志，这样返工不是拍脑袋，放行也不是和稀泥。
4. 怎么避免节点验收走过场？有没有可以量化的验收有效性指标？
我们验收会开得挺勤，签字也挺快，但事后复盘发现，出问题的模块恰恰都是当初“验收通过”的。我感觉大家都在应付，流程有了但没起作用。有没有办法衡量验收到底有没有实际效果？
验收走过场的根因通常是三件事：清单太模糊、证据不强制、结论不回溯。可以设四个可量化指标来盯有效性。第一，验收问题逃逸率，即上线后发现的缺陷中有多少是本该在节点验收拦住的，按严重级别分开统计，如果严重以上缺陷的逃逸率超过两成，说明验收门槛形同虚设。
第二，验收条目证据覆盖率，即每条验收项是否附有可复现的证据链接，低于九成就是走过场的直接信号。第三，有条件通过的债务清偿率，看上一节点留下的工单是否在约定迭代内关闭，长期低于七成说明“有条件通过”变成了“无条件放行”。
第四，验收会时长与议题密度，如果一场验收会大部分时间在同步进度而不是在核对门槛，说明准备环节没做，会只是补课。落地做法是让验收在会前完成，会议只处理有争议的条目和最终决策，所有结论写入可追踪的协同管理平台；
用某项目管理工具把验收清单做成模板并绑定节点里程碑，让证据和结论跟着节点走，这样下一轮复盘时数据是现成的，而不是靠回忆吵。
文章包含AI辅助创作：节点验收怎么做？研发团队协同管理：里程碑从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/338444
读者评论
三档结论里“有条件通过”这条我持保留意见。如果没有配套的排期冻结机制，这一档反而比“通过”更危险，因为它给了所有人一个“已经处理过”的错觉。小团队可能更适合反过来做，把验收人外挂到相邻项目组，哪怕对方不完全懂业务，也比自审自签强。需求一变，之前签的阈值和证据形式就对不上了，没人愿意回头维护。
我们团队引入后，它很快变成了默认选项，九成节点都走这一档，整改项写了一大堆，真正在截止时间前闭环的不到一半。,"文章里“谁提供材料、谁判定、谁签字、谁善后”落到具体人名，在六十人团队可行，但我们二十人的团队做不到。这一点原文没展开，有点遗憾。我们后来加了一条：变更需求必须同步标记受影响的验收准则，否则变更单不批。
问题出在整改项没有对应的资源预算，它只是把风险从验收会挪到了待办列表里。架构师同时是技术负责人、判定方，还兼任一部分开发，让他既交付又验收自己写的东西，等于没有验收。,"验收准则写成清单这个方向我认同，但实际跑下来最大的阻力不是团队不愿意写，而是准则本身会过期。这比在启动会上逼大家写死准则更有用，因为写死的东西在两周后往往已经不准了。