项目阶段阶段门教程：企业管理者流程优化，避坑指南

我见过最贵的一次阶段门评审，发生在某家做工业检测设备的公司。当时项目已经投到第 4 个门，累计花费 1400 万，决策层在 90 分钟的会上给出结论是”有条件通过”，条件是三个月内完成某项关键认证。五个月后项目被叫停，累计投入 2100 万。复盘时我们翻回第 2 个门的门禁清单，上面写着”关键技术可行性已验证”，评审意见栏填的是”基本符合”。就这四个字，值 700 万。

这不是个例。过去几年我以外部流程顾问的身份参与过 23 个企业的阶段门（Stage-Gate）体系改造，涉及的行业包括工业设备、医疗器械、企业软件、汽车零部件和消费电子。我把这 23 个项目的过程记录和数据做过一次横向整理，发现一个反常识的规律：阶段门失效的企业，往往不是门太少，而是门太多、判决太软、以及没有人因为”放行”而承担后果。

这篇内容写给正在被”流程僵化”和”项目失控”两头夹击的企业管理者。我会先给结论，再拆场景，然后讲清楚我判断一套阶段门是否有效的逻辑，最后落到工具和落地路线。里面所有数据都来自我参与项目的脱敏统计或明确的样本推演，我会标注口径。

一、核心结论：阶段门的本质是投资决策点，不是进度检查点

绝大多数企业第一次做阶段门，都会把它做成”项目做到某个节点，找领导汇报一下”。这种理解从根上就错了。阶段门的原始设计目的只有一个：在不确定性最高的地方，用最小的成本决定是否继续投钱。

如果你把门当成进度检查，你会关心”做完了多少”；如果你把门当成投资决策，你只会关心三件事：已经花的钱换来了什么可验证的证据、继续投下去的最大风险是什么、以及下一笔钱的兑现条件是什么。这两个视角带来的门禁清单、参会人、会议时长、甚至会议室大小都完全不同。

1. 一个有效的门必须同时具备三个部件

缺任何一个，门就退化成会议。我通常用下面这三件套来体检客户的阶段门：

• 入口准则（Entry Criteria）：什么样的交付物齐了，这个门才有资格开。注意是”有资格开”，不是”能通过”。
• 证据包（Evidence Package）：不是 PPT，而是能被第三方复核的材料。测试报告、样机数据、客户签字、成本测算表、供应商报价单。
• 出口决策（Exit Decision）：会议结束必须落一个带资源承诺和时间戳的结论，而不是”继续推进”。

我见过大量企业的阶段门只有第二件。证据包做得漂亮，会议开得热闹，散会时纪要写”与会领导一致同意项目按计划推进”。这种门的风险拦截力约等于零。

2. 门只有四种判决，缺任何一种都会失效

我在给客户做培训时反复强调：门的判决必须是四选一，而且必须当场选。

1. Go（放行）：按原计划进入下一阶段，资源照批。
2. Conditional Go（有条件放行）：允许进入下一阶段，但必须限定范围、限定资源、限定消除条件的时间点。这是最容易被滥用的一种。
3. Hold（暂停）：阶段不推进，团队保留最小规模，等待某个前置条件成熟。很多人把 Hold 当成”软性 Kill”，其实它是最被低估的选项。
4. Kill（终止）：项目停止，人和预算释放。没有 Kill 的门不是门，是仪式。

判断一个企业的阶段门是否真的在运转，我有个很粗暴的指标：看它过去 12 个月所有过门决议里，Kill 和 Hold 加起来占多少。如果低于 5%，基本可以断定这套门是装饰性的。

下面这组数据来自我参与的 23 个改造项目中 14 个有完整前后对比记录的项目，样本推演口径为”每家取改造前后各 4 个季度的过门决议记录”：

3. 门密度的判断依据不是项目重要性，而是”不可逆成本”

很多管理者的直觉是：重要的项目多设几道门，不重要的少设。这个直觉只对了一半。真正的判断依据是，过了这个点之后，已经投入的成本有多难撤回。

我通常用一个简单的三档划分：不可逆成本占比低于 15% 的阶段，不建议设门；15% 到 50% 之间，设轻量门；超过 50% 的阶段（比如开模、量产备料、签署长期采购协议），必须设重门。按这个标准，一个典型硬件产品从概念到量产，真正值得设的门通常只有 5 道，而不是很多企业做的 9 道甚至 11 道。

二、真实场景：阶段门是怎么一步步变成”走过场”的

