阶段验收最佳实践：项目负责人项目阶段流程优化，常见问题

我在过去八年里做过项目负责人，也给二十多家中大型企业做过交付流程诊断。真正让我记住的从来不是那些顺利上线的项目，而是一次很典型的翻车：一个 87 人的研发团队，在 UAT 阶段被业务方一次性提出 143 个问题，其中 31 个直接推翻了已经开发完成的核心流程。复盘时我们发现，问题不是出在开发能力上，而是出在三个月前的需求阶段验收，那次”验收”只开了 40 分钟会，参会 11 个人，产出是一份没有明确准出标准的会议纪要。

三个月后，这份纪要在任何一次争议里都起不到作用。

阶段验收是项目负责人手里最容易被低估、也最容易被形式化的一个杠杆。它不产生代码、不产生需求、不直接推进进度，所以大多数团队把它做成了一次走过场的签字仪式；但恰恰是这一环，决定了风险是在阶段内以几千元的成本被拦住，还是在生产环境以几十万元的成本被暴露。这篇文章会把我实际踩过的坑、观察到的一组组数据、以及可以直接抄走的判断逻辑和配置模板写清楚，重点回答三个问题：阶段验收到底在验什么、项目负责人应该如何重排这套流程、以及不同规模的组织应该在哪里做取舍。

一、核心结论：阶段验收是风险释放机制，不是签字仪式

先给结论，后面所有内容都是围绕这几条展开的。如果你只想拿走一句话，那就拿走第一条。

1. 阶段验收的本质是”可验证的交付物 + 明确的准出标准”

验收的对象不是人、不是态度、不是进度百分比，而是一组可被第三方独立复现的交付物。一份接口契约、一个带版本号和回滚脚本的构建包、一份覆盖率报告、一组压测数据，这些是交付物；”功能基本完成””性能还可以”不是交付物，是形容词。阶段验收失败的项目里，超过七成的根因是准出标准写成了形容词。

项目负责人要做的第一件事，是把每个阶段的准出标准从”描述性语言”翻译成”判定性语言”。判定性语言的特征是：换一个没参与项目的人来读，也能得出同样的通过或拒绝结论。

2. 验收标准必须在阶段开始前定义，而不是阶段结束时补

这是我自己踩过最贵的一个坑。早期我习惯在阶段末期组织验收会，会上大家一起看成果、一起判断行不行。表面上很高效，实际上有一个致命缺陷：标准是事后协商出来的。开发说”能跑就行”，测试说”关键路径没覆盖”，业务说”跟我原来想的不一样”，三方的标准在会议室里现场博弈，最后往往以”先通过，问题记录下来”收场，而记录下来的遗留项在下一个阶段基本无人跟进。

正确的顺序是：阶段启动会上确认准出标准，阶段中期做一次预检，阶段末期只做”是否符合预定义标准”的核对。标准前置之后，验收会的时间通常能压缩一半以上，因为它不再是一个谈判会，而是一个核对会。

3. 阶段验收要分成”交付验收”和”决策验收”两种，不要混着开

交付验收回答的是”东西做对了吗”，参与人是技术负责人、测试负责人、需求负责人；决策验收回答的是”要不要继续投入下阶段预算和人力”，参与人是项目负责人、业务方、财务或产品决策人。这两件事的判断依据、参会人、结论形式完全不同。

把它们塞进同一场会，结果是：技术细节把业务方讲困了，业务方的战略顾虑又把技术团队带偏了，最后两边都没得到想要的结论。我现在的做法是先开交付验收，拿到技术侧结论后，再开一场 30 分钟的决策验收，决策验收只看风险清单、遗留项、剩余预算和下阶段承诺。

4. 项目负责人的角色从”催进度的”变成”守门人 + 风险翻译官”

“守门人”意味着你有权说不通过，并且这个权力被流程保护；”风险翻译官”意味着你要把技术团队说的”技术债还没还完”翻译成业务方能听懂的”下阶段变更需求时，改动成本会比正常情况高 3 倍”。前者靠制度，后者靠表达。我见过绝大多数项目负责人只做了前半段，甚至前半段也没做。

5. 用数据阈值替代主观评价，是提升验收效率最便宜的手段

当准出标准里出现具体数字，缺陷密度、冒烟通过率、覆盖率、接口响应 P95、遗留项关闭率，验收讨论就从”我觉得”变成”数据是几”。这一点在后面第五部分的案例里，我会给出一组前后对比的观察数据。

