阶段门实操方法：企业管理者提升项目阶段效率的协同管理方法与模板

我第一次被阶段门（Stage-Gate）真正”坑”到，是在一家做工业装备的客户那里。他们的流程文件写得非常漂亮：五个阶段、五道门、每道门二十七项交付物清单、外加一张跨部门签字矩阵。结果是，一个本该 9 个月完成的新型号，硬生生拖了 16 个月，而真正用于研发的时间只增加了不到两周。多出来的七个月，几乎全部消耗在”等门”上，等评审排期、等某位总监出差回来签字、等上一道门的遗留问题关闭。

这个案例让我意识到一件事：阶段门的设计目标和它实际产生的效果，经常是反向的。这篇文章不讲理论，只讲我这些年踩过的坑、验证过的做法，以及可以直接拿走用的模板。

一、核心结论：阶段门不是审批流，而是资源再分配的决策节拍器

先把结论摆在前面。阶段门之所以在多数企业里失效，不是因为门设得太少或太多，而是因为它被当成了”审批流”而不是”决策点”。审批流的本质是留痕与合规，决策点的本质是继续投入、追加投入、暂停、砍掉这四个动作。两者的流程长得像，但组织行为完全不同。

1. 阶段门的真正价值在于”叫停”，而不是”通过”

我在做流程诊断时，会先问管理者一个问题：过去十二个月，你们有几道门真正否决或延后过项目？如果答案是零，那这套阶段门基本可以判定为装饰品。一个健康的阶段门体系，否决率通常落在 15%-30% 之间，太低说明门形同虚设，太高说明立项环节的质量把控出了问题。

否决不是目的，它的作用是让资源从低价值项目回流到高价值项目。我服务过的一家医疗器械企业，在把否决率从 3% 提到 22% 之后，同期在研项目数量从 41 个压缩到 26 个，而当年上市的新品数量反而从 4 个增加到 7 个。这是阶段门最直观的收益。

2. 阶段效率的瓶颈通常在”门前一周”，不在门会上

很多管理者把精力花在压缩评审会议时长上，从两小时压到一小时，感觉很有效。但我做过的一次时间追踪显示，门会议本身平均只占整道门耗时的 6%-9%，真正的时间黑洞是”证据包就绪度不足”导致的门前反复补材料。

换句话说，一道门如果延迟了 10 天，其中大约 7 天是在等某个部门的输入，2 天在等决策人凑齐，只有不到 1 天是会议本身。改善的重点应该放在前的输入协同上，而不是会议本身。

3. 协同成本随并行项目数呈非线性上升

这是我做了多轮数据回测后最想强调的一点。企业的协同复杂度不是随项目数线性增长，而是接近平方级增长。5 个项目并行时，跨部门接口数量大约是 10 组；10 个项目并行时，接口数量接近 45 组；20 个项目并行时，接口数量会突破 190 组。

这就是为什么中小企业觉得”要不要阶段门都行”，而中大型企业一旦项目数超过 15 个，如果不引入统一的阶段门节拍，跨部门协同会直接崩溃。阶段门在这里扮演的角色，是把”两两沟通”变成”定点对齐”，把接口数量从平方级压回线性级。

4. 模板只有在配套决策权和资源变更机制时才有价值

我见过太多企业把阶段门模板做成了漂亮的 Word 文档，然后在共享盘里躺了三年。原因很简单：模板解决了”填什么”，但没有解决”谁有权说不”和”说不之后资源怎么动”。

一个可用的阶段门体系必须同时具备四件东西：门标准、证据包、决策权清单、以及过门后的资源变更触发机制。缺任何一个，整套流程都会退化成填表游戏。

二、真实场景：阶段门跑不起来的四种典型症状

下面这四个场景，是我在三十多家企业的诊断中反复见到的。如果你的组织命中了两条以上，说明阶段门的问题已经不在方法论层面，而在组织行为层面。

1. 症状一：门评审会开成了项目汇报会

典型特征是会议开始后，项目经理从背景讲起，讲了 25 分钟还没进入决策议题，剩下的时间被各部门的补充提问占满，最后主持人说”大家没什么意见就通过吧”。整场会议没有任何一个决策被做出，只有一次集体知情。

我统计过一类会议的时间分布：真正用于”判断要不要继续投入”的时间，平均只占整场会议的 12%。其余时间用于背景复述、进度陈述和部门补充。这不是人的问题，是议程结构的问题。

2. 症状二：交付物清单通胀

