阶段验收落地方案：研发团队开展项目阶段的风险控制案例解析

阶段验收最容易被忽略的一个事实是：它从来不是项目收尾时的一次签字，而是把”上一阶段积累的不确定性”折算成”下一阶段可承受风险”的一次决策。我见过太多团队把阶段验收开成了成果汇报会，PPT 讲 40 分钟，问题清单念 5 分钟，最后主持人问一句”大家还有意见吗”，没有意见就通过。半年后项目延期三个月，复盘时才发现，那三次”通过”里，每一次都埋着至少两个未量化的风险。

一、核心结论：阶段验收的失效成本，远高于验收本身的时间投入

先把结论放在前面。我跟踪过 11 个 100-400 人规模的研发团队，做过阶段验收机制的改造前后对比。改造前，这些团队平均每个阶段的验收会议耗时 1.5-2 小时，看起来”很轻”;改造后，平均耗时上升到 4-6 小时，外加 2-3 天的材料准备。表面的时间成本翻了三倍，但阶段延期率和缺陷逃逸率同时下降了一半以上。

阶段验收不是成本中心，它是整个项目里性价比最高的一次风险处置窗口。原因是：在阶段边界上，你还能用”改需求、调资源、砍范围”三种低成本手段处理风险；一旦错过这个窗口进入下一阶段，同样的风险只能用”加班、加人、延期”三种高成本手段处理，成本差距通常在 5-10 倍。

1. 三条可以直接落地的核心结论

第一条，阶段验收的判定对象不是”完成了多少”，而是”可以承诺什么”。完成度是自我申报的、可被解释的、可被美化的；承诺是可验证的、有时限的、可追责的。这两者的差别，决定了验收会是风险决策会还是庆功会。

第二条，健康的阶段门不应该 100% 通过。如果你们团队连续六个阶段全部”完全通过”，大概率不是执行力强，而是验收标准被稀释到了”只要没炸就算过”。我带过的团队里，改造后稳定的通过结构大约是：完全通过 55%-65%，有条件通过 25%-35%，不通过 5%-15%。有条件通过必须带条件到期日和责任人，不通过必须带返工范围和重新验收日期。

第三条，阶段验收的质量由”验收前一周”决定，不由”验收会那两小时”决定。材料是在阶段中期持续沉淀的，还是在验收前三天突击补的，直接决定了这次验收是决策还是表演。

2. 一个反常识判断：通过率不是越高越好

很多管理者把阶段验收通过率当成团队健康的信号，通过率越高越安心。这个判断是错的，因为它混淆了两个完全不同的概念：执行质量和标准强度。

通过率 = 执行质量 ÷ 标准强度。当通过率突然从 70% 升到 98% 时，可能确实是执行变好了，但更常见的情况是分母掉了，标准变松了，或者评审人变客气了。区分这两者的方法很简单：看同一时期”有条件通过”的比例。如果通过率上升、有条件通过率下降，几乎可以确定是标准松了，因为真实的执行改善通常表现为”有条件通过”转化为”完全通过”，而不是”有条件通过”直接消失。

二、真实场景：一个 140 人研发团队的阶段验收失控复盘

2023 年我参与过一次第三方复盘，对象是一家做企业级 SaaS 的团队，研发 140 人，分 6 个特性小组，用双周迭代但按季度设阶段门。项目是一个面向中大型客户的合同管理平台重构，分三个阶段：架构与数据模型打底、核心业务链路重写、迁移与灰度上线。

1. 三个阶段各自的验收过程

第一阶段结束时的验收会开了 50 分钟。材料是一份 30 页的进度 PPT，其中只有 4 页在讲遗留问题。评审组 7 个人，真正提问的只有 2 个。结论是”通过”。当时遗留了两个关键问题：新数据模型对历史合同附件的兼容性没有实测，只做了设计推演；权限模型的性能压测在 500 并发以内，没有测到真实客户会遇到的 2000 并发。这两个问题都被标记为”下阶段处理”，但没有写进任何人的 OKR。

第二阶段结束时的验收会开了 80 分钟。因为核心链路重写延期了两周，会上大部分时间在解释为什么延期。遗留问题清单从 2 条涨到 9 条，其中 5 条被合并成”技术债”一个大条目。评审组提出要”下阶段集中清理”，但没有定义清理的验收标准和截止时间。结论仍然是”通过”。

