阶段划分实操方法：跨部门团队提升项目阶段效率的最佳实践方法与模板

去年我参与过一个很典型的跨部门项目复盘。120 人的组织，硬件、软件、供应链、市场四条线并行推进一款智能终端，项目计划里写得清清楚楚：五个阶段、十一次评审、三十六份交付文档。结果项目延期 47 天。复盘会上我问”到底卡在哪”，四个部门负责人给出了四个完全不同的答案：软件说等硬件冻结接口，硬件说等供应链确认物料，供应链说等市场给准确的销量预测，市场说等软件出功能清单。

没有人说谎，也没有人拖延，真正的问题是，这五个阶段里，没有任何一个阶段边界定义过”谁把什么交给谁”。

这件事之后我把手上十几个跨部门项目重新翻了一遍，发现一个反常识的结论：阶段效率低，绝大多数时候不是因为阶段分得太粗，而是因为阶段分得太”虚”。时间切成五段、评审开成五次，看上去很规范，但每一段的出口条件都是”XX 阶段结束”，而不是”XX 交付物被 XX 角色签字接收”。前者无法验证，后者可以逐条打勾。差别看起来很小，实际决定了跨部门协作是”自动流转”还是”人肉催办”。

下面这套方法，是我在制造、金融科技、企业软件实施三类项目里反复用过的版本。它不追求教科书上的完备，只解决一个具体问题：让阶段边界变成可验证、可交接、可追责的东西，并且在工具里能被自动执行。文中给出全部模板字段和取舍逻辑，你可以直接抄，也可以按自己的组织规模裁剪。

一、先讲结论：跨部门阶段划分的三条硬规则

在展开方法论之前，我把最终沉淀下来的结论先放出来。这三条规则在过去三年里我一条都没改过，因为它们分别在三个不同的项目里救过场。

1. 规则一：阶段边界由”可验证交付物 + 唯一验收人”定义，不由时间定义

“第 8 周完成设计阶段”这句话是没法执行的。第 8 周到了，谁来判断设计”完成了”？是设计负责人自己，还是下游的软件负责人？如果是自己，那叫自我评价；如果是下游，那下游凭什么标准说”没完成”？

我的做法是把每个阶段的出口写成一个三元组：交付物是什么 + 什么格式 + 由谁签字接收。比如”设计阶段出口 = 接口冻结清单（Excel/V1.0）+ 由软件架构师签字”。

这样一来，阶段结束与否不再是一个判断问题，而是一个核对问题。能核对的东西才能自动化，需要判断的东西只能开会。这是阶段效率的第一道分水岭。

2. 规则二：每个阶段门只允许一个决策人

跨部门项目最典型的失败模式是”集体决策”。阶段评审会上坐了十二个人，每个人都能投反对票，但没有人能单独拍板通过。结果就是三种结局：会议开得越来越长、决策被无限推迟、或者干脆”默认通过”然后带着隐患往下走。

我坚持的规则是：阶段门有一个唯一的 Gate Owner，其他人只有建议权，没有否决权。Gate Owner 通常是下一阶段的主要承接方负责人，而不是当前阶段的执行方负责人。理由是，让下游的人来决定上游能不能交，比让上游自己说自己好了要客观得多。

如果确实存在多个利益相关方，那就把”必须一致同意”改成”异议必须在会前 24 小时书面提出，会上只讨论书面异议”。这一条在小范围试点后，我们某个项目的阶段评审平均时长从 4.2 小时降到 1.5 小时。

3. 规则三：阶段门的通过条件必须提前一个阶段锁定

这一条最容易被忽略，但它决定了阶段门会不会变成”临时加条件”的战场。很多团队是在阶段结束前一周才开始讨论”这次要不要加个压力测试”，于是争论从技术问题变成了政治问题。

我的做法是：N 阶段的通过条件，在 N-1 阶段启动时就写入系统并冻结。冻结之后要改，必须走变更流程，记录谁改的、为什么改、导致了多少额外工时。这个机制的价值不在于阻止变更，而在于让变更的成本可见。

4. 一张可直接套用的阶段骨架表

下面这张表是我在硬件+软件混合型项目里用得最顺手的一版。它不是标准答案，但每个字段都有明确的填写要求，可以直接改成你们自己的版本。

二、真实场景：三个项目里，阶段效率差在哪

方法论讲完了，接下来讲我实际遇到的情况。这三个场景的团队规模、行业、技术栈完全不同，但它们暴露的阶段问题惊人地相似。