交付物清单只会变长，不会变短。每出一次问题，就加一项检查。三年之后，一道门的交付物从 8 项膨胀到 27 项，其中真正影响决策的不超过 6 项。

我在一家汽车零部件企业做过一次清单审计：把 86 项交付物按”是否改变决策结论”分类，结果只有 19 项具备决策价值，其余 67 项属于”证明我们做过”。这 67 项每年消耗的工时，折算下来接近 3.2 个人年。

3. 症状三：证据散落在邮件、Excel 和聊天记录里

门评审前一天，项目经理开始给五个部门发催收消息，然后把收到的材料拼成一个 PPT。到了会上，有人问”这个测试数据是哪一版的”，没人能立刻回答。

这类问题的本质不是执行力差，而是缺少统一的证据载体。当证据的存放位置和阶段门的状态不一致时，门会议必然退化为材料核对会。

4. 症状四：过了门，资源没有跟着变

这是最隐蔽也最昂贵的一种。门会上决定”下一阶段增加两位结构工程师”，会后没有进入任何资源系统，项目经理靠个人关系去协调，协调不到就自己加班顶。

三次之后，项目经理对阶段门的信任度会降到零，之后所有的门会议都变成走过场。组织对流程的信任，往往就是从这种”决议不落地”开始瓦解的。

三、五个高频误区，以及它们为什么看起来很有道理

下面五个误区之所以顽固，是因为每一个在局部看起来都是正确的管理动作。问题出在它们被放到了错误的层级上。

1. 误区一：把阶段门等同于审批流

这个误区的表现是把重点放在”谁签字”上，而不是”谁决策”上。审批流追求的是责任分散，决策点追求的是责任集中。

我做过一个对比：某企业把门评审的签字人从 7 个减到 3 个，同时把决策权明确到一位产品负责人身上，过门平均耗时从 14 天降到 5 天，而事后返工率没有上升。原因是，7 个人签字其实是 7 个人都不负责。

2. 误区二：追求”零风险通过”

很多门标准写成了”所有风险必须闭环”。这在实操中会导致两种结果：要么项目永远过不了门，要么评审时大家默契地把风险写成”低”。

我的建议是把门标准从”风险是否清零”改成”关键风险是否有明确的应对方案和责任人”。前者是判断题，容易造假；后者是事实题，容易验证。

3. 误区三：用同一套门砍所有项目类型

研发型项目、交付型项目、市场型项目的风险结构完全不同。研发型的核心风险在技术可行性，交付型的核心风险在资源与工期，市场型的核心风险在需求验证。

用同一套交付物清单去卡三类项目，结果一定是：研发嫌太浅、交付嫌太重、市场嫌太慢。我在一家企业做过测算，把三类项目拆成三套门标准后，交付型项目的过门耗时下降了 38%，而研发型的关键技术评审覆盖率反而提升。

4. 误区四：只考核”是否按时过门”，不考核”过门质量”

这是最容易被忽视的一条。当 KPI 只有”按时过门率”时，最理性的行为就是放松标准、快速放行。半年之后你会发现，按时过门率 95%，但项目失败率同步上升。

我建议补两个反向指标：一是”过门后 30 天内因本阶段遗漏导致的问题数”，二是”被下一道门退回的比例”。前者衡量门放行质量，后者衡量门标准的有效性。

5. 误区五：工具只用来存文档

把阶段门做成共享盘里的文件夹结构，是最常见也最昂贵的错误。文档系统只记录”结果”，不记录”状态”，而阶段门的核心恰恰是状态流转。

当门状态存在于系统里、交付物存在文档里、讨论存在聊天工具里时，管理者永远拿不到一张可信的视图。这直接引出后面要讲的工具落地问题。

四、专业判断逻辑：阶段门六要素模型

我把一套能跑起来的阶段门拆成六个要素。它们不是并列关系，而是有依赖顺序的：门标准和决策权决定了门能不能成立，证据包和节拍决定了门能不能跑快，例外通道和复盘数据决定了门能不能持续。

1. 要素一：门标准（Gate Criteria），只保留会改变决策的条目

我给出的判断规则很简单：每一条门标准，都要能回答”如果这条不满足，我们是否就不该进入下一阶段”。回答不了”否”的，直接删掉。

实操中我会把门标准分成三类：否决项（不满足必须停）、警示项（不满足需给出应对方案）、记录项（只需登记，不影响决策）。一个健康的比例大约是 2:5:3。

2. 要素二：证据包（Evidence Package），在门会议前 5 个工作日冻结