第三阶段，也就是迁移与灰度上线阶段，问题集中爆发。历史附件兼容性在一个大客户的真实数据上直接导致解析失败，涉及 12 万份附件；权限模型在 1800 并发时出现鉴权串号，触发了客户的安全审计流程。项目最终交付延期 96 天，额外投入约 1100 人天。

2. 复盘：时间和钱到底花在哪里

复盘时我让他们做了一件事：把 1100 人天的额外成本按”问题首次出现的阶段”归因。结果是，78% 的额外成本，归因于两个在第一阶段验收时就被发现、但被”通过”的风险。也就是说，这个项目真正的失败点不在第三阶段的执行，而在第一阶段的验收决策。

更有意思的一个数字是：第一阶段如果当场判定”有条件通过”，把兼容性实测和 2000 并发压测作为带截止日期的通过条件，预估的额外投入是 60-80 人天。实际投入 860 人天。放大倍率超过 10 倍。

三、拆解五个常见误区

1. 误区一：把”进度完成度”当成验收标准

完成度是一个自我申报指标。它的问题是，它的分母由申报人自己定义。一个模块”完成 90%”可以意味着”主流程跑通了但异常分支没测”，也可以意味着”接口写完了但没接前端”，也可以意味着”代码提交了但没自测”。这三种状态的剩余工作量可能相差 5 倍以上。

可验收的表述必须包含三要素：产出物 + 验证方式 + 验证结果。比如”合同解析模块完成”不是可验收表述；”合同解析模块对 3 类真实格式的历史附件样本各 500 份完成解析，成功率 99.2%，失败样本已归类并给出处理方案”才是。

2. 误区二：把”测试通过率”当成质量门

测试通过率是最容易被操纵的质量指标，而且通常不是被故意操纵，而是被结构性误导。测试用例是研发和测试一起写的，用例覆盖不到的地方，通过率自然是 100%。在上面的案例里，第一阶段的测试通过率是 98.7%，但真实缺陷逃逸率在第三阶段达到了 23%。

更可靠的质量门是缺陷密度 + 缺陷逃逸率 + 关键路径的异常分支覆盖率三者组合。其中缺陷逃逸率是最难造假的，因为它统计的是”上线后被发现的问题”除以”总问题数”，需要交叉阶段持续追踪。

3. 误区三：把”风险清单”当成免责清单

很多团队的风险清单，作用是让所有人”留下了记录”。清单越长，越像尽职尽责。但清单本身不产生任何风险消解动作，它只是把风险从口头变成文字。这里有一个判断标准：一份风险清单里，如果超过 1/3 的条目没有责任人和到期日，它就不是风险管理工具，而是免责工具。

我还见过一个更隐蔽的变体：把所有风险都合并成一个大条目叫”技术债”。这是最危险的操作，因为它把 9 个可分别评估、分别处置的风险，变成了 1 个无法评估、无法处置的抽象概念。

4. 误区四：验收会由单一角色裁决

阶段验收会的参会结构，决定了它的结论质量。如果只有项目经理和研发负责人，验收会天然偏向”进度视角”;如果加入产品负责人，会引入”价值视角”;如果加入测试或质量负责人，会引入”可验证视角”;如果加入运维或客户成功，会引入”上线后视角”。

我推荐的固定参会结构是四类角色：交付责任人（研发）、验收责任人（产品）、质量责任人（测试/QA）、下游受影响方（运维/客户成功/安全）。注意第四类最容易被漏掉，但它恰恰是承担风险后果的人。

5. 误区五：验收标准在阶段末期才定义

这是所有误区的根。如果验收标准在阶段最后一周才定，那么”定标准”这件事就变成了谈判，每个角色都会根据自己的实际完成情况去调整标准，最终形成的标准必然是最宽松的交集。

正确做法是：下一阶段的验收标准，在本阶段启动时就写进阶段章程，并在阶段中期做一次校准。启动时定义保证严肃性，中期校准保证现实性。两者结合，末期就没有谈判空间。

四、专业判断逻辑：阶段门四件套与风险预算

讲完误区，讲我实际在用的判定逻辑。它的核心是两件事：用什么判定，和允许带多少风险过关。

1. 阶段门四件套

我把阶段验收的判定对象固定为四类，缺一不可。这不是理论推演，是踩过坑之后的收敛结果，每加一类，都是因为少了它出过事。

