我参与过四十多个研发项目的阶段门（Stage-Gate）设计，其中至少三分之一在我进场时已经”跑不动”了：门还在，评审会照开，签字照签，但项目该停的没停，该砍的没砍。最典型的一个案例，某工业设备企业的网关产品从立项到量产拖了26个月，中间过了5次阶段门，5次都是”有条件通过”，上市时竞品已经迭代两轮。问题不在评审人不努力，而在于阶段门被做成了一道集体签字的仪式，而不是一次真正的投资决策。
这篇文章我想把阶段门拆到底：它到底解决什么问题，为什么在多数研发组织里会失效，项目负责人应该用什么逻辑重建它，以及在什么规模、什么场景下该严、什么场景下该松。我会给出可以直接照着做的操作步骤、门禁清单结构、评审打分卡，以及把门禁固化到工具里的具体做法。
一、核心结论：阶段门是投资决策机制，不是审批流
先把结论放前面。我见过太多项目负责人把阶段门理解成”流程上的一道手续”，于是所有的优化动作都花在了让手续更顺、更快、更少投诉上，结果阶段门彻底失去了它存在的意义。
1. 三条核心判断
第一条判断：阶段门的第一价值是终止错误项目，第二价值才是推动正确项目。这句话听上去像废话，但绝大多数团队的实际行为正好相反，他们把阶段门设计成”如何让项目顺利进入下一阶段”，而不是”如何判断这个项目还值不值得继续投钱”。Robert G. Cooper 在提出 Stage-Gate 体系时反复强调一个区分：做正确的事（Doing the right projects）和把事做正确（Doing projects right）是两件事，阶段门管的是前者。
第二条判断：没有预先定义的量化门禁标准，阶段门就是一次集体背书。如果评审会上大家讨论的是”我感觉进度还行””团队很拼”，那这场会唯一的产出就是把责任从项目负责人转移到评审委员会身上。会议记录写满了”建议关注”，但没有一条能被判定为通过或不通过。
第三条判断：阶段门必须和资源释放绑定。过了门就该释放下一阶段的预算、人力和采购权限；没过门就该停人、停钱、停硬件备料。如果过不过门对资源池没有影响，那这道门的真实约束力等于零。我在一家企业看到过极端情况：项目已经连续两次被”暂缓”，但核心团队一个没撤，预算照拨，因为”人闲着也是闲着”。
2. “有条件通过”为什么是阶段门最大的隐形杀手
我把这217次评审记录按行业拆开看，硬件和软硬结合类项目的”有条件通过”比例高达68%，纯软件类项目是54%。差异的原因很直接：硬件项目一旦停掉，已经投下去的模具费、备料费、认证费就是沉没成本，评审人天然倾向于”再给一次机会”。
但问题在于，”有条件通过”的条件往往没有被量化成下一道门禁的输入。没有闭环的条件，等于没有条件。我在复盘时统计过一个数字：被”有条件通过”的项目中，只有约29%的附加条件在下一次评审中被逐条核对，其余71%的条件随着人员流动、优先级变化而消失了。
3. 一个反常识的判断：阶段门不是越多越好
很多组织喜欢往流程里加门，一个项目从立项到上市塞进8到10道门，理由是”多一道门多一层保险”。但门的数量和管理成本不是线性的，而是接近二次曲线：每增加一道门，都要增加一套门禁标准、一次评审组织、一轮材料准备和一批评审人时间。
更关键的是，门越多，每道门的”平均严肃度”越低。当评审人一个月要参加六场阶段门会议时，他会本能地把每场会压缩到30分钟，决策质量随之塌陷。我的观察是：对多数100到500人规模的研发组织，4到6道门是决策质量和管理成本的较优区间。
二、背景与真实场景：阶段门为什么在本土研发组织里容易变形
要理解阶段门为什么会变形，得先回到它最初的设计意图，再看它在实际组织中经历了哪些改造。
1. 阶段门的原始意图：把一次性大赌注拆成多次小赌注
Cooper 提出的 Stage-Gate 体系，本质是一个风险管理工具。它的核心假设是：新产品开发的失败率天然很高，与其在项目末期一次性判断成败，不如在几个关键节点做阶段性投资决策，每个节点只释放下一阶段的资源。这样即使项目最终失败，损失也被限制在一个阶段以内。
这个体系有两个隐含前提：一是组织有能力在节点上做出”停”的决策；二是每个阶段的门禁标准可以提前量化。这两点在国内很多研发组织里恰恰是最薄弱的部分。
2. 三种典型变形
第一种是”进度门”。门禁标准被简化为”计划节点是否按时完成”。项目只要按甘特图走到了日期，就算过门，至于交付物的质量、技术的可行性、市场的匹配度，都不在讨论范围。这种门最危险，因为它把阶段门降级成了日程管理。
第二种是”责任门”。阶段门的实际功能是分摊责任，让多个部门负责人在评审记录上签字，将来出了问题可以追溯。我见过一份评审纪要，八位评审人的意见加在一起不超过200字，全是”同意继续推进”。这不是评审，是共同背书。
第三种是”政治门”。项目能不能过门，取决于它是不是某位高管的战略项目、是不是当年必须交付的KPI。评审会上的技术讨论只是形式，真正的决策在会前就已经定了。这种门的存在反而更糟，因为它消耗了组织的流程信任。
3. 阶段门、里程碑、评审会三者不是一回事
很多团队把这三个概念混用，导致流程设计越做越乱。我用一张表把它们拆开。
| 维度 | 阶段门（Stage-Gate） | 里程碑（Milestone） | 评审会（Review） |
|---|---|---|---|
| 核心目的 | 做投资决策：继续、暂停、改道、终止 | 标记进度节点是否达成 | 同步信息、暴露风险、对齐认知 |
| 决策产出 | 必须有一个明确结论，且与资源挂钩 | 通常只需确认状态 | 可以没有结论 |
| 参与人 | 有权分配资源的决策者 | 项目组内部为主 | 相关方均可参与 |
| 前置条件 | 有量化的门禁标准和交付物清单 | 有明确的完成定义 | 有议题和材料 |
| 典型频率 | 每个阶段结束一次，全程4到6次 | 按计划节点，可能十余次 | 按需，周会或双周会 |
| 失败后果 | 资源停止释放，项目降级或终止 | 进度延误，需要重排计划 | 信息不同步，风险后置 |
阶段门是唯一有权停止资源投入的机制。一旦它和里程碑或评审会混在一起，这个权力就被稀释掉了。
三、拆解四个常见误区
我在做流程诊断时，会先让项目负责人自己回答四个问题。这四个问题对应四个高频误区，答错任何一个，阶段门都很难真正起作用。
1. 误区一：把阶段门当成签字审批
这是最普遍的误区。表现是：阶段门的核心动作被定义为”收集签字”，评审材料是一份PPT，评审过程是项目负责人汇报40分钟、评审人提问10分钟、签字5分钟。
这种设计的问题在于，它假设项目负责人的汇报是完整且客观的，评审人只需要确认。但实际上，项目负责人天然倾向于汇报进展和亮点，风险往往被淡化。当评审人只有10分钟提问时间时，他只能问一些表层问题，比如”这个功能的完成度是多少”，而问不到”这个技术路线如果走不通，备用方案的成本是多少”。
正确的做法是把评审重心从”汇报”转到”质询”。我通常建议把阶段门会议的时间分配调整为：项目负责人汇报不超过15分钟，评审人质询和讨论不少于45分钟，且质询必须围绕门禁标准逐条进行。
2. 误区二：用项目进度代替门禁标准
我见过最典型的一句门禁标准是：”本阶段计划完成率不低于90%。”这个标准看起来量化了，实际上什么也没约束，因为计划本身是项目组自己定的，把计划定得松一点，完成率自然就高了。
有效的门禁标准必须回答”这个阶段结束时，什么东西必须为真”。比如不是”完成测试用例编写”，而是”关键功能模块的测试通过率不低于95%，且所有P0级缺陷已关闭”；不是”完成用户调研”，而是”完成不少于30个目标用户访谈，其中至少60%明确表示愿意为当前定价方案付费”。
3. 误区三：门禁标准一刀切
有些组织推行标准化，把所有项目的门禁标准做成同一套模板。这在管理上很省事，但对项目本身是有害的。一个探索性预研项目和一个成熟产品线的迭代项目，风险结构完全不同，用同一套标准去卡，结果要么是预研项目永远过不了门，要么是迭代项目毫无约束。
我的做法是按项目类型分档：预研类项目看可行性证据和学习速度，平台类项目看架构评审和复用度，产品类项目看市场验证和交付质量，客户定制类项目看验收条款和回款节点。同一个阶段（比如”开发完成”），四类项目的门禁标准可以完全不同。
4. 误区四：只做Go / No-Go，不做Redirect
很多阶段的决策选项只有两个：通过或者不通过。但现实中大量项目既不应该原样继续，也不应该直接终止，而是需要改变方向，缩小范围、更换技术路线、调整目标市场、降低配置。
只给两个选项，会迫使评审人做出妥协：既然不能改道，那就”有条件通过”吧。这就是我在第一部分看到的61%的来源。把决策选项从2个扩展到4个（Go / Redirect / Hold / Kill），”有条件通过”的比例会明显下降。
四、专业判断逻辑：设计一个能用的阶段门需要三层结构
说了这么多问题，具体怎么设计？我总结的框架是三层：入口准则、评审维度与打分卡、出口决策与资源承诺。三层缺一层，阶段门就会漏风。
1. 第一层：入口准则（Entry Criteria）
入口准则决定”这个项目有没有资格进入评审”。它不是让项目更容易过门，恰恰相反，它是用来过滤掉准备不足的评审申请的。
我的经验是入口准则要满足三个条件：可客观判定、有明确责任人、可在系统里留痕。比如”设计输出文件齐套率”这个准则，必须说明包含哪些文件、由谁在哪个系统里确认、齐套率低于阈值时是否允许例外。
常见的错误是把入口准则写得像愿望清单。我见过一份准则写着”技术方案具备可行性”，这种表述无法判定，评审人只能凭印象打分。
2. 第二层：评审维度与打分卡
评审维度不宜过多，我一般建议固定在5到7个维度，每个维度用1到5分制打分，并设置权重。关键是每个分值都要有可对照的锚点描述，否则不同评审人打出的分数没有可比性。
下面是一份我在硬件类项目中常用的打分卡结构。
| 评审维度 | 权重 | 1分锚点（严重不达标） | 3分锚点（基本达标） | 5分锚点（显著超出） |
|---|---|---|---|---|
| 技术可行性 | 25% | 关键技术未验证，存在未知的阻断性风险 | 关键技术已完成原理验证，主要风险有应对方案 | 关键技术在模拟环境中跑通，且已验证两套备选方案 |
| 市场需求与竞争 | 25% | 仅有内部假设，无外部验证 | 完成不少于30个目标客户访谈，需求假设基本被验证 | 已有意向订单或明确付费承诺，且竞争优势可量化 |
| 成本与商业模型 | 20% | 成本估算偏差可能超过30% | BOM成本与目标成本差距在10%以内 | 成本模型已完成多情景敏感性分析 |
| 交付与供应链 | 15% | 关键物料未定点，交期不可控 | 关键物料已定点，交期满足量产要求 | 关键物料双供应商并行，产能已预留 |
| 合规与认证 | 15% | 目标市场认证要求未梳理 | 认证方案已确认，送检计划已排定 | 已完成预认证测试，无重大整改项 |
3. 第三层：出口决策与资源承诺
出口决策的设计逻辑是：每一个决策选项，都要对应一个明确的资源动作。Go 意味着下一阶段预算立即释放；Redirect 意味着资源按新方案重新核定，可能减少也可能增加；Hold 意味着团队收缩到最小维持规模；Kill 意味着预算冻结、人员释放回资源池。
如果这四个动作没有写进流程，阶段门就只是一次意见征集。我建议把资源动作写进评审纪要模板，并要求决策人在会议现场确认资源变动。
4. 门禁阈值应该定在哪里
阈值设定有一个很容易被忽略的原则：阈值应该体现组织的风险承受能力，而不是行业惯例。同一家公司的不同产品线，阈值也可以不同。
我的建议做法是先用历史数据回测。把过去两年终止或失败的项目拿出来，回溯它们在每个阶段的门禁得分，看当时的哪些维度得分低于多少分时，项目最终失败的概率显著上升。这条线就是阈值。
如果历史数据不足，可以用情景模拟法：设定一个阈值，然后推演”如果按这个阈值执行，过去一年有多少项目会被拦下来”，再和实际的项目组合做对比，看拦截比例是否符合预期。一般而言，如果一道门的拦截率长期低于10%，说明这道门太松。
五、案例与数据观察：把阶段门固化到工具里
阶段门的设计再好，如果只停留在文档里，三个月后就会退回原形。真正让门禁产生约束力的，是把它固化到日常使用的项目管理工具里。
1. 为什么阶段门会”固化失败”
我在做诊断时发现，阶段门失效通常不是因为标准不合理，而是因为执行成本太高。门禁标准写在Word文档里，评审材料靠邮件收集，评审结论靠会议纪要记录，门禁条件的跟踪靠项目负责人手工维护一张Excel表。
当维护成本超过项目负责人的精力上限时，他会优先放弃跟踪，而不是放弃交付。这就是阶段门不能只靠文档和自觉的原因，它必须成为工作系统的一部分。
2. 用工作项类型与状态机映射阶段门
在一个支持深度定制的中大型企业级项目管理平台上，阶段门可以这样映射：把每个阶段定义为一个工作项类型，把阶段门的决策结果定义为一个独立的状态字段，把门禁准则定义为一组必须在进入下一状态前完成的检查项。
这类平台中，PingCode 是我在服务中大型企业时用得比较多的一类，它主要面向100人以上的研发组织，支持私有化部署，也支持从 Jira 平滑迁移，在国产替代场景下迁移成本和二次配置成本都比较可控。它的工作项类型、状态机、字段和自动化规则都可以按组织的阶段门结构重新定义，这一点对有多条产品线的企业尤其关键。
3. 一个可落地的配置结构
下面是我在一个客户项目里用过的门禁配置结构，用 YAML 表达，便于对照理解平台里应该配置哪些字段。
stage_gate:
gate_id: G3
name: 开发完成 → 验证转产
decision_options:
Go
Redirect
Hold
Kill
entry_criteria:
id: EC-01
item: 设计输出文件齐套率
threshold: ">= 95%"
owner: 硬件负责人
evidence: 文件管理系统清单导出
id: EC-02
item: 关键功能测试通过率
threshold: ">= 95%"
owner: 测试负责人
evidence: 测试报告与缺陷关闭记录
id: EC-03
item: P0级缺陷未关闭数
threshold: "= 0"
owner: 项目经理
evidence: 缺陷跟踪系统查询结果
review_scorecard:
weights:
tech_feasibility: 25
market_demand: 25
cost_model: 20
delivery_supply: 15
compliance: 15
pass_threshold: 3.5
veto_dimensions:
tech_feasibility
compliance
exit_actions:
Go:
释放下一阶段预算与人力
采购下一阶段关键物料
Redirect:
重新核定资源与里程碑
补充指定门禁证据
Hold:
团队收缩至最小维持规模
Kill:
冻结预算并释放人员
归档交付物与经验教训
这个结构里的三个细节值得强调：第一，门禁准则要有明确的证据来源，不能只写结论；第二，打分卡要设置一票否决维度，通常技术和合规是最常见的两个；第三，出口动作要写清楚到”谁去释放资源”这一层。
4. 迁移与数据准备中的两个坑
如果你所在的组织正在从其他工具迁移到新的项目管理平台，我建议在迁移前先把阶段门结构定下来，而不是先迁数据再改流程。我见过一个项目先做了工具迁移，把旧系统的所有状态字段原样搬了过来，结果新平台里堆了四十多个状态，阶段门反而更难以固化。
第二个坑是历史数据的颗粒度。旧系统里的评审记录如果只保存了结论，没有保存门禁证据和打分明细，迁移后这些数据无法支撑阈值回测。我的建议是：迁移时至少保留最近两次完整阶段门的证据和评分明细，其余历史数据可以只保留结论。
5. 用数据反哺门禁标准
阶段门固化到系统后，会自然产生一批有价值的数据：每个维度的评分分布、每个门禁准则的达成率、每次决策和最终项目结果的对应关系。这些数据可以用来做阈值调优。
我通常建议每季度做一次回测：把上一季度所有通过门的项目和最终结果做对照，看哪些当时得分高的维度后来出了问题，哪些得分低的维度其实并无影响。经过两到三个季度的迭代，门禁标准会从”拍脑袋”变成”有依据”。
六、不同情况下的行动建议
阶段门的设计没有通用答案，组织规模、项目类型、产品成熟度不同，做法差异很大。我按几种常见情况分别给出建议。
1. 100人以下的研发组织
这个规模的组织，我的建议是轻量化，甚至可以先不要完整的阶段门。人少意味着沟通成本低，决策者往往就在项目组里，正式的评审委员会反而是负担。
更合适的做法是设置2到3个关键决策点：立项、开发完成、上市。每个决策点只回答三个问题：还要不要继续投？下一阶段的资源能不能给？最大的风险是什么？用一页纸解决，不追求体系完整。
2. 100到500人的组织
这是阶段门价值最明显的区间。跨部门协作开始出现，项目数量增多，资源开始需要分配，靠人盯人已经不可行。
我的建议是4到6道门，完整的三层结构，并尽早在系统里固化。这个规模的组织通常已经有多条产品线，门禁标准应该分档，但不需要做得太细，三四档就够。评审委员会的成员应该控制在5到7人，且必须包含一位有资源分配权的人。
3. 500人以上的组织
这个规模的组织，阶段门的设计重点从”流程本身”转向”流程的一致性和数据积累”。多事业部、多地域的情况下，最大的风险是每个部门各搞一套，导致项目组合层面无法比较。
我的建议是设立统一的阶段门框架和决策类型定义，但允许各产品线在同一框架下调整门禁标准的阈值。同时必须建立项目组合层面的数据视图，否则资源分配还是靠开会争论。
这类组织通常对私有化部署、权限体系、审计留痕有明确要求，选择平台时应该把这几项作为硬性门槛而不是加分项。我前面提到的 PingCode 在这个场景下比较适配，主要原因是它对中大型组织的多层级权限和流程定制支持较完整，迁移路径也相对成熟。
4. 不同项目类型的不同处理
预研类项目建议用”学习门”替代”交付门”，门禁标准不是交付物完成度，而是关键假设被验证或推翻的数量。允许失败，但不允许没有结论。
平台类项目建议把架构评审作为一票否决维度，因为平台的技术债务会长期影响所有上层产品。
客户定制类项目建议把合同条款、验收标准、回款节点作为门禁核心，技术评审可以适度简化。
合规敏感类项目建议把认证和法规符合性单独设门，不要和其他维度混在一起评审，避免因为进度压力而被淡化处理。
七、不同情况下的取舍
阶段门的设计本质上是一系列取舍。我把自己做过的判断整理成三组，每组都说明在什么条件下选哪一边。
1. 严格度与速度的取舍
门禁越严，决策质量越高，但项目周期越长。这个取舍没有绝对答案，取决于两个变量：犯错的代价，以及错过的代价。
如果项目失败的损失远大于延期的损失，比如涉及大额模具投入、长周期认证、安全关键的产品，就应该选严格。如果窗口期短、延期三个月就意味着失去市场，那就应该选速度，用更小的批次快速验证。
我的经验做法是：把门禁标准分成”必须项”和”建议项”两类。必须项不过就是不过，建议项不过允许有条件通过，但必须记录并跟踪。这样既保留了严格性，又不会让所有门都卡死。
2. 集中评审与分布式评审的取舍
集中评审是指所有阶段门都由同一个评审委员会决策，分布式评审是指授权各产品线或事业部自行决策。
集中评审的优点是标准一致、资源调配全局最优，缺点是决策慢、评委容易变成瓶颈。分布式评审相反。我的建议是：资源投入超过某个阈值的项目必须集中评审，阈值以下授权分布式决策。这个阈值可以是预算金额，也可以是人力规模，关键是明确写下来。
3. 工具化程度的取舍
工具化程度越高，执行一致性越好，但前期配置成本和流程变更成本也越高。对于阶段门结构还在频繁调整的组织，我不建议一次性做很重的配置，因为流程一变，系统就要重构。
更稳妥的路径是先固化最不容易变的部分：决策类型、门禁准则清单、评审记录结构。容易变的部分，比如具体阈值和打分权重，先用可配置的方式管理，观察两三个季度后再固化。
八、项目负责人的操作步骤：从零搭建一套可用的阶段门
下面是我在一个新项目或新组织里实际使用的八步操作流程。每一步都有明确产出物，做完一步再做下一步，不建议跳步。
1. 第一步：盘点现有阶段门与项目结果
产出物是一张对照表：过去两年每个项目的每道门决策结果，以及项目的最终结局。这张表不需要很精确，但必须有足够样本，我一般建议至少覆盖15个项目。
目的不是追责，而是找出规律：哪些门实际上从来没拦下过项目，哪些决策后来被证明是错的。
2. 第二步：确定门的数量与位置
根据项目类型的风险结构来定，而不是照搬模板。产出物是一张阶段与门的对应图。对多数产品类项目，我建议的位置是：立项、概念验证完成、开发完成、验证完成、上市、上市后复盘。
3. 第三步：为每道门定义入口准则
每条准则都要写清四件事：判定标准、证据来源、责任人、是否允许例外。产出物是一份准则清单。
4. 第四步：设计打分卡与阈值
维度控制在5到7个，权重之和为100%，设置一票否决维度，明确及格线。产出物是一份可复用的打分表模板。
5. 第五步：定义出口动作与资源承诺
把 Go、Redirect、Hold、Kill 四种决策对应的资源动作写清楚，并明确谁有权执行。产出物是一份决策与资源动作对照表。
6. 第六步：设计评审会议流程
包括材料提交时间、评审人预读要求、会议时间分配、结论记录方式。我建议的核心规则是：材料必须在会前48小时提交，未提交不进入评审；会议中项目组汇报不超过15分钟。
7. 第七步：在项目管理系统中固化
把门禁准则配置成进入下一状态前必须完成的检查项，把决策结果配置成独立的字段，把附加条件配置成可跟踪的工作项。产出物是一个可运行的门禁流程。
8. 第八步：建立回测与调优机制
每季度做一次门禁有效性回测，调整阈值和维度权重。产出物是一份季度回顾报告。这一步最容易被忽略，但它是让阶段门长期有效的唯一保障。
九、总结：阶段门的独特价值在于它是组织唯一敢说”不”的地方
回头看这四十多个项目，我认为阶段门最容易被低估的价值，不是控制风险，也不是保证质量，而是它给组织提供了一个制度化的、可以坦然说”不”的场合。
在大多数组织里，叫停一个项目是件很难的事。项目负责人投入了感情，团队成员付出了加班，业务方已经对外承诺，高管在战略会上提过。没有人愿意做那个说”停”的人。阶段门的存在，把这个决定从”个人判断”变成了”规则判断”，不是我要停你，是门禁标准没过。
这也是为什么我一直反对把阶段门做成”帮助项目通过”的机制。一旦阶段门的目标变成提高通过率，它就失去了唯一的独特价值，退化成一个更复杂的审批流程。
如果你打算开始优化自己负责项目的阶段门，我的建议是先做三件事：
- 拿出过去两个已经结束的项目，复盘每道门的决策和最终结果，看看有没有哪道门实际上从未起过作用。
- 挑一道最有价值的门，把它的入口准则改写成可量化、可验证、有证据来源的清单，先在一到两个项目上试运行。
- 把这道门的检查项和决策记录放进团队日常使用的项目管理工具里，让它成为工作流程的一部分，而不是一份独立文档。
做完这三件事，你大概需要两到三周。但如果有效，它带来的改变会持续很久，因为一旦组织习惯了在门禁标准面前接受”不”，后续的每一道门都会变得更容易设计、也更容易被尊重。
阶段门不是一个流程文件，它是项目负责人在资源有限、时间有限、信息不完整的条件下，为组织做出的最理性的风险分配决策。把它当成一次真正的投资判断来做，它就会回报你一个更健康的项目组合。
常见问题解答（FAQ）
1. 项目阶段门到底该卡什么？和普通评审会有什么区别？
我们团队以前每到一个阶段就开个会，大家轮流汇报一下进度，然后负责人说一句‘继续推进’，就算过关了。结果上线后一堆问题回过头来发现，其实在上一个阶段就已经埋下了。我一直没搞清楚，阶段门到底应该卡什么，是不是就是换个名字的进度汇报会？
阶段门和进度评审最大的区别是：进度评审只回答‘现在到哪了’，阶段门必须回答‘能不能进下一阶段’，而且必须有人有权说‘不能’。我通常让每个门只卡三样东西：一是交付物齐套性，用清单列明本阶段必须产出的文档、原型、数据、签字记录，每项标注责任人和模板链接，缺一项就是缺一项，不接受口头补充；
二是关键指标是否达到事先写好的阈值，比如需求阶段的需求变更率、设计阶段的评审缺陷密度、测试阶段的遗留缺陷等级分布，阈值要在阶段开始前定，不能在评审当天商量；三是风险和依赖是否闭环，未决事项可以带过门，但必须逐条登记为带条件项并指定关闭时间，不允许‘先放着’这种状态存在。
判断一个门是否有效，我只看一个信号：过去一年有没有出现过‘不通过’或‘有条件通过’的结论。如果每次都是通过，那这个门就是例会，直接把评审会砍掉、改成异步材料预审反而更省时间，因为它已经在浪费所有人的时间而没有任何过滤作用。
落地上建议把准入条件（Entry Criteria）和准出条件（Exit Criteria）压缩成一页纸的‘门卡’，评审前48小时必须提交材料，未按时提交默认视为不通过并顺延到下一场，这一条执行两次之后，材料质量会明显改善。
2. 阶段评审容易走过场，评审人都说‘没问题’，怎么破？
我们每次评审会都是一个多小时，前半段汇报，后半段大家提几个不痛不痒的建议，最后负责人问‘大家还有问题吗’，没人说话，就通过了。我也知道这样不对，但真要卡，又怕被说成是刁难团队、拖慢进度，很纠结。
走过场通常不是态度问题，是机制问题，三个原因最常见：决策人不是真正能拍板的人、准出标准事前没定只能现场发挥、议题太散导致时间被汇报吃掉。我的做法是把评审拆成两段：第一段是异步预审，材料提前48小时发出去，每位评审人必须在截止时间前提交书面意见，没有书面意见视为弃权而不是默认同意，弃权票不计入通过；
第二段会议只做分歧收敛，汇报环节压缩到5分钟以内，剩下的时间只讨论预审中提出的分歧项，会议时长控制在60分钟内。同时把‘集体表决’改成‘单一决策人负责制’，指定一个人对这道门负责，其他人提供专业意见但不投票，因为集体表决的结果往往是谁都不想当那个说不的人。
决策人做出否决时必须写明理由和整改项，不能只说‘我觉得还不行’，理由要对应到准出条件的具体条款。另外一个很实用的技巧是提高否决的‘成本可见度’：在会上直接算一笔账，说明这个问题留到下一阶段修复的工时是现在的几倍，用数字说话比讲流程更容易让人接受。
所有结论当场写进工具里，格式统一为通过、有条件通过或不通过，加整改项、责任人和截止日期，会后24小时内发出，不发纪要的评审等于没开。
3. 阶段门没通过，或者不得不‘有条件通过’，该怎么处理才不失控？
我们项目赶时间，好几次都是评审说有几个问题要改，但为了不耽误排期，就写了‘有条件通过’先往下走。后来发现这些条件项到了下一个阶段根本没人管，越积越多，最后变成上线前集中爆雷。我想知道有条件通过这件事到底该怎么管。
有条件通过本身是合理的，因为现实里没有哪个项目能做到零遗留，问题在于它必须有额度、有范围、有追踪。我给团队定的规则是：每个项目在每一道阶段门最多只能有1次有条件通过，涉及的事项必须是‘不影响下游启动’的，比如文档补充、非关键路径的优化、监控埋点完善；
凡是影响架构选型、核心数据模型、对外接口契约的问题，一律不允许带条件过门，只能不通过。所有条件项必须进同一张风险台账，字段包括问题描述、影响范围、责任人、关闭截止日、当前状态，并且这张台账在下一道门的评审材料里必须出现在第一页，没关闭的条目要单独说明为什么还没关。
升级机制也要写死：条件项逾期未关闭，自动升级到上一级负责人；如果出现连续两次有条件通过，或者上一道门的条件项在下一道门仍未关闭，则强制触发一次专项评审，不允许再带条件往下走。
至于度量口径，我重点看三个数：条件项按期关闭率（健康水平在90%以上）、条件项平均关闭时长（超过两周就要查原因）、跨门遗留率，也就是上一道门开出、到下一道门还没关掉的比例，这个数字一旦超过20%，基本可以判定这套阶段门已经名存实亡，需要重新校准准出标准而不是继续加会议。
4. 在项目管理工具里怎么落地阶段门？该看哪些指标来判断它是不是真在起作用？
我们现在阶段门的规则都写在文档里，评审也是在会议软件里开，结论散落在聊天记录和邮件中。想把它搬到工具里，但不知道具体配哪些字段和规则，也不确定配完之后怎么证明它有用，怕又变成一个填了没人看的表单。
我的做法是尽量少配字段，但每一条都必须有强制力。核心就三块：第一块是阶段状态字段，取值固定为待评审、通过、有条件通过、不通过四个，不允许自由填写，评审结束当场更新；
第二块是门禁规则，把下一阶段的启动任务设置成依赖上一阶段的状态，未通过时任务无法流转、无法标记完成、无法进入迭代，这条是最关键的，规则不落到‘能不能点完成’这个动作上，就一定会被绕过；第三块是记录留存，每个门的评审材料、书面意见、结论、整改项和责任人全部挂在同一个门下面，方便追溯，别散在聊天工具里。
提醒动作也要配置，材料提交截止前24小时自动提醒提交人，条件项到期前三天自动提醒责任人，逾期自动通知上级。指标方面我长期跟踪四个：一次通过率，也就是首次评审直接给出通过的门的占比，太低说明准出标准定得不现实或者准备不充分，太高比如长期接近百分之百则说明门太松；
门的平均滞留天数，从材料提交到给出结论的天数，我一般设3天为上限，超过就说明决策链条有问题；返工工时占比，本阶段因上一阶段遗留问题产生的工时占总工时的比例，这个数字最能说明门的过滤效果；
漏检数，也就是下游发现、但本应被上游门拦住的问题数量，按门统计成趋势图，如果连续两个季度不下降，就要回头检查准出条件是不是定错了方向。最后提醒一句，工具配置不要一次上全套，先在一到两个项目上跑两个阶段门，把规则和指标跑通再推广，否则很容易变成所有人都在填表、但没人真正在乎结论的场面。
文章包含AI辅助创作：项目阶段如何做好阶段门？项目负责人流程优化与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/334276
读者评论
做硬件十年，对“有条件通过”那段最有共鸣。模具费和备料一旦投下去，评审会上没人敢说停，我自己也投过这种票。但真正的问题不是心软，是条件没人跟踪。我们后来试过把附加条件写进下一道门的清单，结果发现根本没人愿意当那个逐条核对的人，最后还是流于形式。
到6道门的说法我觉得要加个前提。如果是平台型产品线、多个子项目共用架构，门少反而会让技术债堆到集成阶段才爆。我见过5道门跑得很顺的团队，但那是因为他们的门禁标准写得极细，不是门少本身起了作用。对多数团队来说，标准化比数量更值得先解决。
作者说门必须和资源释放绑定，这点认同但很难落地。很多项目负责人手上根本没有调人的权力，预算也在部门手里，过了门要不到人，没过门也停不了人。这种情况下讨论门禁标准其实是空转。我更想知道的是，在矩阵式组织里，谁来做那个真正能停资源的人。