阶段门落地方案：企业管理者开展项目阶段的制度设计案例解析

去年下半年，我参与了一家做工业检测设备企业的研发流程复盘。这家公司有完整的阶段门制度文件，一共 72 页，定义了 5 个阶段、4 道门、18 类交付物、32 个评审检查项。但把 2023 年全年的评审记录拉出来之后，数据很难看：全年立项 47 个项目，触发阶段门评审 141 次，其中被否决的只有 2 次，否决率 1.4%；而同期项目按期交付率只有 38%，需求变更率 61%，量产阶段暴露出设计缺陷的项目有 9 个。

也就是说，这套看起来很严谨的阶段门，实际上没有拦下任何东西。它把一个本该用来”停下来、看清楚、再决定要不要继续投钱”的决策机制，做成了一年盖 141 次章的行政流程。这不是个案。我在 2022 到 2024 年间参与过 23 家企业的研发流程诊断，阶段门平均否决率是 3.7%，而根据项目不确定性的不同，合理区间应该在 15% 到 30% 之间。低于 10% 的阶段门，基本可以判定为形式化。

所以这篇文章不打算再讲一遍”阶段门是什么、有哪几个阶段”这类百科内容。我想讲的是：一个能真正拦住项目的阶段门，在制度设计上有哪些必须做对的判断，以及这些判断落到工具和日常操作里长什么样。我会用我实际参与过的项目案例、可复现的配置方式，以及一套可以直接拿去改的取舍框架来说明。

一、核心结论：阶段门的本质是决策权设计，不是流程设计

先把结论摆出来。如果你只有五分钟，看完这一节就够了。

1. 阶段门解决的是”什么时候必须停下来”的问题

大部分流程制度的写法是”我们要做什么”，阶段门的写法应该是”我们什么时候不允许继续做”。这两者的差别非常大。前者是加法，谁都可以往上加检查项；后者是减法，它必须明确在某个时间点上，如果证据不足，项目就停在这里，不能进入下一阶段。

一个没有”停”的权力的阶段门，无论文档写得多厚，都只是一次例会。我见过最典型的场景是：评审会开始 15 分钟，项目经理念一遍进度，大家问两个不痛不痒的问题，然后主持人说”那我们就继续推进吧”。整个过程没有任何一个环节需要做”继续 / 暂停 / 调整”的明确表态。

2. 门的价值来自否决率和资源重排，而不是通过率

很多管理者在汇报时会说”我们阶段门通过率 98%”，把它当成流程顺畅的证据。这是指标方向搞反了。阶段门的产出应该是三类决策：放行、有条件放行、不予放行。有条件放行里必须写清楚条件是什么、谁负责、什么时候补齐、不补齐会怎样。

如果一家企业的阶段门里，”有条件放行”占比低于 20%，”不予放行”低于 5%，那这个门大概率在空转。反过来，如果一个门的不予放行率长期高于 40%，说明前面的阶段根本不该放进来，门设得太靠后了。

3. 制度写在文件里，证据必须落在系统里

这是我在诊断中反复看到的分水岭。做得好的企业，评审会之前所有材料已经在一个统一的系统里，评审人提前 48 小时就能看到需求验证数据、测试覆盖率、成本基线偏差；做得差的企业，评审会现场有人在群里发 PPT，有人在共享盘里找上一版测试报告。

证据不在系统里的阶段门，一定会退化成”谁汇报得好谁通过”。因为评审人没有独立的、可比对的、有时间戳的数据来源，只能依赖汇报人的叙述，而叙述天然是选择性呈现的。

4. 门的密度必须匹配项目的不确定性

不是所有项目都需要 4 道门。一个基于成熟平台做定制配置的项目，和一个要攻克新型传感器工艺的项目，不确定性差了好几个量级，用同一套门去管，结果一定是前者嫌烦、后者嫌松。

我的经验值是：技术不确定性高、单项目投入超过 300 万元、涉及硬件模具或长交期物料、有外部合规要求，这四类特征满足两项以上的项目，才值得设 4 道以上硬门。其余项目用 2 道软门加日常迭代评审就够了。

二、背景与真实场景：三道门为什么只剩下一个章

1. 一个典型的退化时间线

阶段门的退化几乎都遵循同一条路径，而且速度比大多数人想象得快。我复盘过一家软件企业的完整过程，从制度发布到彻底形式化，用了 11 个月。