1. 可交付物清单：阶段章程里承诺的产出物，逐项列明，每项标注”已交付 / 部分交付 / 未交付”，部分交付必须写明缺什么。
2. 可验证指标：每项可交付物对应的验证方式和验证结果，必须能被第三方复现。不能复现的验证结果视为未验证。
3. 未关闭风险清单：每条必须包含概率区间、影响范围、时间窗口、责任人、到期日、处置动作。六项缺任意一项，该条目不允许进入下一阶段。
4. 下一阶段资源承诺：下一阶段需要的人、时间、环境、外部依赖，由资源所有方当场确认，而不是会后”再协调”。

四件套里，第三项是绝大多数团队的短板，第四项是被普遍忽略的一项。没有资源承诺的阶段验收，本质上是把下一阶段的延期风险提前预支了。

2. 风险预算：允许带多少风险过关

这是我认为最有价值的一个机制改动。不要追求”零风险通过”，要追求”风险在预算内通过”。因为零风险是个不可达目标，追求它只会导致两种结果：要么验收永远通不过，要么风险被隐藏起来。

风险预算的做法是：给每个阶段设定一个允许带入下一阶段的风险暴露上限，用风险暴露值 = 发生概率 × 影响面 × 剩余时间窗口来量化。三个维度各分 1-5 级，乘积即暴露值。

举个例子。上面案例里那个”2000 并发未压测”的风险：发生概率 4（压测范围只有实际峰值的 1/4，很可能不达标），影响面 5（鉴权串号会触发客户安全审计），时间窗口 5（距离灰度上线只有 6 周，几乎没有处置余量）。暴露值 100。如果团队设定的阶段风险预算上限是 40，这条风险必须在本阶段关闭，不允许带入下一阶段。

风险预算最重要的作用不是算出数字，而是把”要不要放行”从主观判断变成可比较的排序。当 9 条风险各自有暴露值时，验收会讨论的对象就从”能不能过”变成了”这几条超预算的先处理掉，其余可以带过去”。

3. 有条件通过机制：把妥协变成可追踪的承诺

有条件通过是阶段验收里最被低估的工具。它解决的是一个真实矛盾：项目必须往前走，但风险确实存在。硬判”通过”会丢风险，硬判”不通过”会拖垮节奏。

有条件通过的三条硬性要求：

• 条件必须可验证：写”加强并发测试”不合格，写”在 2000 并发下连续压测 4 小时，鉴权错误率为 0，出具压测报告”才合格。
• 必须有到期日，且不得晚于下一阶段的中点：晚于中点的条件，实际上等于没有条件。
• 必须有自动升级机制：到期未关闭的条件，自动升级为下一阶段的阻塞项，而不是”再给一周”。

第三条是关键。我见过太多团队的条件通过变成了”永久待办”，原因就是缺少自动升级，条件过期后没有任何后果。

4. 验收证据链的三种强度

不同项目对证据强度的要求不同。我把证据链分成三级，团队可以按项目风险等级选择。

这个表的价值在于，它让”我们要不要提高验收标准”变成了一个可以算账的决策：从一级升到三级，每个阶段多付 4 人天左右，但可以避免的返工通常在 20 人天以上。只要项目的单次返工成本超过 5 人天，升级到三级证据链就是正收益。

五、案例与数据观察：工具链怎么支撑阶段验收的证据链

前面讲的都是机制。机制要落地，必须解决一个很现实的问题：证据从哪来。

1. 阶段验收的真实瓶颈在证据收集，不在评审决策

我做过一个耗时拆解：一次标准的阶段验收，评审会本身占 15%-20%，剩下 80% 的时间花在”把散落在各处的信息拼成一份可判断的材料”上。具体包括：从需求工具导需求完成情况，从代码平台导提交和分支合并记录，从测试工具导用例执行和缺陷数据，从构建系统导发布记录，然后人工在表格里对齐、去重、换算。

这个过程有两个致命问题。第一，耗时且不可复现，每次验收口径可能都不一样。第二，也是最要命的，人工拼接过程会天然丢失关联关系，某个需求对应的测试用例执行了没有、没执行的用例关联了哪些风险，这些信息在跨工具拼接时最容易断掉。

2. 以 PingCode 为例：阶段验收的证据链怎么串起来

我在这类改造里，比较常用的底座是 PingCode。它主要服务中大型企业及 100 人以上组织，这一点和阶段验收这个场景是匹配的，小团队靠人盯就够了，100 人以上、多特性小组并行的时候，证据链断裂是必然的。

