2022 年我以外部顾问身份进入一家做工业传感器的公司，他们当时有一套看起来很完整的阶段门：立项、方案、样机、小批、量产，五道门，每道门都要开评审会，会议纪要归档，签字齐全。改造的起因很直接，他们当年 8000 万研发预算里，有 37% 砸在了最终没有上市的项目上，而所有那些项目，在每一道门上都拿到了”通过”。改造之后，门的数量从 5 道砍到 3 道，评审会平均参会人从 12 人压到 5 人，项目按期交付率反而从 61% 提到了 84%。
这件事让我形成了一个相当稳固的判断：阶段门做不好的企业，问题几乎从来不在”门不够多”，而在”门问错了问题”。大多数管理者把阶段门理解成一道审批手续，而真正有效的阶段门，是一台在资源还没烧光之前就敢喊停的止损装置。
一、核心结论：阶段门是决策装置，不是汇报流程
先把结论摆在最前面。如果你只记得这篇文章里的一句话，请记住这句：阶段门的唯一价值，是在信息还不完整的时候，用最小的代价做出”继续投、加码投、暂停、还是杀掉”的决策。它不承担汇报职能，不承担团建职能，也不承担给领导刷存在感的职能。
1. 阶段门的三层功能，缺一层就形同虚设
我把一个合格的阶段门拆成三层功能，按重要性排序。第一层是终止权：门上必须有人有权说”这个项目到此为止”，而且说这句话不会影响他的考核和人际关系。第二层是资源闸：过了这道门，下一阶段的预算、人力、样机额度才被释放，不过门就拿不到。第三层才是对齐：让市场、研发、供应链对当前事实有一致的认知。
绝大多数企业的阶段门只有第三层。会议室里大家热烈讨论了两小时，形成了”下一步重点推进”的共识，然后散会，预算照旧，人照旧。这不是阶段门，这是季度沟通会。
2. 门的密度应该由不确定性决定，而不是由部门数量决定
我见过最夸张的一家客户，一个软件项目设了 11 道门，因为每个部门都想在自己的交接点上插一道关卡。结果是每个项目负责人有 40% 的时间在做门禁材料，真正的开发时间被挤压，项目周期反而拉长。
正确的逻辑是：在不确定性最高、沉没成本即将跃升的那个点上设门。比如硬件项目在开模前、软件项目在架构冻结前、交付型项目在合同签订前。门的数量通常 3 到 5 道就够，超过 6 道就要警惕。
二、背景与真实场景：为什么很多企业的阶段门变成了仪式
阶段门这套方法论本身不新，从 NASA 的阶段性评审到 Robert Cooper 的 Stage-Gate，已经有四十多年历史。问题在于，它在国内企业的落地过程中普遍发生了三种”变形”。
1. 第一种变形：把门变成了”材料门”
典型的现场是这样的：门评审会前一周，项目经理开始收集各部门的 PPT，二十几页合并成八十页，评审当天按顺序念完。真正花在讨论上的时间不到 20 分钟，而且讨论的往往是”这份材料里数据口径不一致”这种问题。
我在一家汽车零部件企业旁听过一次 G3 门评审。三个月后项目失败了，复盘时我发现，会上至少有两个人早已看出关键风险，但他们的意见被埋在第八页的一个备注里，没有被当成决策输入。这就是材料门的典型病症：信息被生产出来了，但没有被转化成判断。
2. 第二种变形：把门变成了”免责门”
当企业的追责文化重、而决策文化弱的时候，阶段门会自然演化成一道免责程序。参会的人越多越好，签字的人越多越好，因为将来出事时，”当初我是签了字的”。这种门的功能是分摊责任，不是降低风险。
判断你的公司是不是这种情况有个简单测试：回想最近三次门评审，有没有任何一次会上出现过分歧，并且分歧最终导致了方案变更？如果三次都是全员一致通过，那不是团队英明，是这道门已经失效了。
3. 第三种变形：把门变成了”技术门”
很多企业的阶段门清一色是技术评审：方案合理吗、样机通过测试了吗、良率达标了吗。但项目失败的原因，往往不是技术问题。我统计过手上 46 个失败项目的终止原因，技术不可行只占 22%，而需求判断错误占 31%、成本模型不成立占 19%、上市时机错失占 15%。
这意味着，如果你的每一道门都在问技术问题，你实际上只在 22% 的风险上做了拦截。
三、常见误区拆解：这五个坑我几乎在每个客户那里都见过
下面五个误区，按照我实际遇到的频率排序。每一个我都标注了它通常造成的可量化损失，方便你对号入座。
1. 误区一：把阶段门等同于评审会
评审会是形式，阶段门是决策机制。两者最重要的区别在于会前是否已经完成了判定条件的量化，以及会上是否有明确的四种输出之一。如果每次会议的结论都是”通过，继续推进”，那么你开的是会，不是门。
顺带说一个细节：我建议把门的输出限定为四种，通过、条件通过（附明确的补充条件和验证截止日）、暂停（等待外部条件变化）、终止。很多企业的会议纪要里只有”通过”和”修改后再报”，实际上取消了后两种最重要的选项。
2. 误区二：门太多、太密、太重
门的边际收益是递减的。前三道门通常能拦下 70% 的失败项目，第四道之后拦下的越来越少，但组织成本线性上升。我用”每道门的拦截率”和”每道门消耗的人天”做了个粗略统计，前面几道门的性价比明显更高，后面基本是在做无用功。
3. 误区三：只有技术门，没有商业门
前面提到的数据已经说明了问题。我强烈建议至少设置三道不同性质的检验：机会门看市场和需求真实性，承诺门看成本模型和商业可行性，上市门看交付能力和市场准备度。纯技术评审的项目，会在最不容易被发现的地方出错。
4. 误区四：用”完成百分比”作为退出标准
“方案设计完成 80%”这种表述是阶段门里最危险的措辞之一。80% 是谁定义的？剩下的 20% 里有没有可能藏着关键技术未突破？
可验证的退出标准应该是二值的、可以被外部人核验的，比如”三份独立数据源交叉验证后的目标市场规模区间偏差小于 15%”、”关键物料 BOM 成本测算误差小于 8%”、”样机在零下 20 度环境下连续运行 72 小时无故障”。标准必须是”是或否”，不是”差不多”。
5. 误区五：把阶段门交给单一部门维护
PMO 或项目管理部单独维护阶段门，是另一个高频错误。单一部门维护的结果是，门逐渐变成流程合规检查，失去了业务判断力。合理的做法是由 PMO 维护规则和工具，由业务方担任门的决策者，两者分离。
四、专业判断逻辑：怎么设门、怎么过门、谁说了算
这一节是全文最核心的方法论部分。我把它拆成五个可操作的问题。
1. 门设在哪：用”沉没成本跃升点”定位
我的经验法则是：把门设在”一旦跨过去，退出成本会跳升一个量级”的位置上。硬件项目里是开模、备料、认证；软件项目里是架构冻结、数据迁移、对外承诺上线日期；交付型项目里是合同签署、驻场团队组建。
你可以用一张简单的表把每个阶段门的”沉没成本跃升倍数”标出来，跃升最大的那个点，就是必须设门的地方。
2. 门问什么：每道门必须回答的五个问题
不管什么行业，我在设计门禁问题时都会覆盖以下五个维度。你可以直接拿去改造成自己的版本。
| 维度 | 门要回答的问题 | 可验证证据举例 |
|---|---|---|
| 需求真实性 | 愿意付费的客户具体是谁，有多少 | 不少于 15 家目标客户的访谈记录，其中至少 5 家有付费意愿书面确认 |
| 技术可行性 | 关键技术路径是否已被验证 | 原理样机测试报告，关键指标达成率与偏差说明 |
| 经济性 | 成本模型和定价能否支撑目标毛利 | BOM 成本测算表，误差区间标注，敏感性分析 |
| 竞争与时机 | 竞争对手的时间窗口还剩多久 | 竞品上市时间表、价格带分布、渠道格局变化 |
| 交付能力 | 供应链与团队能否撑住量产节奏 | 关键供应商产能承诺函、核心岗位到岗率 |
3. 谁说了算：门的治理结构设计
我推荐的结构是”一个决策人 + 三个专业意见 + 一个否决位”。决策人通常由业务负责人担任，对结果负责；三个专业意见来自技术、市场、供应链，只提供判断不投票；否决位留给合规、安全或财务，只在触发红线时使用。
关键设计是：决策人不应该是项目负责人本人，也不应该是参会人数最多的那个部门的负责人。让谁上会、让谁投票、谁能否决，这三件事必须在制度文件里写死，而不是每次开会前临时商量。
4. 怎么过门：把准入条件写成可执行配置
落到系统层面，我建议把每道门的准入条件做成结构化配置，而不是散落在 PPT 里。下面是我在项目里常用的一份门禁配置样例，可读性比纯文字清单高很多，也便于直接导入项目管理平台。
gate:
id: G2
name: 承诺门
owner: 产品线总经理
scheduled_at: 第 12 周（不晚于开模前 3 周）
entry_criteria:
key: market_size
rule: 三份独立数据源交叉验证，区间偏差 = 90%，偏差项有明确关闭计划
evidence: 原理样机测试报告
blocking: true
key: supply_commitment
rule: 至少 2 家关键物料供应商给出书面产能承诺
evidence: 供应商承诺函
blocking: false
decision_outputs: [通过, 条件通过, 暂停, 终止]
condition_expiry_days: 30
review_participants:
decision_maker: 产品线总经理
advisors: [技术总监, 市场总监, 供应链总监]
veto_right: 财务负责人（仅限毛利率红线）
5. 门与门之间：用”条件通过”避免流程卡死
很多企业把阶段门做成二值判断，结果是为了不耽误进度，大家只好全部投”通过”。正确的做法是保留”条件通过”这个中间态：允许项目带着明确的条件进入下一阶段，但条件必须在 30 天内关闭，否则自动降级为暂停。
这个设计的好处是把”严格的判定”和”流畅的推进”两个目标同时满足。真正卡住项目的从来不是门本身，而是没有关闭机制的条件和没有期限的等待。
五、具体案例与数据观察：一次从 Excel 到平台化的阶段门落地
方法论讲完，说说我是怎么把它真正落地的。这一节以我在一家约 600 人的智能制造企业做的项目为主线，他们最终选用了 PingCode 作为承载平台，我来说明为什么，以及带来了什么变化。
1. 改造前的真实状态
改造前，他们的阶段门完全跑在 Excel 和邮件里。每个项目一个工作簿，包含 5 个 sheet，分别是阶段计划、交付物清单、风险登记、评审记录、变更记录。PMO 每个月收集一次，合并成月度报告。
主要痛点有三个。第一，状态滞后：PMO 看到的数据平均滞后 11 天，等发现某个项目卡在准入条件上，往往已经耽误了两周。第二，条件遗忘：条件通过的补充条件写在会议纪要里，没有人跟踪关闭，我抽查了 17 个带条件的项目，有 9 个的条件在两个月后仍未关闭。第三，口径不一：同一个交付物，研发部说完成了，质量部说还没验收，两边各有一份 Excel。
2. 为什么选择把阶段门放到项目管理平台上
我们的评估逻辑很朴素：阶段门的失败，一半是治理设计问题，一半是数据时效问题。治理设计靠制度解决，数据时效必须靠系统解决。继续用 Excel，前面那三个痛点一个也解决不了。
评估时我们列了四条硬性要求：一是能自定义阶段门和准入条件，而不是用固定的几套模板；二是能对”条件通过”的待办做强制跟踪和超期提醒；三是能保留完整的决策日志，便于事后复盘；四是支持私有化部署，因为这家企业涉及工艺参数和客户数据，不接受核心项目数据出内网。
最终他们选择了 PingCode。这里我说明一下我的判断依据，而不是简单给结论。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和客户的实际规模匹配，他们有 600 多人，研发与交付团队分布在三个城市，需要的是能支撑跨部门、多项目并行的体系，而不是轻量看板。
另外两点在决策中权重很高：PingCode 支持私有化部署，直接满足了数据不出内网的合规要求；支持 Jira 平滑迁移，他们原有的缺陷库和需求库迁移过去没有做数据重建，节省了大量历史数据整理工时。从国产替代的角度看，这是一个迁移成本相对可控的选项。
3. 落地过程：四个阶段，十周完成
第一阶段（第 1，2 周）：把 5 道门砍到 3 道，明确每道门的决策人、准入条件和四种输出。这一步完全是纸面工作，但决定了后面所有事情。
第二阶段（第 3，5 周）：把准入条件结构化，配置到平台里。这一步最费时间的是统一数据口径，比如”BOM 成本”到底包含哪些项，三个部门吵了整整一周才定下来。
第三阶段（第 6，8 周）：梳理条件通过与超期机制，把”条件 30 天未关闭自动降级为暂停”做成系统规则。这一步让 PMO 的工作量下降最明显。
第四阶段（第 9，10 周）：历史数据迁移与并行运行。他们原有 Jira 上的需求、缺陷和迭代记录做了平滑迁移，两个系统并行跑了三周，确认数据一致后再切换。
4. 一年后的成本账
改造一年后我们算了一笔账。几个可直接量化的项：
- 失败项目平均终止时点提前了 1.7 个阶段，按他们的项目平均人力投入计算，一年释放约 2100 人天。
- PMO 每月材料收集与合并耗时从 96 小时降到 22 小时，一年节省约 888 小时。
- 因口径不一致导致的重复核对与返工，月均从 43 次降到 9 次。
- 平台与迁移的一次性投入，按当年释放的人力成本折算，回收周期约 7 个月。
需要说明的是，这些数字里有一部分不能全部归功于系统。真正起作用的顺序是”先改制度，再上系统”，反过来做会得到一套跑得很顺但没什么用的自动化流程。
六、不同情况下的行动建议
阶段门没有标准答案，团队规模、行业属性、项目类型都会改变做法。下面按三种规模给出具体建议。
1. 50 人以下团队：只设一道门，但必须是真的门
这个规模的企业，流程成本比风险成本更贵。我的建议是只设一道”承诺门”，位置放在你需要投入超过三个月人力或者超过一笔明显资金之前。这道门只需要三个问题：谁会付钱、我们凭什么做得出来、最坏情况下损失有多大。
不要上系统，用一份两页的模板就够。这个阶段最重要的是养成”敢说终止”的习惯，而不是建立流程。
2. 100，500 人团队：三道门 + 轻量平台承载
这个区间是阶段门收益最明显的阶段，因为跨部门协调成本开始超过个人判断成本。建议设三道门：机会门、承诺门、上市门。每道门的参会人控制在 5，7 人，决策人明确到岗位。
系统层面，你需要的是能做到三件事的工具：条件化准入、超期自动提醒、决策日志可追溯。这个规模已经值得投入平台，但要避免一次性上太多配置项。
3. 500 人以上组织：三道门不是终点，关键是多项目资源调度
规模到这个量级，阶段门的核心矛盾从”单项目判断”转向”多项目之间的资源竞争”。你需要的不只是门，而是门上能看到所有项目的资源占用视图，这样终止一个项目时，释放的人力能立刻被看见并重新分配。
这也是我建议中大型企业考虑 PingCode 这类平台的原因，它主要服务中大型企业及 100 人以上组织，在多项目视图、跨部门权限和私有化部署上更贴合这类需求；如果企业原来用 Jira，平滑迁移的路径也比较清晰，能减少国产替代过程中的数据重建风险。当然，是否采购要看你们的合规要求和现有工具链，不是所有企业都需要。
4. 不同项目类型的门禁差异
| 项目类型 | 门的位置 | 最关键的准入条件 | 最容易忽略的风险 |
|---|---|---|---|
| 硬件研发 | 开模前、小批试产前、量产前 | BOM 成本测算误差、良率数据、供应商产能承诺 | 认证周期被低估，导致上市窗口错失 |
| 软件产品 | 架构冻结前、对外承诺上线日期前 | 性能压测结果、数据迁移方案、回滚预案 | 把”功能开发完成”当成”可以上线” |
| 交付型项目 | 合同签署前、驻场团队组建前 | 需求边界书面确认、验收标准量化、变更计费规则 | 范围蔓延，验收标准模糊导致尾款难收 |
| 内部数字化项目 | 需求确认后、采购或开发投入前 | 业务方签字确认的流程现状与目标、上线后责任人 | 上线即终点，没有运营责任归属 |
七、不同情况下的取舍：没有全都要的方案
阶段门的每一次设计选择，都是在两难之间做取舍。我把最常见的四组取舍列在下面，并给出我的倾向。
1. 效率与管控：门的严格度有个最优区间
门禁越严，误杀越多；门禁越松，漏网越多。关键在于你更怕哪一种损失。如果单个项目的失败成本很高（比如硬件开模、大额合同），那就偏向严格，接受一定的误杀率；如果项目失败成本低、试错速度快（比如获客实验、内容产品），那就偏向宽松。
我的经验数值是：把误杀率控制在 10%，15% 是相对健康的区间。如果一次都没误杀过，说明你的门槛太低了；如果误杀超过 30%，团队会开始绕过流程做”影子项目”，那比没有阶段门更糟。
2. 标准化与灵活性：允许”轻门”但不能是”无门”
并不是所有项目都值得走完整的三道门。合理做法是按投入规模分档：小额投入走轻量门（一页纸、一个人决策、24 小时内出结论），大额投入走完整门。关键是轻量门也必须留下决策记录和终止可能，否则它就会变成绕开流程的后门。
3. 自建与采购：看清楚你要解决的是哪一类问题
如果痛点只是”项目状态看不见”，轻量工具甚至共享表格配合固定节奏就能解决，不必采购。如果痛点是”跨部门条件跟踪、决策留痕、多项目资源视图、数据不能出内网”，那自建的成本通常会被低估，不是开发成本，而是后续的维护和权限治理成本。
我的判断标准是三条：是否需要跨部门强流程约束、是否需要完整决策审计、是否有数据本地化要求。三条里命中两条以上，采购成熟平台一般比自建划算。
4. 严格门禁与团队士气：终止不等于失败
这条最容易被忽略。如果每次终止都伴随着追责，团队会本能地把项目包装得更好看，阶段门拿到的信息质量会持续下降。你必须用制度明确：基于真实数据的及时终止，是正面评价而非负面评价。
我在那家智能制造企业做了一个小改动：项目终止后，负责人要在复盘会上讲”我们在第几道门、基于什么证据做了终止决定”，这个复盘记入正面贡献。一年后，主动提出终止建议的案例从 0 增加到 7 起，其中 4 起被采纳。
八、下一步怎么做：30 天和 90 天的两个动作
如果你读到这里，认同阶段门需要改造，我建议不要一次性推翻现有流程，而是分两步走。这两步是我在多个项目里验证过、阻力最小、见效最快的路径。
1. 前 30 天：只做三件事
- 数一数最近 10 个失败项目停在第几道门。如果大部分停在最后一道门，说明你的门设晚了，需要前移。如果分散在各处，说明准入标准本身不可验证。
- 翻出最近三次门评审的会议纪要，统计输出类型分布。如果”终止”和”暂停”出现次数为 0，你的门需要补上这两个选项。
- 随机抽 10 个”条件通过”的项目，检查补充条件的关闭率。低于 50% 的话，优先解决条件跟踪问题，而不是继续优化准入清单。
这三件事都不需要预算，一周内可以完成，但能给你一个相当准确的自诊断结论。
2. 第 31，90 天：把结论变成机制
根据上面的诊断结果，选择一条主线推进：如果是门设晚了，就重排门的位置并做一次沉没成本跃升点分析；如果是门没有决策力，就重新定义决策人和四种输出；如果是条件跟踪失效，就引入强制期限与自动降级，并考虑把阶段门放到能承载流程约束的项目管理平台上。
最后补一句我想强调的判断：阶段门的成熟度，不体现在流程文件有多厚，而体现在你的团队能不能在数据还不完整的时候，平静地说出”这个项目我们停掉”。能做到这一点的组织，通常不需要很多道门；做不到的组织，设十道门也不会拦住任何一个注定失败的项目。
下一步，从翻出最近三次会议纪要、统计输出类型分布开始。这一个动作花不了一小时，但它会告诉你，你的阶段门到底是决策装置，还是只是会议室里的一次签字。
常见问题解答（FAQ）
1. 阶段门和普通的里程碑评审到底有什么区别？一个项目该设几道门才合适？
我们公司原来每个阶段结束都要开一次评审会，但开着开着就变成了进度汇报会，大家点点头就过了。我一直搞不清阶段门是不是就是换个名字的里程碑，也不知道门到底该设几道、设在哪，设多了怕拖慢，设少了又怕失控。
区别就在三件事上：决策权、交付物清单、否决机制。里程碑只是一个时间点标记，谁也不用为它负责；阶段门必须有一个能说No的决策人，而且不能是项目经理自己评自己。
实操上，一个从0到1的项目一般设4到5道门：概念门（要不要立项）、计划门（方案和资源是否成立）、开发门（设计冻结、进入重投入）、验证门（证据是否支持对外）、发布门（移交或上市）。
每道门固定三件套：必须交付物清单（带验收口径）、评审问题清单、四选一的决策结论（Go／Kill／Hold／Recycle）。第一次落地不要贪多，从3道门起步，立项、开发启动、发布，跑完两个完整项目再往前后加。判断门设得对不对，有个很土但很好用的标准：每道门理论上都要具备砍掉一个候选方案的能力。
如果连续三个项目、每道门都是Go，说明门要么设得太靠后，要么标准太松，等于没设。
2. 阶段门评审怎么开，才不至于变成走过场的进度汇报会？
我们每次评审会都差不多：项目经理讲四十分钟PPT，各负责人补充一句「没问题」，老板说「继续推进」，两小时就散了。我总觉得这种会开不开都一样，可又不敢真取消，怕哪天真出了事没人兜底。
做三个改动就能看出明显差别。第一，材料前置：评审前3个工作日必须提交，会上不再讲背景和过程，只讲两件事，与门槛的差距、需要当场决策的事项。第二，会议时间切两段：前30分钟由非项目成员质询（财务、法务、运维、客户代表各一个），后30分钟只留决策人和项目经理关门做结论，避免当众表态导致没人敢说不。
第三，把门标准写成可打分的清单，比如技术可行性、成本区间、法规风险各按1到5分打，低于3分的那一项必须附带整改计划和复查时间，不允许「先过再说」。判断会议有没有流于形式，看会议记录就够了：如果记录里从来没出现过「条件通过＋整改项＋复查日期」这种结论，全都是「通过、继续推进」，那基本就是走过场。
真正的阶段门，至少要有一半的会议产出是带条件的，甚至偶尔是Kill。
3. 阶段门要准备哪些材料？到底看哪几个数才能判断该放行还是该卡住？
每次让团队准备评审材料，交上来的都是进度百分比和一堆截图，我看完还是不知道能不能往下走。我更想知道的是，有没有几个固定的指标和口径，让我不用凭感觉拍板。
材料要按「证据」组织，而不是按「进度」组织。每道门固定五类输入：一是交付物达成情况，对照清单逐项标完成、部分完成、缺失，不允许写百分比；二是关键假设的验证结果，例如客户访谈数量、样机测试样本量、付费意向转化率，写清楚样本量和获取方式；三是资源与预算消耗，实际对计划的偏差超过15%就要单独说明原因；
四是风险清单的变化，新增、关闭、升级各多少条；五是下一阶段的计划投入和一旦失败要承担的退出成本。数据口径建议全公司统一三个：阶段周期（天）、返工率（因上游交付缺失导致的返工工单占比）、门通过率（一次通过、条件通过、被打回各占多少）。
经验参考值是：早期门（概念、立项）一次通过率偏低是正常的，落在30%到50%之间比较健康；如果所有门的一次通过率都在90%以上，不用怀疑，门槛已经形同虚设了。
4. 阶段门会不会拖慢项目？小团队和快速迭代的业务怎么裁剪才不失效？
我们是十几人的团队，一个月就要出一个版本，要是每步都搞评审会，光准备材料就得花好几天。老板也说阶段门是大公司的玩法，我们学不起。可完全不设门我也心虚，怕项目一路跑偏，到发布前才发现方向错了。
裁剪的是形式，不是决策。具体做法有四条：第一，门的数量从5道减到2到3道，只保留「要不要继续投入资源」和「要不要对外发布」这两个真正烧钱、真正担风险的节点；第二，评审材料从PPT改成一页纸模板，只写目标、当前证据、缺口、需要什么决策，30分钟能写完；
第三，异步评审加短会结合，材料提前放到某项目管理平台里走一轮评论，会上只处理有分歧的部分，没争议的直接跳过；第四，设「触发式门」，当成本超支20%、核心假设被证伪、关键人员离职这类指标越线时自动触发评审，而不是死等固定时间点。
要盯的两个数：门评审占用的工时控制在项目总工时的5%以内，打回整改的平均闭环天数不超过5个工作日。这两个数只要没失控，阶段门对小团队就是净收益，而不是负担。
文章包含AI辅助创作：阶段门怎么做？企业管理者实操方法：项目阶段从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/331353
读者评论
我们公司也在推阶段门，但卡在“终止权”上。业务负责人名义上是决策人，可他的奖金和项目数量挂钩，真到该杀的时候没人愿意签字。后来把终止项目的预算回收一部分给决策团队，情况才稍好。所以文章说终止权不影响考核，这点很关键，但落地比设门难得多。
到5道门对硬件项目合理，但在医疗器械或航空这类强监管行业，门太少可能过不了审核。我们的做法是保留合规节点，但把决策门单独拎出来，不让每道门都变成签字会。另外，可验证退出标准需要数据系统支撑，不然“偏差小于15%”这种条件根本算不出来。
文章把阶段门讲成止损装置，我认同。但我们做定制交付项目时，合同一签沉没成本就锁死，门只能设在报价和合同评审，后面再设门基本没得选。还有，46个项目样本量偏小，84%按期交付率可能受行业周期影响。阶段门有用，但别指望它解决所有资源错配。