项目阶段阶段门全流程：跨部门团队数据分析与一文讲清

2024年第一季度，我参加了一家约600人规模的制造加软件混合型企业的项目复盘会。他们有一个做了14个月的车联网平台项目，结项时产品、研发、测试、运维、市场五方对“这个项目到底成不成功”给出了五套答案：产品经理说需求交付率91%，研发负责人说还有37个未关闭的高优缺陷，运维说上线后前三个月发生17次生产故障，市场说首批激活率只有23%。

没有人撒谎。每个部门报出的数字都是真的，只是口径不同、时间窗不同、统计对象不同。问题的根不在数据本身，而在于他们的项目阶段门被设计成了一次“盖章会议”，而不是一次“数据对齐动作”。

这篇文章我想把项目阶段门全流程讲透：从门禁指标怎么定、跨部门数据怎么对齐、门禁判定规则怎么写，到不同规模组织该怎么取舍。我会用我自己踩过的坑、真实项目的观察数据，以及在中大型企业里比较常见的一类落地路径来说明。如果你正在被“评审会开成对数会”“阶段门形同虚设”“每个部门一套报表”折磨，这篇应该能帮你把框架搭起来。

一、先给结论：阶段门全流程的六个核心判断

在展开细节之前，我先把这十几年做研发管理和过程改进得到的结论摊开。这六条不是理论推演，是反复被项目验证过、也反复被违反过的。

1. 阶段门是数据契约，不是审批仪式

大多数团队把阶段门理解成“到点了要开个会、签个字、归档一批文档”。这种理解下，阶段门的产出是会议纪要，价值接近于零。

真正有效的阶段门，产出是一份跨部门共同确认的数据快照，以及基于这份快照做出的继续/暂停/调整决策。审批只是这个决策的形式外壳，不是内容。

我见过最健康的一次G2（设计与架构冻结）评审，会议室里没人在翻PPT。所有人盯着同一块看板：需求变更率8.3%、接口契约覆盖率76%、关键路径资源缺口2人、上阶段遗留风险关闭率60%。讨论只围绕一件事，这四个数是否支撑进入开发。45分钟结束。

2. 跨部门数据对不齐，根因是对象模型不统一

产品说的“需求”是用户故事，研发说的“需求”是开发任务，测试说的“需求”是测试用例集合，运维说的“需求”是变更单。这四个东西在不同的表里，有不同的ID，有不同的生命周期。

你想让它们在同一张阶段门报表里对齐，靠Excel手工映射是撑不过两个迭代的。必须先统一对象模型：需求对象、任务对象、缺陷对象、变更对象、风险对象，各自有唯一ID和稳定字段，跨部门报表才有共同底座。

这是为什么工具选型在阶段门落地里占了很大权重，不是因为工具好看，而是因为对象模型决定了你能不能在门禁上做自动判定。

3. 门禁指标要少而可验证，超过7个就等于没有

我统计过自己参与评审的40多场阶段门会议，门禁指标超过9项的，实际被认真讨论的通常只有3到4项，其余全部变成“这个后面再看”。

一个阶段门建议保留5到7个硬指标，其中至少3个必须能由系统自动计算。剩下的可以是人工判断项，但要有明确的判定人和判定依据，不能是“大家感觉差不多”。

4. 数据自动采集率决定阶段门能不能活过三个月

这是我踩过最深的坑。早期我推过一套很完整的阶段门模板，22个字段，全部手工填报。第一个月执行率100%，第二个月78%，第三个月41%，第四个月没人填了。

原因很简单：手工填报的成本由填报人承担，收益由评审会享受。这种成本收益错配必然导致衰减。只有当门禁数据的大部分来自日常研发行为的自然沉淀，阶段门才具备长期存活的可能。

5. 阶段门必须包含“反向门”和“退出机制”

绝大多数团队只设计“向前走”的门：立项门、设计门、开发门、测试门、发布门。没有人设计“退回去”和“停下来”的门。

结果是项目一旦启动就再也停不下来，即使市场窗口已经关闭、技术路线已经证伪，团队依然会硬着头皮走到发布门，然后把烂摊子丢给运维。缺少退出机制的项目管理体系，本质上是把风险从项目阶段推迟到了运营阶段，而运营阶段的修复成本通常是项目阶段的5到10倍。

6. 工具选型跟着组织规模走，不要跟着功能清单走