第 1 到第 2 个月，大家还比较认真，评审前会准备材料，评审会上会争论技术方案。第 3 个月开始，因为一次紧急项目要赶客户节点，项目经理申请跳过第二道门，管理层批了。这是一个关键转折点，一旦有项目成功跳过门且没有付出代价，门就变成了可选项。

第 5 到第 7 个月，跳过的人越来越多，但为了在流程上留痕，大家开始”补记录”，也就是事后补一份评审纪要。第 8 个月之后，评审会变成 15 分钟的同步会，材料提前一天发群里，没人提前看。

2. 退化背后的三个结构性原因

第一个原因，是门的决策权没有和资源权绑定。门评审通过了，但项目经理想要的额外人力并没有因此到位；门评审否决了，但项目组的人也没被释放去做别的事。当一次决策不改变任何资源分配时，参与者很快就明白这只是走个形式。

第二个原因，是评审标准写的是”应当”。我翻过很多制度文件，检查项里大量出现”需求应当明确””方案应当经过验证””风险应当可控”。这类表述没有可举证性，评审人无法判断”是否明确”，只能凭感觉打分，最后统统给通过。

第三个原因，是缺少反例训练。组织里没有人见过”因为阶段门被否决，项目被终止或重构”的案例，大家默认最坏结果只是补材料，于是没人真正在意门的严肃性。

3. 我观察到的数据基线

把 23 家企业的数据放在一起，有一些相对稳定的规律。制度文件页数和阶段门有效性之间没有正相关，页数超过 50 页的 7 家，否决率中位数只有 2.9%；页数在 20 到 35 页之间的 9 家，否决率中位数是 11.4%。

另一个规律是，设置了”有条件放行”这一中间态的企业，门质量明显更好。因为二选一的决策压力太大，评审人倾向于选择”通过”；给出中间态后，实际上的拦截效果反而提升了。让评审人有不尴尬的否决方式，比反复强调”要严格”有用得多。

三、常见误区拆解：八个把阶段门做废的动作

1. 把门做成审批流

审批流的逻辑是”谁签字同意”，阶段门的逻辑是”什么证据成立”。这两件事看起来像，实际上完全不同。审批流的终局是签字完成，阶段门的终局是做出继续投入或停止投入的判断。

判断方法很简单：看这个门的结论里有没有”投入金额”和”人力数量”的变化。如果没有，它就是审批流。

2. 通过标准不可举证

把检查项改成可举证的表述，是成本最低、收益最高的一次改造。举个例子，”需求应当明确”可以改成”核心需求已由不少于 5 名目标用户完成可用性测试，任务完成率不低于 80%”。后者无法靠汇报糊弄过去。

3. 决策人不在场，或者授权错位

我见过最离谱的一次，是某企业把阶段门决策权授予了一个由各部门代表组成的委员会，而这个委员会里没有任何一个人有权决定预算。评审结论是”通过，但资源需要另行申请”。这个结论等于没有结论。

正确的做法是把决策角色分成三类：举证方（项目团队，负责提供证据）、质询方（技术、质量、财务、合规，负责挑问题）、决策方（对预算和人力有调配权的人或其明确授权的代表）。三者不能混。

4. 门没有资源联动

阶段门最强的抓手不是否决，而是”通过之后的资源释放”。如果通过第一道门之后，项目能自动拿到下一阶段的预算和人力，那么项目组就有动力认真准备门材料；如果通过之后还要再走一轮资源申请，门就失去了分量。

5. 门只进不出

很多企业的阶段门只对”新项目立项”和”进入下一阶段”设置关卡，却没有设置退出机制。结果是项目一旦立项就永远存在，哪怕已经明显不成立。我在一家企业看到过 2019 年立项、到 2024 年仍然在”研发中”的项目，没有产出、没有结项、没有终止。

阶段门必须包含”终止门”或”重估门”。通常设在第二道门之后，明确要求对项目继续投入的价值做一次独立判断。

6. 用里程碑替代阶段门

里程碑是时间点，阶段门是决策点。里程碑到了意味着”该交付的东西交付了”，阶段门到了意味着”我们要做一个继续投入的决定”。把两者合并，就会出现”里程碑延期，所以评审也延期，评审延期，所以决策也延期”的连锁效应。

7. 制度与工具两张皮

制度写在 Word 里，执行靠邮件和会议，数据靠 Excel 汇总。这种情况下，阶段门的证据永远无法完整留存，也无法做横向比较。想在半年后回答”我们第二道门的否决率是多少”，会发现根本拿不出数据。

8. 一刀切所有项目