二、背景与真实场景：阶段验收为什么会退化成走过场

要解决问题，先得承认它的成因。我访谈过的项目负责人里，说”我们知道阶段验收很重要”的接近 100%，但说”我们每个阶段的验收都真实起作用”的不到 20%。中间的落差不是认知问题，是结构和激励问题。

1. 一个真实项目的四道阶段门，只有一道真的在拦人

拿我 2023 年跟进的一个企业级系统替换项目来说，项目分四个阶段：需求与方案、开发与联调、测试与 UAT、上线与试运行。项目负责人在每个阶段末都安排了”阶段评审会”，听起来很规范，实际执行下来是这样的：

• 需求与方案阶段：参会 13 人，会前 2 小时发出材料，会上主要讨论界面配色，准出结论是”整体方向认可，细节后续对齐”。这道门等于没关。
• 开发与联调阶段：准出标准是”接口全部打通”。实际是 47 个接口中 41 个可用，6 个返回兜底数据。会上判定”基本打通”，进入测试。
• 测试与 UAT 阶段：这是唯一一道真的门。业务方在 UAT 里发现了那 6 个兜底接口和 31 个需求理解偏差，项目被迫回退到开发阶段，延期 6 周。
• 上线与试运行阶段：试运行 2 周，没有设定任何量化指标，靠”业务方没投诉”判断通过。

这个项目的教训很清晰：四道门里三道是名义上的，唯一的真门出现在业务方直接接触系统的时刻。而这时候返工成本已经是最高的了。

2. 阶段验收退化的三个结构性原因

第一个原因是验收人不对等。开发阶段的验收如果完全由开发团队自评，那本质上是在问”你觉得你做得怎么样”，答案几乎总是”还行”。有效的门禁必须包含一个与交付方目标不完全一致的角色，测试、架构、或者独立的质控。

第二个原因是没有拒绝的后果，也没有通过的代价。如果门禁不通过，项目只是”再等等”，而项目负责人的考核指标是按时交付，那么理性选择一定是放行。要破这个局，必须让门禁的结论与后续资源、付款节点或人力投入挂钩，让它成为一个有真实权重的事件。

第三个原因是验收材料在会前没有经过结构化整理。我统计过，验收会上一半以上的时间消耗在”这个功能到底算不算完成”的事实澄清上，而不是判断上。材料如果按准出标准逐条对应准备，每条标准、对应证据、通过与否、证据链接，会议就只剩判断，五分钟能过完一个阶段。

三、拆解常见误区：八个把阶段验收做废掉的做法

下面这八条，是我在流程诊断中反复见到的。每一条我都在真实项目里见过它的后果，所以尽量写得具体一点，方便你对照自己的项目。

1. 把阶段验收当成结项验收的缩小版

结项验收关注的是”整体交付是否满足合同”，阶段验收关注的是”这一阶段的产出是否足以支撑下一阶段的投入”。目标不同，标准就完全不同。用结项验收的清单去套阶段验收，会出现两种极端：要么标准过粗（因为结项标准是结果导向的），要么流程过重（把所有交付文档都要求齐全）。

判断方法很简单：问一句“如果这道门不通过，我们接下来会改什么？”如果答不出来，说明这道门的标准跟阶段目标脱节了。

2. 准出标准写成形容词

“功能完整””性能良好””文档齐全””用户满意”，这四个词我在验收单上见过不下两百次。它们的共同问题是无法判定，也无法追责。一个可执行的准出标准长这样：核心链路冒烟用例通过率 ≥ 95%，P0/P1 缺陷清零，P2 缺陷 ≤ 5 且每项有责任人和修复日期，接口 P95 响应时间 ≤ 800ms。

改写的成本很低，收益极高。我通常建议项目负责人花两个小时，把现有验收单上所有形容词逐条替换成数字或可枚举的事实，这两个小时往往能省下后面几十个小时的扯皮。

3. 验收人越多越好

13 个人参会的验收会，实际贡献判断的通常不超过 4 个。其余人的作用是背书和分摊责任。人越多，越容易形成”大家都觉得还行”的从众氛围，也越难得出”不通过”的结论，因为不通过意味着有人要立即投入返工。

我的建议是验收人控制在 3，5 人，且必须包含一个能说”不”的独立角色。其他人的信息通过书面材料同步即可，不必占用他们的会议时间。

4. 验收通过就万事大吉，遗留项无人跟踪