把阶段门做废，不需要谁犯错。它往往是在几个月里，被一连串看起来很合理的”临时调整”慢慢侵蚀掉的。下面三个场景，是我在客户现场见得最多的。

1. 场景一：门慢慢变成了汇报会

最初的设定是”决策会”。第一次开会，项目经理讲了 40 分钟项目进展，决策者问了几个细节，然后说”做得不错，继续”。第二次开会，还是这样。到第四次，会议通知的标题已经变成了”XX 项目阶段汇报”。

这个变化的标志性信号是：会议材料从”证据包”变成了”进展汇报 PPT”，参会人从”能调资源的人”变成了”关心这个项目的人”。一旦变成后者，会就没办法做决策了，因为台下没有一个人有权说”停”。

2. 场景二：门禁清单写成了一组形容词

我收集过 60 多份企业真实的门禁清单，其中出现频率最高的表述是这样的：

• 市场需求已充分验证
• 技术方案基本可行
• 成本控制在合理范围
• 风险已识别并可控
• 团队能力满足要求

“充分””基本””合理””可控””满足”，这五个词是阶段门最大的敌人。因为它们无法被证伪，所以评审时只能靠感觉。而感觉这个东西，在项目还热乎的时候，永远偏向乐观。

3. 场景三：所有项目走同一套门

一个 300 人的企业，产品线既有需要开模的硬件，也有两周就能上线的内部工具，还有纯软件的功能迭代。如果它们都走同一套五阶段门，结果是硬件项目觉得门太松，软件项目觉得门太重，最后两边都开始绕过流程。

我见过最极端的案例，是某企业的门禁清单固定在 47 个检查项。他们的一位研发负责人告诉我，团队为了准备一次门评审，平均要花 6 到 8 个人天整理材料。当过门成本高于项目本身的风险时，流程一定会被绕过。

三、七个常见误区，我自己踩过其中五个

接下来这部分，我尽量说得直白一些。下面七条里，前三条是我早期做顾问时自己也主张过的做法，后来被数据打脸才改过来。

1. 误区一：门越多越严谨

我 2018 年给一家消费电子公司设计过一套 9 门体系，当时觉得非常完整。执行一年后复盘，发现从第 5 个门开始，评审通过率是 100%，平均会议时长 22 分钟。也就是说，后 5 个门基本没有产生任何决策价值，只产生了行政成本。

门不是越多越好。每一道门都应该能回答一个问题：”如果这里判断错了，后面会损失多少钱？”如果答案是”没多少”，这道门就应该删掉。

2. 误区二：用”完成度百分比”当门禁

“技术方案完成 80%”，这句话没有任何信息量。80% 是哪个 80%？是文档写完了 80%，还是风险验证了 80%？

更麻烦的是，百分比会诱导团队去凑数。我见过一个团队为了把”完成度”从 60% 提到 85%，两周内补了 30 页文档，但关键的可靠性测试一次都没做。门顺利通过，两个月后测试暴雷。

正确的做法是使用证据等级。我通常用五级：L1 假设提出、L2 纸面分析、L3 实验室验证、L4 实际环境验证、L5 客户环境验证。门禁写”关键可靠性需达到 L3 及以上”，比写”完成 80%”清晰一个数量级。

3. 误区三：只加门，不加资源

这是最隐蔽的一个坑。企业设了新门，但没有为”门后资源兑现”设计任何机制。结果是项目过了门，人还是那几个人，钱还是那笔钱，只是多了一堆评审材料要写。

我给客户的建议是：门的决议里必须包含一条资源承诺，并且这条承诺要有兑现时间和责任人。如果某次门决议写了”放行”，但没写”下阶段追加 3 名测试工程师，6 月 15 日前到位”，那这个决议就是无效决议。

4. 误区四：考核”按期过门率”

这个指标听起来很合理，实际上毒性极强。一旦”按期过门率”进了 KPI，项目经理的最优策略就变成了”确保按时到会、确保材料齐全、确保结论是 Go”。至于技术风险有没有真的验证，那是次要的。

更好的替代指标有三个：门后 30 天内出现重大返工的项目比例、决议条件的按期关闭率、Kill 项目资源的再利用率。这三个指标都在衡量”门的判断质量”，而不是”团队配合程度”。

5. 误区五：Kill 了一次，就再也没人敢 Kill

我见过一个事业部，两年前砍掉过一个由副总力推的项目。之后整整两年，所有项目一律放行。我私下问一位总监为什么，他说：”谁还敢提 Kill 啊，那不是打脸吗。”

