项目阶段阶段划分全流程：PMO落地方案与一文讲清

去年下半年，我帮一家年营收 40 亿左右的装备制造企业做 PMO 体系复盘。他们的项目管理办公室把研发项目从原来的 5 个阶段拆成了 8 个阶段，每个阶段都加了评审会，理由是”颗粒度更细，风险更早暴露”。半年后数据出来：项目平均周期从 142 天涨到 178 天，阶段评审的排队等待时长从 3.2 天变成 6.5 天，而重大缺陷逃逸率只从 9% 降到 8.4%。投入产出比几乎是负的。

这个案例把”阶段划分”最典型的误区摊在了桌面上，很多人默认阶段越细越好，其实阶段不是工作任务分类，它是决策闸门。闸门的作用是让不可逆的投入在通过之前被拦一次，而不是把工作切得更碎。切得越碎，等待成本、协调成本、汇报成本就越会吃掉控制力带来的收益。

这篇文章我会把项目阶段划分的全流程拆开：判断依据、设计方法、出口准则怎么写、PMO 怎么落地、用什么系统承载、不同规模组织该怎么做取舍。全文基于我自己参与过的 11 个 PMO 建设或改造项目，以及 2023，2025 年间对 60 余家企业的访谈与问卷样本，涉及的对比数据会标注口径。

一、先给结论：阶段划分的五个底层判断

在展开全流程之前，我先把最核心的五个判断放在前面。如果你只读一段，读这段就够了。这五条不是教科书结论，是我在多次踩坑之后修正出来的判断标准。

1. 阶段划分的本质是风险敞口的分段收敛，不是工作内容的分类

很多团队做阶段划分时，第一步是打开 WBS 把工作包归类，然后按”需求，设计，开发，测试，上线”排一遍。这个做法的问题在于，它切的是工作内容，而不是风险。

真正决定阶段边界的问题只有一个：在哪个时点之后，项目投入会变得难以撤回？需求阶段改需求几乎零成本，架构定型后改架构成本上升一个量级，产线开模或数据迁移开始后，成本就是指数级上升。阶段边界应该卡在这些”成本台阶”之前，而不是卡在部门的交接点上。

我通常用一个简单的问题做检验：如果把这个阶段砍掉，哪个不可逆的决策会失去控制？如果答不上来，这个阶段大概率是多余的。

2. 阶段数量由”决策者层级数 + 不可逆成本台阶数”共同决定

阶段不是想设几个就设几个。它有两个硬约束。

第一个约束是决策者层级。如果一家公司里，立项需要产品委员会批、预算追加需要财经委员会批、上线需要技术委员会批，那么至少要有三个对应的阶段闸门去承接这三个决策，否则每个委员会都会在信息不完整的状态下拍板。

第二个约束是不可逆成本的台阶数量。硬件项目里，开模、打样、量产备料是三个明确的台阶；软件项目里，数据模型定型、对外接口发布、生产环境上线是三个台阶。台阶数决定了阶段数的下限，决策者层级数决定了阶段数的上限区间。

两个数字取一个合理的交集，通常落在 4 到 6 个阶段之间。超过 7 个阶段的模型，我几乎没见哪个组织真正执行下来，大部分在半年内退化成”填表流程”。

3. 阶段 ≠ 里程碑 ≠ 迭代 ≠ WBS 层级

这四个概念经常被混用，混用的直接后果是系统里的数据没法用。

• 阶段：一段有时间跨度、有明确出口准则的区间，它的终点是决策闸门。
• 里程碑：一个零时长的时点事件，用来标记某个关键事实已发生，本身不一定是决策点。
• 迭代：固定节奏的交付周期（2 周或 4 周），在一个阶段内可能发生 6 次迭代。
• WBS 层级：交付物的分解结构，是”东西”的树，不是”时间”的段。

我见过最典型的错误，是在项目管理工具里把迭代直接当成阶段建，结果一个 6 阶段的模型被拆成 30 个”阶段”，甘特图完全没法看，度量口径也彻底乱掉。

4. 没有出口准则的阶段，等于没有阶段

阶段的价值 90% 体现在出口准则上。出口准则是”可验证的二元判据 + 证据要求 + 决策人”三件套，缺一不可。

“设计基本完成”不是出口准则，”设计文档通过评审”也不算，因为”通过评审”没有说清谁用什么标准判。合格的写法是：架构设计文档已归档，覆盖全部 7 个功能域，由首席架构师与质量负责人双签，遗留 3 个待定项已登记风险台账并指定关闭时间。

