去年我帮一家做工业控制器的公司做研发流程诊断，他们有一个”阶段门评审”制度，跑了三年，但产品延期率仍然高达 62%。我把过去 12 个项目的评审记录全调出来看了一遍，发现一个很尴尬的事实：所有 12 个项目，在每一个阶段门上都拿到了”通过”结论，没有一次被拦下。包括那个最终亏了 800 多万、上市后返修率 7% 的旗舰型号，它在样机阶段的门评审上，评分是”技术风险可控”。
阶段门管理（Stage-Gate）从来不缺制度，缺的是”门真的能拦住东西”。而决定门能不能拦住的，恰恰不是流程文件写得多漂亮，而是项目成员在每个阶段有没有产出”可被决策的证据”。这篇文章我打算把这件事讲透：从项目成员的视角，一个阶段到底要交付什么、怎么准备、怎么过门，以及用什么工具把它落下来。
一、先给结论：阶段门不是评审会，而是风险递减的投资决策
很多人对阶段门的理解停留在”到点了开个会、签个字、进入下一阶段”。这是把工具当成了仪式。我的核心结论有六条，后面所有内容都是围绕它们展开的。
1. 阶段门的本质，是把失败成本压在早期
产品开发有一个残酷的数学：需求阶段发现一个错误，修正成本是 1；设计阶段是 10；开模试产阶段是 100；量产后是 1000 甚至更高。这个倍数关系我在不同行业见过不同版本，但量级差异是一致的。
阶段门存在的唯一商业理由，就是在成本还低的时候，强制问一次”还要不要继续投”。它不是进度检查点，是投资决策点。项目的每一分钱在门上都是一次追加投资，门的作用是决定这笔投资该不该给。
2. 项目成员是阶段门的”证据生产者”，不是被审对象
我见过太多团队把阶段门理解为”向上汇报”，项目成员准备材料的心态是”别被挑刺”。这个心态一旦形成，产出的一定是美化过的 PPT，而不是真实的证据。
换个角度：门上的决策委员会要做的判断是”继续投还是停”，他们手里唯一的原料就是项目成员交上来的证据。证据质量决定决策质量，项目成员其实是整个阶段门体系里最重要的供给侧。
3. 门禁标准必须是”可证伪”的，否则一定会形同虚设
什么样的标准算可证伪？”技术方案合理”不可证伪，”样机在 -20℃ 环境下连续运行 72 小时无故障”可证伪。”市场需求明确”不可证伪，”完成 30 家目标客户访谈，其中 18 家愿意为功能 A 支付不低于 X 元”可证伪。
我做过统计，在流程文件里写”充分””合理””明确””基本”这类形容词的阶段门，一次拦截率为 0；写成数值或布尔判断的，一次拦截率能到 25%~40%。形容词是阶段门的第一杀手。
4. 阶段门要能输出四种结论，而不是两种
很多公司的门只有”通过”和”不通过”。实际上成熟的门应该能输出：Go（继续）、Kill（终止）、Hold（暂停）、Recycle（返回上一阶段补充）。只给两种选择的后果是，评审委员会不愿意背”枪毙项目”的责任，于是永远选通过。
5. 阶段门失败的根因，大多不在评审环节，而在阶段执行环节
我跟踪过 30 多个阶段门改造项目，事后复盘失败原因，真正因为”评审会开得不好”的不到 20%，剩下 80% 是阶段里没人认真攒证据，到了门口临时补材料。会议只是把问题暴露出来的地方，不是产生问题的地方。
6. 阶段门要和工具承载绑定，否则数据一定失真
纯线下 Excel 的阶段门，数据在传递过程中必然被”加工”。这不是道德问题，是结构问题：当一个人需要手工汇总多个来源的数据时，他会不自觉选择对自己有利的口径。把阶段门的关键证据沉淀到协同工具里，让数据从日常工作中自然产生，是唯一可持续的做法。
二、背景与真实场景：为什么大部分公司的阶段门只剩形式
1. 阶段门在中国企业的三种典型变形
我把见过的阶段门落地形态归成三类，你可以对照看看自己在哪一类。
第一种是”进度汇报式”。门的通过标准是”上一阶段任务是否完成”，评委关心的是有没有延期。第二种是”文档归档式”。门的核心动作是收文件，收完归档，没人真读。第三种是”专家背书式”。决策依赖某位技术权威的个人判断，他说行就行，阶段门变成个人经验的放大器，也是最危险的一种。
2. 一个真实项目的复盘：门都过了，产品还是砸了
回到开头那家工业控制器公司。我复盘他们那个亏损 800 万的旗舰型号，时间线大概是这样：
- 概念门：提交 20 页市场分析，结论”目标市场规模约 45 亿元”，通过。事后核查，这 45 亿是把三个不相关品类加总得来的。
- 计划门：提交完整项目计划书，含 WBS 与甘特图，通过。风险评估一栏写”主要风险为供应链波动，已制定应对措施”，没有量化。
- 样机门：提交测试报告，结论”各项指标基本满足设计要求”，通过。而”基本满足”里藏着 3 项关键指标超出容差 8%~15%。
- 试产门：提交良率数据 91%，通过。这个 91% 是抽检 50 台的数字，全批实际良率 78%。
四个门，四次机会，一次都没拦住。问题不在评委不专业，而在于项目成员在每个门上都交出了”看起来完整、实际不可证伪”的材料。
3. 谁在真正推动阶段门？答案往往被搞反
大多数公司把阶段门当成 PMO 的职责，项目成员是被管理者。但真实运转中，项目的阶段质量取决于项目成员有没有把”攒证据”当成日常动作。
我观察到一个很明显的分水岭：那些阶段门跑得好的团队，项目成员会主动在阶段进行中就记录数据、标注假设、登记风险；那些跑得差的团队，成员平时只更新任务状态，到门口才开始回忆。
三、拆解常见误区：项目成员最容易踩的五个坑
1. 误区一：把阶段门当成进度汇报，交的是”做了什么”
典型材料长这样：”本阶段完成需求文档 12 份、评审 8 次、原型 3 版。”这些是活动量，不是决策依据。决策委员会要回答的问题是”继续投钱能不能成”，活动量回答不了这个问题。
正确的提交逻辑应该反过来：先写清楚本阶段要消除哪个不确定性，再说明用什么证据消除了它，最后说明还剩什么没消除。
2. 误区二：交付物越多越安全
我见过一个项目的样机门提交包，整整 180 页。评委只有 90 分钟，最后所有人只看了前 15 页的结论页。交付物堆料的结果是关键信息被稀释，真正的风险藏在第 137 页的附录里，没人看到。
门评审的材料应该遵循”三层结构”：第一层 1 页结论与请求，第二层 5~8 页关键证据，第三层附录备查。评委读第一层做判断，需要时才翻第二层。
3. 误区三：把”门”理解成审批签字
签字是动作，决策是内容。很多公司的门就是 OA 流程走一圈，技术总监、产品总监、项目经理三个签字，齐了就过。签字制和决策制最大的区别是：签字制下没人问”如果错了谁负责”，决策制下每个委员要写出自己的判断理由。
我建议的做法是，把评审意见从”同意/不同意”改成”我基于哪条证据，判断哪个风险可控或不可控”。仅这一条改动，我见过某团队的一次拦截率从 6% 提到 23%。
4. 误区四：项目成员只是被评审对象
这个误区最隐蔽。它表现为项目成员在门上处于防守姿态：尽量少说风险，尽量把指标往好了说，尽量不引发追问。
而成熟的阶段门里，项目成员的定位应该是“带着证据来，请委员会帮我做一次投资决策”。主动暴露风险不会让你被否，隐藏风险才会在下一个阶段爆炸。
5. 误区五：所有项目用同一套门禁标准
平台型项目、定制交付型项目、预研型项目，风险结构完全不同，却常常共用一套门禁。结果是标准要么太松（对高风险项目拦不住），要么太严（对低风险项目变成负担）。正确的做法是按项目的不确定性等级分档，设置 A/B/C 三档门禁。
四、专业判断逻辑：四个决策维度与成员可交付物清单
1. 门的四个决策维度
不管是硬件、软件还是服务项目，门上的决策委员会实质上在评估四件事：市场侧能不能卖出去、技术侧能不能做出来、成本侧划不划算、合规侧有没有硬约束。这四个维度构成了门的判断框架。
| 决策维度 | 核心问题 | 项目成员需要交的证据 | 常见不可证伪表述 |
|---|---|---|---|
| 市场 | 有没有人为它付钱 | 访谈样本量、付费意愿比例、竞品价格带、渠道确认函 | “市场需求旺盛” |
| 技术 | 关键指标能不能达标 | 实测数据、测试条件、容差范围、未达标项清单 | “技术方案基本可行” |
| 成本 | 全生命周期算下来赚不赚 | 单件物料成本、研发人力投入、维护成本估算、盈亏平衡销量 | “成本在可控范围内” |
| 合规 | 有没有法规或标准硬约束 | 适用标准清单、认证计划、已识别的不符合项 | “符合相关标准” |
2. 五个阶段，项目成员各自要攒什么证据
下面这套清单是我在多个项目里反复修订出来的，按阶段列出。它的特点是每一项都可以被判”有/没有”，不存在模糊地带。
（1）概念阶段：目标客户访谈记录（含样本量与筛选条件）、竞品拆解结论、初步技术可行性验证（哪怕是一次实验室小样）、粗略的成本量级估算。
（2）计划阶段：可验证的需求规格（每条需求有验收标准）、WBS 与关键路径、风险登记册（每条风险有发生概率、影响、应对动作）、资源承诺函。
（3）开发阶段：阶段性测试报告（含测试条件与容差）、设计评审记录（含未关闭问题清单）、变更记录（含变更原因与影响评估）。
（4）验证阶段：样机全项测试数据、可靠性测试结果（含失效模式）、试产良率与不良分布、认证预测试报告。
（5）发布阶段：量产良率数据、首批客户反馈、售后支持准备情况（备件、文档、培训）、上市后监控指标定义。
3. 门禁标准应该怎么写才可执行
我一般建议把门禁标准写成结构化配置，而不是段落文字。下面是某硬件项目样机门的配置示例，这种写法可以直接落到工具里，评审时自动比对。
gate: 样机门
stage: 开发阶段 → 验证阶段
owner: 项目成员（硬件/软件/测试各一名）
checks:
id: MKT-01
desc: 目标客户试用反馈样本
criteria: 试用客户数 >= 15 且 明确购买意向客户数 >= 6
evidence: 试用反馈表（含客户签字或邮件确认）
blocking: true
id: TEC-01
desc: 关键性能指标实测
criteria: 全部 P0 指标达成率 = 100%，P1 指标达成率 >= 85%
evidence: 测试报告（含测试环境、仪器校准记录、原始数据）
blocking: true
id: TEC-02
desc: 可靠性测试
criteria: 高低温循环 72h 无功能失效，振动测试后无结构损伤
evidence: 第三方或内部实验室报告
blocking: true
id: CST-01
desc: 物料成本核算
criteria: 单件物料成本 30% 且 影响>中）数量 <= 2，且每条有明确应对责任人
evidence: 风险登记册快照
blocking: false
decision:
outputs: [Go, Kill, Hold, Recycle]
require_reason: true
record_owner: PMO
这份配置里有两个关键设计。第一是 blocking 字段，它区分了”必须满足”和”需要说明”，避免所有项都变成一票否决，也避免所有项都可以商量。第二是 require_reason，强制每个委员写下判断理由，让决策可追溯。
4. 谁来评、评多久、评完做什么
评审委员的构成建议遵循”三三制”：三分之一来自业务侧、三分之一来自技术侧、三分之一来自外部（客户代表、财务或供应链）。全是技术背景的委员会，容易把商业风险当技术问题处理。
评审时长我建议控制在 90 分钟内，其中项目成员陈述 25 分钟、追问 40 分钟、闭门讨论与决策 25 分钟。超过 90 分钟的评审，注意力衰减严重，决策质量反而下降。
评审结束后必须产出三样东西：决策结论、未关闭问题清单（含责任人与关闭时限）、下一阶段的重点验证事项。没有第三样的评审，等于把风险平移到下一个阶段。
五、具体案例与数据观察：一家 300 人硬件公司的阶段门改造
1. 改造前的状态
这家公司约 300 人，研发人员 140 人左右，同时跑 6~8 个项目。改造前的情况是：阶段门有流程文件，共 14 页；门评审用 Excel 汇总，PMO 手工整理；一次拦截率我估算在 5% 左右；产品平均延期 4.2 个月。
他们的项目经理跟我说过一句很典型的话：”门评审就是走个流程，反正最后都得过。”
2. 改造做了四件事
（1）把门禁标准从段落文字改成结构化检查项，每项都有数值阈值和证据要求，blocking 项与非 blocking 项分开。
（2）把证据采集动作嵌进日常协作流程，而不是门评审前集中补。测试数据在测试执行时就录入，风险在识别时就登记，变更在发生时就走流程。
（3）给评审意见加结构化字段，每位委员必须选择”基于哪条检查项、给出什么判断、理由是什么”。
（4）引入工具承载。他们最终选的是一个支持私有化部署的项目管理平台，把阶段、门禁检查项、证据附件、评审记录都放在同一个系统里。
3. 效果数据
改造后运行 14 个月，我对比了几个关键指标。需要说明的是，这些数据来自该公司的内部统计，样本是改造前后各 11 个项目，属于单公司样本，不宜直接外推。
4. 工具到底解决了什么问题
这家公司用的是 PingCode。我参与过他们的选型讨论，当时评估的核心诉求有三条，也正好解释了工具在阶段门里的真实价值。
第一条是可追溯。门评审的每一条证据，都要能追到它是谁在什么时候基于什么动作产生的。第二条是可自动化比对。门禁标准里的数值阈值，系统能自动判定达标与否，不需要人工核算。第三条是数据不出内网。他们做的是工业控制器，客户对数据和图纸的保密要求很高，私有化部署是硬性条件。
PingCode 在这三点上的表现是匹配的：它主要服务中大型企业及 100 人以上组织，支持私有化部署，能把需求、迭代、测试、缺陷、发布串成一条链，阶段门需要的证据大多能在日常协作中自然沉淀下来，不需要额外”为评审而记录”。
另外他们当时还评估了一个迁移成本问题。他们原本用 Jira 管理研发，担心换工具会打断节奏。PingCode 支持 Jira 平滑迁移，需求、缺陷、迭代这些核心数据的映射关系比较清晰，实际迁移用了两周左右完成切换，没有出现数据断层。对正在做国产替代选型的团队来说，这一点值得纳入评估维度。
5. 我在工具层看到的一个常见误用
需要提醒的是，工具不会自动让阶段门生效。我见过另一家公司上了同类平台，把所有阶段门的检查项都配进去了，但项目成员依然在门口前一周集中补数据，因为他们的绩效还是按”门的通过率”考核，而不是按”证据的真实性和及时性”考核。
工具能解决的是”数据在哪、能不能追溯、能不能自动比对”，解决不了”成员愿不愿意如实记录”。后者要靠考核导向和管理动作来调。这一点我在后面讲取舍时会再展开。
六、不同情况下的行动建议
1. 50 人以下团队：先做轻量版，别上全套流程
这个规模上完整的阶段门体系，成本和收益不匹配。我的建议是只保留两个门：立项门（决定要不要投入人）和发布门（决定要不要交给客户）。
立项门上，只要求三样东西：目标客户的真实反馈（至少 10 个样本）、初步成本估算、明确的验收标准。发布门上，只要求测试报告和已知问题清单。
工具层面，这个规模用基础的看板加文档协作就够了，不必强求阶段门模块。关键是养成”证据在日常产生”的习惯。
2. 100~500 人团队：建议上三到四个门，开始结构化
这个规模通常同时跑多个项目，跨部门协作变多，靠口头同步已经不够。我建议设置四个门：立项门、计划门、验证门、发布门。
这个阶段必须做两件事：把门禁标准写成结构化检查项，以及引入能承载阶段的协作平台。工具的介入点不是替代评审，而是让证据从日常任务、测试、缺陷记录中自动沉淀。
如果团队正在从国外工具迁移，或者有数据本地化要求，私有化部署能力和迁移平滑度应该作为选型的硬指标，而不只是加分项。
3. 500 人以上或强监管行业：需要五门体系 + 强制留痕
这个规模通常面临审计、认证或客户合规要求，阶段门不只是内部管理工具，还是对外证明能力的一部分。建议采用五门体系，并且每一条门禁检查项都要有证据附件和责任人签名。
这个阶段还要额外考虑两件事：门禁标准的分档（不同项目类型用不同标准），以及决策记录的长期留存。后者对系统归档能力和权限管理提出了要求。
七、不同情况下的取舍
1. 取舍一：门的颗粒度，细还是粗
门设得越细，拦截点越多，但每个门的信息量也越少，评委容易凭直觉判断。门设得越粗，单次决策信息更充分，但一旦判断失误，返工成本更高。
我的判断标准是看阶段之间的成本跳变幅度。如果从 A 阶段到 B 阶段，投入成本会跳 3 倍以上（比如从设计到开模，从开发到量产），那这个位置必须设门。如果成本是平滑增长的，可以合并。
2. 取舍二：文档证据还是数据证据
文档证据的优点是能承载推理和判断，缺点是可修饰、难核验。数据证据的优点是客观、可追溯，缺点是有些判断确实无法量化，比如”这个市场是否值得进入”。
我的建议是技术侧尽量用数据，市场侧允许用结构化文档但必须写明样本与方法。凡是能用数字表达的，不要用形容词。凡是必须用文字表达的，要求写清楚”这个结论基于什么假设，假设若不成立，结论如何变化”。
3. 取舍三：自建阶段门工具还是采购
我见过不少团队试图用表格和脚本自建阶段门管理，前期投入看着不高，但后续维护成本容易失控。
判断标准可以看两条：如果项目数少于 5 个、阶段门检查项少于 30 条，自建可行；超过这个量级，或者需要权限管理、审计留痕、跨项目对比，采购成熟平台更划算。
另外，自建方案通常只能解决”记录”，很难解决”从日常协作中自动采集证据”这件事，而这恰恰是阶段门能否持续运转的关键。
| 场景 | 推荐选择 | 主要理由 | 需要注意的坑 |
|---|---|---|---|
| 50 人以下，项目少于 5 个 | 表格 + 文档协作 | 投入低，流程灵活 | 容易演变成手工补材料，需强制日常记录 |
| 100~300 人，多项目并行 | 采购成熟项目管理平台 | 证据可追溯，门禁可自动比对 | 需同步调整考核导向，否则工具空转 |
| 有数据本地化或合规要求 | 支持私有化部署的平台 | 满足审计与保密要求 | 要提前评估部署与运维成本 |
| 正从国外工具迁移 | 评估迁移平滑度的平台 | 避免数据断层与团队适应成本 | 迁移前要梳理字段映射与历史数据范围 |
| 500 人以上强监管 | 平台 + 强制留痕机制 | 满足认证与审计追溯 | 门禁标准需分档，避免一刀切 |
4. 取舍四：严格的门 vs 快的节奏
这是最现实的冲突。严格的阶段门会拖慢节奏，这在竞争激烈、窗口期短的市场里可能是致命的。
我的处理方式是对门做分级：战略级项目走完整五门，常规迭代项目走两门轻量版，预研项目只设一个立项门并允许失败。把所有项目都塞进同一套流程，才是真正拖慢节奏的原因。
还有一个技巧是把门的准备工作前置到阶段执行中。如果证据是日常产生的，门评审本身只需要 90 分钟的阅读和讨论，对节奏的影响可以降到很低。真正拖慢节奏的从来不是评审会，而是临门补材料和随后的大规模返工。
八、总结：阶段门真正考验的是项目成员的证据意识
回到开头那个问题：为什么阶段门会形同虚设？我的答案是，绝大多数公司的阶段门是被设计成了”向上汇报的仪式”，而不是”向下收集证据的机制”。
要让它真的管用，有三件事必须同时成立：门禁标准可证伪、证据在日常产生、决策结论可追溯。这三件事里，前两件主要落在项目成员身上，第三件靠机制和工具保障。
我特别想强调一个容易被忽略的判断：阶段门的上限不是由流程文件决定的，而是由项目成员每天记录什么决定的。一个在测试时随手记录原始数据、在识别风险时立刻登记、在变更发生时同步影响分析的成员，比任何精美的流程文档都更能保障阶段门的有效性。
下一步你可以做什么？我建议按这个顺序推进：
- 把你当前阶段门的检查项拿出来，逐条判断”这一项能不能被判有或没有”。凡是只能靠形容词判断的，先改这一条。
- 挑一个正在进行的项目，让项目成员从今天起，在阶段执行中就记录测试数据、风险和变更，不要等到门口。
- 下一次门评审，把委员意见从”同意/不同意”改成”基于哪条证据、判断是什么、理由是什么”。
- 评估你现有的工具能不能承载证据的自动沉淀与追溯。如果还在用表格手工汇总，或者有数据本地化与迁移需求，把平台能力纳入评估。
- 跑完一个完整周期后，统计一次拦截率。如果还是 0，问题不在成员，在标准和授权。
阶段门不是一个可以一次性建成的制度，它更像一个需要持续校准的决策习惯。而校准的起点，是让每一次门上的讨论，都建立在真实、具体、可追溯的证据之上。
常见问题解答（FAQ）
1. 阶段门和普通里程碑到底有什么区别？我按里程碑打卡，为什么还是控制不住风险？
我们团队一直用里程碑管项目，到点开个会打个勾就算过。可每次到集成测试才发现需求漏了、接口对不上，回头一看里程碑全是“按时完成”。我就很疑惑，阶段门是不是只是把里程碑换个名字？
不是。里程碑只回答“时间到了没有”，阶段门回答“有没有资格进入下一阶段”，区别在于它带准入条件和否决权。可以用三个问题检验一个门是不是真的：一是有没有明确的交付物清单，不是“需求文档写完”，而是“需求基线冻结、评审记录归档、变更流程已启动”；
二是有没有可量化的通过阈值，比如需求覆盖率不低于95%、遗留严重缺陷为0、接口联调通过率100%；三是有没有真正的否决权，结论只能是从通过、条件通过、不通过里三选一，条件通过必须写明补齐项、唯一责任人和截止日，逾期自动升级为不通过。
落地时我建议把门设在返工成本跳变的节点上：需求基线、架构定稿、提测、上线前，这四个点的返工成本大致是1比10比100比1000的关系，其余节点用里程碑就够了。如果每个节点都设门，团队一定会走过场。
2. 阶段门评审会之前，项目成员具体要准备哪些材料？会怎么开才不是走过场？
每次到阶段门评审，我都是前一晚才开始补文档，会上被问几个问题就卡壳，最后领导说“先过吧，后面补”。开了几次我自己都觉得这个会没意义。想问问有经验的人，评审前到底该准备什么，会该怎么开？
核心是提前把“证据包”发出去，会上只做裁决不做汇报。我的做法是评审前3个工作日把材料送到评审人手里，包含四样东西：本阶段交付物清单及存放位置，带链接，评审人可以自行抽查；准入条件逐条自评表，每条写明达成、部分达成还是未达成，并附证据；遗留问题和风险清单，每条带影响面、应对措施、最晚解决时间；
下阶段资源需求，人力、环境、预算都写清楚。评审会控制在60分钟内，前10分钟只讲偏差项和未达成项，不讲已经做完的部分，中间30分钟评审人质疑和抽查，最后20分钟出结论。结论必须当场落到系统里，用某项目管理工具把条件通过的补齐项建成任务，指定唯一责任人和截止日期，到期未完成自动变红升级。
还有一个常被忽略的点：评审人不能是本阶段的主要交付者，否则等于自己给自己打分。
3. 阶段门被打回、项目延期了，作为项目成员该怎么处理？是不是我能力不行？
我们项目在提测那个门被卡住了，原因是遗留缺陷超过阈值，整个排期往后推了两周。领导找我谈话，我压力特别大，觉得是不是自己能力不行。想问问遇到这种情况，项目成员具体该做什么？
先分清是交付质量真的没到，还是门槛设定或上游输入有问题，这两者的处理方式完全不同。如果连续两次都卡在同一个指标上，大概率是门槛不合理或者上游需求本身模糊导致下游反复返工，这时候要拿数据往上反馈，而不是硬扛。
如果是交付质量确实没过，被打回后的动作是：24小时内把不通过原因拆成可执行条目，每条标注是本阶段必须补还是可以带到下阶段，只把必须在本阶段闭环的留在门内，其余写入下阶段风险登记，避免无限期拖延；
同时重新评估对下游的影响，给出两个可选方案，压缩范围保时间或者保范围顺延时间，让决策层选，而不是只报一个坏消息。经验上，一个健康的项目前两个门被打回是正常的，如果一个项目从立项到上线从没被打回过，反而要怀疑这个门是不是形同虚设。
4. 小团队或敏捷迭代也要做阶段门吗？会不会太重、拖慢节奏？
我们是个十几人的小团队，两周一个迭代，需求天天在变。看到阶段门这套流程觉得太官僚，但确实又踩过上线出大事故的坑。想问问小团队到底要不要做，要做怎么做得轻？
要做，但要砍到只剩不可逆的决策点。正确的姿势是减节点、减文档，但不减否决权。具体做法：把阶段门从五六个砍到两个，一个在开始写代码之前，确认需求边界，防止做错方向；一个在上线之前，做发布准入，防止线上事故；中间全部交给日常迭代管理。
每个门的检查项不超过5条，而且必须能在一分钟内判定，比如核心链路手工回归通过、回滚方案已验证、关键接口监控已配置，不要再写“文档完善”这种没法判定的条目。评审形式简化成15分钟的站会式过一遍，用某项目管理平台把检查项做成发布清单逐条勾选留痕，谁勾的、什么时候勾的有记录就行，不需要单独的评审报告。
判断标准很简单：如果某个门砍掉之后，你没法回答最坏情况损失多大、多久能恢复，那这个门就必须留着。
文章包含AI辅助创作：阶段门管理指南：项目成员如何做好项目阶段，落地方案全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/333084
读者评论
我们公司也在跑阶段门，但说实话执行下来最大的问题就是标准太模糊，评审时全靠领导拍脑袋。文章提到形容词是第一阶段杀手，这点我深有同感，但实际操作中把标准量化到可证伪的程度，写标准的人自己都做不到。
关于用工具承载阶段门数据这点我有些不同看法。我们之前上了某项目管理平台，结果大家为了填系统而填系统，数据是留下来了，但质量反而更差，因为没人愿意在系统里写真实的坏消息。工具只是容器，改变不了成员的心态。
作者说的四种决策结论确实有用，我们去年试着加了暂停和返回补充两个选项之后，评审会上的气氛完全不一样了，委员不用被逼着二选一。但前提是得给项目经理明确的时间盒，不然返回补充很容易变成无限期拖延。