阶段验收落地方案：管理层开展项目阶段的制度设计案例解析

去年第四季度，我以外部顾问身份参与了一家接近400人规模的软硬件混合研发企业的年度复盘。这家公司全年做了37次阶段验收，其中34次的结论是”通过”，通过率高达92%。但同一年，他们有4个项目的关键里程碑整体后移超过90天，最严重的一个后移了128天，而复盘时几乎没有人把责任归到阶段验收上，因为在所有人的记忆里，每次验收都”顺利通过了”。这是我近几年见过最典型的一种制度性失效：验收动作按计划执行，验收结论全部合规，但项目照样失控。

问题不在于团队不认真，也不在于评审专家水平不够，而在于这套阶段验收制度从一开始就被设计成了”确认进度”的仪式，而不是”确认可交付性”的关卡。前者的产出是一份会议纪要，后者的产出是一个可以被下一阶段直接消费的交付物。这两者在制度设计层面的差别，远比大多数人想象的要大。

这篇文章我想把这件事拆到底：阶段验收的制度设计应该从哪几个变量入手，管理层在什么节点介入才有价值，验收标准怎么写才不会变成事后补材料，以及不同规模的组织应该怎么取舍。我会用我实际参与过的一个改造案例作为主线，把设计过程、数据变化和踩过的坑都摊开讲。

一、核心结论：阶段验收失效的第一因不是评审质量，而是验收点设计

先把结论摆出来。我复盘过十几家企业的阶段验收制度，发现一个高度一致的规律：阶段验收的失效，80%发生在验收之前，只有20%发生在验收现场。换句话说，即使你把评审会开成世界一流水平，只要验收点选错了、准入门槛没定义、结论没有强制动作，验收依然会变成走过场。

1. 我的三个反常识判断

第一，验收点的密度和项目风险不成正比，甚至可能成反比。很多管理层的第一反应是”既然失控，那就多设几个验收点”。但验收点本身是有成本的：准备材料、组织评审、等待决策、会后整改，一个中等复杂度的阶段验收平均消耗约42人天（含各角色时间），其中真正用于发现问题的不到15人天。验收点过密，团队会把精力从交付转向”准备被验收”，反而挤压了真实的质量投入。

第二，阶段验收要验的不是”做完了什么”，而是”下一步能不能安全开始”。这是判断验收点是否有效的唯一标准。一个阶段的产出如果不通过验收就能进入下一阶段而不产生不可逆成本，那这个验收点就是可选的；如果跳过它会导致后期返工成本指数级上升，那它就必须是硬卡点。

第三，验收结论不应该是二元的。“通过/不通过”是一个伪选择，它逼着验收人做非黑即白的判断，结果往往是”有条件通过”，而”有条件”三个字在实践中几乎等于没条件。我在案例里会详细讲我们最终采用的五级结论设计。

2. 阶段验收真正要解决的问题

把话说得更直白一些：阶段验收制度的本质是一份可验证的交付契约。它要回答三个问题，这一阶段承诺的交付物是否完整存在？它们的质量是否达到下一阶段可以直接消费的程度？如果没有达到，谁在什么时间之前把它补齐？

凡是不能帮助回答这三个问题的验收环节，无论是汇报PPT、打分表还是领导讲话，都属于仪式性成本。管理层在设计制度时最该做的第一件事，其实是删减，而不是增加。

3. 一个可量化的判断标准

我给这套制度设计了一个衡量指标，叫验收拦截率：在本阶段验收中被判定为”必须整改才能进入下一阶段”的问题数，除以本阶段实际发现的全部问题数。经验值上，这个比率低于15%说明验收过松，高于45%说明验收点设置得太晚、把本该在日常解决的问题堆到了关口。

健康的区间大致在20%到35%之间。这个数字比”通过率”有用得多，通过率高不一定是好事，很可能只是标准太软。

二、背景与真实场景：为什么”每阶段验收”在中大型组织里必然走形

要理解制度为什么会走形，得先看清楚谁在参与、他们各自要什么。这是设计制度的起点，跳不过去。

1. 一个真实案例的开场

我参与改造的这家企业，主营工业设备的软硬件一体化研发，年营收规模在十几亿量级，研发人员约310人，分7条产品线。他们的阶段验收制度原本写得很完整：需求评审、方案评审、样机评审、小批试产评审、量产评审，五道关卡，每道都有评分表和签字栏。