Kill 变成政治行为，门就死了。解法不是讲道理，而是把 Kill 制度化、去人格化。具体做法包括：把 Kill 写进门禁清单的默认选项之一；规定 Kill 决议不做责任追究；以及定期公布”被 Kill 项目释放的资源被用到了哪里”，让大家看到 Kill 是一种资源再配置而不是惩罚。

6. 误区六：把阶段门和敏捷迭代对立起来

这是最常见的认知冲突。研发团队说”我们要敏捷”，管理层说”我们要阶段门”，两边吵得不可开交。实际上这两者管的是不同粒度的事。

敏捷管的是”怎么把一件确定要做的事做好”，阶段门管的是”这件事还应不应该继续做”。一个是执行节奏，一个是投资节奏，完全可以共存。业界的通行做法是”双轨”：阶段门按季度或按重大不可逆投入点设置，通常一季度不超过一次；迭代按周或双周运转，不设外部评审。

7. 误区七：用审批流工具做阶段门

很多企业把阶段门直接搭在 OA 审批流里：提交材料→部门经理审批→总监审批→副总审批。形式上看是有门，实际上完全跑偏。

审批流的设计目标是”合规留痕”，阶段门的设计目标是”证据驱动的取舍决策”。前者关心的是”谁签了字”，后者关心的是”证据够不够、风险有多大、要不要继续投”。这两件事对工具的要求完全不同：阶段门需要的是证据关联、决策历史对比、门禁清单的可视化、以及跨项目的资源视图，这些在审批流里做不出来。

四、专业判断逻辑：一套我实际在用的阶段门设计法

讲完坑，讲讲方法。下面这套设计法是我在最近 8 个项目里反复迭代出来的，不敢说普适，但至少是可执行的。核心思路是：先分级，再设门；先定判决，再定标准；先把决策者的时间锁住，再谈材料格式。

1. 第一步：按不可逆成本和不确定性给项目分级

我通常用二维矩阵分三级，而不是按项目金额单维度分。因为金额大但技术路径成熟的项目，和金额中等但技术路径全新的项目，风险结构完全不同。

这张表里最重要的不是数字，而是“C 类项目可以不走正式阶段门”这件事被明确写下来。我见过太多企业，制度上说了分级，实操中所有项目都被要求走全套流程，最后分级形同虚设。

2. 第二步：把门禁准则写成”可验证、非黑即白”的句子

写门禁准则有个简单的测试方法：把这条准则给一个没参与项目的人看，他能不能独立判断”是”或”否”？如果不能，这条准则需要重写。

我把常见的模糊表述和改写版本列在下面，供对照：

这个改写动作看起来琐碎，但它带来的效果非常直接：评审会从”讨论该不该过”变成”核对证据是否达标”。前者可以吵三小时，后者二十分钟就能结束。

3. 第三步：决策包提前 48 小时送达，会议只做决策

我把这条称为”48 小时规则”。决策包（含证据清单、风险登记册、成本测算、上次门决议的条件关闭情况）必须在会议前 48 小时送到每位决策者手上，并且要求会前回执”已阅”。

会议本身的时间分配我建议是：10 分钟澄清问题，35 分钟讨论分歧点，15 分钟做决策并记录条件。取消所有”项目介绍”环节。如果决策者到会才开始了解项目，这场会就不该开。

4. 第四步：决议必须包含资源、条件、时间戳三要素

我设计了一个决议模板，强制包含以下字段。用结构化的方式写下来，工具里就能直接配置成必填项：

门决议记录模版（YAML 示意）
gate_id: G3-2024Q2

project: 工业检测仪 A3

decision: conditional_go # go / conditional_go / hold / kill

scope_limit: 仅进入样机试制，不进入量产备料

resource_commitment:

追加测试工程师 2 名，到位时间 2024-06-15

追加样机预算 45 万元，拨付时间 2024-06-20

conditions: # 有条件放行时必填，最多 3 条

id: C1

desc: 完成 EMC 预测试并取得报告

owner: 张工

close_by: 2024-07-31

id: C2

desc: 完成第二供应商比价并锁定

owner: 李工

close_by: 2024-07-15

next_gate: G4

next_gate_date: 2024-09-10

gatekeeper: 王总（事业部） / 陈总（财务） / 刘工（技术）

模板的价值在于它是可统计的。条件关闭率、资源兑现率、下一次门的准时率，这些数据只有在结构化记录之后才能算出来。用 Word 纪要开会，你永远得不到这些指标。