50人以下的团队用轻量看板加一份规范文档就够了，上重型平台反而是负担。100人以上、有多个并行项目、有跨部门协作和合规要求的中大型组织，才真正需要对象模型统一、权限分级、阶段门可配置的平台。

在这个区间里，我近几年观察和实际使用比较多的是 PingCode。它主要服务中大型企业以及100人以上的组织，支持私有化部署，也支持从 Jira 平滑迁移，在国产替代场景里是比较常见的选择。后面我会用它作为具体案例，讲清楚阶段门怎么落。

二、背景与真实场景：四种典型的阶段门现场

抽象讲阶段门很容易变成方法论空转。我把过去几年亲眼见过、并且深度参与过的四种场景写出来，你可以对照自己的组织找最像的那一个。

1. 场景一：硬件与软件混合研发的样机门

这是一家做智能硬件的公司，软硬件团队加起来约300人。他们的痛点非常典型：硬件那边样机还没到，软件这边已经在等联调；软件这边接口没冻结，硬件那边结构件已经开模。

他们的G3（样机验证门）门禁最初设了14项，包括结构件公差报告、电源测试报告、固件版本清单、驱动兼容性矩阵、APP联调记录等等。听起来很严谨，实际上每次评审都要花三四天收集材料，而且收上来的材料版本经常对不上。

我们后来做的第一件事不是加指标，而是砍指标：把14项压到6项，其中4项从工具里自动拉取，2项由硬件负责人现场确认。联调记录不再要求单独整理，直接从需求对象下的关联测试执行记录里汇总。

调整之后，G3评审准备时间从平均4.5天降到1.2天，而且因为数据来源唯一，扯皮次数明显下降。

2. 场景二：100人以上组织的平台迁移期阶段门

第二类场景是很多中大型企业正在经历的：从一套老旧的项目管理工具迁到新平台。这个过程本身就是一个需要阶段门管控的项目。

我见过最糟糕的一次迁移，团队用了三个周末做数据搬迁，结果迁移后第一个月，原平台里的15000个历史工单有近4000个关联关系断裂，燃尽图和统计报表全部失效。团队花了两个月手工修补。

后来我们复盘出一个结论：迁移项目必须设三道门，数据清点门、映射验证门、双轨并行退出门。每一道门都有可量化的门禁条件，例如字段映射覆盖率、历史数据抽样校验通过率、双轨期业务操作中断次数。

这也是为什么“支持平滑迁移”这件事不能只看宣传语。真正的平滑，是能给出字段映射方案、能保留历史关联关系、能在双轨期做到两边状态一致，而不是“有个导入按钮”。

3. 场景三：多事业部并行的立项门

第三类场景是集团型组织。三个事业部同时提立项，资源池是共享的，预算总额是固定的。这时候立项门就不只是“这个项目值不值得做”，而是“在有限资源下，这几个项目谁先做”。

我参与过的一次立项门评审，七个项目争夺同一个架构组的支持。以前的做法是各部门分别汇报，谁嗓门大谁先上。后来我们把立项门的门禁指标改成统一口径：战略匹配度、预期年化收益、所需共享资源人月、技术复用度、风险等级。

统一口径之后，七个项目第一次可以被放在同一张表上排序，决策从“说服”变成了“比对”。这是阶段门最被低估的价值。

4. 场景四：强监管行业的合规门

第四类场景是金融、医疗、车规这类强监管行业。阶段门不只是内部管理手段，还要对齐外部的合规检查点。

这类组织的门禁指标里，可追溯性权重极高：谁在什么时间改了什么、依据是什么、审批链是否完整。手工方式是撑不住的，必须靠平台的审计日志和权限体系。

三、拆解常见误区：阶段门为什么会失效

阶段门失效基本逃不出下面六种原因。我把它们按我观察到的出现频率排序，你可以先对照自己的组织打个分。

1. 误区一：把阶段门做成文档评审

最常见的错误。评审材料是几十页PPT，会上大家翻文档、提意见，会议结束形成一份会议纪要。

问题在于，文档评审审的是“表达”，不是“事实”。一份写得很漂亮的阶段报告，完全可以掩盖需求变更率高达30%、关键路径资源缺口2人这些事实。而阶段门要判断的恰恰是这些事实。

我的判断标准很简单：如果一场阶段门评审，把PPT全部拿走，就什么都审不了，那这个阶段门一定是形式主义的。

2. 误区二：跨部门数据靠“对数会”解决