但实际运行中，评审会平均时长压缩到55分钟，其中约40分钟是汇报和演示，真正用于质询的时间不足15分钟。评分表的9个维度里，有6个维度所有项目得分都在4.5分以上（5分制），完全失去了区分度。

最要命的是，验收结论只有两种：通过，或者”有条件通过，问题记录在案，下次评审确认”。而”下次评审”往往已经是两三个月之后，中间没有任何跟踪动作。这就是我在开头说的：验收动作全部合规，项目照样失控。

2. 三类参与者与他们的真实诉求

阶段验收现场通常有三类人，他们的诉求并不一致，这是制度失效的深层原因。

交付方（项目经理与研发骨干）的核心诉求是让验收尽快通过，因为验收通过意味着可以解锁下一阶段的资源和排期。在他们的收益函数里，验收是一个”通过即收益”的关卡，天然倾向于弱化问题。

验收方（技术专家、质量、架构师）的诉求是避免自己签字后被追责。如果制度设计让验收人对后续风险承担责任，他们的理性选择是要么严格但拖延，要么宽松但免责。大多数组织的制度实际上逼他们选了后者。

管理层（分管副总或PMO负责人）的诉求通常是整体节奏可控，而不是单个项目的质量最优。当他们发现某个阶段验收卡住了整体交付节奏，第一反应往往是”先放过去，后面补”，这在个案上合理，在制度上致命，因为它向组织传递了一个信号：卡点是可以被谈判的。

制度设计的核心任务，就是让这三类人的理性选择和组织的整体利益对齐，而不是靠觉悟。

3. 组织规模越过100人后发生的三个变化

（1）上下文断裂。验收人不再可能了解项目的全部细节，只能依赖交付方提供的材料做判断。材料的组织方式因此成为验收质量的上限。

（2）记忆失效。在30人团队里，”上次说的那个问题”大家还记得；在300人团队里，没有记录就等于没发生。这直接决定了阶段验收必须有系统承载，而不是靠会议纪要。

（3）博弈显性化。跨部门之间的验收开始带有资源争夺的成分，验收结论不再纯粹是技术判断，而是组织政治的产物。制度设计必须显式考虑这一点，否则再好的流程也会被博弈稀释。

三、拆解七个常见误区

下面这七个误区，是我在复盘中最频繁遇到的。我按出现频率排序，并且标注了它们的典型后果。

1. 把阶段验收开成成果展示会

典型表现是：汇报PPT精心设计，演示流程反复彩排，但整场会议没有一个人拿着交付物清单逐项核对。判断标准很简单，如果这场会议换成书面材料传阅，结论会不会改变？如果不会，说明现场质询没有产生增量信息。

我见过最极端的一次，验收会开了90分钟，其中78分钟是演示，剩下的12分钟里，有8分钟在讨论下一阶段的排期。

2. 验收标准在评审前48小时才写出来

这是最普遍也最隐蔽的问题。验收标准如果是在临近评审时才由交付方自己起草，它必然是对现状的描述，而不是对要求的规定。真正的验收标准应该在阶段启动时就冻结，并且作为该阶段的工作输入之一。

我建议的做法是：验收标准与阶段计划同源同批发布。阶段计划里写”要做什么”，验收标准里写”做到什么程度算完成”，两者是同一份文档的两面。任何一方单独变更，另一方的变更流程必须同步触发。

3. 只验”做完了什么”，不验”能不能承接下一步”

这是阶段验收失效最本质的原因。我把它叫做交付物消费性缺失，交付物本身存在，但下一阶段的角色无法直接使用它。

举几个具体例子。需求阶段的输出是一份需求文档，但测试团队拿着它写不出测试用例，因为缺少异常路径和边界条件；设计阶段的输出是一套接口定义，但后端拿着它无法直接编码，因为错误码和超时约定没写；样机阶段的输出是一台能运行的样机，但试产线拿着它无法排产，因为关键工艺参数公差没有标注。

这些都不是”没做完”，而是”做完了但不可消费”。判断方法只有一个：让下一阶段的真实使用者参与验收，并且让他们现场尝试使用交付物，而不是听交付方讲解。

4. 把验收结论做成二元选择

“通过”与”不通过”之间，真实世界存在大量中间状态。强行二元化，结果是所有中间状态都被塞进”通过”里，或者被塞进”不通过”里导致项目停滞。