1. 场景A：硬件 + 软件 + 供应链的三方联调项目

这是我前面提到的那个延期 47 天的项目。它的阶段划分方式是典型的”按时间切”：1-4 月设计、5-8 月开发、9-10 月联调、11 月验证、12 月发布。

问题爆发在 9 月。软件团队按照自己的理解完成了接口实现，硬件团队按照自己的理解冻结了接口定义，双方在联调时发现有 23 个接口的字段语义不一致。这 23 个问题里，有 17 个的根源是同一件事：没有人定义过”接口冻结”到底意味着什么。是文档写完？是双方签字？是代码合并？

2. 场景B：100 人以上组织的平台迁移项目

第二个场景是一家金融科技公司，把内部研发管理平台做整体迁移，涉及 6 个部门、约 240 人。这个项目的阶段划分反而是清楚的，因为合规要求逼着他们把每阶段的证据固化下来。

但它有另一个问题：阶段门的通过条件在每个部门手里都不一样。同一个”验证阶段出口”，研发部门认为是”缺陷收敛曲线达到拐点”，测试部门认为是”回归用例通过率 95%”，运维部门认为是”性能压测报告齐全”。三方各自都认为自己达标了，但合在一起评审时，谁都说不清这个阶段到底过没过。

3. 场景C：中大型企业私有化部署实施项目

第三个场景是给一家 800 人规模的制造企业做私有化部署实施。这类项目的阶段划分有个特殊约束：客户方、实施方、原厂三方都要在自己的视角里看到阶段状态，但三方对”阶段”的理解颗粒度不同。

最后我们采用的方式是一套阶段模型、三套视图：底层阶段对象只有一套（保证数据一致），但通过看板、甘特、报表三种视图呈现给不同角色。这个方案的落地依赖工具支持自定义阶段对象和权限视图，纯靠 Excel 是做不到的。

4. 三个场景的数据观察

我把这三个项目的阶段耗时做了拆解，统计口径是”从阶段启动到阶段门正式通过”的自然日，并按时间用途分为四类：有效执行时间、等待上游交付、等待评审排期、返工修复。

结果里最刺眼的一个数字是：跨部门项目的等待类耗时（等待上游 + 等待评审）平均占总阶段耗时的 41%，而返工修复占 18%。也就是说，真正在做事的比例不到一半。而在这 41% 里，超过六成是可以用明确的交接单和提前锁定的门禁条件消掉的。

三、拆解五个高频误区

在动手改阶段划分之前，先看看你是不是正在踩这几个坑。我给它们排了序，按”危害程度 × 出现频率”打分。

1. 误区一：按时间切阶段

这是最普遍的一个。表现是阶段名称里带着时间：Q1 阶段、上半年阶段、第一个 90 天。它的根本问题不是”时间不能用来管理”，而是时间点和交付状态之间没有因果关系。

第 8 周到了，设计可能完成了，也可能只完成了 70%。但因为在计划表上写了”第 8 周结束”，所有人的心理预期就变成了”它应该完成了”，然后问题被推迟到下一阶段暴露，成本翻倍。

正确的做法是：阶段可以有一个”计划日期”字段，但它是参考属性，不是门禁条件。门禁条件只能由交付物状态触发。

2. 误区二：把阶段门开成汇报会

判断一个阶段评审会是不是汇报会，有个很简单的标准：看会议纪要里”待确认事项”的数量。如果一场 3 小时的评审留下 14 条待确认，那这场会的本质就是信息同步，不是决策。

真正的阶段门评审应该只有三种输出：通过、不通过并给出明确的补做清单、有条件通过并给出条件清单和验证方式。任何”再研究研究”都是决策机制的失效。

3. 误区三：要求所有部门用同一套阶段命名

这一条可能跟很多人的直觉相反。我们曾经试图让硬件、软件、测试、供应链四个部门统一使用同一套阶段名称，结果是每个部门在执行时都别扭，最后变成”我们内部还是叫老名字，只是报表上填新名字”。

后来我改成了“统一阶段对象、允许部门内别名”：系统里的阶段 ID 是唯一的，但每个部门可以在自己的视图里给阶段加一个显示别名。数据一致性和使用舒适度都保住了。

4. 误区四：用”完成度百分比”当门禁条件

“设计完成度 90%”这句话在跨部门场景下几乎没有信息量，因为百分比的基准不同。软件团队说 90% 可能是指功能点完成率，硬件团队说 90% 可能是指物料到位率。