很多组织意识到数据对不齐，于是安排每个迭代开一次对数会，让各部门把数据核一遍。

这个做法短期有效，长期失效。因为它默认了一个错误前提：数据本来就该不一样，只是需要沟通协调。而真相是，同一个业务事实在不同系统里被记录成了不同的值，这是数据模型问题，不是沟通问题。

对数会开到第十次的时候，你会发现大家开始用“上次怎么说的”来对齐，而不是用事实对齐。

3. 误区三：门禁指标越多越严谨

指标数量与严谨度不成正比，甚至成反比。我见过一个测试门的门禁有23项，结果评审时前三项花了80%的时间，后面20项全部是“无异议，通过”。

门禁指标的本质是一组筛选条件，筛选条件太多会导致“全通过”，筛选条件太少会导致“漏判”。5到7个是我目前认为最稳的区间，其中至少3个要能自动判定。

4. 误区四：门禁没有否决权

有些团队设了门禁指标，但即使不达标也照样通过，理由是“进度不能耽误”。这在短期内是理性的，长期是灾难性的。

我的经验是：门禁不能只有“通过”和“不通过”两种结果，至少要有三档，通过、带条件通过、不通过。带条件通过必须明确条件项、责任人、关闭时间和验证方式，并且这些条件要自动进入下一个阶段的待办清单。

这样既保住了进度弹性，又没有让门禁变成橡皮图章。

5. 误区五：阶段门只在项目侧，不进运营侧

大多数团队的阶段门止于“发布”。发布之后项目解散，进入运营期，没人再回头验证当初的门禁假设是否成立。

结果就是阶段门永远得不到校准：设的指标到底有没有预测力，没有人知道。

我建议至少加一道“发布后回顾门”，通常放在上线后30到60天。这道门的门禁指标不看交付，看结果：实际使用率、故障恢复时长、当初立项时假设的业务指标偏差。这道门是唯一能让阶段门体系自我进化的机制。

6. 误区六：评审角色不固定，靠临时拉人

每次评审换一批人，判断标准就会漂移。同一个阶段门，上半年通过的项目和下半年通过的项目，质量基准完全不同。

固定角色比固定流程更重要。通常需要三类角色：决策人（有权说停）、数据责任人（对数字准确性负责）、外部挑战者（不带项目利益，专门提反对意见）。第三类角色最容易被忽略，也最关键。

四、专业判断逻辑：阶段门四层数据模型

讲完误区，我要给出一套我自己用了很多年的判断框架。它的核心思路是：阶段门不是一堆指标的堆叠，而是四层数据从下往上逐层收敛的过程。每一层解决一个特定的信息不对称问题。

1. 第一层：交付物层，我们做出了什么

这是最基础的一层，回答“有没有、对不对、齐不齐”。典型对象包括需求基线、设计文档、接口契约、测试用例集、构建产物。

关键不在于文档数量，而在于交付物是否可被机器校验。例如接口契约覆盖率、用例与需求的关联率、构建产物的可追溯版本号。这些都能自动算出来。

这一层如果靠人工清点，就会变成“清单打勾游戏”；如果能自动关联，就是最可靠的地基。

2. 第二层：过程度量层，我们做得怎么样

这一层回答“过程是否健康”。典型指标包括需求变更率、缺陷回归率、构建成功率、代码评审平均等待时长、迭代承诺达成率。

我在这一层有个明确的判断：不要在同一阶段门里同时看交付速度和交付质量，两者会互相稀释。要么这一道门以质量为主、速度为辅，要么反过来，但要有明确的主次。

很多阶段门开成扯皮会，就是因为门禁里同时塞了“按期交付”和“零遗留缺陷”，两个目标本身冲突，会上自然打起来。

3. 第三层：跨部门协同层，我们配合得怎么样

这是四层里最容易被忽略、但对中大型组织最有价值的一层。它回答的是部门之间的接口是否顺畅。

典型指标：跨部门阻塞项平均停留时长、需求从提出到研发接单的等待时长、上游交付物被下游退回的次数、共享资源冲突次数。

这一层的价值在于，它把“部门之间的问题”变成了可测量的数字，而不是归因于某个人的态度。我见过太多团队在阶段门会上互相指责，其实只要把“上游交付物退回次数”这个指标摆出来，问题立刻就具体了。

4. 第四层：商业结果层，这件事值不值得继续

最后一层回答“继续投入还是停止”。典型指标：预期收益偏差、目标用户覆盖率、单位成本变化、机会成本评估。