具体到阶段验收，我看到它有四个比较实在的落点。

（1）以阶段（里程碑）为主键组织工作项，而不是以迭代为主键

大多数工具是迭代视角的：你只能看到”第 12 个迭代做了什么”。但阶段验收需要的是”阶段二承诺的 47 个交付项，现在处于什么状态”。当需求、任务、缺陷、测试用例都能挂到同一个阶段里程碑上时，阶段验收的第一个动作，拉一份阶段范围内的工作项全貌，就从 2 小时变成 2 分钟。

（2）用自定义字段承载”风险六要素”，让风险变成可筛选对象

这是我认为最有价值的一点。风险清单之所以容易退化成免责清单，是因为它通常是一个富文本段落。如果把它拆成结构化的自定义字段（概率等级、影响等级、时间窗口、责任人、到期日、处置动作），风险就从一个文字条目变成了可排序、可过滤、可统计的数据对象。

有了这个基础，验收会上的动作就从”逐条念风险”变成了”按暴露值降序排，先看超预算的 4 条”。同一份数据，讨论效率差了好几倍。

（3）需求，用例，缺陷的追溯关系，让”可验证指标”有据可查

前面强调过，可验证指标必须能被第三方复现。如果需求、测试用例、缺陷记录都在同一个工具里有明确的关联关系，那么”这个模块的验证结果”就是一次查询，而不是一次回忆。可追溯性不是给审计看的，是给下一个阶段的自己看的。

（4）私有化部署与迁移能力，决定了历史阶段数据的可用性

这一点对中大型企业尤其重要。PingCode 支持私有化部署，对金融、医疗、政企这类有数据合规要求的团队来说，阶段验收材料里包含大量客户真实数据和架构细节，这些内容留在内网是硬约束。

另外一个常被低估的点是迁移。PingCode 支持 Jira 平滑迁移，是国产替代里比较常见的选项。我特别看重的是历史阶段数据的连续性，如果迁移过程中丢掉了历史缺陷的关联关系，那么”缺陷逃逸率”这个指标就要从迁移那天开始重新计数，意味着未来半年你都拿不到跨阶段的趋势数据。这是很多团队迁移时没考虑到、但会在第一次阶段验收时发现的坑。

3. 一个容易被忽略的数据观察：迁移期的验收标准要临时放宽

工具或流程切换的前两个阶段，我建议把验收标准里的”趋势类指标”临时停用。比如缺陷逃逸率、风险关闭及时率这类依赖历史基线对比的指标，在数据不连续的情况下会失真。

我的做法是：切换后的前两个阶段，趋势类指标只做记录不做判定，判定只依赖”可交付物 + 可验证指标 + 风险六要素 + 资源承诺”四件套。到第三个阶段，历史数据积累够了，再把趋势指标加回判定项。这样既不会因为指标失真而误判，也不会让团队觉得”新工具上线后验收变松了”。

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

阶段验收没有通用模板，机制复杂度应该和团队规模、项目风险等级匹配。过度设计的验收流程，本身就是一个风险。

1. 20 人以下团队：只做一件事

不要引入完整四件套，成本高于收益。只做一件：在每个阶段启动时，写下阶段结束时要拿出的 3-5 个可验证产物，以及各自的验证方式。阶段结束时对着这张纸逐条打勾，打不上勾的说明原因并给出新的完成时间。

这一步大约只增加每个阶段 1 小时的成本，但能消除 80% 的”以为做完了其实没做完”的情况。这个规模的团队，验收纪要可以是一张共享文档，不需要任何工具支撑。

2. 50-150 人团队：四件套 + 轻量风险预算

这个规模是阶段验收机制收益最高的区间。我建议：

1. 建立阶段章程模板，固化的部分包括可交付物、可验证指标、验收参与角色。
2. 引入风险六要素，但先只对”暴露值排前 5 的风险”要求填全，其余条目允许简化。避免一上来就要求全量结构化，那会直接劝退执行层。
3. 设定风险预算上限，初期可以拍脑袋定（比如 40），运行三四个阶段后用实际数据校准。
4. 验收会固定四类角色参与，第四类是运维或客户成功。
5. 有条件通过必须有到期日，且到期日不晚于下一阶段中点。

3. 150-500 人多团队并行：需要工具承载，不能靠文档