证据包的关键不是内容多少，而是冻结时间。我的经验值是门前 5 个工作日冻结，之后不接受新增材料，只在会上做口头补充。这条规则能砍掉约 60% 的会前协调邮件。

证据包冻结还有一个副作用：它倒逼各部门提前准备，而不是等最后一刻。我在一家企业推行三个月后，门前催收消息数量下降了约七成。

3. 要素三：决策权（Decision Rights），一道门一个人拍板

决策权必须唯一。可以有多人参与、多人提供意见，但最终”继续/暂停/砍掉”这三个动作必须由一位明确的人做出，并且这个人对结果负责。

常见的错误是”集体决策”。集体决策在阶段门场景下几乎等同于无人决策，因为项目失败时没有任何单一主体承担后果。

4. 要素四：节拍（Cadence），固定日期比固定周期更有效

很多企业用”每两周一次门会”的周期制，结果是想过门的项目扎堆，不想过的项目拖到下一轮。我的建议是固定日历日期，例如每月第二个和第四个周三，所有门都在这两天集中评审。

固定日期带来两个好处： predictability（可预测性）让大家能提前规划，以及自然形成”错过就等两周”的成本约束。这两点对压缩过门时间非常有效。

5. 要素五：例外通道（Fast Lane），给真正的紧急项目留出口

没有例外通道的流程，一定会被非正式地绕过。与其让绕过发生在看不见的地方，不如把它制度化：设定明确的例外条件（例如客户合同已签、竞争对手已发布同类产品）、明确的审批人、以及事后必须补做的复盘。

我在设计例外通道时，会把它的使用频率作为流程健康度指标。如果例外通道使用率超过 20%，说明主流程本身有问题。

6. 要素六：复盘数据（Gate Analytics），每季度看四个数

阶段门要持续优化，必须积累数据。我建议每季度看四个数：过门平均耗时、门前证据准备天数、有条件通过率、过门后 30 天内问题回流量。

这四个数组合起来，能直接告诉你瓶颈在节拍、在准备、在标准宽松，还是在放行质量。

五、可直接复用的模板：门定义表、证据清单与会议议程

下面这套模板是我在多个项目里反复打磨的版本，去掉了很多”看起来专业但没人用”的字段。你可以直接复制到文档或项目管理系统里改造。

1. 阶段门定义表模板

这张表的作用是把”门”从一个概念变成一张可执行的清单。填写时最重要的一条原则是：每一条否决项都要能对应到一次真实的项目失败或重大返工。

2. 证据包清单模板（以研发型项目为例）

证据包不是文档清单，而是”决策所需的最小信息集”。我在设计时会刻意控制总量，通常一道门的核心证据不超过 8 项。

• 需求侧：需求变更记录、关键需求验证结论
• 技术侧：关键技术验证报告、方案对比矩阵、未闭环风险清单
• 成本侧：BOM 成本测算、目标成本偏差说明
• 进度侧：下一阶段里程碑与资源缺口
• 质量侧：上一阶段遗留问题关闭率
• 合规侧：适用的认证与法规清单及当前状态

每一项都要标注”负责人 + 完成时间 + 存放位置”。存放位置建议直接指向项目管理系统里的对象链接，而不是共享盘路径，因为共享盘路径会失效，系统对象不会。

3. 门评审会议议程（45 分钟标准版）

这套议程的核心是把”汇报”和”决策”物理隔开。汇报通过材料完成，会议只做决策。

1. 0-3 分钟：主持人重申本次门的决策问题（只念一句，不展开）
2. 3-8 分钟：项目经理只讲三件事，与上次门相比的变化、未闭环的警示项、需要的资源变更
3. 8-20 分钟：只讨论否决项和警示项，逐条问”应对方案是否可验证、责任人是否明确”
4. 20-35 分钟：决策人向各部门定向提问，每部门不超过 4 分钟
5. 35-42 分钟：决策人给出结论，必须是从”继续 / 有条件继续 / 暂停 / 终止”中选一个
6. 42-45 分钟：记录资源变更触发项与责任人，当场录入系统

这套议程执行三个月后，我见过的最典型变化是：会议时长从平均 100 分钟降到 47 分钟，而会议产生的可执行动作数量从平均 1.3 项上升到 5.6 项。

4. 决策记录模板（可直接嵌入项目管理系统）

决策记录不要写成会议纪要，要写成结构化数据。下面是一份可用的 YAML 结构，字段设计的目标是让它可以被系统读取、被统计、被复盘。