5. 第五步：门与门之间设”预警线”

只设门不设预警线，结果就是风险在门与门之间悄悄积累，到门口才爆发。我的做法是在每个门中间设一个预警线，只监控 3 到 4 个关键指标，一旦越线就触发”提前门”。

常见的关键指标包括：关键技术验证进度偏差超过 20%、成本测算突破目标值 10%、核心人员流失、关键供应商变更、以及累计投入超出该阶段预算 15%。这五类信号中命中任意两类，就应该提前召集决策者，而不是硬撑到下一个正式门。

五、案例与数据观察：把阶段门真正落到项目管理平台里

流程设计完，接下来是工具。这一段我用一个真实项目来说明，为什么阶段门最终一定要落到项目管理平台上，以及具体怎么落。

1. 案例背景：一家 800 人的软硬结合型企业

这家客户做智能装备，员工约 800 人，研发人员 420 人，产品线三条，同时并行的研发项目常年维持在 30 到 40 个。他们原来的阶段门完全靠邮件加 Excel：项目组发材料给 PMO，PMO 汇总成 PPT，开会评审，会后 PMO 手写纪要，再邮件通知。

问题是可预见的：材料版本混乱、条件关闭没人跟、资源承诺无法追溯、跨项目的资源冲突看不出来。他们 PMO 只有 3 个人，却要维护 30 多个项目的过门记录，常年处于救火状态。

2. 我们做了什么：把五道门完整搬进平台

这个客户最终选择的是 PingCode。选型过程我不展开，只说与他们需求匹配度最高的几点：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，而且支持 Jira 平滑迁移。他们当时正在做 Jira 的国产替代评估，迁移成本是核心考量之一。

具体落地动作分四块，我按执行顺序列出来：

1. 把阶段门建成里程碑层级。每个项目下固定挂 5 个阶段里程碑（G1 概念、G2 立项、G3 样机、G4 试产、G5 量产），里程碑的完成条件绑定自定义字段，不满足条件无法标记完成。
2. 把门禁清单做成必填检查项。每个门挂 5 到 8 个检查项，采用”是/否 + 证据附件”的形式。检查项未全部处理的项目，在仪表盘上会标红，且不允许进入下一阶段的工作项。
3. 把决议结构化。用自定义字段记录决议类型、条件条目、条件责任人、条件关闭时间、资源承诺内容和兑现时间。这部分是整个改造里最关键的，因为它把”会议纪要”变成了”可查询的数据”。
4. 把门决策包自动化生成。配置自动化规则：门会前 96 小时自动汇总该项目当前的门禁完成情况、未关闭条件、风险清单和预算消耗，生成决策包并推送给决策者；会前 48 小时未回执的自动提醒。

这套配置他们内部花了大约 26 人天完成，加上流程设计和模板打磨，整体投入在 76 人天左右，由 PMO 加 IT 各出一部分人力。

3. 数据观察：改造后四个季度的变化

下面这组数据是他们 PMO 提供的改造前后各四个季度的对比，口径统一为”三条产品线全部研发项目”，我把关键项整理成了表格和图表。

需要说明的是，延期率的下降有相当一部分来自 Hold/Kill 的上升，而不是执行效率的突然提升。因为一部分本来注定延期甚至失败的项目，在早期就被叫停了，不再计入延期统计。这个因果关系如果不讲清楚，数据很容易被误读成”流程一上，效率翻倍”。

4. 为什么这类改造更适合放在 PingCode 这类平台上

我把判断标准总结成四条，供同类企业参考：

• 需要承载”跨阶段的结构化数据”。阶段门本质上是一组带条件的决策记录，普通任务看板存不下这种结构。PingCode 的里程碑加自定义字段加自动化规则的组合，能把这部分表达出来。
• 需要有跨项目的资源视图。当并行项目超过 20 个时，决策者最需要的其实是”我这个季度要放行多少项目、会消耗多少测试资源”这类视图，而不是单个项目的进度条。
• 部署与合规要求。制造业和医疗器械类客户普遍有数据不出内网的要求，PingCode 支持私有化部署，这一点在选型阶段往往是硬门槛。
• 迁移成本。已经在用 Jira 的团队如果重新做一次流程迁移，成本很高。PingCode 支持 Jira 平滑迁移，对于正在做国产替代评估的中大型组织，这是务实的考量。