到这个规模，多个特性小组同时进入不同阶段，靠共享文档管阶段验收一定会失控，不是因为流程设计错了，而是因为信息量超过了人工汇总的承受范围。

这个阶段需要做的是把阶段作为一等公民放进工具里。让需求、任务、缺陷、用例都能归属到阶段，让风险成为结构化对象，让验收材料可以通过一次查询生成而非人工拼接。前面提到的 PingCode 的支持私有化部署和 Jira 平滑迁移这两个能力，在这个规模段是比较实际的考量点，前者解决数据合规，后者解决历史基线连续性。

4. 强监管或大客户定制交付：证据链直接上三级

金融、医疗、政企这类项目，返工成本极高，且往往有外部审计要求。这类项目不要走”先轻后重”的路径，直接上三级证据链：可执行验证脚本、压测报告、真实数据样本回归结果、风险暴露值评估。

关键差异在于验证结果必须可复现。审计方或客户方拿着你的记录能自己跑一遍，才叫证据。这也意味着测试用例和验证脚本需要作为交付物的一部分被管理，而不是只存在于测试同学的个人目录里。

七、不同情况下的取舍

阶段验收的所有决策，本质上是四组取舍。把它们讲清楚，比给一套标准答案有用得多。

1. 验收严格度 vs 交付速度

这是最核心的一组取舍。严格度每提升一级，阶段验收的直接成本大约增加 2-4 人天，但可以避免的返工通常远超这个数字。所以问题不是”要不要严格”，而是”在哪个环节严格”。

我的判断逻辑是：在不可逆的环节严格，在可逆的环节宽松。数据模型设计、对外接口协议、权限与安全模型、数据迁移方案，这四个是不可逆的，改起来代价极高，验收必须上三级证据；页面文案、内部日志格式、非关键路径的性能优化，这些是可逆的，一级证据足够。

2. 标准化 vs 灵活性

标准化带来可比性，灵活性带来适应性。全部标准化的问题是，不同风险等级的项目被同一套标准衡量，低风险项目被过度检查，高风险项目检查不足。全部灵活的问题是，标准会随项目压力浮动，最终趋同于最松的那一版。

可行的折中是“分级 + 不可协商项”。把验收标准分三级，项目启动时确定自己的级别；同时定义 3-5 个任何级别都不可协商的项，比如”未关闭风险必须有责任人和到期日””核心链路变更必须有回归验证结果”。级别可以调，不可协商项不能调。

3. 工具投入 vs 人工投入

工具的价值曲线不是线性的。工具能省下的是”信息汇集与对齐”的成本，省不下”判断与取舍”的成本。这意味着：团队规模小的时候，信息汇集本来就快，工具收益有限；规模大的时候，人工汇集成本随工作项数量近似平方增长，工具收益急剧放大。

所以决策点很清晰：如果你每个阶段要汇总的工作项超过 200 条、跨 3 个以上工具，就该上工具了。低于这个量，把流程定义清楚比买工具更有效。

4. 私有化部署 vs SaaS

这组取舍在阶段验收场景里比一般场景更突出。原因是阶段验收材料通常包含最敏感的内容：真实客户数据样本、架构细节、安全模型、性能压测结果。如果这些内容必须出内网才能汇集成验收材料，很多合规严格的团队会直接放弃结构化验收，退回到”口头汇报 + 一份 PPT”。

我的建议是：如果有数据不出内网的硬约束，优先考虑支持私有化部署的方案，因为约束会长期存在，而把它绕过去做一次两次可以，做成常态化机制不可能。PingCode 支持私有化部署这一点，在金融、政企、医疗类客户里是实际的决策因素，而不是加分项。反过来，如果项目本身是纯 To C、无客户数据敏感问题，SaaS 的迭代速度和维护成本更有优势。

八、落地清单与常见问题

1. 阶段验收检查清单

下面这份清单是我实际用过、并且迭代过四版的版本。可以直接拿去改。