把同一套门应用到所有项目，会导致两个后果：低不确定性项目被过度管控，团队想方设法绕过；高不确定性项目被管控不足，风险在后期集中爆发。

四、专业判断逻辑：阶段门制度设计的五个杠杆

1. 门位与门数的设计

门位指的是门设在哪个节点，门数指的是一共设几道。这两件事必须跟着不确定性走，而不是跟着”行业惯例”走。

我通常用一个简单的判断表来定门位。技术可行性未知的，第一道门要放在技术验证之后，而不是需求确认之后；市场需求未知的，第一道门要放在用户验证之后；工艺或供应链风险高的，必须在开模或下长交期订单之前设一道门。

门数的经验区间是：成熟的定制类项目 2 道，标准产品迭代 3 道，新产品研发 4 道，涉及硬件和量产的新品 5 道。超过 5 道门的项目，实际执行中一定会有门被跳过。

2. 通过标准的三层结构

我发现有效的阶段门标准通常分成三层，缺一层就会出问题。

第一层是硬性条件，也叫一票否决项。比如”未完成安全认证测试””模具成本超出基线 15% 以上””核心专利检索未完成”。这类条件不满足，直接不放行，不进入讨论。

第二层是软性条件，用评分或阈值判断。比如需求覆盖率、缺陷密度、关键路径偏差天数。这类条件允许有条件放行，但必须写明补齐期限。

第三层是风险敞口，也就是”如果现在放行，最坏情况是什么”。这一层最容易被省略，但恰恰是决策层最需要的信息。我通常要求项目团队在门材料里用一段话写清楚：最坏情况下损失多少、影响哪些客户、能不能回滚。

# 阶段门配置示例（YAML 结构，可直接映射到项目管理平台的阶段门模块）
gate:

id: G2

name: 技术方案验证门

position: after_phase_technical_validation

decision_roles:

decider: [研发副总, 产品总监] # 对预算与人力有调配权

challengers: [架构组, 测试负责人, 财务BP]

presenter: 项目经理

hard_criteria: # 一票否决项

key: poc_completed

desc: 关键技术点完成 POC，且通过率 >= 90%

evidence: 测试报告链接（系统内）

key: ip_check

desc: 核心专利检索报告已归档

evidence: 检索报告附件

soft_criteria: # 阈值判断项

key: requirement_coverage

desc: 需求覆盖率

threshold: ">= 85%"

condition_pass: 有条件放行（30 天内补齐）

key: architecture_review

desc: 架构评审遗留高风险问题数

threshold: "risk_exposure: # 风险敞口描述

required_fields: [最坏损失金额, 影响客户数, 是否可回滚]

outcomes: [放行, 有条件放行, 不予放行]

condition_followup:

owner: 项目经理

deadline_days: 30

auto_escalate_to: 研发副总

3. 决策权与角色的分离

举证的人不能同时是决策的人。这条听起来是常识，但在很多企业里，项目经理既是材料准备者，又是评审组织者，还是最终结论的实际拍板者。这种情况下，评审会的主要功能变成了”让项目经理把已经决定的事情讲一遍”。

分离的具体做法是：举证方由项目团队承担，质询方由跨职能专家承担，决策方由掌握资源的管理者承担。决策方人数控制在 1 到 2 人，人数越多越难做出否定结论。我在实践中看到，5 人以上的评审委员会，否决率通常是 2 人决策组的四分之一。

4. 证据载体与数据留痕

这一条是能不能持续改进的关键。阶段门的所有材料、评审记录、结论、条件跟进，必须在同一个系统里，且带有时间戳和版本号。原因有三个。

第一，只有留痕才能做横向比较，才能回答”我们的门是不是太松了”。第二，只有留痕才能追责到具体条件，避免”有条件放行”变成”无条件放行”。第三，只有留痕才能让新加入的管理者快速理解历史决策逻辑。

5. 与预算、人力、绩效的联动

门通过之后应该发生什么？这是制度设计里最容易被忽略的一环。我的建议是三个联动：预算联动（门通过触发下一阶段预算释放）、人力联动（门否决触发人员回收，重新分配到其他项目）、绩效联动（门材料的质量纳入项目经理考核，而不是只考核项目是否按期）。

尤其第二条，很多企业做不到。项目被终止了，人还在，只是换了个名义继续做。这种”软终止”会让阶段门的威慑力彻底消失。

五、落地案例：某中大型企业用 PingCode 承载阶段门的全过程

1. 企业背景与痛点