遗留项是阶段验收里最危险的部分。它给了所有人一个心理台阶：”问题不大，记下来下阶段处理。”但下阶段有下阶段的任务，遗留项如果没有责任人和截止日，100% 会被稀释。

我在项目里强制加了两条规则：任何遗留项必须有单一负责人和明确日期；遗留项数量超过阈值时，该阶段不得通过。第二条尤其重要，它把”记下来”这个动作从逃生通道变成了技术债的显性化。

5. 用会议纪要替代验收单

会议纪要是叙述性的，验收单是判定性的。三年后如果有人问”这个阶段当时到底算不算通过”，会议纪要里通常找不到答案。而一份结构化验收单可以明确回答：哪条标准、谁确认的、什么证据、什么结论、什么时间。

这不是流程洁癖。在涉及多方、跨年度、甚至涉及付款节点的项目里，验收单是最低成本的举证材料。

6. 阶段验收与付款节点完全脱钩或过度绑定

完全脱钩，门禁就没有牙齿；过度绑定，团队会把所有精力放在”怎么让验收通过”而不是”怎么把东西做好”，甚至演变成验收材料美化。更健康的做法是让门禁结论影响后续资源分配和风险等级，而不是直接影响现金流。

比如：门禁未通过但风险可控时，允许带条件进入下一阶段，但下阶段新增人力需要额外审批；门禁连续两次未通过，项目进入升级管理流程。这种间接挂钩比直接扣款更可持续。

7. 所有阶段用同一套验收重量

一个三周的迭代和一个涉及核心账务迁移的阶段，用同样重量的验收流程，是资源错配。我的做法是按风险暴露度 × 不可逆性给阶段分级：高风险不可逆阶段（数据迁移、核心链路切换、合规改造）走重门禁；低风险可回滚阶段（界面优化、非核心模块迭代）走轻门禁，甚至只做自动化检查。

8. 缺陷密度一刀切

把”缺陷密度 ≤ 0.5 个/千行”当作全项目统一标准，会带来一个副作用：团队为了达标，把缺陷挪到下一阶段报。我见过最夸张的案例是开发团队把明显的问题写成”设计待确认”，绕过缺陷统计口径。

更合理的做法是分模块设定基线。核心交易链路严，辅助功能宽；同时监控缺陷发现阶段的分布变化，如果缺陷从开发阶段大量后移到 UAT 阶段，说明门禁在放水，而不是质量变好了。

四、专业判断逻辑：一套可以照着用的门禁设计方法

前面讲的是问题和误区，这一节讲可操作的方法。我把它总结成一个四要素模型加一个三级门禁结构，最后给一个”卡不卡”的判断公式。

1. 四要素模型：入口准则、交付物、验证方法、出口准则

任何一个阶段门禁，如果这四项缺一项，这道门就不可靠。我用一个具体的 YAML 配置来说明，这个结构可以直接搬到你自己的流程文档或项目管理平台的阶段门禁配置里。

stage: S3-开发转测试
entry_criteria:

需求基线已冻结，变更单闭环率 = 100%

单元测试行覆盖率 >= 70%

代码静态扫描高危问题 = 0

deliverables:

可部署构建包（含版本号、依赖清单、回滚脚本）

接口契约文档 v1.2（含错误码与限流策略）

自测报告（覆盖核心链路 100%）

verification:

方式: 自动化冒烟 + 人工抽检

冒烟样本: 核心链路 100%，非核心链路 20%

抽检负责人: 测试负责人（独立于开发团队）

exit_criteria:

P0/P1 缺陷 = 0

P2 缺陷 冒烟用例通过率 >= 95%

接口 P95 响应时间
owner: 技术负责人

signoff: [技术负责人, 测试负责人, 项目负责人]

fail_action: 触发 48 小时整改窗口，二次不通过自动升级至项目指导委员会

注意最后一行 fail_action。这是最多团队缺失的一项，也是让门禁真正有牙齿的关键。没有明确的失败动作，门禁不通过就只是一个状态，不是一个事件。

2. 三级门禁结构：自检、技术验收、业务验收

我把每个阶段的验收拆成三层，逐层收敛，避免最后一层承担全部压力。

1. 第一级 自检：由交付方自己完成，产出是自检清单。这一级不是形式主义，它承担了 60% 以上的低级问题过滤。核心要求是自检清单必须与准出标准逐条对应，不能另起一套。
2. 第二级 技术验收：由独立于交付方的技术角色主持，重点验证可复现性。做法是”照着文档走一遍”，如果文档里写的部署步骤在某台干净环境上跑不通，那就不算通过。
3. 第三级 业务验收：由业务方主持，重点验证业务场景闭环。这一级不重新讨论技术方案，只回答”这个阶段承诺的业务能力，能不能真实跑通”。

