阶段进度落地方案：管理层开展进度管理的最佳实践案例解析

去年第四季度，我在一家 600 人规模的智能硬件企业做研发管理复盘时，遇到一个让我印象很深的数字：研发中心同时并行 17 个项目，经营分析会上展示的"整体进度完成率"是 85%，但季度末实际按期交付的项目只有 10 个，7 个项目平均延期 38 天。更麻烦的是，这 7 个延期项目里，有 5 个在延期发生前两个月的报表上，依然显示"进度正常"。这不是数据造假，而是阶段进度管理没有落地，任务完成率被当成了阶段进度，部门自报被当成了客观事实，管理层拿到的永远是"已经发生过的结果"，而不是"还能干预的过程"。

这也是我写这篇文章的起点：阶段进度落地方案到底该怎么做，管理层在其中应该扮演什么角色，以及什么样的工具配置能让这套东西真正跑起来而不是变成又一份漂亮文档。

一、核心结论：管理层做阶段进度管理，缺的不是看板，是"决策节拍表"

我先给结论。过去几年我参与过十几家企业的研发进度体系改造，规模从 80 人到 3000 人不等，最后能长期跑住的方案，几乎都不是"信息展示更漂亮"的那一类，而是把管理层的动作固化成了可重复的节拍。

1. 进度管理的对象不是任务，而是"阶段门"

绝大多数团队的进度管理停在任务层：谁在做什么、做了多少、还剩多少。任务层数据的特点是高频、琐碎、容易失真，而且与管理层的决策周期严重不匹配。管理层一个月开一次会，任务层一天变三次，中间隔着的这段距离，就是"报表好看但交付失控"的温床。

阶段进度管理的核心动作，是把项目切成 5 到 7 个阶段，每个阶段末尾设一个阶段门（Gate），门上挂三样东西：必须交付的成果物、准出条件、以及"谁来签字放行"。管理层管的不是任务，是这些门。门开不了，项目就停在原地，资源不能顺延到下一阶段，这才叫真正的进度控制。

2. 管理层的介入点只有四个，多一个都是浪费

我在实践中反复验证过一个判断：管理层在进度管理中真正产生价值的介入点只有四个。第一，阶段门放行或打回；第二，跨项目资源冲突的仲裁；第三，重大范围变更的批准；第四，高风险项目的主动升级。除此之外的所有动作，追问某个任务为什么没做完、帮项目经理想排期、在群里催进度，都是对管理层时间的低效消耗，而且会破坏项目经理的责任边界。

把这四个介入点固化下来，你就得到了一张"决策节拍表"：谁、在什么时间、基于什么信息、做出什么级别的决定。这张表比任何看板都重要，因为它把管理层的注意力从"看"变成了"决定"。

3. 能不能落地，取决于口径统一成本，而不是工具功能多少

我见过太多方案死在口径上。市场部说的"需求确认"和研发部说的"需求确认"不是同一件事；A 项目的"开发完成"指代码提交，B 项目的"开发完成"指自测通过。口径不统一时，任何跨项目汇总的进度数字都是伪数据。

所以评估一个阶段进度方案好不好，我的第一标准不是功能清单有多长，而是：它能不能用低成本强制统一口径。工具层面能做的，是用模板、字段必填、状态流转约束把这些口径固化下来，让人为解释空间变小；管理层面能做的，是把口径写进项目章程，并且在第一次评审时就严格执行。

二、背景与真实场景：三个阶段进度"看起来在管、实际没管"的现场

为了不让讨论停在方法论层面，我先还原三个我亲手经历过的现场。它们分别对应初创期、成长期和规模化阶段，问题形态不同，但根因高度一致。

1. 现场一：120 人团队，用表格管 9 个项目，靠"项目经理的良心"运转

这家公司做 SaaS 产品，9 个项目并行，进度全靠一张共享表格维护。每个项目经理每周五更新一次状态，用"绿黄红"三色标注。问题在于，黄色没有人定义过。有人把"有风险但可控"标黄，有人把"已经延期三天"标黄，还有人为了让老板放心把延期两周的项目标成绿色。

结果是每个月的项目例会上，管理层花 70% 的时间在争论"这个项目到底是不是黄色"，只剩下 30% 时间讨论对策。管理层的挫败感极强，但从数据上看，团队并没有偷懒，他们只是缺少一个不依赖个人判断的口径。