我在案例中最终采用的五级结论是：通过、带条件通过、限范围通过、退回整改、终止或重定义。每一级对应明确不同的后续动作，这一点在后面会详细展开。

5. 验收人由项目经理指定

这是一个结构性问题。谁被指定为验收人，直接影响验收结论。如果由交付方指定，理性选择必然是熟悉且态度温和的人。

正确做法是建立独立的验收人池，按领域、按项目类型预置名单，由PMO或质量部门从池中抽取，并且对同一项目设置回避规则。这件事在100人以下组织可能显得过重，但越过150人后几乎不可避免。

6. 验收记录只留在会议纪要里

会议纪要是一种弱持久化的记录载体。它的问题不在于会丢失，而在于不可结构化查询。当你想知道”过去半年所有项目在样机阶段被拦截的问题类型分布”，会议纪要无法回答这个问题，而结构化的验收记录可以。

这直接决定了组织能否从阶段验收中积累经验。我在案例中会展示，改造后最有价值的副产品恰恰是这个数据库。

7. 阶段验收与考核强挂钩但没有申诉通道

验收结果一旦直接影响个人绩效，交付方就会系统性地隐藏风险。这个规律几乎在所有组织中都成立，区别只是隐藏得高明与否。

处理方式不是取消挂钩，而是区分”结果指标”与”过程指标”：验收是否通过影响项目结果，是否如实暴露问题影响过程评价，且后者应该与前者解耦。这样团队才有动机在关口前主动暴露风险。

四、专业判断逻辑：阶段验收制度的四根支柱

前面讲了问题，这一节讲解法。我把阶段验收制度拆成四根支柱，任何一根缺失，制度都会退化。这四根支柱的排序也是实施顺序，不建议跳着做。

1. 验收点选择：按不可逆成本布置，而不是按时间均匀

验收点应该放在”越过这个点，返工成本会发生数量级跃升”的位置。判断方法是对每个候选节点问一个问题：如果这个节点的问题留到下一个节点才被发现，成本会增加几倍？

经验上，倍数低于3倍的节点，可以不设正式验收，改为轻量的自检；倍数在3到10倍之间的节点，设标准验收；倍数超过10倍的节点，设硬卡点，且必须由独立验收人签字，缺一不可进入下一阶段。

用这个标准筛一遍，大多数企业的验收点会从”均匀分布”变成”前重后轻”或”中段集中”。比如软硬件一体化研发，样机评审往往是倍数最高的节点，因为它同时锁定了硬件结构、关键器件选型和软件接口协议，一旦通过，后续变更要同时付出模具、采购和代码改造成本。

2. 准入门槛：定义”可验收”的最小完备集

很多验收会开得混乱，是因为提交验收的材料本身不具备可评审性。解决方式是为每个验收点定义准入门槛，一组必须齐备才能进入评审的交付物与前置条件。门槛不满足，验收会自动被驳回，不占用评审人时间。

准入门槛要写成可核对的清单，而不是形容词。举个例子，下面是我们在案例企业为”样机评审”定义的准入门槛，用配置文件的形式固化在工具里：

gate: sample_review
preconditions:

样机连续运行时长 >= 72h，且运行日志完整可导出

关键器件清单已冻结，替代料方案已评审通过

硬件结构与软件接口协议版本号一致

上一阶段遗留的 P0/P1 问题关闭率 >= 100%

上一阶段遗留的 P2 问题关闭率 >= 80%

deliverables:

样机测试报告（含异常路径记录）

接口协议文档 v2.1 及以上

试产工艺参数表（含公差与容差）

风险清单与应对方案

reviewers:

独立验收人池抽取 2 名（回避本项目成员）

下游角色代表 1 名（试产线工程师）

auto_reject_if:

任一前置条件未满足

任一交付物缺失或版本不一致

这份清单的价值在于：把”准备好没有”这个主观判断，变成了工具可以自动核对的布尔值。团队在提交时就知道自己能不能过门槛，而不是在评审会上被当面指出。

3. 验收人机制：三类角色分离

我把验收人分成三类，各自职责清晰，不允许合并到同一个人身上。

第一类是技术验收人，负责判断交付物的技术完备性，从独立验收人池抽取，必须具备该领域的一线实践背景。他们的判断依据是交付物本身，不是汇报材料。