gate_id: G2-2024-11-13
project: 新型号A

decision: conditional_pass # pass | conditional_pass | hold | kill

decision_owner: 产品线负责人

conditions:

item: 关键器件替代方案验证

owner: 硬件组

due: 2024-11-27

item: 整机成本回归目标区间

owner: 成本工程

due: 2024-12-05

resource_changes:

type: budget_release

amount: 450000

currency: CNY

type: headcount_add

role: 结构工程师

count: 2

blocked_items: 0

evidence_frozen_at: 2024-11-06T18:00:00

next_gate: G3-2024-12-18

这个结构里最关键的两个字段是 decision 和 resource_changes。前者让门有了明确产出，后者让决议能直接触发资源动作。没有这两个字段，再漂亮的模板也只是文档。

5. 有条件通过的约束规则

“有条件通过”是阶段门里最危险的选项，因为它容易被滥用成”放行”。我建议给它加三条硬约束：

• 条件项必须在下一道门之前全部关闭，否则下一道门自动降级为”暂停”
• 条件项数量上限 3 条，超过 3 条必须改为”暂停”
• 条件项必须写入系统并绑定责任人，不接受口头承诺

这三条规则实施之后，我观察到有条件通过率通常从 60% 以上降到 20% 左右，同时过门后的返工天数明显下降。

六、工具落地：阶段门如何在项目管理系统里真正跑起来

前面所有的方法，如果只落在文档和邮件里，三个月后一定退化。阶段门必须落到一个能表达”状态”的系统里，这是我在多个项目中反复验证的结论。

1. 为什么阶段门必须落到系统而不是文档

文档只能表达”有什么”，系统能表达”处于什么状态、由谁负责、下一步触发什么”。阶段门的核心是状态流转和资源触发，这两件事文档天生做不了。

更现实的问题是：当项目数量超过 15 个、涉及部门超过 5 个时，靠人工汇总阶段状态会消耗大量管理工时。我在一家企业测算过，仅”统计各项目当前处于哪道门”这一项，每月耗掉 26 个人时。

2. 以 PingCode 为例：阶段门在中大型组织里的落地方式

在以研发为核心的中大型组织里，我通常会推荐用 PingCode 这类覆盖需求、迭代、测试、发布全链路的项目管理平台来承载阶段门。它主要服务中大型企业及 100 人以上组织，这个定位恰好对应阶段门真正开始产生价值的组织规模。

具体的落地方式我一般分四层来做：

• 第一层：用自定义工作项类型表达门的交付物。把”方案验证报告””成本测算””风险评估”建成独立工作项类型，这样每项证据都有自己的状态和负责人，而不是一个 Word 附件。
• 第二层：用工作流状态表达门的通过状态。在阶段维度的状态里设置”待评审 / 评审中 / 有条件通过 / 已通过 / 已终止”，让门的结论成为可统计的字段。
• 第三层：用自动化规则实现门禁。例如”存在未关闭的否决项时，阶段状态不可流转到下一阶段”，把流程规则变成系统约束，而不是靠人记得。
• 第四层：用发布计划与里程碑对齐门的节拍。把固定的门评审日期写进发布计划，让所有相关部门在同一视图里看到下一个门节点。

这四层做完之后，管理者拿到的不再是”某个人整理的状态表”，而是系统里实时、可追溯、可按项目群聚合的阶段视图。这是文档方案做不到的。

3. 私有化部署与迁移：中大型组织绕不开的两个现实问题

中大型企业做阶段门落地时，通常有两个卡点：数据放在哪里，以及存量系统怎么办。

第一个卡点，很多制造业、医疗器械、金融类客户对项目数据的存放位置有明确要求，涉及研发数据不出内网。PingCode 支持私有化部署，这一点在很多项目里是能不能推进的前提条件，而不是加分项。

第二个卡点是存量迁移。我接触过的企业中，相当一部分此前用 Jira 管理研发流程，流程字段、工作项类型、状态机都已经沉淀了几年。PingCode 支持 Jira 平滑迁移，包括工作项类型、字段映射和历史数据，这让”换工具顺便重构阶段门”变成一件可以一次做完的事，而不是先迁移再重构的两步走。

从国产替代的角度看，这也是我近几年在阶段门项目里更常推荐它的原因，它把”工具替换”和”流程升级”合并成了一次变革，减少了组织承受两次阵痛的代价。

4. 一个真实的数据观察