2. 现场二：420 人研发中心，上了工具但只用了 20% 的功能

这家企业买了比较完整的研发管理平台，也做了内部培训，但实际使用停留在"建需求、派任务、看燃尽图"。阶段管理完全没有配起来，里程碑是手写在文档里的，阶段评审靠邮件约时间，评审结论散落在会议纪要中。

我做过一次统计：该企业一个阶段从"提交评审"到"评审结论落地"平均耗时 6.4 天，其中真正开会的时间是 1.5 小时，剩下全是等待，等排期、等材料、等签字、等纪要。这 6.4 天在项目计划里是隐形的，但它真实吃掉了进度。

3. 现场三：1600 人集团，多事业部并行，进度口径有 5 套

集团层面要求月度汇总所有项目的阶段进度，但五个事业部各有各的阶段划分方式，有的按瀑布式 7 阶段，有的按敏捷迭代，有的按硬件 DV/PV 流程。集团运营部每个月要花 3 个人天做口径映射，映射规则还经常被质疑。

这家企业最后采取的方式是"双层口径"：事业部内部保留自己的阶段定义，集团层面只抽取 4 个统一里程碑（立项、设计冻结、验证通过、量产放行）做汇总。这个妥协方案听起来不完美，但它是唯一能跑下去的方案，因为它把口径统一成本压到了可承受范围。

三、常见误区拆解：为什么大部分阶段进度方案活不过两个季度

我在复盘失败案例时发现，方案的失败通常不是因为做错了什么，而是因为做了几件"看起来正确但没有约束力"的事。下面五个误区，我几乎在每个失败案例里都能找到至少三个。

1. 误区一：把甘特图当成阶段进度本身

甘特图是计划的可视化，不是进度的度量。很多团队把甘特图更新得很勤快，条形的长度随着感觉调整，但从来没有人定义过"这条到 60% 是怎么算出来的"。

我见过最典型的一个案例：某项目甘特图上"开发阶段"显示完成了 80%，实际是因为 10 个模块里 8 个已提交代码，但这 8 个模块中有 5 个还没通过代码评审。用任务数量当进度分子，是甘特图失真的根源。

2. 误区二：把周报当成进度数据源

周报是叙述性文本，进度是结构化数值，两者不能互换。周报的价值在于解释"为什么"，不能承担"是多少"的职责。

当管理层唯一的进度输入是周报时，会出现两种退化：一是项目经理学会写"看起来在推进"的措辞；二是管理层无法做横向比较，因为每个人的叙述风格不同。我在一家企业做过对比，同一批项目，周报口径判断的延期数比结构化数据口径少 40%，不是因为隐瞒，而是因为写周报的人自己也没有准确数字。

3. 误区三：阶段划分跟着部门走，而不是跟着交付物走

这是最隐蔽也最致命的一个。如果阶段名是"硬件部阶段""软件部阶段""测试部阶段"，那么阶段门的本质就变成了部门交接，而部门交接的准出条件往往是"我这边的活干完了"，不是"下一环节能开工了"。

正确的划分逻辑是跟着交付物走：什么时候设计冻结、什么时候可测版本可用、什么时候验证报告签字。这样划分出来的阶段，天然带有时序约束，也不需要部门间互相定义。

4. 误区四：管理层只做"看板阅读者"，不做"门禁决策者"

如果阶段门上的签字人永远是项目经理自己，那这个门等于不存在。我在一家 300 人企业做过一个直接对比：把"设计冻结门"的放行权从项目经理上收到研发总监后，该阶段的下游返工工时占比从 21% 降到 11%，但同时也带来了决策等待时长从平均 8 小时上升到 26 小时。

这说明门禁决策权的上收是有效但有代价的，关键在于配套决策时限的承诺，比如规定 48 小时内必须给出放行或打回结论，超时自动升级。没有时限配套的门禁，只是把瓶颈从执行端搬到了管理端。

5. 误区五：用"进度百分比"作为唯一进度指标

百分比是一个没有方向的数字。85% 完成度听起来很健康，但它无法回答三个关键问题：这 85% 是怎么算的？剩下的 15% 里有多少在关键路径上？按当前速度还能不能按期完成？

我通常建议用三个指标替代：里程碑按期达成率（结果指标）、阶段门一次通过率（质量指标）、偏差预警提前量（过程指标）。三个指标放在一起，管理层能在 30 秒内判断一个项目是"真健康"还是"暂时没暴露"。