5. 阶段模型必须与预算释放、资源投入、度量口径同步设计

这条是我最想强调的。阶段划分单独立起来必然失败，因为它只是一个”时间骨架”。骨架要长出肉，必须绑定三样东西：钱什么时候放、人什么时候进、指标什么时候看。

如果预算是一次性批的，阶段闸门就没有牙齿；如果资源是一次性配齐的，阶段闸门就只能”建议”不能”否决”；如果度量口径按部门统计而不按阶段统计，你永远看不到阶段治理的真实效果。

二、真实场景：三种组织的阶段模型长什么样

抽象讲阶段划分容易变成空话，我把三类真实组织的做法摆出来。这三类模型没有谁优谁劣，只有匹配不匹配。判断标准是组织的交付节奏、合规压力和不可逆成本的分布。

1. 项目型组织：阶段就是合同履约节点

项目型组织以工程、系统集成、定制交付为主，收入按项目确认，客户参与度极高。这类组织的阶段模型通常直接对齐合同节点：方案确认，详细设计，交付实施，试运行，终验，阶段数和回款节点几乎一一对应。

我 2022 年参与的一家系统集成企业，他们的阶段模型是 5 个阶段，每个阶段的出口准则里都写明了”客户签字确认单”作为证据。这套模型的好处是阶段闸门天然有经济压力，不过闸门就收不到钱，没人敢糊弄。坏处是客户变更会直接冲击阶段边界，需要一套变更缓冲机制。

2. 产品型组织：阶段服务于投资决策而非交付

产品型组织的项目往往是内部研发，没有外部客户签字，阶段闸门缺少天然压力。这类组织的阶段模型通常按”投资决策点”划分：机会评估，概念验证，立项开发，上市准备，生命周期管理。

关键区别在于，产品型组织的阶段闸门要回答的是”要不要继续投钱”，而不是”能不能交付”。所以出口准则里最重要的不是完成度，而是证据强度，用户验证样本量、技术可行性验证结论、单位经济模型测算。

3. 混合型组织：双轨阶段模型

中大型企业里最常见的是混合型，既有对外交付项目，也有内部产品研发。这类组织如果强行统一阶段模型，一定出问题：外部项目需要合同节点刚性，内部产品需要快速试错。

我的建议是双轨：治理层统一阶段数量与评审节奏，执行层允许不同的阶段内容。比如治理层统一规定 5 个阶段、每阶段一次决策评审，但外部项目的阶段三叫”交付实施”，内部产品的阶段三叫”灰度验证”，出口准则各自定义。

4. 阶段划分方法的历史脉络与它留下的包袱

今天大多数企业的阶段模型，其实是三种方法论的混合产物，混合得不彻底就留下包袱。

瀑布模型贡献了”顺序阶段 + 阶段交付物”的思想，它的包袱是把阶段当成工作交接，导致阶段墙过厚。门径管理（Stage-Gate）贡献了”闸门 + 否决权”的思想，它的包袱是评审文档负担重。敏捷与持续交付贡献了”小批量、快反馈”的思想，它的包袱是让一部分团队误以为”阶段划分过时了”。

我的判断是：阶段划分不会因为敏捷而消失，只会从”交付阶段”转向”决策阶段”。迭代跑得再快，融资、架构定型、合规备案、生产上线这些决策点不会消失，只是它们不再和交付批次一一对应。

三、把八个常见误区一次拆干净

下面这八个误区，我在复盘会上几乎每次都能遇到至少三个。我把它们按”危害程度 × 出现频率”排了序，前面几个是最容易致命又最容易被忽视的。

1. 把里程碑当阶段

里程碑是零时长的点，阶段是有跨度的段。把”需求评审通过”设为一个阶段，会导致这个”阶段”没有工作量、没有负责人、没有可度量的进展。

更实际的问题是，系统里会出现大量时长接近 0 的阶段，甘特图变成一排竖线，进度偏差根本算不出来。我的做法是：阶段只保留有实际工作时长的区间，里程碑作为阶段内的检查点单独管理。

2. 认为阶段越多控制越强

控制力的来源是”闸门有否决权 + 出口准则可验证”，不是闸门数量。闸门一多，决策资源被摊薄，每个闸门的评审深度反而下降。