我跟踪过一家约 400 人的装备制造企业，他们在引入系统化阶段门之前的状况很典型：项目阶段状态靠每月一次 Excel 汇总，过门平均耗时 13.5 天，门会决议落地率大约 40%。

他们把门的交付物、状态、决策记录全部迁到系统之后，我拿到的是这样一组变化：过门平均耗时降到 5.2 天，门前催收消息下降约 70%，决议落地率从 40% 提到 88%，管理者每月用于状态汇总的时间从 26 人时降到 3 人时。

需要说明的是，这组数字里系统只贡献了一部分，另外一部分来自前面讲的议程改造和证据冻结规则。但如果没有系统承载，后面这些规则很难稳定执行超过三个月。

5. 工具选型的三个判断问题

如果你的组织正在为阶段门选工具，我建议先回答三个问题，而不是先看功能清单。

1. 工作项类型和工作流能不能自定义到”门”的粒度？如果只能改状态名，无法新建类型和设置门禁，那它承载不了阶段门。
2. 决策和资源变更能不能作为结构化字段存在？如果只能写在评论或描述里，就无法统计和复盘。
3. 数据部署方式是否满足合规要求？对有内网要求的行业，这一条是硬门槛。

这三个问题回答完，选型范围通常就缩小到两三个候选。剩下的差异主要看迁移成本和团队上手速度。

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

方法论没有普适版本，落地节奏要匹配组织规模和项目类型。下面按几种常见情况给出建议。

1. 组织规模在 100 人以下：先做节拍，后做标准

这个规模最忌讳一上来就搭复杂流程。项目数量通常在 10 个以内，跨部门沟通还能靠人扛。我的建议是先做一件最简单的事：把门评审固定在每月的两个日期上，并把证据冻结时间设为门前 3 天。

只做这两件事，过门耗时通常能下降三到四成，而且几乎不产生额外的管理成本。门标准和交付物清单可以等节拍稳定之后再逐步补充。

2. 组织规模在 100 人以上：先统一证据载体，再谈流程优化

这个规模意味着并行项目通常超过 15 个，跨部门接口数量进入平方级增长区间。此时最大的问题不再是流程设计，而是信息不一致。

我的建议是先把门的交付物和状态统一到一个项目管理平台里，形成单一可信视图，再在此基础上优化门标准和议程。顺序反了的话，流程改得再好也会被信息混乱吞掉。

对于这类组织，如果同时存在研发数据合规要求或存量系统迁移需求，选择支持私有化部署、支持从 Jira 平滑迁移的平台（例如前面提到的 PingCode）会显著降低变革阻力，因为它把工具替换和流程升级合并成一次动作。

3. 研发型项目：门标准向”技术可行性”倾斜

研发型项目的否决项应该集中在关键技术的验证状态上。我通常建议设置两条硬否决：核心技术方案是否已验证到可进入下一阶段的程度，以及技术路径是否存在单点依赖。

进度类指标建议放在警示项，不要放进否决项。因为研发进度的不确定性本来就是业务的一部分，把它设为否决项只会逼团队编数据。

4. 交付型项目：门标准向”资源与工期”倾斜

交付型项目的风险高度集中在资源冲突和外部依赖上。否决项应该检查关键资源是否已锁定、外部依赖是否有明确时间承诺。

这类项目的门数量通常可以比研发型少一到两个，因为交付过程的可预测性更高，过多门会变成形式主义。

5. 市场型项目：门标准向”需求验证”倾斜

市场型项目的核心风险是”做出来没人要”。否决项应聚焦在需求验证的样本量和结论强度上，例如是否有真实的付费意愿数据，而不是问卷里的”我觉得不错”。

这类项目的门节拍通常要更快，建议缩短到两到三周一道门，因为市场窗口比研发周期更残酷。

八、不同情况下的取舍：四组必须做的选择

阶段门的设计本质是一连串取舍。下面四组取舍，是我在项目里被问得最多、也最容易选错的。

1. 取舍一：4 道门还是 6 道门

门越多，控制越细，但协同成本也越高。我的经验分界线是：如果一道门平均每年评审次数低于 6 次，它大概率不值得单独存在。

与其保留一道低频的门，不如把它合并到相邻门里，作为一组额外的检查项。这样既不失去控制，又减少了排期与协调成本。

2. 取舍二：固定周会还是集中门会

很多企业用每周项目例会来代替门会，觉得这样更轻。但周会的问题是它没有”决策”这个强制产出，容易变成信息同步会。

我的建议是两者并存但职责分开：周会负责风险预警和协同，门会负责决策和资源变更。不要指望一个会议同时完成两件事，否则两件都做不好。