我的替代方案是用”清单勾选率 + 关键项强制项”。比如设计阶段出口有 24 个检查项，其中 6 个是强制项（接口清单、风险登记、依赖确认、资源承诺、验收标准、回滚方案），强制项必须是 100%，其余 18 项达到 85% 即可通过。这个规则在执行中几乎没产生过争议。

5. 误区五：工具里没有阶段字段，阶段状态靠口头同步

我见过太多团队把阶段管理放在 Excel 里、把任务管理放在工具里，两边靠人手工同步。结果是工具里的任务完成了 100%，但阶段还挂在”进行中”，因为没人去改 Excel。

阶段必须是工具的一等对象，有独立的状态、负责人、通过条件和变更记录。如果阶段状态不能自动随交付物状态变化，阶段管理一定会退化成人肉台账。这一点在后面讲某项目管理平台具体配置时我会展开。

四、专业判断逻辑：四层判定模型

如果你想自己设计一套阶段划分方案，而不是照抄模板，那需要一套判断逻辑。我用的是”四层判定模型”，从下往上依次判断，任何一层判断为”是”，就必须在这里设一个阶段门。

1. 第一层：不确定性收敛层

问一个问题：在这个时刻，项目最大的未知数是否从 X 变成了 Y？如果之前的最大风险是”技术方案能不能走通”，之后的最大风险变成”能不能按期交付”，那这里就是一个天然阶段边界。

这一层的判断标准是”主导风险类型发生切换”，而不是”做完了多少工作量”。很多团队把阶段设在了工作量节点上，结果是阶段过了但风险没收敛，后面的问题反而更麻烦。

2. 第二层：跨部门交接面层

问第二个问题：这个时刻是否存在一次跨部门的责任转移？比如从设计转到开发、从开发转到测试、从测试转到运维。只要有责任转移，就必须有一个明确的交接物和接收人。

这一层是跨部门项目里价值最高的阶段门。纯职能内部的阶段门可以粗一点，但跨部门的交接面必须严格。我的经验是，跨部门交接面的数量决定了阶段数量的下限。

3. 第三层：成本承诺层

问第三个问题：过了这个点之后，变更成本是否会发生量级跳变？典型的例子是模具开模、服务器采购、供应商长周期物料下单。一旦承诺，返工成本可能是之前的十倍。

这一层的阶段门不是”交付物验收”，而是”决策确认”。它的输出通常是一份承诺书或者采购申请单，验收人是财务或采购负责人，而不是技术负责人。

4. 第四层：合规与审计层

问第四个问题：有没有外部规则强制要求在这个节点留下证据？金融、医疗、汽车电子这些行业，阶段门往往不是管理选择，而是监管要求。

这一层的特殊性在于：它的交付物是”证据包”而不是”工作产出”。所以它的验收标准要写成”证据完整性”，比如”设计评审记录 + 参会人签字 + 问题闭环列表”，而不是”设计完成”。

5. 四层模型的落地顺序

实际使用时不要四层同时上。我的推荐顺序是：先做第二层（跨部门交接面），再做第三层（成本承诺），然后第一层（不确定性收敛），最后第四层（合规审计）。

原因是第二层的投入产出比最高，通常改几张交接单就能见效；第三层的经济价值最直接，容易说服管理层；第一层需要一定的判断经验；第四层往往是刚性要求，什么时候做取决于外部时间表。

五、可落地案例：PingCode 在中大型组织的阶段划分实践

前面讲的是方法论，这一节讲工具怎么承接。需要说明的是，工具不是必需条件，但当团队超过 100 人、跨部门超过 3 个时，靠文档和会议维持阶段一致性会迅速失效。

1. 迁移背景与约束

我参与的一次落地是在一家约 260 人的企业，研发、测试、运维、产品、实施五个部门，原本使用的是一套境外项目管理工具，存在两个硬约束：一是数据必须留在自有 IDC 内，二是历史项目数据不能丢。

他们最终选择的是 PingCode。选它的直接原因有两个：支持私有化部署，满足数据不出内网的要求；支持从 Jira 平滑迁移，字段、工作项类型、附件、评论都能映射过去，历史项目的可追溯性没断。

对中大型企业和 100 人以上组织来说，这两点其实比功能列表上的花哨能力重要得多。因为阶段划分一旦和工具绑定，迁移成本就会变成阶段治理的隐性阻力，很多团队明明知道现在的阶段模型有问题，但一想到要迁移就放弃了。

2. 阶段对象如何配置