这一层的难点是数据往往不在项目管理体系里，而在业务系统里。所以门禁设计上要允许跨系统取数，或者至少要有一个明确的取数人和取数时间。

我的经验是：第四层不必每道门都有，但立项门和发布后回顾门必须要有。前者决定要不要开始，后者决定要不要继续。

5. 门禁判定的三种规则：硬门、软门、条件门

四层数据准备好之后，还需要判定规则。我把它们分成三类：

• 硬门：不达标直接不通过，没有商量空间。通常用于安全、合规、资金类指标。例如“安全扫描无高危漏洞未修复”。
• 软门：用阈值区间判定，允许带条件通过。例如“需求变更率≤10%为通过，10%~15%需决策人签字，>15%不通过”。
• 条件门：当某个前置条件未满足时，允许以“条件+期限”的方式通过。例如“性能指标未达标，但已排期在下个迭代的第二周完成压测”。

下面是一段我之前在某个项目里用过的门禁配置片段，目的是让你看到“可机器判定”长什么样：

gate_id: G2_设计与架构冻结
owner: 架构负责人

entry_criteria:

id: req_baseline

rule: 需求变更率 = 0.80

source: 接口文档库关联率（自动）

id: risk_closure

rule: 上阶段遗留高风险关闭率 >= 0.90

source: 风险对象状态统计（自动）

id: resource_gap

rule: 关键路径资源缺口 <= 1 人

source: 资源视图（自动）

id: tech_review

rule: 架构评审纪要已归档且结论明确

source: 人工确认（架构负责人）

result_rule:

全部门禁通过: 通过

仅 tech_review 未通过: 条件通过（3个工作日内补）

其他任意一项未通过: 不通过

这段配置的关键不在于语法，而在于五个门禁项里有四项来自自动统计，只有一项需要人工确认，并且结果规则明确写清楚了什么情况可以通过、什么情况必须打回。

五、具体案例与数据观察：一套阶段门在 PingCode 上的落地过程

下面这个案例来自一家约450人的企业，做企业级SaaS产品，研发、产品、测试、运维、实施五个部门，同时并行11个项目。他们在引入阶段门之前的状态是：每个项目一套进度表，每两周一次跨部门对齐会，每次会两小时，会后依旧对不齐。

1. 落地前的基线数据

我们先做了两周的基线测量，得到几个不太好看的数字：需求从提出到研发接单平均等待6.4天；跨部门阻塞项平均停留4.1天；阶段评审平均准备时间3.8天；上线后前30天的严重缺陷平均5.2个。

管理层最初的直觉是“评审不够严”，想加人加会议。我的判断相反：不是评审不严，是评审没有数据可用，所以只能靠加会来弥补。

2. 阶段门怎么配置

我们在 PingCode 上把项目阶段门拆成五道：立项门、方案门、开发完成门、发布门、发布后回顾门。每道门5到7个门禁项，其中至少3项是自动统计。

关键的三件事：

1. 统一对象模型：需求、任务、缺陷、风险、变更单各自有唯一ID，跨部门报表全部基于这些对象生成，不再单独维护Excel台账。
2. 门禁项绑定数据源：门禁不再是一张检查表，而是绑定了具体的数据源和统计口径。数据一旦刷新，门禁状态自动更新。
3. 条件通过自动流转：带条件通过的项目，条件项自动生成待办并指派责任人，到期未关闭会在下一次门禁检查里高亮。

这里要说明一点：这家企业选择私有化部署，是因为他们的部分客户数据不能出内网。对于100人以上、有数据边界要求的中大型组织，私有化部署基本是硬条件，而不是可选项。

3. 六个月的观察数据

六个月后我们做了一次复盘，几项关键指标的变化如下表。需要说明的是，这些数字来自这一家企业的实际运行记录，不构成行业基准，仅供参考。

我想特别强调第四行和第五行。门禁项自动判定比例是阶段门体系的“心率”，低于60%基本意味着制度在靠人的自觉硬撑；带条件通过的条件关闭率则是“免疫力”，低于70%说明条件通过正在变成变相放行。

4. 迁移期的阶段门：为什么“平滑迁移”本身也需要门禁

这家企业原来用的是一套海外项目管理平台，历史工单约2.6万条，附带大量自定义字段和工作流。迁移本身就是一个小项目，我们给它单独设了三道门。