需要提醒的是，工具能解决的是”信息流转和可追溯”，解决不了”决策者不敢 Kill”。我见过不少企业把工具配得很漂亮，但决议依然全是 Go。工具是放大器，不是发动机。这一点在选型和上线阶段一定要跟管理层讲透。

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

阶段门没有通用方案。下面我按组织规模和行业特征给出具体建议，你可以直接对照自己的情况取用。

1. 100 人以下的团队：不要建正式阶段门

我的建议很直接：100 人以下的组织，通常并行项目不超过 10 个，创始人或核心管理层对每个项目的状态基本有直接感知。这个阶段引入正式阶段门，管理成本会大于风险控制收益。

替代方案是做”重大投入前的三人决策会”：在开模、签长约、招关键岗位、大额采购这四类不可逆动作前，强制要求一次不超过 60 分钟的决策会，会后记录决议和条件即可。不设文件模板，不设审批流，不设门禁清单。

2. 100 到 500 人：从一条产品线试点，用 B 类标准门起步

这个规模是阶段门收益最明显的区间。建议做法是：选一条产品线试点，只设 3 道门，单门 5 到 6 个检查项，决策者固定在 3 人以内。

试点周期建议 2 个季度，观察四个指标：门后 30 天重大返工率、决议条件按期关闭率、门后资源兑现率、以及 Hold/Kill 决议占比。如果 Kill 占比仍然是 0，说明决策层没有真正参与，需要往上找原因，而不是继续优化流程文档。

3. 500 人以上、多产品线：必须做分级，且必须有统一数据口径

这个规模的核心矛盾是资源冲突。三条产品线同时要过门，测试资源只有一份，谁先谁后？如果没有统一的数据口径和资源视图，这个矛盾只能靠开会吵。

具体建议：建立公司级门日历（哪个项目在哪一周过门，提前一个季度公示）；建立跨项目的资源占用视图（测试工时、样机预算、关键专家时间）；引入 A/B/C 三级门并明确各级决策权限。这个阶段一定要上工具，Excel 加邮件的方式在 30 个并行项目以上会迅速崩溃，我在前面那个 800 人案例里已经说明了这一点。

4. 强合规行业：门的数量由标准决定，不由管理偏好决定

医疗器械、汽车零部件、航空、轨道交通这类行业，阶段门的形态很大程度上被行业标准锁定，比如医疗器械的设计控制要求、汽车的 APQP 节点。这类企业的优化空间不在”要不要设门”，而在两件事：

• 把法规要求的评审和内部管理评审合并，避免同一批人对同一份材料开两次会。
• 把合规证据和管理证据统一归档，一次准备两处复用。这一项通常能省下 30% 到 40% 的评审准备工时。

5. 正在做工具迁移的团队：先固化流程，再迁移数据

顺序千万不能反。我见过一个团队先把历史数据全量迁到新平台，再开始设计阶段门，结果流程一变，所有迁移过来的项目结构都要返工，白白浪费了三周。

正确顺序是：先用一个试点项目把门的结构和字段定义清楚，在平台上跑通一轮完整的门决策；确认结构稳定后，再批量迁移历史项目数据。在国产替代场景下，PingCode 支持 Jira 平滑迁移这一点能降低迁移期的数据丢失风险，但迁移策略本身仍然要按这个顺序走。

七、不同情况下的取舍

流程优化最难的部分从来不是”怎么做”，而是”在两件都对的事之间选哪件先做”。下面这几组取舍，是我在项目中被问得最多、也最容易反复摇摆的。

1. 集中式 PMO 主导 vs 业务线自管

集中式的好处是标准统一、跨项目资源看得清；坏处是 PMO 容易变成审批衙门，业务线觉得被管。自管的好处是决策快、贴合业务；坏处是标准不一，跨线资源冲突无解。

我的判断依据是并行项目数量和共享资源的稀缺程度。并行项目少于 15 个、共享资源不紧张的，业务线自管更合适；超过 25 个、或者测试/样机/专家时间存在明显争抢的，必须集中管理，否则资源冲突会变成政治问题。

折中方案我也用过：PMO 管标准和数据，不管决策。也就是 PMO 负责门禁模板、数据口径、门日历和跨项目视图，但具体某个项目过不过门，由业务线决策者拍板。这个分工在我们 8 个项目里跑下来阻力最小。

2. 强约束工具 vs 轻量看板

强约束是指系统层面不允许跳过门禁项、不允许在没有决议的情况下推进阶段。轻量看板是指系统只记录和展示，不强制阻断。