这家企业是做智能仓储设备的，研发人员 620 人，分 4 条产品线，同时有软件团队和硬件团队。2023 年之前，他们的阶段门靠一套自研的 OA 表单加共享盘管理。问题很集中：评审材料分散，历史数据无法统计，硬件团队和软件团队的阶段定义不一致，跨部门门的结论经常互相矛盾。

他们的核心诉求有三条：阶段门证据要统一落库、研发过程数据要能和门绑定、系统要能私有化部署以符合客户与内部审计要求。第三条对他们是硬约束，因为他们的产品要交付给一些对数据出境有严格要求的行业客户。

2. 为什么选择把阶段门承载在 PingCode 上

在评估过程中，他们比较过几种路径：继续自研 OA 表单、用通用项目管理工具、用专门面向研发全流程的平台。最后选择 PingCode，主要是三个原因。

第一是研发链条的覆盖度。PingCode 覆盖需求、迭代、测试、缺陷、发布这条链路，阶段门需要的证据，需求覆盖率、测试通过率、缺陷密度、发布记录，都能直接从工作项里取，而不是靠人工填表。这对中大型企业特别重要，因为人工填表的数据在第三个月就会开始失真。

第二是私有化部署能力。这家企业最终采用的是私有化部署方案，代码和研发数据留在自己机房，符合他们对客户审计承诺的要求。对于 100 人以上、尤其是 500 人以上有合规压力的组织，这一项经常是一票决定项。

第三是Jira 平滑迁移。他们原本有 5 年多的 Jira 使用历史，积累了大量项目、工作项、自定义字段和看板。迁移时最大的坑不是数据本身，而是自定义字段和工作流的映射关系。PingCode 提供了对应的迁移支持，把历史工作项、附件、评论、状态映射批量导入，同时保留了原来的项目结构，使得迁移周期从原本预估的 4 个月压缩到 7 周左右。对正在做国产替代选型的团队来说，这一点会显著降低切换风险。

3. 阶段门在系统中的具体配置

他们把 4 道门落成了系统的四个阶段关口，每个关口绑定三类信息：交付物清单、硬性条件检查项、评审记录。具体的操作步骤是这样的。

1. 在平台里按产品线建立项目模板，模板中预置 4 个阶段和对应的门。
2. 为每道门配置交付物清单，交付物直接关联平台内的需求、测试计划、缺陷报告、发布记录，不采用外链附件。
3. 配置硬性条件为阻断项，未满足时项目无法流转到下一阶段，从机制上避免”跳过门”。
4. 配置软性条件为阈值提醒，触发告警但不阻断，由决策方在评审中判断是否接受。
5. 评审记录作为独立对象挂在门上，包含参与人、结论、条件、责任人、补齐期限，并自动在到期时提醒。
6. 把门的数据接入研发度量看板，按季度统计否决率、有条件放行率、条件按期关闭率。

4. 上线前后的数据观察

系统上线后跑了两个完整季度。最直接的变化不是效率，而是数据的可获得性。上线前，他们无法回答”第二道门的历史否决率是多少”，因为记录散落在邮件里；上线后，这个数字随时可以拉出来。

第二个变化是评审前置。因为材料必须在系统里齐备，评审人提前就能看到，评审会从”信息同步”变成了”针对争议点讨论”，平均评审时长从 78 分钟降到 46 分钟，但争议点数量反而增加了。

第三个变化是有条件放行的跟进闭环。上线前，有条件放行的项目里有相当一部分条件从未被验证过；上线后，因为条件被写成系统对象并且有到期提醒，按期关闭率显著提升。

需要说明的是，否决率上升不是坏事，恰恰是制度开始起作用的标志。真正要盯的是它有没有稳定在合理区间。到第二季度末，他们的否决率稳定在 10% 到 13%，有条件放行率稳定在 25% 左右，条件按期关闭率超过 80%，这组数字在我看来已经进入健康区间。

5. 迁移与落地中的三个实操提醒

第一，迁移之前先做字段审计。Jira 里往往积累了大量废弃的自定义字段，直接迁移会把混乱带过去。他们的做法是先把字段分成”必须迁移””归档保留””直接放弃”三类，字段数量从 137 个精简到 41 个。

第二，不要一次把 4 道门全部开启阻断。他们的做法是先用两个月跑软门，只记录不阻断，让团队适应材料要求；第三个月开始对第二道和第三道门开启硬阻断，这两个门的历史问题最集中；第四道门在第四个月才开硬阻断。