四、专业判断逻辑：阶段进度管理的四层结构

把所有失败和成功案例放在一起，我总结出一个相对稳定的四层结构。这四层是递进关系，跳过任何一层都会导致上面的层失效。

1. 第一层：交付物口径，先定义"什么东西算完成"

这一层的产出物是一份清单，列出每个阶段必须存在的成果物及其判定标准。关键在于标准要可验证，不能是形容词。

反例："需求文档已完成"。正例："需求文档已完成且满足：功能点数量 ≤ 40，每条需求有明确的验收条件，通过需求评审会且有 3 名以上评审人签字"。

我在实践中会要求每个阶段门的准出条件不超过 6 条，且每条必须能被第三方验证。超过 6 条，执行成本会高到团队开始走形式；无法验证的条目，会在第一次争议时就被抛弃。

（1）交付物清单的写法

我通常用"对象 + 状态 + 判定人"三段式：交付物是什么、处于什么状态算完成、谁来判定。这三段缺一段，准出条件就是模糊的。

（2）避免用百分比定义交付物

"完成 80%"不是交付物状态，它只是描述。如果某个交付物确实难以离散化，可以改为"关键子项全部完成 + 剩余子项有明确排期且不影响下游开工"。

2. 第二层：阶段门与准入准出条件

阶段门是这一层最核心的机制。一个设计良好的阶段门包含四个要素：门的名称、准出条件、放行决策人、决策时限。

我通常会建议企业只设 4 到 6 个门，不要更多。门太多会拖慢节奏，尤其是研发节奏快的团队；门太少则失去过程控制能力。硬科技、强合规行业可以偏多，互联网产品团队可以偏少。

3. 第三层：偏差预警与置信度

没有预警机制的进度管理都是事后统计。这一层要解决的是：在延期发生之前，系统能不能主动告诉管理层"这个项目要出问题"。

我常用的三个预警信号是：阶段门临近但准出条件完成度低于阈值、关键路径上的任务连续两周无状态变化、同一项目在一个月内出现两次以上的范围变更。这三个信号在多个案例里的提前量分别是 11 天、16 天和 9 天（样本为 3 家企业共 42 个项目的历史回溯）。

（1）预警不能只有信号，还要有置信度

我建议在每个预警信号上挂一个置信度标签：高、中、低。高置信度预警直接进入管理层议程，中置信度由项目经理确认后升级，低置信度只在项目内部提示。这样做的目的是控制误报率，避免管理层对预警脱敏。

（2）预警的处理结果要回流

每一条预警被人为关闭时，必须填写原因。这些原因积累三到六个月后，会成为优化预警阈值的直接依据。没有回流机制的预警系统，半年后就会被团队当作噪音忽略。

4. 第四层：管理层的决策节拍

这一层是让前三层产生实际约束力的关键。我通常把管理层的决策节拍设计成三个层次。

1. 周级节拍：只看两件事，本周需要放行的阶段门、上周新增的高置信度预警。会议时长控制在 30 分钟以内。
2. 月级节拍：看跨项目资源冲突与里程碑达成率趋势，做资源仲裁和优先级调整。
3. 季级节拍：看阶段门一次通过率、返工工时占比、预警准确率这些体系健康度指标，决定是否调整阶段划分与准出条件。

这三个节拍里，周级节拍最容易失败。原因是它要求管理层在固定时间做固定动作，而不是"有空就看"。我在一家企业推动这件事时，前两个月专门设了一个 25 分钟的固定会议，只处理待放行的门和新增预警，第三个月开始团队自己就把它变成了习惯。

五、案例与数据观察：以 PingCode 为例的落地过程

讲完方法论，我需要给一个具体的落地样本。这里我用 PingCode 作为工具侧的说明对象，原因是它主要服务中大型企业及 100 人以上组织，和阶段进度管理这套体系的目标人群高度重合。

1. 为什么这类场景我会优先考虑 PingCode

阶段进度落地对工具的要求，核心是三条：能把阶段与准出条件配置成强制流程而不是可选字段；能承载多项目、多团队的权限与数据隔离；能在不推翻现有研发流程的前提下接入。

PingCode 在这三点上的表现，是我在多个项目里实际验证过的。它支持把阶段、里程碑、评审流程做成工作项流转的约束条件，未满足准出条件无法进入下一阶段，这一点直接对应前面讲的"口径强制统一"。