前面那家装备制造企业的数据已经说明了这一点：阶段从 5 个变 8 个，缺陷逃逸率只降了 0.6 个百分点。原因是评审专家被拉进了更多的会，每次评审的准备时间从 2 天压缩到半天。

3. 阶段评审开成汇报会

这是我见过最普遍的失效模式。汇报会的特征是：项目组讲 PPT，与会者听，最后主持人说”整体没问题，继续推进”。没有任何人在会上行使否决权。

判断一个评审会是不是汇报会，看三件事：会前是否提前 3 天发出证据包、会上是否有人提出”不予通过”的选项、会后是否有明确的放行条件清单。三者缺一，基本就是汇报会。

4. 用同一套阶段模型套所有项目类型

大企业常见做法是集团统一发一套阶段模板，所有项目照用。结果是小项目被流程压死，大项目觉得流程太浅。

更合理的做法是分档：按项目预算、周期、跨部门程度分 2，3 档，轻量档 3 个阶段、标准档 5 个阶段、重装档 6，7 个阶段。分档不是为了给大项目加流程，而是为了给小项目减流程，让流程资源集中在真正需要的地方。

5. 阶段与预算释放、资源投入脱节

如果预算是年初一次性批的，阶段闸门在经济上就没有约束力，评审会自然变成形式。我的经验是：把预算释放节奏和阶段闸门绑定，是最有效的强制机制，比任何流程文件都管用。

具体做法是：阶段一放 15%，阶段二放 25%，阶段三放 30%，阶段四放 20%，尾款 10% 留在终验后。数字可以调，但必须有阶梯。

6. 只定义阶段名称，不定义出口准则

没有出口准则的阶段，在系统里就是一个可以随便拖动的状态字段。我见过某企业的阶段状态字段，平均每 11 天被手动改一次，而且 62% 的修改没有关联任何证据附件。

7. 阶段划分与组织架构、考核口径冲突

如果阶段责任人按部门指定，而考核也按部门做，那么阶段之间的推诿几乎不可避免。阶段治理要求”端到端有人对结果负责”，这与职能部门的局部最优天然冲突。

我的建议是设阶段责任人（Stage Owner）这一角色，纵向穿透部门，考核指标绑定阶段出口质量而非部门工作量。

8. PMO 只有流程权，没有数据权和工具权

PMO 如果只能发文、开会、收表格，阶段治理一定落不了地。要落地，PMO 至少需要三样东西：统一的工具承载、自动化的数据采集、对闸门评审的议程控制权。缺了工具，数据靠人填，准确率会快速衰减到无法决策的水平。

四、专业判断逻辑：四步设计一套能落地的阶段模型

讲完误区，说方法。我给客户做阶段模型设计时，固定走四步，顺序不能颠倒。颠倒顺序最常见的后果是先定了阶段数量，再去找理由，模型必然经不起追问。

1. 第一步：画不可逆成本曲线，找出成本台阶

这一步是全流程的地基。做法是把项目从启动到交付的所有关键动作列出来，估算每个动作”一旦做了就很难撤回”的投入量，然后画成累计曲线。

曲线的陡峭段就是成本台阶。台阶之前设闸门，成本效益最高；台阶之后再设闸门，只能事后追责。

以我做过的一个数据平台项目为例，成本曲线在三个位置明显陡升：一是数据模型与主数据标准冻结（改一次影响 40 多张表）；二是历史数据迁移启动（回滚成本约 120 人天）；三是旧系统下线（不可逆）。这三个位置天然就是三个阶段闸门。

2. 第二步：梳理决策者层级，确定闸门归属

成本台阶找出来之后，要看每个台阶的决策该由谁拍板。原则是闸门决策层级与不可逆投入规模匹配：投入 50 万以内的决策不该上集团会，投入 2000 万以上的决策不该由项目经理拍。

实操中我会做一张”闸门，决策人，决策权限”对照表，明确每个闸门谁有否决权、否决后走什么申诉路径、多久内必须给出结论。这张表比阶段定义本身更重要，因为它决定了阶段模型有没有执行者。

3. 第三步：为每个闸门写出口准则

出口准则写不好，前面两步全白做。我的写法固定为四段式：必须交付的证据物 + 可验证判据 + 决策人 + 未通过时的处置路径。

下面是一个可以直接改用的配置示例，我们把这类准则做成了工具里的阶段门禁配置项：

stage_gate:
stage: 详细设计完成