第一道是数据清点门，门禁项包括：历史项目清单完整率、自定义字段清单完整率、活跃用户映射表完成率。第二道是映射验证门，门禁项包括：字段映射覆盖率、抽样数据校验通过率、工作流等价性验证项数。第三道是双轨并行退出门，门禁项包括：双轨期数据不一致条数、业务操作中断次数、用户切换完成率。

最后的结果是：2.6万条历史工单，字段映射覆盖率98.7%，抽样校验通过率99.2%，双轨并行期共三周，业务操作中断0次。这个结果在迁移类项目里算是比较好的。

我在这里得到一个可复用的判断：凡是涉及数据搬迁或平台替换的项目，一定不要把迁移当成技术任务，而要当成有阶段门的独立项目来管。否则数据一旦断链，后面所有报表都不可信，而这会直接摧毁阶段门体系的可信度。

5. 一个失败的反例

同期我还观察了另一家企业，规模相近，方向也类似，但阶段门推行失败了。他们的做法是：先在旧工具上把阶段门模板做好，用Excel收集数据，等流程跑顺了再考虑换平台。

结果三个月后模板还在，数据没人填了。他们的负责人后来跟我总结说：“我们以为先把流程理顺再上工具，实际上是工具没上，流程就永远理不顺。”

这个反例说明的正是第一条核心结论：阶段门是数据契约，契约需要载体。没有载体的契约，只能靠人的意志力维持，而意志力是稀缺资源。

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

阶段门没有通用方案。下面按组织规模和特点给出我的具体建议，你可以直接对号入座。

1. 50人以下团队：不要上阶段门体系，先做两件事

这个规模的团队，最大的优势是信息传递成本低，最大的风险是把优势浪费在流程上。

我的建议是只做两件事：第一，把需求、任务、缺陷三类对象的字段规范统一，为将来留好接口；第二，只设两道门，立项门和发布门。

立项门看三件事：目标用户是否明确、成功指标是否可量化、不做的代价是什么。发布门看三件事：核心路径是否验证通过、已知缺陷是否有明确处置计划、回滚方案是否演练过。就这些，够了。

2. 100到500人团队：这是阶段门价值最大的区间

这个规模的典型特征是：跨部门协作开始变重，信息开始失真，但还没到必须靠制度硬管的程度。这是引入阶段门的最佳窗口期。

我建议的做法：

1. 先把对象模型统一，这是所有后续动作的前提。
2. 设四道门（立项、方案、发布、回顾），每道门5到7个门禁项。
3. 门禁项自动判定比例定为核心考核指标，目标首先是60%，稳定后冲80%。
4. 所有带条件通过的项目，条件必须自动生成待办，有责任人和关闭时间。

工具上，这个区间基本需要一套完整的项目管理平台。是否私有化部署取决于数据边界要求；如果涉及客户数据或合规审计，私有化通常必要。同时如果团队原来在使用海外平台，迁移的平滑度会成为选型的关键权重之一。

3. 500人以上或多事业部组织：阶段门要解决的是资源分配

这个规模下，阶段门的第一目标不再是项目健康度，而是资源分配的透明度和一致性。

我的建议是增加两件事：一是统一立项门的评分模型，让所有项目在同一把尺子上排序；二是把共享资源占用情况作为门禁项，避免多个项目同时承诺同一个架构组。

另外，这个规模的组织一定要建立“阶段门模板库”。同一个类型的项目（例如新功能交付、平台迁移、合规改造）复用同一套模板，避免每个事业部各自发明一套。

4. 强监管行业：把可追溯性做成默认能力，而不是额外动作

这类组织的建议只有一条：所有门禁数据的来源必须可审计，包括谁在什么时间修改了什么。凡是不能满足这个条件的指标，宁可不用。

这也意味着，这个场景下工具的权限体系、操作日志、审批链完整度，比功能数量重要得多。选型时要专门验证这三点，而不是看功能清单长度。

七、不同情况下的取舍

讲完建议，必须讲取舍。阶段门落地过程中有四个绕不开的矛盾，每一个都没有标准答案，只有适合当下组织状态的答案。

1. 取舍一：门禁严格度与交付速度

这是我被问得最多的问题。我的判断是：不要试图同时优化两者，而是按阶段门分层处理。

越靠前的门（立项、方案）应该越严，因为此时变更成本最低；越靠后的门（发布）应该在保证安全底线的前提下适度放宽，因为此时时间价值最高。