第三，把门的数据接入管理看板，但只给管理层看三个指标：否决率、条件按期关闭率、门的平均停留天数。指标太多会让人失去焦点，阶段门管理看板超过 5 个指标就开始失效。

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

1. 100 到 500 人的单一或双产品线组织

这个规模的组织，最大风险是流程过重导致研发效率下降。我的建议是只设 3 道门：立项门、技术方案门、发布门。立项门由产品负责人和研发负责人共同决策，技术方案门由技术负责人决策，发布门由质量负责人和产品负责人共同决策。

这个阶段不需要复杂的委员会机制，但必须做到两件事：所有门的材料在系统里齐备、所有门的结论有明确的下一步动作。前者保证证据可追溯，后者保证门不是走过场。

工具选择上，这个规模的组织适合直接用一体化研发管理平台，不必自研。PingCode 在这个区间的适配度较好，因为它的阶段门能力是跟着需求、测试、发布链路走的，不需要额外搭建表单系统，也不需要为了统计数据再做一次数据集成。

2. 500 到 2000 人的多产品线组织

这个规模的核心矛盾是统一和灵活之间的平衡。建议采用”统一门框架 + 产品线自定义检查项”的模式：门的数量、位置、命名全公司统一，硬性条件和软性条件的阈值允许按产品线配置。

同时必须建立跨产品线的门数据看板，按季度做横向对比。我在实践中发现，一旦某个产品线的否决率连续两个季度显著低于其他产品线，这通常不是因为它做得更好，而是因为它的门标准松了。

这个规模往往有私有化部署和合规要求。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，对已经用了多年 Jira、又需要满足国产化和数据留存要求的中大型组织，是一条迁移成本相对可控的路径。

3. 软硬结合或涉及量产的组织

硬件项目最特殊的点是不可逆投入。开模、长交期物料采购、认证测试，这些动作一旦发生，回退成本极高。所以门位必须设在不可逆动作之前，而且必须是硬阻断。

我的建议是设 5 道门：立项门、技术验证门、投料门（开模或下长交期订单前）、量产准备门、上市门。其中投料门是最关键的一道，硬性条件至少包括：结构与工艺评审完成、关键物料供应商确认、成本基线偏差不超过 10%、可靠性测试方案已通过评审。

4. 项目型交付组织

以项目交付为主要业务的组织，阶段门的设计重心不在技术风险，而在范围、成本和验收风险。建议设 4 道门：合同与技术协议确认门、方案设计门、交付实施门、验收门。

这类组织特别容易出现的问题是把商务变更和阶段门混在一起。我的建议是分开：商务变更走变更流程，阶段门只管交付物的完备性和风险敞口。

5. 正在从 Jira 迁移的团队

迁移期间最容易出问题的是阶段门证据的连续性。我的建议是分三步：先迁移历史数据并只读保留，保证审计可追溯；再在新系统里重建阶段门配置，用 2 到 3 个新项目试跑；最后按产品线逐步切换。

迁移过程中要特别注意自定义字段和状态的映射关系，这是绝大多数迁移项目延期的主要原因。PingCode 提供了针对 Jira 的迁移支持，包含工作项、附件、评论、状态和项目结构的批量导入，能显著缩短这个阶段的周期。

6. 强监管行业的组织

如果产品涉及医疗器械、汽车电子、航空、金融等强监管领域，阶段门的检查项需要直接映射到对应标准的要求条款。这时门的数量往往由标准决定，不由组织决定。

这类组织的重点不是减少门，而是降低门的执行成本：把所有标准条款变成系统里的检查清单，把证据自动关联到工作项，把审计需要的追溯链条自动生成。对于强监管行业，阶段门不是管理工具，是合规资产。

七、不同情况下的取舍

1. 强门与弱门的取舍

强门意味着硬性条件不满足就不允许流转，弱门意味着只提醒不阻断。很多人会问，是不是所有门都应该做强门。

我的判断是：只有涉及不可逆投入或重大风险的门才适合做强门，其余应该做软门加显式提醒。原因很简单，强门会带来绕过行为，一旦有人找到绕过方式，整个制度的权威性都会受损。如果你在四个门上全部做强阻断，实际结果是团队会想办法在门之前就把事情”处理”掉，而不是真正解决问题。

判断标准可以这样定：如果这个决策造成的损失超过项目总预算的 15% 且无法回滚，用强门；否则用软门加评审记录。

2. 集中评审与分级授权的取舍