第二类是下游消费代表，负责判断交付物是否可以被下一阶段直接使用。这一类人最容易被忽略，但恰恰是拦截”消费性缺失”问题的关键。他们的验收方式是现场试用，不是听讲解。

第三类是决策人，通常是项目负责人或分管领导，负责在技术结论基础上做资源与节奏判断，裁定五级结论中的具体级别。决策人不参与技术判断，也不应该推翻技术验收人给出的事实结论。

4. 结论与闭环：五级结论加强制动作

五级结论的设计要点是每一级都绑定一组不可跳过的后续动作，并且这些动作直接写入系统，不需要人再去”安排”。

通过：下一阶段计划自动解锁，交付物归档到基线库。

带条件通过：下一阶段可以启动，但必须在约定天数内关闭指定问题，逾期自动升级到项目管理办公室并在下次验收中强制检查。

限范围通过：只解锁部分下游工作，明确哪些模块可以继续、哪些必须等待。这个结论在实践中使用频率被严重低估，它比”退回整改”温和，比”带条件通过”更精确。

退回整改：本阶段重新提交，下一阶段完全冻结，且需重新走准入门槛。这个结论必须设置次数上限，避免无限循环。

终止或重定义：由决策人判断，触发项目范围或目标的重新定义。

关键在于，这五级不是靠人记忆执行的，而是写进工具的状态机。结论一旦录入，后续动作自动触发，没有谈判空间。这是制度能否落地的分水岭。

五、案例解析：一家300人企业的阶段验收制度改造

这一节讲具体的改造过程。我尽量把数据、动作和踩坑都讲清楚，方便你对照自己的组织做裁剪。

1. 改造前的状态与量化基线

企业基本情况：研发人员310人，7条产品线，软硬件一体化研发，年度在研项目约45个，其中跨部门项目占六成。改造前我们做的第一件事是建立基线，用三个月时间采集了以下指标：

• 阶段验收平均准备耗时：6.2人天/次
• 单次验收平均发现问题数：2.1个
• 缺陷逃逸率（本阶段应拦截但流入下一阶段的缺陷占比）：31%
• 验收后整改项闭环率（30天内关闭）：44%
• 里程碑按期达成率：63%
• 验收结论可追溯率（可在系统中查询到完整记录的比例）：25%

基线建立之后，我们在管理层会议上做了一次对照：验收通过率92%，里程碑按期达成率63%。这两个数字放一起看，任何管理者都能立刻意识到问题所在。

2. 制度设计：六个阶段的验收卡点

我们没有推翻原有的五道评审，而是重新做了三件事：调整验收点位置、定义准入门槛、重构结论体系。

（1）验收点从五个调整为六个，但分布完全改变。把原来均匀分布的评审改为按返工成本倍数布置：需求评审和样机评审设为硬卡点，必须独立验收人签字；详细设计评审降级为轻量自检加抽查；新增”上线前评审”作为硬卡点，因为面向客户的风险倍数高达11倍。

（2）每个验收点定义准入门槛清单。六份清单共包含87个可核对项，全部配置进工具做自动校验。团队提交验收时，系统会先跑一遍门槛检查，不满足直接驳回，不进入人工评审。

（3）结论体系从二元改为五级，并绑定强制动作。这一改动最初遭到不少抵触，项目经理普遍担心”限范围通过”这个结论会让排期变得不可预测。实际运行三个月后，抵触明显下降，因为他们发现这个结论反而减少了无意义的返工。

3. 工具承载：为什么最终选择了 PingCode

制度设计完成后，我们面临一个现实问题：这套制度需要的自动校验、状态机、独立验收人池和结构化记录，靠邮件加表格根本承载不了。

选型阶段我们评估了五款工具，评估维度包括私有化部署能力、研发流程模型的贴合度、从现有工具平滑迁移的成本、验收状态机与准入门槛的可配置程度，以及验收数据的结构化查询能力。最终选择 PingCode，主要基于三点判断。

第一，私有化部署能力。这家企业的硬件研发数据涉及未公开的产品参数和客户定制信息，研发过程数据必须留在自有环境内，这一点是硬性要求。PingCode 支持私有化部署，数据不出内网，能够满足这类中大型企业的合规与保密需求。

