2019 年我参与过一家工业软件公司的项目复盘。那家公司有 6 个阶段门，从立项到交付走了 14 个月，最后仍然延期、超预算、上线后三个月内爆发了 40 多个严重缺陷。复盘时我把 6 次阶段门评审记录全部翻出来看，结果是：6 个门里有 5 个是”有条件通过”，其中一个门的通过率是 100%，历史上从未拦下过任何项目。他们不缺流程文件，缺的是一个真的敢说”不”的机制。
这篇文章我想把阶段门这件事拆到底：跨部门团队要怎么设计制度，才能让阶段门真的拦住东西，而不是变成每隔两个月开一次、两小时散会的仪式。我会给出五要素制度模型、可复制的门禁标准写法、一次阶段门评审的完整操作步骤，以及不同组织规模下的取舍建议。
一、核心结论：阶段门拦不住项目，是因为它被设计成了”仪式”
我先把结论放在前面，后面所有内容都是围绕这三条展开的。
1. 阶段门本质是一次”继续 / 转向 / 终止”的投资决策，不是一次汇报
大多数公司把阶段门开成了项目组的汇报会：项目组讲 PPT，领导听，听完说”辛苦了，继续推进，注意风险”。这种会的本质是信息通报，不是决策。
真正的阶段门必须回答一个二选一的问题：基于当前证据，这个项目应该继续投入，还是应该停下来、改方向、或者直接终止？如果这个问题的答案在开会之前就已经是”继续”了，那这个门就是无效的。
我在做诊断时有一个很简单的判断方法：翻过去 12 个月所有阶段门记录，看有多少次结论是”不通过”或”有条件通过且设置了硬性截止日期”。如果比例低于 15%，这个阶段门体系基本可以判定为失效。这不是说要为了否决而否决，而是说明决策没有真实发生。
2. 阶段门的有效性只取决于三件事
我见过很多公司花大力气做流程文档，几十页的阶段门定义、几十个检查项，但依然拦不住项目。原因在于他们做的是”全面但不可执行”的设计。有效的阶段门只需要三件事同时成立：
- 门禁标准可验证：每一条标准都能被第三方用客观证据判定”满足 / 不满足”，而不是”感觉差不多了”。
- 决策人有权限且有动力：说”不”的人必须是不承担该项目日常交付压力的人，否则他一定会选择放行。
- 不通过有明确出路：不通过之后项目组知道该做什么、多久之内复查、谁负责，否则大家会本能地避免触发”不通过”。
这三条里，最难的不是第一条，而是第二条。因为它触动的不是流程，是权力和考核。
3. 跨部门阶段门失败的第一原因，是”没人愿意当坏人”
我服务过的中大型企业里，阶段门评审委员会通常由各部门负责人组成：研发负责人、产品负责人、质量负责人、项目经理、有时还有业务方。这个结构看起来合理，实际上有一个致命缺陷，大部分委员同时也是项目资源的提供者，项目被叫停对他们自己的部门指标是不利的。
研发负责人否决项目，意味着他手下的人要重新分配；产品负责人否决项目，意味着他自己的需求规划要推翻；业务方否决项目，意味着他之前向上汇报的预期要修改。在这种激励结构下，”有条件通过”就成了一种集体默契：既显得我审查过了，又不用承担叫停的责任。
所以制度设计的第一步不是写标准，是设计激励和权力结构。
二、真实场景：跨部门团队做阶段门时到底发生了什么
1. 一个典型的中大型企业场景
我拿一家 800 人规模的智能硬件公司举例，这是我印象最深的一次改造项目。他们的产品线有三条，每条线都有独立的研发、测试、供应链团队，同时共享一个平台架构组。
他们原来的阶段门是这样的：概念评审、计划评审、开发完成评审、测试完成评审、量产评审。五个门，每个门由项目经理发起，参会人包括各线负责人，会议时长 2 小时，输出一份会议纪要。
问题出在跨部门的接口上。平台架构组不参与前两个门，因为”还没到架构讨论的时候”；供应链团队只在量产评审出现，因为”前面跟我们没关系”。结果到量产评审的时候，供应链发现某个关键物料交期 26 周，而项目计划留给采购的时间只有 8 周。这个项目最终延期 5 个月。
这个案例说明一件事：阶段门的参会人不是”按职能重要性”选的，而是”按这个阶段需要做出的决策类型”选的。供应链的问题不是量产阶段才出现的，是从概念阶段的设计选型就埋下的。如果概念评审没有供应链的人，这个门就是漏的。
2. 阶段门退化的三种典型形态
我总结过，阶段门失效基本逃不出三种形态。
（1）橡皮图章门
评审结论 90% 以上是”通过”。评审过程是项目组讲 90 分钟，委员提问 20 分钟，最后主持人说”大家没有异议吧”。没有异议的原因不是没问题，是委员手里的信息不足以形成异议。
（2）会议门
阶段门变成了一个时间点，而不是一个决策点。会议开完就结束了，没有跟踪、没有复查、没有”有条件通过”的条件闭环。我见过最夸张的一个案例，某个项目连续三次”有条件通过”，三个条件一个都没验证过，但项目已经推进到下一个阶段了。
（3）补材料门
项目组为了通过评审，会花大量时间准备评审材料而不是做项目本身。有个客户的研发总监跟我说过一句让我记到现在的话：”我们每个阶段门前一周，团队基本不干别的，就写 PPT。”这不是阶段门的问题，是阶段门被设计成了材料审查，而不是证据审查。
3. 三个最常见的误区
误区一：门越多越安全。实际上门的数量和拦截效果不是线性关系。门越多，每个门能看到的新增证据越少，委员的注意力越分散，边际拦截能力快速衰减。我在诊断中见过设 9 个门的项目，拦截效率反而不如设 4 个门的同类项目。
误区二：标准越细越严格。我见过一份 200 多条的阶段门检查表，结果项目组直接把它当成”打勾清单”，逐条勾完就认为完成了。细则的代价是执行者会失去判断力，把”满足条款”当成目标，而不是”降低风险”。
误区三：评审委员会人数越多越权威。决策人数超过 7 人之后，责任就开始分散，每个人都觉得”我不说也有别人说”。这就是典型的责任稀释。
三、制度设计：阶段门五要素模型
把上面这些问题收敛一下，我给出一套在多个组织验证过的五要素模型。这五个要素缺任何一个，阶段门都会退化。
1. 决策权：谁有一票否决权，谁只有建议权
这是最容易被含糊处理的地方。我的建议是三条规则：
- 每个阶段门必须指定一名唯一的”门主”，由他对最终结论负责。可以是项目发起人、产品线负责人或独立的质量负责人，但必须是一个人。
- 否决权只给 1，2 人，且这两人的考核不能与被评审项目的短期交付指标挂钩。如果没法做到完全脱钩，至少要引入一个独立角色，比如质量负责人或架构负责人。
- 其余委员只有建议权。他们的价值是提供专业判断，而不是投票。集体投票会直接导致责任稀释。
我知道有些组织文化里很难接受”一个人说了算”。但请注意，阶段门的否决权使用频率极低，大多数时候仍然是协商一致。真正起作用的是”有人能说了算”这件事本身带来的行为改变，项目组知道材料糊弄不过去。
2. 门禁标准：Exit Criteria 而不是 Checklist
门禁标准要回答的是”这个阶段必须产出什么、达到什么水平，才能进入下一阶段”。它应该是一组可判定的条件，而不是一张打勾清单。具体写法我在第四节展开。
3. 证据包：Evidence Package
证据包是阶段门评审的输入。核心原则是：评审会上不应该第一次看到材料。证据包必须在会前 48 小时分发，并留出书面提问期。没有预审的评审会，本质上是在用会议时间做本该提前完成的阅读。
证据包至少要包含四类内容：本阶段目标与实际结果的偏差说明、关键风险清单及应对、下一阶段的资源需求与假设、本阶段放弃的选项及其理由。第四类最容易被忽略，但价值最高，因为它反映的是决策质量而不是执行质量。
4. 会议机制：60 分钟决策会
我强烈建议把阶段门评审限定在 60 分钟，并且强制一个规则：前 20 分钟不讨论细节，只讨论偏差和风险。汇报式的前 40 分钟项目进展介绍应该被取消，因为委员已经读过证据包了，重复宣讲只是浪费所有人的时间。
5. 不通过的处置路径
这是五要素里最被忽略、但决定整个机制能否活下来的一环。不通过不是终点，必须有明确的三条出路：
- 有条件通过：列出不超过 5 条硬性条件，每条指定负责人和截止日期，到期自动触发复查，未完成则自动升级为”不通过”。
- 整改后复审：明确复审时间（通常不超过 4 周）和复审时需要补充的证据。
- 终止或转向：明确资源回收方式、已投入成本的账务处理、对相关方预期的管理动作。
另外我想强调，“有条件通过”的条件数量必须设上限。我见过一次评审给出 23 条条件的，那不是通过，那是把否决伪装成了通过。超过 5 条，说明这个阶段本身没有达到标准。
四、门禁标准怎么写：从”感觉可以了”到”可验证”
1. 三层标准结构
我建议把每个阶段门的门禁标准分成三层，这样做的好处是不同层级的问题可以在不同层级被处理，不会把商业判断混进技术检查里。
- 第一层·合规底线：必须满足，不满足直接不通过，没有讨论空间。例如安全合规审查通过、关键许可证获得、法务意见出具。
- 第二层·质量门槛：可量化、可测量。例如核心功能测试用例通过率 ≥ 95%、遗留严重缺陷数 = 0、接口性能满足 P95 < 200ms。
- 第三层·商业判断：无法完全量化，需要决策人基于证据判断。例如市场窗口是否仍然存在、投入产出预期是否变化、是否有更优替代方案。
关键点在于：第一层和第二层不能用”基本””大致””原则上”这类词，第三层则必须明确写出判断依据是什么。很多公司的阶段门标准之所以失效，就是把第三层的内容写成了第一层的语气。
2. 好标准与坏标准的对照
| 维度 | 坏标准（不可判定） | 好标准（可判定） |
|---|---|---|
| 需求 | 需求基本明确，客户认可 | Top 20 需求已完成优先级排序并签署；剩余未决需求 ≤ 3 条且均有负责人 |
| 技术 | 技术方案可行 | 关键技术风险点已完成 PoC 验证，验证报告经架构评审通过 |
| 质量 | 质量总体可控 | 严重缺陷遗留数 = 0；一般缺陷收敛趋势连续 2 周下降 |
| 资源 | 资源已协调到位 | 下一阶段所需人力已在排期中锁定，锁定率 ≥ 90% |
| 供应链 | 物料供应有保障 | 所有长交期物料已完成供应商确认，交期满足项目计划且留有 ≥ 2 周缓冲 |
这张表我建议每个团队自己照着改一遍，把现有的阶段门标准逐条对照，改完你会发现原来至少有一半条款是无法判定的。
3. 用配置化方式管理门禁标准
对于有工具支撑的团队，我建议把门禁标准做成可配置的结构，而不是写死在文档里。这样调整标准不需要重新发文件，也便于统计每个门的通过率。
下面是一份简化后的阶段门配置示例，用 YAML 表达，实际落地时可以映射到项目管理平台的阶段门模块中：
stage_gate:
id: G2
name: "开发完成评审"
owner: "研发负责人"
veto_rights: ["质量负责人", "产品线负责人"]
preconditions:
五、跨部门角色设计：谁在阶段门里做什么
1. 五种必要角色
跨部门阶段门至少需要五种角色，缺哪种都会留下盲区。
- 门主（Gate Owner）：对结论负责，主持会议，宣布结论。通常由项目发起人或产品线负责人担任。
- 项目责任人（Presenter）：提交证据包，回答质询，但不参与决策。
- 独立评审人（Independent Reviewer）：来自与被评审项目无直接利益关系的部门，如质量、架构、安全、财务。他们是否决权的主要承载者。
- 下游接收方（Downstream Receiver）：下一个阶段的实际承接方，例如测试负责人、供应链负责人、运维负责人。他们的价值在于提出”你现在交付给我的东西，我用不了”。
- 记录与跟踪人（Gate Secretary）：不参与讨论，负责记录决议、条件、责任人和截止日期，并跟踪闭环。
第四类角色是我在改造中加得最多的一类。很多阶段门失效，就是因为下一个阶段的人从来没有机会在这个阶段说话。
2. RACI 分工示例
| 阶段门活动 | 门主 | 项目责任人 | 独立评审人 | 下游接收方 | 记录跟踪人 |
|---|---|---|---|---|---|
| 确定门禁标准 | A | C | C | C | I |
| 提交证据包 | I | R | I | I | A |
| 会前预审提问 | C | I | R | R | A |
| 主持评审会 | R/A | C | C | C | R |
| 行使否决权 | C | I | R/A | I | I |
| 条件闭环跟踪 | A | R | C | I | R |
| 升级与复盘 | R/A | C | C | I | I |
这张表里有两点值得说明。第一，否决权由独立评审人承担，而不是门主。门主负责推进流程，独立评审人负责守底线，两者分离可以显著降低”和稀泥”的概率。
第二，记录跟踪人在预审环节是 A（负责），在决策环节是 R（执行）。这个设计是为了让跟踪人有动力在会前把问题问出来，而不是会后被动记录一堆无法验证的条件。
3. 三种角色冲突及处理方式
冲突一：下游接收方不参加早期阶段门。处理方式是强制的，把下游接收方的出席写进门禁标准的第一层，作为”会议有效性”的前提。人不齐，会议无效。
冲突二：独立评审人本身资源紧张，倾向于快速放行。处理方式是给独立评审人设置”评审质量指标”，例如后续阶段发现的本阶段应识别缺陷数。这个指标会让放行的短期收益变得不划算。
冲突三：门主既想推进项目又是否决人。处理方式是拆分：如果组织实在无法设置独立门主，至少要把否决权交给质量或架构负责人，门主只保留”有条件通过”的权限。
六、操作步骤：一次阶段门评审的完整运行流程
下面这套流程是我在多个项目里迭代出来的版本，从发起到闭环一共五步，全程约 10 天，实际占用核心人员的时间不超过 4 小时。
1. 会前 7 天：发出评审通知与门禁标准
这一步的作用是把”标准”提前固化。通知里必须包含：本次阶段门的门禁标准全文、证据包清单、提交截止时间、参会人名单及角色、会议时长。
我坚持要求门禁标准必须在会前 7 天发出，原因是标准一旦提前公开，项目组就会按标准去准备证据，而不是按自己的习惯准备材料。这本身就是一次有效的前置自查。
2. 会前 48 小时：证据包提交与书面预审
证据包提交后进入书面预审期。每个有否决权的评审人必须在此阶段提交书面提问，至少 1 条。这一条规则看起来很小，但它把”会上才第一次思考”变成了”会上验证思考”。
预审提问有几个规范：必须指向具体证据条目；必须说明提问的判定依据；如果提问指向的是缺失证据，直接记入待补清单。
3. 会议当天：60 分钟决策会
会议结构我建议固定成四段：
- 偏差陈述（15 分钟）：项目责任人只讲目标与实际结果的偏差，不讲进展流水账。
- 风险与假设（15 分钟）：讲下一阶段的关键假设、假设失效的后果、以及应对预案。
- 质询与讨论（20 分钟）：评审人提问，项目责任人回答。门主控制节奏，避免陷入技术细节。
- 结论与条件（10 分钟）：门主宣布结论。如果是”有条件通过”，当场逐条确认条件、责任人和截止日期。
一个硬性规则：结论必须在会上当场宣布，不允许”会后再定”。“会后再定”等同于没有结论，而且会让所有人在会后陷入等待，浪费更多时间。
4. 会后 24 小时：决议归档与条件录入
记录跟踪人在 24 小时内完成决议归档，并把所有条件录入跟踪系统，设置自动提醒。这里的关键是条件必须进入与项目任务同一套系统，而不是另建一个 Excel。条件一旦游离在项目管理系统之外，闭环率会急剧下降。
5. 门后跟踪：到期自动升级
到了截止日期，系统自动检查条件完成情况。未完成的，自动升级给门主和上一级管理者。这个自动化动作的价值在于，它把”要不要催”这个社交难题变成了系统动作，避免了人情压力。
七、工具承载：让阶段门不靠人肉推动
1. 为什么阶段门最终一定要落到工具上
我见过的失败案例里，有很大一部分不是制度设计得不好，而是制度没有承载物。条件写在一份 Word 会议纪要里，没人跟踪；门禁标准写在一份流程手册里，版本混乱；通过率统计靠人工翻记录。
阶段门对工具有三个刚性需求：标准可配置、证据可追溯、条件可闭环。这三件事靠文档和 Excel 是做不到的，尤其是在跨部门、多产品线的中大型组织里。
2. 以 PingCode 为例：阶段门在研发管理系统里怎么落
我参与过几次研发管理平台的选型与落地，其中 PingCode 是这几年在中大型企业里遇到比较多的一个。它主要服务中大型企业及 100 人以上组织，这个定位和阶段门治理的痛点恰好吻合，小团队靠人盯就够，百人以上组织必须靠系统。
它在阶段门场景下有几个点是我认为比较实用的。
第一，阶段与门禁可以配置成工作流的强制节点。团队把前面那份 YAML 里的门禁标准映射成平台的阶段门配置，第一层合规项和第二层质量指标作为阻断条件，不满足时下一阶段的任务无法流转。这就把”标准”从文档变成了系统约束。
第二，条件是挂在需求或任务上的，天然具备闭环能力。“有条件通过”的 5 条条件直接创建成带责任人和截止日期的条目，到期未完成会出现在项目的风险视图中。这比另建一个跟踪表要可靠得多，因为它和交付物在同一套上下文里。
第三，通过率、否决率、条件闭环率可以直接统计。这一点对治理很重要。我在做阶段门诊断时，第一步要的就是过去 12 个月的阶段门数据，很多公司拿不出来。如果平台自带这类统计，治理就从”凭印象”变成了”看数据”。
另外两个在选型时经常被提到的点：PingCode 支持私有化部署，这对金融、政务、军工一类有数据驻留要求的组织是硬性条件；同时它支持从 Jira 平滑迁移，包括工作项、字段映射和历史的保留，这对已经在用 Jira 的团队来说迁移成本可控，也是国产替代方案里比较务实的一个选择。
当然我也要说清楚边界：工具解决的是承载和闭环问题，解决不了”没人愿意当坏人”的问题。如果决策权设计没做对，再好的工具也只会让橡皮图章盖得更快。这两件事必须一起做。
3. 落地顺序建议
我的建议顺序是先制度、后工具，但两者间隔不要超过一个季度。具体是：先在一个产品线上把五要素模型跑通一遍，确认门禁标准写法、角色配置和条件闭环方式都可用；然后再把跑通的版本搬到平台上做配置化。
反过来做，先用工具搭一套流程，再往里塞内容，失败率很高。我见过一个客户花了四个月配置了一套非常完整的阶段门工作流，结果因为没有明确门禁标准，所有项目都在用”跳过审批”的例外通道，最后这套工作流形同虚设。
八、不同情况下的行动建议
1. 50 人以下团队：把门减到 3 个以内
小团队最大的问题是门太多会拖死自己。我的建议是只保留三个门：立项门、开发完成门、发布门。每个门的门禁标准不超过 8 条，且全部是可判定的硬指标。
决策结构上，门主一人拍板即可，但必须引入一个”外部视角”，可以是创始人、技术顾问或核心客户代表。小团队最难的是自我否定，外部视角能补上这一块。
2. 100，500 人组织：这是阶段门最容易失效的区间
这个规模的组织通常有 3，8 条产品线，部门墙已经形成，但流程规范还没有沉淀。我的建议是四到五个门，其中至少要有一个门是专门为跨部门接口设置的。
角色上必须建立独立评审人机制，哪怕只有一个人兼职。同时建议引入工具承载，因为这个规模已经开始出现”跟踪靠人记”的问题。
3. 500 人以上或多产品线组织：分层治理
大组织不适合所有项目走同一套阶段门。我建议按项目影响面分三级：影响公司级营收的项目走完整五门；影响单个产品线的走三门；小规模迭代走轻量审批。
同时必须建立”例外通道的审计机制”。大组织总会有紧急项目需要跳过某些门，这是合理的，但例外本身必须被记录、被统计、被定期复盘。没有审计的例外通道，最终会吞掉整个流程。
4. 强监管行业：额外增加合规门
金融、医疗、汽车电子这类行业，阶段门需要额外增加合规审查层。这类门的特点是标准高度外生（来自监管要求），因此不应该和业务判断混在一起评审。我建议把合规门做成独立通道，由法务或合规部门单独出具意见，通过后再进入业务阶段门。混在一起的结果通常是业务压力把合规意见稀释掉。
九、不同情况下的取舍
阶段门设计里没有”全都好”的方案，只有明确的取舍。下面四组是我在项目中反复要做的权衡。
1. 严格度与速度：拦截率提升必然带来周期变长
这是最根本的一组取舍。门禁标准越严，早期拦截的问题越多，但项目周期也会变长。我的经验值是：把门禁标准的严格度提升一个档位，项目平均周期会增加 8%，15%，但后期返工成本会下降 25%，40%。
所以我一般建议：对交付周期敏感、试错成本低的项目（如互联网产品迭代），阶段门适度放宽，重点放在发布门；对返工成本极高、交付不可逆的项目（如硬件量产、系统上线），阶段门必须收紧，前三道门尤其不能松。
2. 决策人数与决策效率：超过 7 人开始失效
我做过一个粗略统计：评审委员会人数从 5 人增加到 9 人，平均决策耗时从 1.2 小时增加到 3 小时以上，而识别出的新增有效风险不足 10%。也就是说，增加决策人数带来的边际收益极低，边际成本极高。
取舍原则：核心决策圈控制在 3，5 人，其余人员以”提供书面意见”的方式参与，不进入决策会议。这样既保留了专业输入，又不会拖慢决策。
3. 标准化与灵活性：例外通道必须存在，但要有成本
完全标准化会逼着团队造假，完全灵活等于没有制度。我的建议是保留例外通道，但给例外设置成本：每一次例外都需要门主和一位独立评审人共同签字，并且自动进入季度复盘清单。
这个设计的巧妙之处在于，它不禁止例外，但让例外变得”需要解释”。绝大多数不必要的例外会因为这个成本而消失。
4. 自建与采购：不要在阶段门本身上做定制开发
我见过一些公司自研阶段门管理模块，投入 6，12 人月，最后维护成本超过使用价值。我的判断是：阶段门的运行机制是通用的，不值得自研；值得自研的是门禁标准的具体内容，因为那是业务知识。
所以取舍建议是：流程承载用成熟平台，门禁标准、证据模板、评审规则用自己的。这也是为什么像 PingCode 这类支持私有化部署和深度配置的平台，在中大型组织里比较受欢迎，通用部分开箱即用，业务部分可以自己定义。
十、落地检查清单与下一步
最后我把整篇文章收敛成一份可以直接拿去做自查的清单。你可以对着现有阶段门体系逐条核对，凡是打不上勾的，就是你下一步要补的地方。
- 每个阶段门是否指定了唯一的门主，且门主对口否决结论负责？
- 否决权是否交给了考核与项目短期交付脱钩的人？
- 门禁标准中可客观判定的条款占比是否超过 70%？
- 是否存在至少一个专门针对跨部门接口的阶段门？
- 证据包是否在会前 48 小时分发，且有强制书面预审提问？
- 评审会议是否控制在 60 分钟内，且取消了进展宣讲环节？
- “有条件通过”的条件数量是否有上限（建议 5 条）？
- 条件是否录入与项目任务同一套系统，并设置了到期自动升级？
- 过去 12 个月的阶段门否决率与有条件通过率是否可统计？
- 例外通道是否有签字要求和定期复盘机制？
如果这十条里有超过三条没打上勾，我建议你不要急着上一个新工具，先把制度和角色这两块补上。因为工具会放大制度的效果，也会放大制度的缺陷。
下一步我建议做一件很小的事：把你们最近一次阶段门的评审记录翻出来，逐条核对当时的”通过条件”，看看有几条真的闭环了。这个数字会非常直观地告诉你，你们的阶段门到底是决策机制，还是仪式。
常见问题解答（FAQ）
1. 阶段门的准出条件怎么定，才能让跨部门评审不吵架？
我们做的是软硬件混合作项目，每到阶段门评审就变成扯皮大会：研发说文档齐了，测试说用例还没跑完，市场说需求早就变了。制度里只写了一句“本阶段工作完成”，结果每次都要靠嗓门定胜负。我特别想知道，通过标准到底该怎么写才不乱。
把“通过标准”从一句话改成可判定的证据清单，每条拆成三段：判定项、证据形式、判定人。比如不要写“需求文档完成”，要写“需求基线已冻结，需求条目数与变更流程已定义，证据=需求基线评审记录+变更台账模板，判定人=产品负责人+系统工程师”。
同时给门槛分两类：硬门（安全、合规、成本红线，一票否决）和软门（进度、质量，允许带条件通过），硬门每阶段控制在3到5条，超过就没人记得住了。裁决结果固定三档：通过、有条件通过、不通过；
有条件通过必须列明条件、责任人和关闭日期，条件项上限3条、关闭期限不超过2周，这是我们踩出来的经验值，条件超过3条的项目基本都会烂尾。操作上，评审前3个工作日由PMO把证据包发给评审人预审，评审会只讨论“证据是否满足”，不讨论“要不要满足”，会议性质一改，吵架量能掉一大半。
2. 跨部门评审人总说没时间，阶段门评审怎么才不走过场？
我是项目经理，每次拉研发、测试、市场、供应链来评审，会上只有我一个人在讲，其他人低头看手机，最后签字了事。等到出问题复盘，每个人都说不清楚，锅就落在我头上。这种评审到底还有没有必要坚持？
先改会议形态：把“评审会”拆成“预审+决策会”。材料提前72小时发出，评审人必须在系统里逐条勾选“同意/有异议/信息不足”，决策会只处理有异议的条目，会议时长一般能从2小时压到40分钟。
第二，制度里明确写“未表态视为默认同意，事后不可追责”，这条看着狠，但它把沉默从免责手段变成了有成本的默认同意，评审人才有动力提前看材料。
第三，评审人角色要精简，每道门5到7人就够，其中只有1到2人真正握有一票否决权（通常是质量、安全或财务），其余是咨询角色，人越多责任越稀释，这是评审走过场的根本原因。KPI也要改：考核“异议提出的质量”而不是“出席率”，出席率是唯一一个靠坐着不动就能拿满分的指标。
3. 阶段门和敏捷迭代节奏冲突，团队嫌流程太重，怎么办？
我们研发跑双周迭代，交付节奏本来挺顺的，但公司要求每个阶段都得做阶段门评审，团队要额外准备PPT、拉会、走签批。大家私下都在吐槽说这是给敏捷加官僚主义，我夹在中间很难受。
思路是让门长在迭代上，而不是长在迭代旁边。具体做法：阶段门只卡在阶段最后一次迭代的回顾会之后，直接复用迭代评审会的产出，不再单独让团队做PPT。因为阶段门要看的东西本来就是迭代的副产品，可运行版本、缺陷趋势、需求变更记录。
如果这些东西拿不出来，说明迭代本身没产出可验证的成果，那门不是额外负担，而是帮你发现了问题。第二是砍门的数量：6到9个月的项目周期，硬门3到4道足够（立项、方案冻结、上线、结项），其余降级为检查点，检查点邮件或系统确认即可，不开会。
判断依据很简单：如果一道门平均占用团队超过8人小时，就要砍它的检查项，而不是去说服团队多花时间。
4. 阶段门怎么在一个项目管理工具里真正落地，又怎么判断门是真的过了？
我们制度文件写了十几页，执行全靠Excel加邮件，谁改了什么根本查不到。我想在某项目管理平台里把它固化下来，但不确定字段和流程该配到什么颗粒度。也不想配完变成一堆形式主义的打卡。
核心原则是让“门”变成一个可追踪的对象，而不是一场会。配置上做三件事：一，建立“阶段门”实体（里程碑或专门的任务类型），字段包括门名称、计划裁决日期、通过标准清单、裁决结果、条件关闭日期、裁决人。
二，把通过标准清单拆成子条目，每条必须挂证据链接（文档、测试报告、代码分支、样机照片），没挂证据的条目不允许勾选通过。三，用工作流规则做门禁：门未裁决为通过或有条件通过之前，下一阶段的任务不能被拉进“进行中”状态，由某项目管理平台自动拦，而不是靠人盯。
度量上盯两个指标就够：门按时通过率=按计划日期±3天内裁决为通过或有条件通过的门数÷应裁决门数；条件关闭逾期率=超过关闭日期的条件项÷全部条件项。这两个数字比“开了几次会”有用得多，也直接暴露流程是不是在空转。最后提醒一个坑：绝对不要开放补录。
我们最早允许事后补填日期，季度复盘时发现80%的门记录都是补的，所有度量瞬间归零。
文章包含AI辅助创作：项目阶段如何做好阶段门？跨部门团队制度设计与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/333406
读者评论
关于“决策人同时是资源提供方”这条有同感。我们后来引入了一个独立质量角色参与评审，但他的人事和预算还在研发副总下面，评审前一周基本就被沟通过了。制度上脱钩和实际上脱钩是两件事，靠流程文件好像解决不了。
不通过处置路径那段说到点上了，但“有条件通过不超过5条”我觉得要分阶段看。概念阶段本来信息就少，硬凑出五条可验证的硬条件，反而逼着团队编出好看但没意义的指标。有时候诚实的结论就是“证据不足，四周后复审”，不一定非要包装成有条件通过。
会前48小时发证据包加60分钟决策会，我们在三十来人的团队试过一轮，结果是预审几乎没人看，会上又从头讲一遍，反而多了一道文档负担。小团队口头同步确实更快，这套会议机制可能更适合中大型组织，直接照搬容易水土不服。