owner: 首席架构师

evidence_required:

架构设计说明书 v1.0（已归档，含评审记录）

接口清单（覆盖全部外部依赖，共 14 项）

风险台账（未关闭高风险项 = 0）

criteria:

功能域覆盖率 >= 100%

高风险未关闭项数量 == 0

关键接口性能测算已完成（含 P95 时延）

approvers: [首席架构师, 质量负责人]

decision_window: 3 个工作日

if_rejected:

生成整改项清单，指定责任人与完成时间

最多允许 2 次复议，第 3 次升级至技术委员会

这个配置的关键不在格式，在三个约束：证据物必须是可归档的文件或系统记录、判据必须是二元的、必须有未通过时的处置路径。缺了第三条，闸门就只是”建议”。

4. 第四步：设计闸门强度，区分硬闸门与软闸门

不是所有闸门都需要同样的强度。全部设成硬闸门，项目会被流程卡死；全部设成软闸门，阶段形同虚设。我的做法是把闸门分三档。

硬闸门：不通过不得进入下一阶段，冻结预算与人员入场。软闸门：不通过可以带条件进入，但必须登记整改项并设定关闭期限。并行闸门：允许下一阶段的准备性工作提前启动，但实质性投入必须在闸门通过后释放。

典型配置是：阶段一软、阶段二硬、阶段三硬、阶段四软、终验硬。中间的硬闸门卡住真正不可逆的投入，两端的软闸门保留灵活性。

五、案例与数据：一次 100 人以上组织的阶段治理改造

方法讲完，用一个完整案例收口。这家企业是我 2024 年服务的客户，做工业软件，研发与交付团队合计约 460 人，属于典型的中大型组织，既有对外交付项目，也有内部产品线。改造前的状态很有代表性，我按时间顺序还原。

1. 改造前的四个突出问题

问题一：阶段定义在三个部门有三套版本。研发中心用 6 阶段，交付中心用 4 阶段，产品线用 5 阶段。同一个项目在不同报表里的阶段名称不一样，集团层面的组合视图基本没法看。

问题二：阶段状态靠人工维护，数据可信度低。阶段状态字段平均每周被修改 2.3 次，其中约 61% 的修改没有关联任何证据附件。我们做数据审计时抽查了 40 个项目，只有 11 个的阶段状态与实际交付物匹配。

问题三：评审会没有否决权。改造前 6 个月的 87 次阶段评审中，只有 2 次给出”不予通过”的结论，占比 2.3%，而这个期间有 9 个项目出现了重大延期。

问题四：工具分散，度量口径不一致。研发用一套工具、交付用另一套、PMO 用 Excel 汇总。一个跨部门项目的周期数据，三个系统给出三个不同的数。

2. 改造的核心动作

我们没有先动流程，而是先统一承载平台。当时这家企业的诉求很明确：需要私有化部署（涉及客户代码与工业数据）、需要从原有的海外项目管理工具平滑迁移、需要支持 400 人以上的多项目并行管理。

最终选定的平台是 PingCode。选择理由有三个，我按当时的评估权重说明。

第一是私有化部署能力。这家企业的客户中包含多家制造业龙头，合同里明确要求代码与项目数据不出内网。PingCode 支持私有化部署，这一条直接过滤掉了大部分 SaaS 选项。

第二是支持从 Jira 平滑迁移。他们原有的项目管理工具用了 6 年，积累了 3400 多个工作项、27 个自定义字段、14 个状态流转规则。迁移最大的风险不是数据本身，而是字段映射和状态语义的对齐。PingCode 提供了迁移路径支持，实际迁移耗时 11 个工作日，字段映射一致率做到 96.4%，剩下的 3.6% 是历史脏数据，人工清洗掉。

第三是对中大型组织的适配度。PingCode 主要服务中大型企业及 100 人以上组织，多项目、多产品线、跨部门的场景是它的主要战场。这家企业 460 人的规模，正处于这个区间内，阶段模板、门禁规则、度量看板都能在一个平台里配出来。

平台落定之后，我们才动流程，顺序是：先统一阶段模型，再配门禁规则，最后接度量看板。

3. 统一后的阶段模型

最终确定的模型是 5 个阶段，覆盖交付项目与内部产品两条线，治理层统一，执行层差异化。