强约束的好处是执行力有保证，坏处是一旦流程设计有偏差，会大面积阻塞工作，而且会催生”系统外作业”。轻量看板的好处是灵活，坏处是容易退化成又一个没人看的报表。

我的经验是分阶段使用：前两个季度用强约束，因为需要建立习惯；第三个季度开始逐步放开非关键项，只对 A 类项目的关键门保留强约束。一直强约束会积累怨气，一直轻量会自然消亡。

3. 私有化部署 vs SaaS

这个取舍在阶段门场景下尤其重要，因为门的决策包里往往包含未公开的产品规划、成本结构和供应商信息，敏感度高于普通的任务数据。

判断依据主要有三条：行业监管是否有数据出境或数据驻留要求；研发数据的商业敏感度；以及 IT 运维能力是否支撑得起私有化环境。制造业、医疗器械、军工配套类企业基本没有选择余地，必须私有化。互联网和纯软件企业如果数据敏感度不高，SaaS 的迭代速度和运维成本优势更明显。

PingCode 在这个维度上提供了私有化部署选项，这也是它在中大型制造与研发密集型企业里被频繁选中的原因之一。

4. 采购成熟平台 vs 自研

自研的最大诱惑是”完全贴合流程”。但我必须说一句实话：阶段门流程本身会变，尤其是在头两年。你把流程硬编码进自研系统，后面每次调整都要排开发资源，而开发资源永远排不上。

我见过的自研案例里，有两家最终回到了采购路线，原因都是维护成本。自研方案的第一年投入通常在 150 到 300 人天，之后每年还要 60 到 100 人天维护，而绝大多数企业的阶段门需求并没有特殊到需要自研的程度。

自研真正划算的场景只有两种：一是所在行业有非常特殊的合规留痕要求，市面产品无法满足；二是企业本身就有成熟的自研平台团队，且这个平台还要承载其他业务。

八、落地路线图：三周、三个月、三个季度分别做什么

最后给一个我实际用过的落地节奏。它的特点是不做全公司动员，不做制度发文，全部从试点开始。

1. 前三周：定义与对齐

1. 第 1 周：盘点在跑项目，按不可逆成本和不确定性做 A/B/C 分级，选出 2 到 3 个试点项目。
2. 第 2 周：为试点项目设计门结构，只设必要数量的门，每个门 5 到 8 个检查项，全部改写为可验证表述。
3. 第 3 周：和决策者对齐门日历，把未来两个季度的门评审时间提前锁进日历；同时确定决议模板的三个必填字段（资源承诺、条件、下次门日期）。

2. 前三个月：跑通与纠偏

1. 第 1 个月：完成工具配置，把门结构、门禁清单、决议字段落到系统里；第一轮门评审用新模板举行，会前 48 小时发决策包。
2. 第 2 个月：第一次复盘，重点看两件事，材料返工率是不是降了，以及决策者有没有真的提反对意见。如果没人提反对意见，说明材料还是太少或者太晚。
3. 第 3 个月：第二次复盘，同时开始统计四个指标：门后 30 天重大返工率、条件按期关闭率、资源兑现率、Hold/Kill 占比。

3. 前三个季度：扩面与制度化

• 第 2 季度：把试点从 3 个项目扩展到整条产品线，此时可以开始做分级落地，让 C 类项目正式脱离全套流程。
• 第 3 季度：建立公司级门日历和跨项目资源视图，开始处理资源冲突这个真正的难题。
• 第 4 季度：把阶段门体系写进项目管理制度，但要注意，制度里必须明确写出”哪些项目不走这套流程”，否则分级会在半年内被稀释掉。

回到开头那个 700 万的教训。如果当时第 2 个门的门禁清单写的是”关键模块在真实工况下连续运行 ≥ 200 小时，故障间隔 ≥ 150 小时”，而不是”关键技术可行性已验证”，那场评审就不可能用”基本符合”四个字糊过去。团队会老老实实去跑测试，或者老实地承认还没跑到，然后被 Hold 住。

阶段门真正的价值，不在于它拦住了多少项目，而在于它让”我们其实还没验证”这件事没办法被含糊地掩盖过去。这是流程优化里最反直觉的一点：好的门不是让决策更严格，而是让决策更诚实。

如果你准备动手，我建议只做一件事，把现有门禁清单拿出来，逐条问”这条能不能被一个外人独立判断是否达成”。把不能判断的条目全部改写或删掉。这一个动作通常在一周内就能完成，而它带来的评审效率提升，往往超过后面所有的工具建设。