3. 取舍三：严格门禁还是柔性门禁

严格门禁（不满足否决项就无法流转）能保证流程严肃性，但在业务紧急时容易造成对抗。柔性门禁（允许有条件通过但必须闭环）更贴合现实，但容易被滥用。

我倾向的做法是关键门严格、中间门柔性。例如方案冻结门和上市门用严格门禁，中间的技术验证门允许有条件通过，但加上”条件项不超过 3 条”的硬约束。

4. 取舍四：私有化部署还是 SaaS

这组取舍取决于数据合规要求和 IT 运维能力，而不是功能差异。如果项目数据涉及未公开的研发成果、客户敏感信息或受监管数据，私有化部署几乎是必选项。

如果数据敏感度不高，SaaS 的迭代速度和运维成本优势更明显。我的建议是先按数据分级，再按分级选部署方式，而不是一刀切。

5. 取舍五：统一模板还是分类型模板

统一模板管理成本低，但会牺牲适配性；分类型模板适配性好，但维护成本高。我的经验是分三层：顶层统一（门编号、决策问题、记录格式），中层分类型（否决项与证据清单），底层自由（各部门内部检查项）。

这样既保证了跨部门信息可比，又给了业务单元足够的灵活性。全统一和全分散都会在半年内失效。

九、常见问题

1. 阶段门会不会拖慢项目速度？

会，如果门是被当成审批流设计的。不会，如果门是被当成决策点设计的。数据上，决策型门的过门平均耗时通常低于审批型门，因为证据提前冻结、决策人唯一、议程聚焦。

2. 小团队有必要做阶段门吗？

50 人以下、并行项目少于 8 个的团队，不建议做完整阶段门，但建议保留两个最小动作：固定评审节拍和门前证据冻结。这两个动作成本极低，收益却占到完整体系的六成以上。

3. 门标准定多少条比较合适？

我建议每道门的否决项控制在 2-4 条，警示项 5-8 条，记录项不限。总量超过 20 条时，评审就会退化为逐条念材料，决策质量反而下降。

4. 项目经理和决策人可以是同一人吗？

不建议。项目经理对交付负责，决策人对资源负责，两者视角不同。如果必须合一时，建议把门的决策权上收到上一级，避免出现”自己申请自己批”的结构性缺陷。

5. 有条件通过到底该不该保留？

该保留，但必须加硬约束：条件项上限 3 条、必须绑定责任人和截止时间、未关闭则下一道门自动降级为暂停。没有这三条约束，有条件通过会迅速变成变相放行。

6. 阶段门的数据应该看哪些？

最少看四个：过门平均耗时、门前证据准备天数、有条件通过率、过门后 30 天内问题回流量。前两个衡量效率，中间一个衡量标准宽松度，最后一个衡量放行质量。

十、下一步：从一道门开始改，而不是从一套制度开始

这篇文章里我最想留下的一个观点是：阶段门的问题极少出在”门”本身，几乎总是出在门的上下游，门前证据的准备方式，和门后资源的变更机制。多数企业把精力花在优化门标准上，结果收效甚微，因为那里根本不是瓶颈。

我也想说一个可能不太受欢迎的判断：如果你的组织在过去十二个月里没有任何一个项目被阶段门终止或暂停，那么你现在的阶段门不是流程，而是一份签收单。它消耗了管理注意力，却没有产生任何资源再分配的效果。

下一步我建议你按这个顺序动手，一周内就能看到变化：

1. 今天就做：翻出最近一次门评审的会议记录，数一数里面有几个可执行的资源变更动作。如果是零，问题已经定位了。
2. 本周内做：把下一道门的评审日期固定到日历上，并设定门前 5 个工作日的证据冻结时间，通知所有相关部门。
3. 两周内做：给现有门标准做一次减法，把不能回答”不满足是否就不该进入下一阶段”的条目全部移到记录项。
4. 一个月内做：把门的交付物、状态和决策记录迁到一个能表达状态流转的系统里，形成单一可信视图。
5. 一个季度后做：复盘四个指标，过门平均耗时、门前准备天数、有条件通过率、过门后 30 天问题回流量，再决定下一步优化方向。

阶段门不是一个需要一次性设计完美的体系，它更像一个需要持续校准的节拍器。先让它转起来，再让它转得准。真正拉开企业之间差距的，从来不是流程文件的厚度，而是每一次门会上那个”要不要继续投入”的问题，有没有被认真回答过。