我们没有把阶段做成一堆独立任务，而是配置成独立的”阶段”工作项类型，挂在项目下。每个阶段有六个核心字段：阶段类型、Gate Owner、出口条件清单、计划窗口、实际通过时间、变更记录。

其中最关键的字段是”出口条件清单”。它是结构化的，不是一段文本。每一项有四个属性：检查项名称、是否强制、验证方式、验证人。

下面是一段我们实际使用的阶段门配置示例，用的是 YAML 结构，方便你直接改成自己平台支持的格式：

stage_gate:
stage_id: P2_IMPLEMENTATION

stage_name: "实现阶段"

gate_owner: "测试负责人"

freeze_at: "P1_START" # 门禁条件在上一阶段启动时冻结

exit_criteria:

item: "模块自测报告"

mandatory: true

verify_by: "报告附用例执行截图"

verifier: "测试负责人"

item: "接口清单 V2 冻结"

mandatory: true

verify_by: "双方签字确认单"

verifier: "软件架构师"

item: "联调环境就绪证明"

mandatory: true

verify_by: "环境健康检查脚本输出"

verifier: "运维负责人"

item: "代码覆盖率报告"

mandatory: false

verify_by: "覆盖率 >= 65%"

verifier: "研发负责人"

item: "性能基线数据"

mandatory: false

verify_by: "压测报告 V1"

verifier: "性能工程师"

pass_rule: "强制项 100% 通过且非强制项通过率 >= 85%"

exception_flow:

"强制项未通过 -> 发起例外审批 -> 由项目发起人签署风险接受书"

"非强制项未达标 -> 记录为技术债 -> 进入下一阶段看板跟踪"

这段配置里有两个设计要点值得单独说。第一，强制项和非强制项分开，避免”全都要”导致阶段永远过不去。第二，例外流程必须写清楚谁签字，否则一旦出现例外就会陷入无休止的讨论。

3. 阶段门的自动化

配置好之后，阶段状态就不需要人工改了。每一个出口条件对应一个可验证的对象：报告、签字单、脚本输出。这些对象的状态变化会自动驱动阶段通过率。

Gate Owner 在评审时看到的不再是一堆 PPT，而是一个进度条和未完成项列表。评审会从”汇报+争论”变成了”确认+决策”，这是我在这个项目里感觉最明显的变化。

跨部门沟通上也省事很多。因为阶段 ID 是唯一的，五个部门在同一个阶段对象上操作，看板、甘特、报表三种视图自动一致，不再出现”研发说这个阶段过了、测试说还没过”的情况。

4. 上线 6 个月的数据

我把上线前 6 个月和上线后 6 个月的数据做了对比。统计口径是”所有已通过阶段门”，样本 43 个阶段周期。

• 阶段门一次通过率：从 34% 提升到 71%。提升主要来自出口条件提前冻结，减少了评审现场临时加条件的情况。
• 阶段评审平均时长：从 3.6 小时降到 1.4 小时。因为汇报部分被清单替代，会议只处理未达项和例外。
• 跨部门交接返工工时：从每月 62 人天降到每月 21 人天。下降最明显的是联调阶段的接口类返工。
• 阶段状态同步耗时：从每周约 9 小时（人工整理台账）降到接近 0。这是纯粹的自动化收益。

需要客观说明的是，这些改善不是单靠工具实现的。工具解决的是”状态一致”和”自动化”，而出口条件的定义、Gate Owner 的确定、例外流程的设计，都是管理动作。我在别的项目里见过工具配置得很漂亮但阶段依然混乱的情况，原因就是这三件事没做。

5. 私有化部署带来的额外价值

这一点很多人没意识到。私有化部署除了满足数据合规，还有一个隐性好处：阶段模型可以按组织自己的语言定制，不用迁就 SaaS 的通用字段。

这家企业有个特殊的阶段叫”客户预验收”，在通用模型里没有对应项。私有化环境下我们直接扩展了阶段类型，并且把这个阶段和客户侧的验收单做了字段映射。这种定制在共享版 SaaS 里通常要绕很大一圈。

六、四个可复用的模板（含字段定义）

这一节给出四个模板的完整字段。它们是我在多个项目里反复修订后的版本，字段增删都有具体原因，我在每个模板后面说明了为什么这么设计。

1. 模板一：阶段定义表

这张表的作用是回答”这个阶段是什么”。它的核心字段有七个，缺任何一个都会导致后续执行时出现歧义。