三级的顺序不能颠倒、不能合并。我见过最常见的错误是把二级和三级合并成一场会，结果是业务方被迫在不懂的领域做技术判断，而技术团队被动接受业务方基于错误理解的否决。

3. “卡不卡”的判断公式：风险暴露度 × 返工成本 × 时间窗

项目负责人最常被问的问题是”这点小问题要不要卡住”。我给团队定了一个简化的判断公式：

卡住的必要性 = 风险暴露度（0-3分） × 返工成本倍数（1-5分） ÷ 可用时间窗余量（天）

风险暴露度看的是这个问题会不会流到生产环境；返工成本倍数看的是它拖到下一阶段处理，成本会放大几倍（跨阶段返工的经验倍数通常在 3，8 倍之间）；时间窗余量是你的阶段缓冲还能不能吃掉修复时间。三项一算，卡还是不卡就有了依据，而不是靠嗓门大小。

这里有一组我实际观察到的成本放大曲线，用来支撑”为什么必须前移”这个判断。

4. 用两个指标衡量门禁本身的质量

门禁设计得好不好，不看它拦了多少，而看两个指标：缺陷逃逸率（本阶段应该发现却流到下一阶段的缺陷占比）和门禁一次通过率。前者的理想区间是 5%，12%，过低说明门禁过严导致大量形式化包装，过高说明门禁在放水；后者的健康区间是 70%，85%，长期低于 60% 说明准出标准定得不现实，长期高于 95% 说明标准太松。

这两个指标一起看，比单独看任何一个都有效。我在诊断时经常遇到”一次通过率 97% 但逃逸率 26%”的团队，这是典型的”标准宽松 + 事后补救”组合。

五、案例与数据观察：把门禁配置落到项目管理平台上

方法论讲完，讲落地。我 2024 年深度参与的一个项目，是某制造企业研发中心约 300 人的组织从原有工具链迁移到 PingCode 的过程，同时重做了阶段验收门禁。这个过程有两个可复用的经验：迁移本身怎么做，以及门禁怎么在平台里变成不可绕过的规则。

1. 迁移前的真实痛点：门禁靠人记，标准靠文档传

迁移前，这个团队的阶段验收完全靠”人治”：准出标准放在一份共享文档里，每次验收前项目负责人手工整理证据，验收结论记录在会议纪要里。三个问题反复出现：

• 标准分散：需求门禁在一份表里，开发门禁在另一个群里，测试门禁靠测试用例平台导出，项目负责人每次要花 6，8 小时手工汇总。
• 无法追溯：验收当时通过了，三个月后追溯”当时哪条标准是什么状态”，只能翻聊天记录。
• 遗留项失控：验收会上记下的遗留项，落到下一个迭代就找不到了，关闭率长期在 40% 以下。

2. 迁移与配置过程：三周的实际安排

迁移这件事，最怕的是”把旧数据搬过去就完事”。我的建议是把它当成一次流程重构的机会，具体分三周推进。

1. 第 1 周：数据映射与试点迁移。梳理原有工作项类型、状态机、字段，映射到新平台的需求、任务、缺陷、测试用例结构。选 2 个中等规模项目做试点迁移，重点验证历史工作项的状态与关联关系是否完整。
2. 第 2 周：阶段门禁规则配置。把四个阶段的入口准则、交付物、出口准则配置成平台内的检查项与状态流转规则，比如”缺陷状态为 P0/P1 未关闭时，阶段状态不允许流转到已完成”。
3. 第 3 周：并行运行与切换。新旧并行一周，用同一批数据跑一遍阶段验收，对比两边结论是否一致，确认无问题后统一切换。

这里要单独说一句迁移的可控性。对于已经在既有工具链上积累了大量历史数据的团队，PingCode 支持从 Jira 平滑迁移，工作项类型、字段、状态机、附件、关联关系可以批量映射过来，不需要人工重录，这一点直接决定了第 1 周能不能压缩在两个工作日以内。对于数据敏感、有内网合规要求的中大型组织，PingCode 支持私有化部署，验收数据不出内网，这一点在涉及生产系统交付的项目里几乎是硬性要求。

3. 关键动作：把准出标准从文档搬到流程规则里