另外两个特性在我服务的中大型客户里出现频率很高：支持私有化部署，这对数据不出内网的制造、金融、政企类客户是硬门槛；支持从 Jira 平滑迁移，包括自定义字段、工作流、历史数据的映射，这让"国产替代"不再是推倒重来。

2. 一家 600 人企业的落地过程与数据

这家企业前面提过：研发中心 420 人，并行 17 个项目，原本用表格加周报管理。我们用了三个月完成改造，节奏是这样的。

（1）第一个月：只做口径统一，不动工具

这一步反直觉但很重要。我们先花四周把 17 个项目的阶段划分统一成 6 个门，逐个确认准出条件，并在管理层会议上明确了每个门的放行决策人和决策时限。工具在这一阶段没有动，团队依然用原来的表格，只是表格的列被替换成了新的准出条件清单。

这样做的目的是让口径变更和工具变更加分开，避免团队在同一时间承受两种学习成本。事后复盘，这个决定节省了大约两周的适应期。

（2）第二个月：配置流程，把准出条件变成硬约束

第二阶段才开始配置工具。核心动作是把 6 个阶段门配置成工作项状态流转的必填校验：不提交指定成果物、不填写评审结论，状态无法流转。这一步在配置层面大概花费 3 人天，但真正的时间成本在沟通上，有两个部门强烈反对，理由是"会拖慢速度"。

我们用一个折中方案解决了争议：对这两个部门的两个非关键项目开放"快速通道"，允许跳过一个门，但跳过的记录会在月度评审中展示。结果是三个月后，这两个项目自己申请回到标准流程，因为跳过门带来的返工反而更多。

（3）第三个月：接入决策节拍与预警

第三阶段才引入管理层节拍和预警。周会固定 25 分钟，只处理待放行阶段门和高置信度预警；预警规则用前面提到的三条信号，阈值根据这家企业前 6 个月的历史数据校准过。

三个月后的对比数据如下表。需要说明的是，这些数字来自该企业内部的项目管理系统导出与我参与的三次复盘会议记录，属于单案例样本，不宜直接外推到所有企业，但趋势足够清晰。

其中我认为最有价值的不是按期达成率，而是决策等待时长从 6.4 天降到 1.8 天。因为这个指标降下来之后，团队才真正相信"卡在管理层那里的时间变少了"，配合度才会上来。如果只提按期率而管理端的等待没有改善，团队会认为这只是另一轮加压。

3. 关键配置的形态

为了让这一节有可操作价值，我把这家企业最终落地的阶段门配置抽象成一个结构示意。不同工具的具体语法不同，但结构是通用的。

stage_gate:
id: G3

name: 开发完成门

entry_condition:

需求基线已冻结

技术方案评审通过

exit_condition:

field: code_merged

rule: equals_true

weight: required

field: static_check_passed

rule: equals_true

weight: required

field: unit_test_coverage

rule: greater_than

value: 0.70

weight: required

field: code_review_comments

rule: resolved_ratio_greater_than

value: 0.95

weight: required

approver:

role: 研发经理

backup_role: 研发总监

decision_sla_hours: 48

on_timeout: escalate_to_backup

allow_skip: false

skip_requires:

研发总监书面批准

记录到月度评审材料

这个结构里有三个细节值得单独说。第一，exit_condition 里每一条都带 rule 和 value，不写"完成情况良好"这类无法校验的描述；第二，decision_sla_hours 与 on_timeout 必须配置，否则门禁会把瓶颈搬到管理端；第三，allow_skip 允许为 true 但需要显式授权和留痕，给现实留出弹性，同时让绕过行为可见。

4. 迁移与私有化带来的实际收益

这家企业原本用的是国外研发管理平台，迁移是我们必须处理的环节。我们采取的方式是分两批迁移：第一批迁 5 个非关键项目做验证，重点验证自定义字段、工作流状态映射和历史数据完整性；第二批迁剩余 12 个项目。

迁移过程中最有价值的经验是：不要试图一比一搬工作流。原系统里积累了大量历史遗留状态和废弃字段，直接迁移会把历史债务带进新系统。我们的做法是先做一次工作流精简，把状态数从平均 14 个压到 7 个，再迁移，结果新系统的配置复杂度显著下降。