第二，Jira 平滑迁移。他们原有的研发管理跑在 Jira 上，积累了大量历史数据，包括需求、缺陷、迭代记录和自定义工作流。迁移最大的风险不是数据搬不过去，而是工作流语义丢失导致历史数据变成死数据。PingCode 提供的 Jira 迁移方案能保留原有工作流语义和字段映射，迁移后历史缺陷的趋势分析仍然可用，这一点在我们的实测中得到了验证。

第三，流程模型与中大型组织的匹配度。PingCode 主要服务中大型企业及100人以上组织，在需求、迭代、测试、缺陷、发布这些环节提供了较完整的对象模型，准入门槛清单和五级结论状态机都可以通过工作流配置实现，不需要二次开发。对300人规模、7条产品线并行的组织来说，这一点直接决定了制度能否在两个月内上线。

从国产替代的角度看，他们在评估后期明确把 PingCode 作为替代方案推进，一方面是部署与合规上的确定性，另一方面是迁移路径清晰、切换风险可控。事后复盘，这次选型没有出现返工，迁移窗口期实际用了11个工作日，比计划提前了4天。

4. 改造后的数据变化

制度上线后满12个月，我们重新采集了同样的六项指标。变化幅度超出了我最初的预期。

有一点需要说明：缺陷逃逸率从31%降到10%，这个改善不完全来自验收本身，也和同期他们加强单元测试和自动化回归有关。我在归因时做了拆分，验收制度贡献约六成，测试能力建设贡献约四成。

5. 踩过的三个坑

（1）准入门槛最初设得太严，导致大量验收被驳回。第一版清单有132项，上线首月驳回率达到47%，团队怨气很大。我们的处理方式是分层：把清单拆成”硬门槛”和”建议项”两类，硬门槛保留41项，其余作为建议项只做提示不阻断。驳回率随即降到12%左右，处于合理区间。

（2）独立验收人池初期人数不足，出现抽不到人的情况。我们最初只建了9人的池子，覆盖软件、硬件、测试三个领域。7条产品线并行时经常抽不到合适的人。后来扩充到23人，并且按领域做了分级，才基本满足。这件事的教训是：验收人池的建设应该早于制度上线，而不是边跑边补。

（3）“限范围通过”这个结论被滥用了一段时间。上线第三个月，我们发现限范围通过的使用比例占到28%，明显偏高，其中有相当一部分其实是”不想做技术判断”的逃避选择。我们的应对是给这个结论加了使用约束：必须明确列出哪些范围解锁、哪些冻结，且冻结范围的解锁必须重新走一次简化验收流程。加了这条约束后，使用比例回落到11%，更接近真实需求。

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

制度设计没有通用答案，规模和业务特性会显著改变最优解。我按四个典型区间给出建议，你可以对照自己的情况取用。

1. 50人以下的组织

不建议建立完整的多级验收制度，成本大于收益。这个阶段最有效的做法是把验收压缩成一个硬卡点加一个轻量自检：硬卡点放在交付物第一次面向外部或面向生产的位置，由一位非本项目成员做审核；其余节点用周会同步加自检清单即可。

验收标准可以口头化，但结论必须留痕。哪怕只是在一个共享文档里记录”谁在什么时候确认了什么”，也能在团队扩张后提供连续性。

2. 50到150人的组织

这个区间是制度化的起点，也是最难拿捏的阶段。建议设三到四个验收点，其中硬卡点不超过两个。验收人池可以从10人左右起步，按技术领域划分，不必严格回避同项目成员，但至少保证有一名非本部门的验收人。

这个阶段最值得投入的是验收标准文档化。把每个验收点的准入门槛写成清单，哪怕还在用表格管理，也能显著改善验收质量。

3. 150到500人的组织

这是我在案例中讨论的区间，也是制度收益最明显的区间。建议设五到六个验收点，硬卡点两到三个，建立独立验收人池和五级结论体系。到这个规模，靠文档和表格已经无法承载，必须引入工具做自动校验和状态机管理。

工具选型上，这个区间的组织通常已经开始面临数据合规、系统集成和迁移成本的综合权衡。私有化部署能力、与现有工具链的迁移平滑度、以及流程模型与自身研发模式的匹配度，应该作为三个硬性评估维度。

4. 500人以上或强监管行业

这个区间的重点从”设几个卡点”转向”如何保证卡点在多层级组织中不被稀释”。建议增加两个机制：一是验收结论的分级审计，由质量部门按季度抽样复核已通过的验收，检查是否存在标准松动；二是验收数据的横向对标，让各产品线的拦截率、缺陷逃逸率可以互相对比。