这是整个项目里我认为最有价值的一步。原来的准出标准写在文档里，靠人记得去检查；迁移后，标准变成了平台内的规则，不满足就无法流转状态。具体配置了四类规则：

• 必填证据项：阶段流转前必须填写对应的验收证据链接（测试报告、压测结果、部署记录），缺项不允许提交。
• 缺陷阈值拦截：存在未关闭的 P0/P1 缺陷时，阶段状态无法流转到下一阶段。
• 遗留项强制归属：验收中记录的每个遗留项必须指定负责人与截止日期，否则不能保存。
• 超期自动升级：遗留项超过截止日期未关闭，自动升级通知到项目负责人和上级，不再依赖人工催办。

4. 六个月的观察数据

下面是这个团队在门禁优化后 6 个月的观察数据。需要说明的是，这是单一组织的内部数据，受团队规模、业务复杂度和人员变动影响，属于样本观察而非行业普适结论，但趋势本身很有参考价值。

有一点特别值得注意：阶段一次通过率从 94% 下降到 79%，这不是退步，而是进步。它说明门禁从”基本都能过”变成了”确实有一批不达标”。如果优化后一次通过率依然是 95% 以上、而逃逸率却没降下来，那才是真正的问题。

六、不同情况下的行动建议

没有一套门禁适合所有组织。下面按规模、交付模式、行业约束三种划分给建议，你可以对号入座，也可以组合使用。

1. 按组织规模

100 人以下团队：不要上来就搞四阶段门禁。先做两件事，需求阶段准出标准量化、上线前量化门槛。两到三条规则足够。重点是通过一次成功体验让团队接受”门禁有用”，而不是一次性铺开全套流程。

100，500 人组织：这是门禁价值最容易被放大的区间，也是流程最容易失控的区间。建议明确三级门禁结构，把准出标准配置成平台内的规则而不是文档，同时指定每个阶段的独立验收角色。这个规模的组织通常有多个并行项目，门禁规则需要统一，否则跨项目对比和资源调度会变得困难。

500 人以上组织：在统一门禁之上，需要额外做两件事。一是按风险等级对项目分级，高风险项目走重门禁，普通项目走轻门禁，避免一刀切拖慢所有项目；二是建立门禁指标看板，把缺陷逃逸率、一次通过率、遗留项关闭率按项目群聚合，让它成为管理层的常规观察指标。

2. 按交付模式

瀑布或强阶段划分的交付：天然适配本文的四要素模型，重点是让每一道门的失败动作明确化。

敏捷迭代：不要把”每个迭代”当成阶段门禁，那会变成负担。建议在迭代内只保留轻量定义完成（DoD）检查，把重门禁放在发布节点、里程碑节点和对外交付节点上。

混合模式：最常见也最麻烦。我的做法是按交付物而不是按时间划门禁，只要涉及数据迁移、对外接口发布、生产环境切换，无论是迭代内还是迭代间，都触发重门禁。

3. 按行业与合规约束

金融、医疗、能源等强监管行业：门禁不仅是效率工具，更是举证工具。验收单必须可追溯、不可篡改、保留完整审批链。这类项目通常需要私有化部署，验收数据留在内网，同时要求审批记录的完整留存。

互联网或创新型业务：门禁的重点应放在”可回滚性”上。如果灰度、回滚、开关机制做得足够好，很多风险可以通过试运行稀释，门禁标准可以适度放宽，换取交付速度。

七、不同情况下的取舍

流程优化的本质是取舍。下面五组取舍是我在实际项目里反复面对的，每组都给一个我自己的倾向和理由。

1. 门禁严格度 vs 交付速度

这是最核心的一组矛盾。我的判断是：不要全局调节严格度，而要按风险分级调节。把所有阶段的严格度一起提高或降低，是效率最低的做法。正确做法是保留 80% 的轻门禁阶段和 20% 的重门禁阶段，把资源集中在不可逆、高风险的节点上。

实际数据也支持这个判断。在前面那个 300 人项目里，四个阶段中只有测试与 UAT、上线与试运行两个阶段用了重量门禁，但这两道门贡献了全部拦截量的 82%。

2. 验收人数量 vs 决策效率

我倾向于验收人少而权责明确。3，5 人的验收小组，每人明确负责一组准出标准，比 13 人的大组有效得多。大组的隐性成本很高：时间协调、责任分散、从众压力。唯一的例外是涉及多方合同主体的项目，这时必须让各方代表在场，但可以拆成”技术核对”和”商务确认”两场。

3. 工具自动化 vs 人工判断