设计要点在于”计划窗口”被标为选填。很多团队的阶段定义表里最详细的就是日期，反而把出口条件留成一句话，这是本末倒置。

2. 模板二：阶段门检查清单

这是评审时实际用的东西。它的结构比阶段定义表更细，因为要支持现场逐条核对。下面是一个实际使用的清单示例：

gate_checklist:
stage: P3_VERIFICATION

gate_owner: "质量负责人"

review_date: "计划评审日期"

items:

id: C1

name: "回归用例通过率"

mandatory: true

criterion: ">= 95%"

evidence: "自动化测试报告链接"

result: "待填"

id: C2

name: "缺陷收敛趋势"

mandatory: true

criterion: "连续 5 日新增缺陷 evidence: "缺陷趋势图"

result: "待填"

id: C3

name: "严重缺陷清零"

mandatory: true

criterion: "P0/P1 缺陷数 = 0"

evidence: "缺陷列表导出"

result: "待填"

id: C4

name: "性能压测报告"

mandatory: false

criterion: "关键接口 P95 evidence: "压测报告"

result: "待填"

final_decision:

"通过"

"有条件通过（附条件清单与验证人）"

"不通过（附补做清单与复查日期）"

注意：不设"再讨论"选项

最后一行注释是这个模板最重要的部分。把”再讨论”从选项里删掉，会强迫评审现场做出决策。这是我用过的最有效的一个约束，比任何流程规定都管用。

3. 模板三：跨部门交接单

交接单解决的是”谁把什么交给谁”。它是跨部门项目里使用频率最高、也最容易被简化掉的一个模板。

最后一行”下游计划影响”，是我后来加上的。有了这个字段，交接延误就能自动折算成工期影响，管理层能直接看到”这次延误值不值得投入资源去救”。

4. 模板四：阶段健康度看板

前面三个模板都是”事前”的，这个看板是”事中”的。它的作用是在阶段门到来之前，提前预警哪些阶段有风险。核心指标有五个：

• 出口条件完成率：已满足项 / 总项数，含强制项单独统计。
• 强制项风险数：距离阶段结束时间不足 20% 但强制项未完成的数量。
• 上游依赖就绪率：本阶段依赖的上游交付物已交付比例。
• 交接单平均滞留时长：从发出到被接收确认的平均小时数。
• 例外审批积压数：已提交但未签署的例外申请数量。

这五个指标里，我建议优先盯强制项风险数和交接单滞留时长。前者预测阶段门会不会卡，后者预测跨部门协作是否健康。其他三个作为辅助参考。

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

同一套方法，在不同规模的团队里执行重点完全不同。我按团队规模和行业特征分了五类，给出各自的建议动作。

1. 20 人以下团队

不要搞阶段门。这个规模下，沟通成本极低，加一层阶段评审反而是纯开销。你需要的是一份 3 到 5 个里程碑的清单，每个里程碑写清楚”什么交付物完成 + 谁确认”就足够了。

我见过 12 人的初创团队照着大厂流程做了 7 个阶段门，结果每个阶段门都是一句话”大家觉得可以了就过”，形式完全空转。

2. 50-150 人单产品线

这是阶段治理收益最明显的区间。建议做三件事：设 5-6 个阶段、每个阶段一个 Gate Owner、把跨部门交接单固定下来。

这个规模下最容易出问题的是”阶段数量失控”。因为部门多，每个部门都想在自己的关键节点设一个门，最后变成十几个阶段。用前面讲的四层模型筛一遍，通常能砍掉一半。

3. 150 人以上或多事业部

这个规模下，阶段模型必须由工具承载，且必须支持多视图。一套阶段对象、多套视图是唯一可行的方案，靠文档同步一定会失效。

如果你的组织有私有化部署或数据本地化要求，同时又需要从现有工具迁移历史数据，那在选型时要把这两点作为硬性门槛来评估。这是我前面提到 PingCode 的适用场景：它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对于正在做国产替代的团队来说是比较省事的一条路径。

4. 强监管行业

金融、医疗、汽车电子的团队，阶段门是刚性的，不能砍。建议的做法是把合规阶段门和管理阶段门分开建模：合规门只关注证据完整性，管理门只关注交付物质量。

这样做的价值在于，当某个合规门卡住时，管理流程可以继续推进，避免整个项目因为一份签字文件而全线停摆。我在一个金融项目里见过因为等一份合规签字导致 60 人停工三天的案例。

5. 正在从 Jira 迁移的团队