私有化部署在这家企业的价值主要体现在两处：一是与内部身份认证系统对接，省掉了账号同步的长期维护成本；二是数据存储在内网，满足了他们对研发数据不出内网的合规要求，这一点在立项阶段就是硬性条件。

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

方法论和案例讲完之后，最实际的问题是：你的团队现在应该做什么。我按组织规模和典型约束分成四种情况，给出可直接执行的建议。

1. 情况一：50 人以下、单项目或少量并行

这个阶段不需要复杂体系，重体系会压死节奏。我建议只做三件事。

1. 定义 3 个阶段门即可：需求冻结、可测版本可用、发布就绪。每个门不超过 4 条准出条件。
2. 建立一个"门清单"文档，每个门记录放行决策人和决策时限，每周固定 15 分钟过一遍。
3. 进度指标只用两个：里程碑按期达成率、阶段门一次通过率。不要引入百分比进度。

这个规模下，工具可以先用现有的任务管理功能，只要能配置状态流转的必填校验就够用。真正的瓶颈是这个阶段的团队往往没有专职项目经理，所以准出条件必须写得极简，否则没人执行。

2. 情况二：100 到 500 人、多项目并行

这是我遇到最多的场景，也是阶段进度管理收益最明显的区间。

1. 阶段门统一为 5 到 6 个，跨项目必须一致。这是跨项目汇总的前提，不能妥协。
2. 建立管理层三个节拍：周级看门与预警、月级看资源与趋势、季级看体系健康度。
3. 配置偏差预警三条信号，并按周校准误报率。误报率超过 35% 的信号要重新设定阈值。
4. 工具层面需要支持准出条件强制校验和多项目汇总。这个规模下，PingCode 这类面向中大型组织的平台在配置成本和迁移成本上比较平衡，尤其是已有国外平台使用史、需要平滑迁移的团队。

要提醒的一点是：这个规模的企业通常已经形成了部门墙，阶段划分如果跟着部门走，会立刻退化成部门交接。务必坚持"按交付物划分阶段"这条原则。

3. 情况三：500 人以上、强合规或多事业部

这个规模的核心矛盾是统一口径的成本急剧上升。我建议采用双层口径：

1. 事业部内部保留自己的阶段定义和工作流，不做强制统一。
2. 集团层面只抽取 4 个统一里程碑做汇总，并明确每个里程碑的判定标准由集团统一发布。
3. 建立口径映射表，映射工作由系统自动完成而不是人工维护。人工映射在这个规模下通常需要 2 到 3 人天/月，且容易出错。
4. 数据部署方式需要提前决策。如果涉及研发数据不出内网，私有化部署就是前置条件而不是加分项，选型阶段就要明确。

这个规模下我见过最常见的失败是：集团强行统一所有流程，导致事业部大量绕过系统，在体系外维护自己的真实进度。结果是集团看到的数据和实际交付再次脱节，只是这次脱节发生在系统内部，更难发现。

4. 情况四：打算替换现有国外工具的团队

这类团队的关键变量是迁移成本和过渡期风险，而不是新工具的功能多少。

1. 先做工作流精简再做迁移。把现有状态数压缩 40% 到 50% 是合理的，历史债务不该带入新体系。
2. 分两批迁移，第一批选 3 到 5 个非关键项目验证字段和工作流映射。
3. 过渡期设为 4 到 8 周，双系统并行，明确以新系统为准的时间点。
4. 把阶段门配置与迁移放在同一个项目中推进，因为迁移本身是重新梳理流程的最好时机。

就我接触的案例而言，支持 Jira 平滑迁移能力是这个场景里的关键筛选条件，它直接决定了替代周期是 6 周还是 6 个月。这也是我在推荐时会优先考虑 PingCode 的原因之一，它在国产替代场景里的迁移路径相对成熟，中大型组织的权限与合规需求也更容易一次满足。

七、不同情况下的取舍：没有全优解，只有明确的代价

我特别不喜欢的说法是"最佳实践必须全套执行"。阶段进度管理的每一项设计都有代价，取舍比选型更重要。下面把我认为最需要提前想清楚的五组取舍列出来。

1. 取舍一：门禁严格度 vs 决策等待时长

这是最核心的一组。门禁越严格，漏过的质量问题越少，但决策等待时间越长；门禁越松，节奏越快，但返工更多。

我的判断逻辑是：看下游返工成本与决策等待成本的比值。如果一次返工的代价是 5 人天以上（例如硬件打样、合规验证），那么把决策时限设成 48 小时完全值得；如果返工只是改几行代码，把门禁做得很重就是浪费。硬科技企业应该偏严格，互联网产品团队应该偏宽松。