集中评审的优点是标准一致，缺点是决策速度慢，而且参与人多时很难出否定结论。分级授权的优点是快，缺点是标准可能走偏。

我的建议是按金额和风险分级。单项目预算在 100 万元以下、技术成熟度高的，授权产品线负责人决策；100 万到 500 万元或有新技术风险的，由研发负责人加产品负责人共同决策；500 万元以上或涉及新市场新技术的，上升到公司级决策。

3. 采购平台与自研表单的取舍

自研表单的优势是贴合现有习惯，初期成本低。但它的隐性成本很高：数据无法与研发过程打通，每次统计都要人工汇总，组织一变化就要重做。我在诊断中见过一家企业，自研的阶段门表单系统迭代了 6 个大版本，累计投入超过 300 人天，最后仍然无法回答”历史否决率是多少”。

采购平台的初期投入更高，但数据天然与需求、测试、发布链路打通，也能直接支撑度量和审计。对于 100 人以上的组织，我倾向于采购一体化研发管理平台；对于 50 人以下、流程简单的团队，轻量表单可能更划算。

4. 全量铺开与试点的取舍

全量铺开的风险是组织摩擦集中爆发，试点的问题是容易变成”试点很好、推不动”。我的建议是：制度全量发布，硬门渐进开启。

也就是说，阶段门的定义、交付物清单、评审规则一次性公布到所有产品线，但硬性阻断按产品线分批开启，每个产品线用一到一个季度适应。这样既保证了制度的统一性，又给组织留出了吸收摩擦的时间。

5. 取舍对照表

八、下一步：30 分钟能做完的最小动作，和 90 天该走完的路径

1. 今天就能做的三件事

第一件事，把最近 12 个月的所有阶段门评审记录找出来，统计三个数字：评审总次数、不予放行次数、有条件放行次数。如果否决率低于 5%，你的阶段门已经在空转，这是改造的起点。

第二件事，随机挑 5 个检查项，判断它们是否可举证。把”应当明确””合理可控”这类表述全部标记出来，这些是需要改写的清单，通常占到总检查项的 40% 以上。

第三件事，找出实际做阶段门决策的人，问他一个问题：你能决定这个项目的预算和人力吗？如果不能，说明决策权配置有问题。

2. 第一个 30 天

1. 第 1 周：完成历史数据统计和检查项审计，输出一份不超过 3 页的现状诊断。
2. 第 2 周：重新定义门位和门数，按项目不确定性分层，不同类型项目走不同的门。
3. 第 3 周：把硬性条件改写成可举证表述，明确一票否决项，控制在每道门 3 到 5 条。
4. 第 4 周：确定决策角色，明确决策方、质询方、举证方，并把决策方和预算权对齐。

3. 第 31 到 90 天

1. 第 5 到 6 周：把阶段门的交付物清单和检查项配置到系统里，先以软门形式运行，只记录不阻断。
2. 第 7 到 8 周：选择 2 到 3 个新项目试跑完整流程，收集评审人反馈，调整检查项。
3. 第 9 到 10 周：对历史问题最集中的一道门开启硬阻断，观察两周内的流转数据。
4. 第 11 到 12 周：建立阶段门度量看板，只保留三个指标：否决率、条件按期关闭率、门的平均停留天数。
5. 第 13 周：做第一次季度复盘，重点看否决率是否进入 10% 到 20% 区间，以及有条件放行的条件是否真的被关闭。

4. 90 天之后要盯的唯一一件事

90 天之后，制度文件、工具配置、评审流程都会趋于稳定，这时候最容易发生的是缓慢退化，也就是本文第二节讲的那条 11 个月曲线。防止退化的办法只有一个：把阶段门的效果和资源分配真正绑起来。

具体做法是每个季度做一次门数据复盘，把否决率异常低的产品线单独拿出来看，把有条件放行但条件未按期关闭的项目拿出来看，把门的平均停留天数突然变长的环节拿出来看。这三个信号出现任何一个，都说明门又开始形式化了。

我最后想强调一个反直觉的判断：阶段门的成功标志不是流程顺畅，而是团队在门上真的会停下来争论。如果你开完一次阶段门评审会，发现没有任何人提出反对意见，没有任何条件被补充，那这次会议的价值就是零。评审会应该是一个有摩擦的地方，摩擦本身就是制度在起作用的证据。

管理者的工作不是让门变得更顺，而是让门变得更有判断力。从今天开始统计那三个数字，你就已经比大多数企业更接近一个真正有效的阶段门了。