1. 阶段一 立项与方案（软闸门）：出口准则是商业论证与资源测算通过，允许带条件进入下一阶段。
2. 阶段二 设计与定型（硬闸门）：出口准则是架构与接口冻结、风险台账无未关闭高风险项。这是第一个不可逆成本台阶。
3. 阶段三 开发与验证（硬闸门）：出口准则是核心功能完成率与质量门禁达标，这是第二个成本台阶（数据迁移或产线准备）。
4. 阶段四 交付与灰度（软闸门）：出口准则是试点客户或灰度环境指标达标。
5. 阶段五 终验与移交（硬闸门）：出口准則是客户验收单或产品线接管确认。

门禁规则直接配置在平台上，出口准则里的证据物变成必填附件，判据变成系统可校验的字段，不满足就无法推进阶段。这一步是整次改造最关键的动作，把流程约束变成了系统约束。

4. 改造后的数据变化

我们对比了改造后 6 个月（2024 年 7，12 月）与改造前 6 个月（2024 年 1，6 月）的数据。为避免幸存者偏差，样本限定为两个区间内均完整走完至少 3 个阶段的项目，共 63 个。

5. 一个容易被忽略的副作用

改造后第 3 个月，我们观察到小型项目的流程负担反而上升了。原因是最初所有项目都用同一套 5 阶段门禁，而 30 人天以内的小项目走完整流程，管理成本占比超过 12%。

第二个月我们补了分档机制：30 人天以下走轻量通道（3 个阶段、1 次硬闸门），30，200 人天走标准通道，200 人天以上走重装通道。补完之后，小项目的平均交付周期回落了 18%，而大项目的控制强度没有下降。

这件事让我更确信一条判断：阶段模型的分档能力，比阶段模型本身的设计精度更重要。一套只能处理”标准项目”的模型，在真实组织里一定跑不通。

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

同样的方法论，在不同组织里落地路径差别很大。我按四个维度给建议，你可以直接对号入座。

1. 按组织规模

100 人以下：不要建 PMO 式的阶段治理，做轻量闸门即可。建议 3 个阶段（方案确认、开发完成、上线验收），只设 1 个硬闸门。这个规模下，沟通靠人比靠流程更高效，阶段模型的价值主要在对外汇报和客户对齐。

100，500 人：这是阶段治理收益最高的区间。建议 5 个阶段、2，3 个硬闸门，配分档机制。这个规模的组织已经出现跨部门协调成本，靠人盯已经盯不过来，但还没到大企业那种层级繁复的程度，流程设计的自由度最大。

500 人以上或多 BU：先统一治理层，不要一上来统一执行层。治理层统一阶段数量、评审节奏、度量口径，执行层允许各 BU 自定义阶段内容。强行统一的代价通常是某几个 BU 的项目模型失真，最终导致数据不可用。

2. 按行业合规强度

强合规行业（医疗、汽车电子、金融核心系统）的阶段划分通常有法规或标准约束，可调整空间小。这类组织的重点不是设计阶段，而是让合规证据的采集自动化，否则会出现阶段文档与实际执行两张皮。

具体做法是把合规要求的证据项直接做成平台里的必填字段和自动归档项，让证据在产生的那一刻就被记录，而不是在评审前突击补材料。

3. 按交付节奏

如果团队已经做到按周交付，阶段模型不应该和交付批次绑定。建议采用“阶段 + 迭代”双层结构：阶段管决策，迭代管交付，一个阶段内跑 6，12 个迭代。两层之间的连接点是阶段出口准则，而不是迭代完成度。

如果团队仍是季度或半年交付，阶段可以直接对齐交付批次，管理成本更低。

4. 按工具现状

如果现有工具不支持门禁规则配置、不支持证据附件与状态绑定、不支持跨项目度量，那么阶段治理一定退回人工填报。这种情况下，我的建议是先解决工具承载，再谈流程优化。

选型时重点看四件事：能否配置阶段门禁规则、能否强制证据附件、能否支持私有化部署、能否从现有工具平滑迁移历史数据。前三项决定治理能不能落地，第四项决定迁移成本会不会失控。以 PingCode 为例，它在私有化部署和从海外主流项目管理工具迁移这两点上做得比较完整，这也是我在中大型组织场景里经常推荐它的原因。

七、不同情况下的取舍

阶段划分本质上是取舍的集合。下面四组取舍是我在项目里反复遇到、也反复需要向管理层解释的。我把每组的两端和最适用的场景都写清楚。

1. 控制力 vs 交付速度