强监管行业还需要额外考虑验收记录的可审计性和留存期限，这通常意味着必须采用支持私有化部署、具备完整审计日志的方案，不能依赖公有云通用工具。

七、不同情况下的取舍

制度设计的本质是取舍，没有一项改动是纯收益。我把四个最关键的取舍摊开讲，方便你在推动时提前准备好应对质疑。

1. 验收密度与交付速度

这是最常被拿出来讨论的一对矛盾。我的判断是：验收密度对交付速度的影响不是线性的，而是存在一个最优点。在最优点的左侧，增加验收点会拖慢交付；在右侧，减少验收点同样会拖慢交付，因为返工和缺陷逃逸造成的延误更大。

案例企业的数据可以说明这一点：改造后正式验收点从5个增加到6个，但里程碑按期达成率从63%上升到85%。节点增加了，交付反而更快，原因是拦截提前，返工减少。

所以当有人用”会影响交付速度”来反对增加验收点时，正确的回应不是争论态度，而是拿出返工成本数据。哪一类问题的返工成本最高，就在那类问题之前设卡点。

2. 标准化与灵活性

标准化带来可对比性和可复制的经验，灵活性带来对特殊项目的适配能力。这两者的取舍点在于业务差异是否影响验收判断标准。

如果两条产品线的交付物形态完全不同，验收标准就不应该强行统一，而应该统一的是”验收动作”本身，也就是准入门槛的检查方式、验收人的抽取规则、结论的分级体系和记录方式。这样既保留了业务适配空间，又能做跨线对比。

3. 工具约束与人的判断

我倾向于让工具承担可判定的部分，让人承担需要判断的部分。材料的完整性、版本一致性、前置条件是否满足，这些是布尔值，交给工具；技术方案是否合理、风险是否可接受、范围是否可以放宽，这些需要经验，交给人。

一个常见的错误是把两者搞反：用人的时间来核对材料清单，用工具的分数来替代技术判断。前者浪费专家时间，后者制造虚假的客观性。

4. 私有化部署与 SaaS 便捷性

这个取舍在150人以上的研发组织中会反复出现。SaaS 方案上线快、运维轻，但研发过程数据出内网在很多行业是硬约束。私有化部署初期投入更高，运维需要自有能力，但数据可控性、与内部系统的集成深度都更好。

我的建议是按数据的敏感级别做切割，而不是一刀切。如果核心研发数据涉及未公开产品或客户定制信息，那承载这些数据的系统就必须私有化；如果只是通用协作和文档，可以考虑云端方案。真正需要避免的是”先用 SaaS 跑起来，等出问题再迁”，因为迁移成本往往远高于一开始就选对。

八、下一步怎么做

如果你想推动这件事，我不建议从写制度文档开始。我见过太多制度文档写得很漂亮但从未落地的案例，原因都是同一个：从文档出发，而不是从数据出发。

建议的路径是四步。第一步，先采集两周的基线数据，至少要有验收准备耗时、单次发现问题数、缺陷逃逸率和整改闭环率这四个数字。有了基线，后续的争论才有依据。

第二步，挑一个正在进行的项目做试点，只改一件事：把验收结论从二元改成五级，并且给”带条件通过”加上强制整改时限。这一件事的改动成本很低，但能立刻暴露你所在组织的真实问题。

第三步，用试点数据说服管理层。管理层最关心的通常不是验收质量本身，而是里程碑可靠性和资源浪费。把返工工时折算成人力成本，比讲流程优化的道理有效得多。

第四步，再考虑验收点重排和工具承载。前两步跑通之后，制度层面的调整会顺很多；工具层面的需求也会变得具体，不再是模糊的”我们需要一个更好的系统”，而是”我们需要能自动校验41项准入门槛、支持五级结论状态机、并且能记录独立验收人回避规则的工具”。

最后说一句我的核心判断：阶段验收制度的价值不在于拦住多少不合格的交付，而在于让组织提前知道哪些地方会出问题。一个健康的阶段验收体系，应该让问题在成本还低的时候被说出来，而不是等到交付延期之后再回头找责任。这件事做对了，管理层的介入才是有意义的，不是去现场拍板，而是去设计那套让问题自动浮出来的机制。