很多团队做反了：立项门很松，什么项目都能上；发布门很严，卡在最后导致交付延期。这个配置会同时损失速度和质量的收益。

具体做法：立项门和方案门设硬门，发布门设软门加条件门。发布门至少要设一条不可协商的硬门，涉及安全或数据破坏的风险项，这条不能松。

2. 取舍二：自研还是采购

我的经验判断是：50人以下不要自研，100到500人可以采购成熟平台，500人以上除非有极特殊的数据主权或业务模型要求，否则也不建议从零自研。

自研的隐藏成本经常被严重低估。真正贵的不是开发，而是持续维护、权限体系演进、审计合规适配、以及每次业务流程变化带来的改造成本。我见过自研工具做到第三年，维护团队比使用团队的人数还多的情况。

采购的取舍点在于：能不能满足对象模型的自定义需求、能不能支持门禁规则配置、能不能满足部署和合规要求。这三点比功能数量重要得多。

3. 取舍三：私有化部署还是 SaaS

这个取舍的判据很清晰：看数据边界，不看规模。

如果项目数据涉及客户敏感信息、生产环境配置、或者行业监管要求数据不出内网，那就只能私有化。如果没有这些约束，SaaS 在迭代速度和运维成本上通常更优。

需要提醒的是，从 SaaS 切到私有化，或者反向切换，成本都不低。所以这是一个前期就要想清楚、后期很难反悔的决策。

4. 取舍四：数据自动采集与人工判断

我的建议是把门禁项分成两类：可量化且重复出现的，一律自动采集；涉及方向判断和价值取舍的，一律人工判断，并且要明确判定人。

最糟糕的中间状态是：把本该人判断的事做成指标，把本该自动统计的事交给人填表。前者会产生大量噪声指标，后者会产生大量衰减数据。

八、90天落地路线与下一步

如果你打算动手，我建议按90天来推进，分三个阶段。这个节奏是我在多个组织里验证过的，太快会因为数据基础不够而失败，太慢会因为热情衰减而夭折。

1. 第1到30天：统一对象模型与基线测量

这个阶段不要设门禁，只做两件事：统一需求、任务、缺陷、风险、变更的对象字段；测出当前的真实基线（等待时长、阻塞时长、返工率、评审准备时间）。

这里的关键是不要美化基线数据。基线越难看，后面改善空间越明显，推行阻力反而越小。

2. 第31到60天：上线两道门，只做自动判定

先上线立项门和发布门这两道最关键的门。门禁项优先选能自动统计的，人工确认项控制在2项以内。

这个阶段的目标不是把所有部门都拉进来，而是让门禁数据的自动判定比例超过40%。达到这个数，后面的推进会明显顺畅。

3. 第61到90天：补齐四道门，建立条件通过机制

增加到四道门（立项、方案、发布、回顾），开始运行条件通过机制。这个阶段要盯的核心指标只有一个：带条件通过项目的条件关闭率，目标不低于75%。

同时开始收集发布后回顾门的数据，为下一轮门禁指标校准做准备。这道门通常要到第六个月才能看到效果，但它是整个体系能否自我进化的唯一通道。

4. 我的三个独特判断

最后总结三个可能和主流说法不太一样的观点。

第一，阶段门的首要产出不是决策，而是共用的数据语言。大部分组织认为自己缺的是决策机制，实际上缺的是让五个部门能讨论同一个事实的基础设施。

第二，门禁数据的自动判定比例比门禁指标本身更重要。指标设计得好不好，最多影响精度；自动判定比例高低，直接决定这套制度能不能活过第三个月。

第三，阶段门的失败通常不是因为太严，而是因为太散。指标太多、口径太多、角色太多、例外太多，最后没有一条是真正被执行的。

5. 下一步你可以马上做的事

如果你今天就想开始，我建议不要先动流程，先做这一件：把你最近一个项目从立项到发布的全部时间节点拉出来，标注每个节点上“信息是谁传给谁的、用了多少天、返工了几次”。

这张图做出来之后，你会非常清楚地看到瓶颈在哪个环节。大部分时候，瓶颈不在某个部门的能力，而在两个部门之间的等待。

然后，再去决定要不要上阶段门、设几道门、门禁项选什么、用哪类工具承载。顺序不能反。先看清信息是怎么流动的，再决定在哪里设闸门，这是我对项目阶段门全流程最核心的一条经验，也是我踩过最多坑之后才想明白的一件事。