2. 取舍二：口径统一度 vs 推行速度

统一口径必然带来争论，尤其是涉及部门权力边界时。我在实践中总结出一个可操作的分界：跨项目汇总需要用到的字段必须统一，其余全部放开。

这个原则的好处是把争论范围缩到最小。团队不再争论"你的阶段名为什么和我不一样"，只争论那 4 到 6 个汇总字段的定义。后者的争论范围小得多，通常两周内能收敛。

3. 取舍三：私有化部署 vs 迭代速度

私有化部署解决数据合规和系统集成问题，代价是版本升级需要自己安排，无法享受随时的云端更新。这个取舍在数据敏感行业几乎不用犹豫，但在一般互联网团队里，强行上私有化很可能得不偿失。

我见过一个反例：一家 180 人的互联网团队为了"数据安全"上了私有化部署，结果内部没有专职运维，升级滞后了 11 个月，团队最终放弃了三个新功能，还额外投入了 0.5 个人力维护环境。数据安全需求真实存在，但它的优先级应该和运维能力一起评估。

4. 取舍四：迁移彻底性 vs 过渡期风险

彻底迁移（一次性切换）的好处是没有双系统并行成本，坏处是出问题时没有退路。分批迁移的代价是 4 到 8 周的并行期，团队需要维护两套数据。

我的判断标准是项目数量：并行项目超过 15 个时，优先分批迁移。因为一次性切换出问题的概率会随项目数上升，而每次出问题都要占用关键路径资源，代价远高于并行期的维护成本。

5. 取舍五：预警灵敏度 vs 管理层注意力

预警设得敏感，漏报少但误报多，管理层会对预警脱敏；设得迟钝，误报少但预警没有提前量。

我建议的做法是分两级：高置信度信号直接进管理层周会，误报率控制在 20% 以内；中低置信度信号只推给项目经理，由他们决定是否升级。这样管理层的注意力只被高价值信号占用，同时低置信度信号不至于被完全丢弃。

八、总结：阶段进度管理的独特价值在于"让管理层做少而准的决定"

写到这里，我想把最核心的判断再强调一次。阶段进度落地方案的本质，不是给管理层更多数据，而是给管理层更少的决定点，但每个决定点都必须产生实际约束。

过去的做法是让管理层看更多报表、参加更多会议、追问更多细节，结果管理层的注意力被稀释在几十个项目、上千个任务上，真正需要他们判断的"这个门能不能开"反而被淹没。正确的做法是反过来的：把决定点收敛到 4 到 6 个阶段门、每周 25 分钟、只看待放行的门和高置信度预警。

另一个我认为很少被讲清楚的观点是：阶段进度管理成功的标志，是管理端的等待时间下降，而不是执行端的速度提升。在我参与的案例里，执行效率本身的改善通常只有 10% 到 15%，而决策等待时长和返工工时的改善可以达到 60% 以上。也就是说，进度失控的主要原因从来不在执行层。

如果你的团队现在正打算推动这件事，我的建议是按下面的顺序动手，不要跳步。

1. 本周：把当前所有项目的阶段划分写下来，检查是否按交付物而非部门划分。如果发现有部门化命名，先改命名。
2. 两周内：为每个阶段门写出不超过 6 条可验证的准出条件，明确放行决策人和决策时限。这一步不要动工具。
3. 一个月内：把准出条件配置成系统中的强制校验，先在 2 到 3 个项目上验证，观察配置成本和团队接受度。
4. 两个月内：启动管理层三个节拍，尤其先把周级节拍固定下来。同时上线三条偏差预警信号，开始记录误报率。
5. 三个月后：用里程碑按期达成率、阶段门一次通过率、决策等待时长、返工工时占比四个指标做一次完整复盘，据此调整阶段门数量与准出条件。

最后提醒一句：这套方案在第一个月一定会遇到"太麻烦"的反馈，这是正常的。判断它是否有效的关键，不是团队有没有抱怨，而是三个月后阶段末返工工时占比有没有下降。如果这个数字降了，说明准出条件的拦截真的起作用了，方案就站住了；如果没降，那说明配置的门只是形式，需要回到第一层重新检查交付物口径是不是可验证。工具只是承载，判断标准永远在业务结果上。