凡是”能不能”的问题，交给工具；凡是”该不该”的问题，交给人。缺陷阈值、覆盖率、必填证据项这些可以自动判定，交给平台规则；而”这个遗留项是否可接受””这个业务风险是否值得承担”必须由人决策。

我见过一些团队把门禁做得过于自动化，结果是所有能自动化的指标都达标，但项目整体质量依然出问题。原因是自动化无法判断”标准本身是否还适用”。所以规则要定期复盘，我一般建议每季度复核一次门禁规则的有效性。

4. 私有化部署 vs SaaS

这取决于数据边界，而不是成本。如果验收过程中产生的材料包含生产数据、客户信息、核心架构细节，那私有化部署基本是必选项。PingCode 支持私有化部署，这一点在面向中大型企业和 100 人以上组织的交付项目中，往往是筛选项而不是加分项。如果项目完全是内部工具、数据敏感度低，SaaS 的运维成本优势会更明显。

5. 文档厚度 vs 可验证性

我明确倾向于薄文档、强证据。一份 40 页的验收报告，不如一份 3 页的验收单加上 20 个可点击的证据链接。前者需要写、需要读、需要理解；后者只需要点开看。可验证性是可以被验证的，文档厚度不能。

判断标准很简单：如果验收的证据需要有人在会上花时间解释才能看懂，那说明证据本身不合格。

八、可以直接使用的落地清单

最后给一份可以照着执行的清单。我把它分成三个阶段，每个阶段只列最关键的动作，避免做成一份看起来很长但没人用的文档。

1. 启动阶段：定义清楚，别急着开会

1. 列出本阶段的所有准出标准，逐条检查是否可以”由第三方独立复现判定”，不合格的用数字或可枚举事实改写。
2. 为每条标准指定唯一的证据形式（报告、链接、截图、日志），并确认证据可以被无解释地读懂。
3. 确定验收小组成员（3，5 人），明确谁对哪组标准负责，并确保至少有一位独立于交付方的角色。
4. 定义门禁失败后的具体动作（整改窗口时长、二次不通过的处理路径）。

2. 执行阶段：中期预检比末期验收更重要

1. 阶段中期做一次预检，只检查”预计无法达标”的项，提前暴露风险。
2. 变更单必须闭环，未闭环的变更要显式列出并评估对标标准的影响。
3. 不要在预检阶段做结论，避免团队提前放松。

3. 验收阶段：把会议变成核对

1. 会前 24 小时发出结构化验收单：每条标准、当前状态、证据链接、负责人。
2. 会上逐条核对，只讨论”证据是否成立”，不讨论”标准是否合适”（标准争议应另开专题）。
3. 遗留项当场指定单一责任人、截止日期和验收方式。
4. 验收单归档，并在平台内配置好超期自动提醒。

4. 关于工具选择的一句实话

工具不能替代流程设计。我见过把门禁配置得很漂亮、但团队依然在验收前一天批量勾选的案例。工具的价值在于让标准不可绕过、让证据可追溯、让遗留项跑不掉，而这三件事决定了门禁能不能持续。对于 100 人以上、有私有化部署需求或需要从 Jira 平滑迁移的中大型组织，PingCode 这类覆盖需求到发布全链路、支持规则化门禁配置的平台，会比”文档 + 群消息 + 手工汇总”的组合省下大量隐性成本。

九、结语：门禁的价值不在于拦住多少，而在于让风险提前可见

回到最开始那个 87 人的团队。他们后来做的最重要的一件事，不是加了更多验收环节，而是把需求阶段那道几乎不设防的门重新做了一遍，准出标准从 4 条形容词变成了 11 条可判定项，验收人从 13 人减到 5 人，会议时间从 90 分钟压到 40 分钟，但这次会议真的拦下了 7 个会导致后期大返工的需求歧义。

我越来越确信一件事：阶段验收不是项目管理里最显眼的环节，但它是投入产出比最高的环节之一。它不产生新东西，但它决定了已经产生的东西会不会被浪费。一个项目负责人能留给团队最好的资产，不是漂亮的进度表，而是一套大家愿意认真执行的门禁。

如果你现在就要动手，我建议按这个顺序推进：本周先把当前阶段的准出标准全部改写成可判定语言，下周选一个中等风险阶段试运行三级门禁，一个月后回看缺陷逃逸率和遗留项关闭率这两个指标。不要一次改完所有阶段，也不要等到下一个项目再开始。先改一条标准，比重新设计整套流程有效得多。