这类团队有个特殊机会：迁移的同时重构阶段模型。因为迁移本身就要做字段映射，顺便把旧的阶段定义整理一遍，边际成本很低。

要注意的是迁移顺序。我建议的顺序是：先迁移工作项和附件保证历史可查，再重建阶段对象，最后配置门禁自动化。不要试图一次性把阶段治理和迁移做完，那会导致项目周期失控。

八、不同情况下的取舍

前面讲的是怎么做，这一节讲清楚代价。任何阶段治理都有成本，明白成本在哪里，才能做出适合自己的取舍。

1. 阶段数量 vs 管理开销

阶段数量增加带来的开销不是线性的。每增加一个阶段门，你增加的不只是一次会议，还有出口条件定义、证据收集、评审排期、例外处理这一整套动作。

我的经验是：阶段数量从 5 个增加到 8 个，管理开销大约翻倍，但风险控制能力的提升通常不到 30%。所以除非有明确的合规要求或高额成本承诺点，否则不建议超过 7 个阶段。

反过来说，如果你的项目单次失败成本极高（比如硬件开模、临床实验），那多设阶段门是划算的。这时候衡量的不是管理开销，而是失败成本的期望值。

2. 门禁严格度 vs 交付速度

强制项 100% 通过这条规则很有效，但它也有代价：当某个强制项因为客观原因无法完成时，整个阶段会被卡住。

我的处理方式是设置例外通道，但例外必须满足两个条件：由项目发起人签署风险接受书，并且记录一个明确的后续跟踪项。这样既不阻塞交付，也不让风险消失。

关键是要让例外变得”贵”。如果例外很容易获得批准，那强制项就形同虚设。我们项目里例外的批准率大约是 23%，这个比例我认为是健康的，足够应对真实困难，又不会滥用。

3. 标准化 vs 部门自治

这是一个长期张力。完全标准化会让部门执行别扭，完全自治会让数据无法汇总。

我采用的折中方案是”底层模型统一、表层呈现自治“：阶段 ID、Gate Owner、出口条件结构这三样必须统一；阶段名称的显示别名、视图布局、部门内补充字段可以自治。

这个方案在 260 人规模的组织里跑了半年，没有出现数据口径不一致的问题，同时各部门的接受度明显高于强制统一。

4. 自建 vs 采购

最后一个取舍是工具层面。自建的最大好处是贴合业务，最大坏处是维护成本高、迁移能力弱。

我的判断标准是：如果你们的阶段模型在未来两年内可能有较大调整，优先选可配置能力强的采购方案；如果阶段模型极其特殊且长期稳定，才考虑自建。

对大多数 100 人以上的组织来说，采购方案的性价比更高，前提是它满足两个硬条件：能承载自定义阶段对象，能导入现有工具的历史数据。

这两点我在前面反复提到，是因为它们决定了阶段治理能不能”落地成本可控”。一个阶段模型设计得再好，如果迁移要重做一遍全部历史数据，团队大概率会选择放弃。

九、下一步怎么做

如果你读到这里，最实际的动作不是立刻改流程，而是先做一次”阶段体检”。下面是我建议的三步走，总投入大约 3 到 5 个人日。

第一步：盘点现有阶段门。把你现在所有的阶段边界列成一张表，标出每个阶段门是否有唯一 Gate Owner、是否有结构化出口条件、是否有变更记录。三个都是”是”的标记绿色，缺一个标记黄色，缺两个以上标记红色。通常你会发现红色比例超过一半。

第二步：用四层模型筛一遍。对每一个红色阶段门，按顺序问四个问题：这里是否发生风险类型切换、是否存在跨部门责任转移、是否发生不可逆成本承诺、是否有外部合规要求。四个答案都是”否”的，直接合并或删除。

第三步：先改交接面，再改门禁。不要一上来就动全部阶段。挑一个跨部门交接最频繁的边界，把它改成结构化交接单，跑一个完整阶段周期，看返工工时有没有变化。有变化再推广。

最后说一个我自己的判断：阶段划分这件事，最容易犯的错误是把它当成一个文档工作，而它本质上是一个接口设计工作。你设计的不是五个阶段的名称，而是五个”上下游之间如何交接”的接口。接口设计得好，跨部门协作就会像流水线一样自动流转；接口设计得含糊，再多的评审会也只是在给混乱打补丁。

如果你只能做一件事，那就做这一件：把下一个阶段的出口条件，在启动这个阶段之前写清楚，并且指定一个唯一的验收人。这一个动作，通常能带来比其他所有动作加起来都更明显的改善。