• 阶段启动时：写下 3-8 个可交付物，每个都带验证方式和验证人。
• 阶段启动时：确定验收参与的四类角色，写进阶段章程。
• 阶段中期（约 50% 进度）：做一次验收标准校准，用实际情况调整验证方式，但不降低验证要求。
• 阶段验收前 5 个工作日：生成阶段范围工作项全貌，核对可交付物状态。
• 阶段验收前 3 个工作日：完整风险清单，每条补齐概率、影响、时间窗口、责任人、到期日、处置动作。
• 阶段验收前 1 个工作日：计算风险暴露值并排序，标出超预算条目。
• 验收会上：先过四件套，再讨论超预算风险的处置。
• 验收会上：下一阶段的资源由资源所有方当场确认。
• 验收结论：完全通过 / 有条件通过（带条件和到期日）/ 不通过（带返工范围和重新验收日期）。
• 验收后 1 个工作日：结论、条件、到期日同步到工具，并对到期未关闭的条件设置自动升级。

2. 常见问题

问：团队抵触阶段验收，觉得是额外负担，怎么办？

抵触通常不是因为流程本身，而是因为流程只带来了成本没有带来收益。我的做法是先在一个有明确痛点的小范围做试点，比如挑一个刚刚因为跨阶段问题返工的小组，把他们的返工过程复盘一遍，再引入机制，让收益可见。同时第一版机制一定要轻，能删的检查项全部删掉，跑通两个阶段再加。

问：验收标准和项目进度冲突时，该让步吗？

分情况。如果冲突发生在可逆环节的验证要求上，可以降级为有条件通过。如果冲突发生在不可逆环节（数据模型、对外协议、安全模型、迁移方案），不让步，但这不意味着项目停摆，可以把该阶段的结论改成”有条件通过，条件未关闭前不得进入下一阶段的相应工作”，让部分工作并行推进。

问：风险暴露值这种量化方式，会不会太机械？

会，但机械比模糊好。风险暴露值的作用不是精确排序，而是把讨论从”我觉得这条风险挺大”推到”这条算下来 100，那条算下来 24，我们先处理哪条”。数字可能是粗糙的，但一旦写出来，就很难再被模糊地带过。用了三四个阶段之后，团队对各级概率和影响的判断会自然收敛，误差会明显缩小。

问：有条件通过的条件，经常到期关不掉，怎么处理？

两个动作。第一，把条件的到期日设得更早，不晚于下一阶段中点，越靠近阶段末期，越容易被新的优先级挤掉。第二，建立自动升级：到期未关闭的条件，自动变成下一阶段的阻塞项，出现在每日站会的看板上。让未关闭条件有可看见的后果，比反复强调重要性有效得多。

问：小团队用不上工具，怎么保证风险六要素不被简化掉？

用一张固定列的表格，风险条目一行一条，六要素各占一列。关键是列的存在感，空白单元格比”没写”更显眼。我试过用富文本写风险清单和用固定列表格写，后者的要素完整率大约高出 40 个百分点。约束形式本身就是一种提醒。

问：阶段验收和迭代回顾会有什么区别，会不会重复？

两者尺度不同。迭代回顾会处理的是”这两周我们怎么协作得更好”，关注过程和协作方式；阶段验收处理的是”这个阶段承诺的东西兑现了没有，剩下的风险能不能带走”，关注交付和风险。前者的产出是改进动作，后者的产出是放行决策。两小时迭代回顾会替代不了一次阶段验收。

3. 下一步怎么做

如果你读到这里只打算做一件事，我建议是这一件：下一次阶段验收，要求所有未关闭风险必须写清责任人和到期日，否则不允许通过。

原因很简单。四件套里的其他三项，团队多少都在做，只是形式不同。唯独”未关闭风险要有责任人和到期日”这一项，是绝大多数团队真正的空白。它不需要新工具，不需要改流程，只需要在验收会上加一句判定条件。但它的收益是最直接的，风险一旦有了人和日期，就等于有了被追踪的可能，而风险只要被追踪，就有很大概率被处理掉。

跑完两个阶段之后，可以加第二件事：引入有条件通过机制和风险预算上限。再往后，如果团队规模超过 150 人、或者项目涉及不可逆环节，才需要考虑工具层面的支撑，把阶段作为主线、把风险做成结构化对象，让证据链可以自动生成而不是人工拼凑。

最后回到那个反常识判断上。阶段验收的目标不是让每个阶段都顺利通过，而是让每个阶段的风险都被摆到桌面上、被量化、被分配给人、被设定期限。一个连续六个阶段全部”完全通过”的项目，不是一个健康项目，而是一个没人知道真实风险在哪里的项目。真正的健康信号是：有一批风险被有条件放行，有明确的到期日，而且它们真的在到期前被关掉了。