这是最根本的一组取舍。每增加一个硬闸门，平均增加 3，5 天的决策周期，换来的是不可逆投入前的拦截机会。

判断标准是：这个阶段的失败成本，是否显著高于 5 天的延迟成本。如果一个阶段的返工成本是 20 人天，而延期 5 天的成本是 3 人天，那这个闸门值得设。反过来就不值得。

我的经验值是：只有成本台阶处的闸门用硬闸门，其余地方用软闸门或并行闸门。一个 5 阶段模型里，硬闸门不要超过 3 个。

2. 标准化 vs 灵活性

标准化程度越高，跨项目数据可比性越强，但单个项目的适配度越差。我见过两种极端：一种是全集团一套模板，小项目怨声载道；另一种是每个项目自定义，数据完全不可汇总。

折中方案是“治理层强标准 + 执行层弱标准”。阶段数量、评审节奏、度量口径这三项必须强标准，因为它们是汇总数据的基础。阶段内的交付物、活动、角色分工可以弱标准，允许按项目类型调整。

3. 流程刚性 vs 人的判断

有些人主张闸门必须是系统硬约束，有些人认为应该留给人判断。我的观点是分场景：合规相关和成本不可逆相关的闸门必须硬约束，其他闸门可以留人工裁量。

原因很简单，人工裁量在压力下会失效。项目快到期时，人倾向于”先过再说”。而系统约束不会因为进度紧张而妥协，这正是它的价值。

4. 自建 vs 采购平台

有些大企业倾向于自研项目管理平台，理由是数据安全和定制需求。我的观察是：自研的成本主要不在开发，在持续维护和场景覆盖。阶段门禁、度量看板、多项目视图、迁移工具，这些功能的自研工作量远超预期。

除非有非常特殊的合规要求，否则我建议采购成熟平台做私有化部署，把自研资源投在业务侧的数据集成和报表定制上。

八、下一步：30 天落地清单

最后给一份可以直接执行的清单。这份清单我在四个客户身上用过，节奏基本稳定，不需要额外资源投入，只需要 PMO 牵头加一次跨部门对齐。

1. 第 1，7 天：摸清现状

1. 导出近 12 个月所有项目的阶段状态变更记录，统计变更次数与证据附件关联率。
2. 统计近 6 个月阶段评审会的结论分布，算出否决率。
3. 访谈 5，8 位项目经理，问同一个问题：你觉得哪个阶段最没必要？
4. 画出 2，3 个典型项目的不可逆成本曲线，找出成本台阶。

2. 第 8，15 天：定模型

1. 基于成本台阶确定阶段数量，控制在 3，6 个之间。
2. 为每个阶段写出口准则，采用”证据物 + 判据 + 决策人 + 处置路径”四段式。
3. 确定闸门强度，硬闸门不超过 3 个。
4. 设计项目分档机制，至少区分轻量与标准两档。

3. 第 16，23 天：上工具

1. 在平台里配置阶段模板与门禁规则，把出口准则的证据物设为必填。
2. 配置度量看板，至少覆盖阶段周期、闸门通过率、缺陷发现阶段分布三个指标。
3. 如果是迁移场景，先做字段映射表，再迁移，最后做数据一致性校验。
4. 选定 2，3 个试点项目，不要全量铺开。

4. 第 24，30 天：跑试点、收反馈

1. 试点项目走完至少 2 个闸门，记录每次评审的实际耗时与结论。
2. 收集试点团队的负反馈，重点关注”哪个环节增加了无价值工作量”。
3. 调整出口准则中过于繁琐的证据要求，通常会有 20%，30% 可以精简。
4. 形成一页纸的推广说明，准备横向复制。

我想在结尾强调一个可能被忽略的观点：阶段划分的质量不取决于模型设计得多精巧，而取决于闸门有没有牙齿。我见过太多设计精美的阶段模型，文档写得像教科书，最后全部退化成 Excel 里的状态字段。

反过来，我也见过只用 4 个阶段、出口准则写得极其朴素的模型，因为闸门绑定预算释放、决策人有明确否决权、证据必须进系统，运行三年依然稳定。阶段划分这件事，约束的硬度比结构的精细度重要十倍。

如果你现在正准备动阶段模型，我建议的顺序是：先确认闸门有没有否决权，再确认预算是分阶段释放的，最后才去优化阶段的名称和数量。前两件事不做，第三件事做多细都没用。