阶段划分怎么做？PMO实操方法：项目阶段从0到1

去年三季度，我给一家 800 人规模的装备制造企业做研发流程诊断。启动会上，研发总监把他们的项目管理规范投到屏幕上，一共 9 个阶段，从”概念”到”量产移交”，画得整整齐齐，往下翻还有三页 A3 的甘特图模板。但同一场会，我在访谈纪要里读到的是另外几句话：项目经理说”阶段评审就是走个流程，反正最后都能过”；测试负责人说”我们每次都在试产阶段才发现需求理解错了”；财务说”项目预算超支要等到结项才知道”。

这三句话指向同一个问题：他们的阶段划分只切了时间，没有切决策。阶段数量从 3 个加到 9 个，评审会议从每月 1 次加到每周 2 次，但真正需要被回答的问题，”这个项目还要不要继续投”、”这个方案要不要推倒重来”、”这笔预算要不要追加”，一个都没有被固定在某一个时间点上。

这篇文章不讲教科书上的阶段定义，我把它拆成三个层次来讲：怎么判断你现在这套阶段划分是不是废的、0 到 1 从零设计一套阶段划分的四步逆推法、以及不同规模、不同不确定性下该怎么取舍。中间会给出一个中大型企业把 9 个阶段压到 5 个阶段的完整改造案例和前后 12 个月的数据。

一、先给结论：阶段划分的本质是”决策点设计”，不是”时间轴切分”

如果把”阶段划分”当成时间轴切分，你会得到一套漂亮但没用的甘特图：每个阶段都有起止时间、都有负责人、都有交付物，但它无法回答任何一个真正需要拍板的问题。真正有用的阶段划分，是先找到项目生命周期里那几个”必须被决策的问题”，再把这些问题的解答时间点连成阶段边界。

我在做流程诊断时，会先问客户一个问题：“如果这个项目注定要失败，你希望在多早的时候知道？”答案往往在一到两个月之间。然后我会追问第二个问题：“你现在实际是在多早的时候知道的？”答案通常在六个月以后，或者干脆是失败的最后一刻。这两个答案之间的差距，就是阶段划分的质量差距。

1. 三个测试，快速判断你的阶段划分是不是废的

不需要完整审计，用下面三个测试就能判断一套阶段划分的实际水平。任何一个测试不通过，后面的流程再精细都是在自欺欺人。

1. 一句话测试。把每个阶段的目标压缩成一句话：”在这个阶段结束时，我们要能够决定 ____。”如果填不出这句话，或者填出来的是”完成 XX 开发”这类任务描述，说明这个阶段没有决策意义，只是一个工作包。
2. 可验收测试。每个阶段至少有一个交付物，能被项目组之外的第三方独立验收。注意关键词是”第三方”和”独立”，自己组内写的代码自己测，不算验收。如果所有交付物都要等到项目结束才能被外部确认，这个阶段划分只是幻觉。
3. 否决权测试。问一句：这个阶段评审有没有真的否决过一个项目或一个方案？如果过去 24 个月里，所有阶段评审的通过率是 100%，那么这套阶段划分的功能等价于零。

我见过最极端的一家客户，他们的阶段评审通过率连续三年是 100%，但同时立项 47 个项目、最终交付 31 个，16 个项目在过程中”自然消失”，没有一次正式终止决策，都是慢慢没人管了。阶段评审沒有否决权，就意味着真正的否决权被转移到了”资源悄悄撤走”这种失控的方式上。

2. 阶段划分要同时服务三个层次，不能只做一层

PMO 最容易犯的错，是把阶段划分只当成”进度汇报口径”。但在中大型组织里，阶段划分其实同时要被三个层次消费，每一层要的东西都不一样。

绝大多数失败的阶段划分，都是用交付层的粒度去喂治理层的决策：给投委会看 9 个阶段、180 个任务的甘特图，投委会看完仍然不知道该不该继续投钱。反过来，如果只给执行团队 3 个阶段，他们又会觉得”阶段太长、目标太虚、干着没有反馈”。

正确的做法是：治理层的决策点是骨架，交付层的交付物是关节，执行层的迭代是肌肉。三者不是同一套东西的三个名字，而是三张不同精度的地图。

二、背景与真实场景：为什么大多数团队是在”补阶段划分的课”

阶段划分这件事有一个特殊之处：它几乎不会在组织早期被认真设计，只会在组织变大以后被紧急补课。我接触过的团队里，阶段划分方案的来源大致分三类，每一类都有明显的后遗症。

1. 三种典型的起点

（1）模板继承型。从上一家公司、咨询公司、或者行业标准里拿来一套阶段定义，直接照搬。典型特征是阶段名称很标准，”概念、计划、开发、验证、发布”，但每个阶段的准出条件是从别的行业抄来的，跟自己的业务节奏对不上。我见过一家做工业软件的公司，把硬件行业的”试产验证”阶段照搬过来，结果整个阶段没有任何人能说清”试产”在软件语境下指什么，两个月后这个阶段被默默跳过。

（2）部门映射型。按组织的部门结构切阶段：需求阶段归产品部、设计阶段归研发部、测试阶段归质量部、上线阶段归运维部。这种切法看起来权责清晰，实际后果是阶段边界变成了部门边界，交接变成了甩锅。每个部门只要把自己的交付物”提交”出去，就算本阶段完成，至于上一步的理解是否正确，不在任何人的 KPI 里。

（3）危机应激型。某次重大事故之后，老板拍板要”加强过程管控”，PMO 连夜补出一套阶段和评审机制。这种方案的典型特征是想覆盖所有已知风险，于是阶段越加越多、检查项越加越细。半年后所有人都觉得流程太重，开始用各种理由申请豁免，一年后整套机制名存实亡。

2. 一个真实的翻车场景

前年我参与过一家新能源企业的流程复盘。一个投资约 2600 万的产线数字化项目，原定 14 个月交付，实际做了 22 个月，超支约 780 万。复盘时我们把所有问题按”最早可被发现的时点”重新排序，结果很扎心。

最关键的一个问题是”设备通信协议选型错误”。这个问题在第 3 个月就埋下了，但直到第 14 个月联调阶段才暴露。中间 11 个月，项目经过了 4 次阶段评审，每一次都通过了。为什么？因为那 4 次评审检查的是”文档是否齐全”、”任务是否完成”，而不是”这个技术假设还成立吗”。

这个案例让我确信一件事：阶段划分如果不承担”证伪”的功能，它就只是成本的搬运工。它把返工成本从阶段内部搬到了阶段之间，让风险看起来被管理了，实际上只是被推迟了。

3. 为什么大组织比小团队更需要阶段划分

100 人以下的团队，阶段划分往往是多余的。人少、沟通链路短、老板本人就是决策者，每天站会就能解决所有对齐问题。但组织一旦超过 100 人、或者项目一旦跨过 3 个部门，情况就变了：

• 信息衰减速度变快。每经过一个层级，信息失真率大约增加 15%-25%。阶段划分本质上是给信息衰减设置若干个”校正点”。
• 决策权的持有者和信息的持有者分离。能拍板的人（投委会、副总）离一线很远，他们只能通过阶段评审材料做判断。材料质量直接决定决策质量。
• 沉没成本效应被放大。人越多、投入越大，”算了继续做吧”的心理压力越强。阶段门禁的否决权，是对抗沉没成本效应的制度化手段。

三、拆解常见误区：六个高频踩坑

下面六个误区，我在实际项目里至少见过其中四个同时出现在同一家公司。它们不是水平问题，而是视角问题，设计阶段划分的人，站错了位置。

1. 按部门切阶段，而不是按交付物切

这是最普遍的一个。按部门切的阶段，边界天然落在”提交”这个动作上，而不是落在”被验证”这个动作上。判断方法很简单：看阶段名称里有没有部门名或职能名。“设计阶段”、”测试阶段”、”运维阶段”，只要出现这类词，基本可以确定是部门映射型。

正确的切法应该让阶段名称指向成果状态，比如”方案冻结”、”首件验证通过”、”小批量交付达标”。名字一变，责任人就从”部门”变成了”交付结果的负责人”，这是个本质区别。

2. 阶段目标写成任务清单，而不是状态描述

“完成需求文档编写”是任务；”需求范围经三方确认且不再有未决争议项”是状态。前者可以靠加班完成，后者必须靠对齐完成。任务清单式的阶段目标，会把项目推向”做完动作就交差”的行为模式。

我通常要求每个阶段目标都写成”状态 + 判定条件”的形式。比如不要写”完成架构设计”，要写”架构方案通过评审，关键接口定义完成，且三个主要技术风险各有验证结论（通过/不通过/降级方案）”。

3. 阶段数量照抄模板，不匹配项目不确定性

这是我认为最反常识的一点。很多团队认为不确定性越高的项目，越要”充分规划”，所以阶段要划得更粗、前期规划要更久。但实际经验正好相反：不确定性越高的项目，阶段应该越短、决策点越密，因为你需要更快拿到”假设是否成立”的反馈。

反过来，一个技术路线已经被验证过、需求高度确定的项目，阶段可以划得更长，因为长的阶段不会带来额外风险，只会减少交接损耗。把这两类项目用同一套阶段划分，必然有一类被伤到。

4. 只有准入条件，没有准出条件和否决条件

我审计过一套阶段规范，写了 40 页，其中 38 页是”每个阶段要做哪些事”，只有 2 页提到”准出”，而且准出条件是”完成上述工作”。这不是门禁，这是清单。一个完整的门禁至少要有三组条件：必须满足的（Go）、必须不存在的（No-Go）、可容忍偏差的（Conditional Go）。

5. 阶段与迭代混为一谈

有些团队做敏捷转型后，直接把”迭代”改名叫”阶段”，然后发现治理层完全看不懂汇报。问题在于：迭代是执行节奏，服务的是团队内部的工作节拍；阶段是治理节奏，服务的是资源与决策。两者可以嵌套，但不能互换。经验比例大概是 1 个阶段包含 3-6 个迭代。

6. 阶段评审会开成了汇报会

判断标准：这场会上，参会者是”来听进度”还是”来回答问题”。如果评审材料是 PPT 进度条加截图，会上一半时间在讲”我们做了多少事”，这本质上是一场汇报会。有效的阶段评审，材料应该是”待决策问题清单 + 证据 + 选项”，会议时间应该主要花在讨论选项上。

我推荐一个硬性约束：阶段评审材料的第一页，必须写清楚”本次评审需要您决策的问题是什么”，最多三个。写不出来，说明这个阶段没有存在的必要。

四、专业判断逻辑：从 0 到 1 设计阶段划分的四步逆推法

我发现绝大多数团队设计阶段划分的顺序是错的：从”我们要做哪些工作”出发，把工作聚类，然后给每一类起个名字。正确的顺序应该是从”谁要在什么时候做什么决策”出发，逆推到工作。这就是我要讲的四步逆推法。

1. 第一步：逆推决策点，先不碰任何工作内容

这一步只做一件事：把项目全生命周期里所有”必须被拍板”的问题列出来。不要考虑现在有没有人拍、能不能拍，先列出来。

提问模板是这三个：谁会在什么时候问出”还要不要继续”？谁能加预算或砍预算？谁是否决权持有人？我通常会在工作坊里让项目组闭眼想一个已经失败的项目，然后问：“回头看，哪三个时间点上，如果有人认真问一句，结局会不一样？”这个问题几乎每次都能逼出最关键的决策点。

一个中等复杂度项目的典型决策点集合是：

• 这个项目要不要立？（对应立项决策）
• 这个技术路线 / 产品方案要不要采用？（对应方案冻结决策）
• 这个版本要不要进入正式开发和资源投入？（对应开发启动决策）
• 这批产品 / 这个版本要不要发给真实用户或客户？（对应发布决策）
• 这个项目要不要正式结项、资源要不要释放？（对应结项决策）

注意，这五个问题里没有一个是”完成 XX 开发”。决策点的标志是它包含”要不要”，而不是”做没做完”。

2. 第二步：归并交付物，把决策所需的信息倒推出来

拿到决策点之后，对每一个决策点问：“要做出这个决策，决策者手上至少需要看到什么？”答案就是该阶段的必备交付物。

以”方案冻结决策”为例，决策者需要看到的通常包括：需求清单及其优先级、三个候选方案的技术对比、成本估算区间、主要风险清单及应对策略、以及”如果不选这个方案会怎样”的反向论证。

第二步最容易出的问题是交付物清单膨胀。需求清单变成需求文档，文档里又被要求包含二十个章节。控制方法是加一条硬规则：每一项交付物都必须能回答”它支撑哪个决策”，答不上来的删掉。这条规则通常能砍掉 30%-40% 的交付物。

3. 第三步：校验粒度，用三个口径把阶段数量收敛

走到这一步，你可能得到 8-12 个候选阶段。接下来要做的是收敛，我用三个校验口径：

1. 时长口径：单个阶段不应该超过项目总工期的 25%，也不应该短于 2 周。超过 25% 意味着这个阶段内部有未被识别的决策点；短于 2 周意味着它不构成治理节奏。
2. 验收口径：每个阶段必须有一个能被外部独立验收的交付物。如果两个相邻阶段都指向同一个交付物，合并它们。
3. 数量口径：项目总阶段数控制在 3-7 个。5 个是最常见的甜蜜点。超过 7 个，交接损耗开始跑赢控制力收益。

我通常的做法是先用时长口径和验收口径机械收敛，再结合项目类型人工微调。微调的原则是：前期密，后期疏。因为项目早期的假设最容易错、纠错成本最低；后期技术路线已定，频繁评审只会拖慢节奏。

4. 第四步：定义准入准出，为每个门禁写三组条件

这一步是决定阶段划分能否落地的关键。每个门禁必须有三组条件，缺一不可：

• Go 条件（必须满足）：通常是 3-5 项，每项都可以用”是/否”判定，不接受”基本完成”。例如”核心接口协议已冻结并有书面记录”。
• No-Go 条件（必须不存在）：任何一项触发即直接否决，不接受讨论。例如”存在未关闭的 A 类质量事故”、”关键技术风险仍无验证结论”。
• Conditional Go 条件（有条件通过）：允许带着明确的整改项进入下一阶段，但必须写清整改项、责任人、截止时间和不整改的后果。这是让门禁保持弹性的关键设计。

我特别建议把 No-Go 条件写少、写硬，三到五条就够，但要真的执行。我见过执行得最好的一家公司，No-Go 只有三条，两年里触发了四次，四次都真的暂停了项目，其中两次整改后继续、一次转向、一次终止。这四次否决，救回的预算远超整个流程管理投入。

5. 阶段、迭代、里程碑、WBS 的边界别搞混

这四个词经常被混用，我给一个我在工作坊里用的对照表，基本上讲完就不会再有人搞混。

最常见的错误组合是：用 WBS 完成率来证明阶段完成。任务都做完了，交付物可能一个都没被验收。这两个指标之间的缺口，是所有”看起来一切正常但最后延期”项目的共同特征。

6. 用配置化方式把阶段门禁写下来，拒绝口头约定

很多公司的阶段门禁只存在于会议纪要和某位资深 PM 的记忆里。我建议在项目管理系统里用配置化的方式把它写死，让门禁成为流程的一部分，而不是制度的一部分。下面是一段我在实际项目里用的门禁配置结构（脱敏示意）：

phase_gate:

id: G2

name: 方案冻结

entry:

required_artifacts:

需求清单（含优先级与来源）

候选方案技术对比（>=3 方案）

成本估算区间（P50/P90）

required_roles: [产品负责人, 系统架构师, 财务BP]

exit:

go_conditions:

关键接口定义完成并有书面基线

三个主要技术风险各有验证结论

成本区间经财务确认

no_go_conditions:

存在未闭环的 A 级风险且无缓解方案

核心依赖供应商未确认交付能力

conditional_go:

allowed_max_items: 3

must_record: [整改项, 责任人, 截止时间, 逾期后果]

decision:

owner: 研发副总

quorum: 4/5

window_days: 5

把这段配置落到系统里的最大好处，不是”更规范”，而是让门禁的执行不再依赖某个人记得。阶段未达准出条件，任务卡在门禁节点上无法流转，责任人自然会被迫处理。这比发一百封邮件提醒有效得多。

五、案例与数据观察：一家 400 人企业把 9 个阶段压到 5 个

下面这个案例是我实际参与过的改造项目，客户是一家约 400 人的智能硬件企业，同时有硬件研发、嵌入式软件和云端服务三条产品线。数据来自客户内部的流程管理统计口径，时间跨度是改造前 12 个月和改造后 12 个月。

1. 改造前的状态

他们原有的阶段划分是 9 个：概念、预研、方案、设计、开发、集成、测试、试产、量产移交。看起来非常专业，实际运行中的问题集中在这几个方面。

• 阶段之间职责不清。方案和设计两个阶段，在三个产品线里的分界完全不同，导致同一个角色在不同项目里要做的事不一样。
• 准出条件无法判定。9 个阶段里有 6 个的准出条件是”完成上述工作”，本质上没有判定标准。
• 门禁执行靠邮件和会议纪要。阶段评审材料散落在共享盘、邮件、企业微信里，历史项目复盘时经常找不到当时的关键决策依据。
• 阶段延期在结项时才被发现。因为阶段进度只在月度例会口头汇报，偏差没有系统化的暴露机制。

2. 改造动作：只做三件事

他们的改造没有引入任何新方法论，只做了三件事，我认为这三件事是可以直接复制的最小动作集。

（1）9 个阶段合并为 5 个。最终的形式是：概念与立项（G1）、方案与架构冻结（G2）、开发与集成（G3）、验证与试产（G4）、移交与结项（G5）。合并的核心依据是”两个阶段之间是否存在一个真实的决策问题”，没有决策问题的边界一律合并。原来”预研”和”方案”之间并没有独立的决策，所以合并；”测试”和”试产”之间也没有独立决策，所以合并。

（2）为 5 个门禁各写三组条件。Go 条件 3-5 项、No-Go 条件 3-5 项、Conditional Go 最多允许 3 个整改项。所有条件都要求可判定，不接受”基本完成”这类表述。这一条是改造中最花时间、也最见效果的部分。

（3）把阶段与门禁落到项目管理系统里。他们选择的是 PingCode 的私有化部署版本，主要是两个考虑：一是硬件与嵌入式团队的数据不能出内网，私有化部署是硬性要求；二是他们原有大量历史项目在 Jira 上，需要平滑迁移，不能接受”重新录入”这种方案。PingCode 支持 Jira 数据平滑迁移，实际迁移过程中历史项目的阶段、任务、缺陷数据基本保持了结构完整，团队没有经历”两套工具并行”的混乱期。

对当时正在做国产替代评估的他们来说，这也是一个可以直接落地的选择。

落到系统里之后，阶段准出条件的检查从”人工比对”变成了”系统校验”，阶段准出材料的齐套率从 61% 提升到 94%。这个数字背后的意义不是材料更整齐了，而是项目经理不用再花时间追材料，可以把精力放在识别风险上。

3. 改造后的 12 个月数据

我要特别强调最后一行。前面的所有指标改善，本质上都来自这一行：当门禁真的能否决项目时，项目组的行为才会改变。在门禁没有否决权的前 12 个月里，他们的阶段延期率是 28%；改造后第一次否决发生在第 7 个月，之后的 5 个月里阶段延期率降到了 12%。这个时间差不是巧合。

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

阶段划分没有通用答案，但有匹配规律。下面我按组织规模和业务特征拆成四种情况，给出可以直接执行的建议。每一条都假设你从零开始，而不是在现有基础上微调。

1. 100 人以下、单一产品的团队

不要设计阶段，设计”决策清单”。这个规模的团队，正式阶段划分的管理成本会超过它的收益。你需要的是把”必须被拍板的问题”列成一张清单，贴在墙上或者放在项目看板里，每次遇到就讨论并记录结论。

具体做法是三步：列出全生命周期的重大决策问题（通常 5-8 个）；为每一个指定一个决策人和一个”最晚决策时间”；决策结论用一页纸记录下来，包括考虑了哪些选项、为什么这么选、什么情况下会推翻。第三步是最容易被省略的，也是最值钱的，它让你在半年后还能理解当时的判断依据。

2. 100-500 人、多产品线或跨部门协作

这是阶段划分收益最高的区间。建议设计 5 个阶段、5 个门禁，并为每个门禁写三组条件。再往上一节讲的四步逆推法走一遍，通常两到三周就能完成初版。

这个规模下我最推荐的一个动作是：把门禁落到项目管理系统里，让”未达准出条件”成为任务无法流转的硬约束。原因很实际，这个规模的团队，PMO 通常只有 1-3 个人，靠人工追流程是追不动的。我参与的那个 400 人案例里，PMO 只有 2 个人，如果没有系统承载，5 个门禁的三组条件根本执行不下去。

工具选择上有两个真实约束要考虑：一是数据边界，如果你的业务涉及硬件、嵌入式、政企交付或合规要求，私有化部署基本是硬性条件；二是历史数据迁移成本，很多中大型组织并不是从零开始，而是从一个已有工具迁移过来，如果迁移必须重新录入，团队会本能地抵触，改造还没开始就先输了一半。这也是为什么我在评估时会重点看工具是否支持从主流项目管理工具平滑迁移，PingCode 在这两点上（私有化部署 + Jira 平滑迁移）是当时那个客户选择它的直接原因，也是目前国产替代场景里比较常见的一个落点。

3. 500 人以上、多事业部或多项目组合

这个规模的难点不再是”怎么划分阶段”，而是“怎么让不同事业部用同一套治理语言，同时不阉割各自的业务特性”。

我的建议是做两层结构：集团层定义 5 个通用决策点（立项、方案冻结、开发启动、发布、结项），事业部层在此基础上定义各自的交付物和准出指标。集团层管的是”什么时候必须做决策”，事业部层管的是”用什么证据做决策”。这样既能横向对比，又不会因为业务差异导致流程失效。

另外必须做的一件事是建立阶段数据的横向看板。500 人以上的组织，如果阶段数据只在各个项目组内部流转，你永远不知道整体健康度。需要监控的核心指标是：各阶段通过率、阶段延期率、整改项数量分布、以及门禁否决次数。最后这个指标如果长期为 0，说明门禁形同虚设。

4. 强合规行业（医疗、汽车、航空、金融）

这类行业的阶段划分往往不是由 PMO 决定的，而是由标准或监管要求决定的。此时不要试图减少阶段数量，而要做”映射”。

具体做法是在合规阶段之上叠加一层治理视角：把监管要求的阶段作为”合规基线”，在其上标注出真正的决策点位置。可能监管要求 8 个阶段，但真正的决策点只有 4 个，其余 4 个是文档检查点。这样治理层看决策，项目组看合规，各取所需，不需要为了统一而妥协。

七、不同情况下的取舍

阶段划分的所有争议，本质上是四组取舍。把这四组想清楚，方案自然就定了。我下面给出每一组的两端和我的判断依据。

1. 颗粒度取舍：细划分 vs 粗划分

细划分的好处是风险暴露早、责任清晰；代价是交接损耗高、响应变慢。粗划分反之。我的判断依据是”不确定性来源”：如果主要不确定性来自技术或需求本身，应该细划分（因为早期暴露最值钱）；如果主要不确定性来自外部依赖或市场时机，粗划分更合适（因为频繁评审不改变外部变量，只会延迟交付）。

2. 刚性取舍：硬门禁 vs 软门禁

硬门禁指不满足条件就无法进入下一阶段；软门禁指可以带整改项通过。我的建议是：No-Go 条件必须硬，Go 条件和交付物可以软。也就是说，”不能带着 A 级风险进入下一阶段”这种规则必须绝对刚性；而”文档是否达到 95% 完整度”可以允许有条件通过。

把所有的门禁都做成硬的，会导致所有人都去申请豁免；把所有门禁都做成软的，等于没有门禁。关键是把刚性集中在少数几条上。我通常建议 No-Go 条件不超过 5 条，且三年内不要轻易修改。

3. 自建 vs 采购：工具承载怎么选

阶段和门禁如果不能落到工具里，执行成本会高到让流程自然消亡。这是我在所有项目里反复验证过的一条规律。工具选择的取舍集中在四个维度：

我见过太多”自建到最后没人维护”的案例。一个很现实的判断方法是：如果你的 PMO 团队里没有专职的开发或配置人员，就不要自建。Excel 加邮件的组合在 10 个项目以内可以撑住，超过就要考虑平台化。

4. 速度取舍：减少阶段 vs 减少检查项

当团队抱怨”流程太重”时，有两种减法：减少阶段数量，或者减少每个阶段的检查项。很多团队本能地选择前者，但结果往往更差。

我的经验是：优先减少检查项，谨慎减少阶段数量。原因是每减少一个阶段边界，就少了一个决策点，风险暴露的时间会往后推；而减少检查项只是降低了单次评审的成本，不会影响风险暴露的时间点。我在那个 400 人案例里做的是两手都用，但减少检查项的幅度（约 40%）远大于减少阶段的幅度（约 44% 的阶段数，但决策点只减少了 1 个）。

八、下一步怎么做：一份 14 天落地清单

回到最开始的那个问题：阶段划分到底在切什么？它切的不是时间，是”组织在什么时刻必须做一次不可回避的判断”。时间轴切错了，只是不好看；决策点切错了，项目会在所有人都以为正常的情况下滑向失败。

我这些年最深的三个判断是：第一，阶段数量没有标准答案，只有与不确定性匹配的答案，高不确定性的项目要密不要疏，低不确定性的项目要粗不要细；第二，阶段划分的收益主要来自减少返工，而不是减少会议，任何以”少开会”为目标的流程改造都会失败；第三，门禁如果没有否决过任何东西，它在组织里的心理权重等于零，这一条比流程设计本身更重要。

如果你现在就要动手，我建议按下面这个 14 天清单推进，不要一开始就追求完整。

1. 第 1-2 天：做否决权测试。拉出过去 24 个月所有阶段评审记录，算一下通过率。如果是 100%，先不要设计新流程，先去搞清楚为什么没人敢否决。
2. 第 3-5 天：做决策点访谈。找 5 位经历过失败项目的骨干，问同一个问题：”回头看，哪三个时间点上如果有人认真问一句，结局会不一样？”把所有答案聚类，你会得到 4-7 个真实决策点。
3. 第 6-8 天：用决策点画出初版阶段。每个决策点对应一个门禁，门禁之间就是阶段。这时候不要考虑现有部门结构，也不要考虑现有系统能不能支持。
4. 第 9-10 天：为每个门禁写三组条件。Go 条件 3-5 项、No-Go 条件 3-5 项、Conditional Go 最多 3 个整改项。所有条件必须可判定，验收人必须写具体角色。
5. 第 11-12 天：校验粒度。用”单阶段不超过总工期 25%、不少于 2 周、总数 3-7 个”三条收敛。收敛后统计一下，你大概率从 9 个降到了 5 个左右。
6. 第 13-14 天：找一个真实项目试跑。不要全公司推行，先挑一个正在进行、且还有 3 个以上阶段没走完的项目试。记录两件事：门禁材料准备时间、评审会上”被决策的问题”数量。

试跑之后再决定要不要平台化。我通常的判断线是：如果你们同时进行的项目超过 10 个，或者 PMO 专职人员少于 3 个，就应该考虑把阶段和门禁落到系统里，而不是靠人盯。这时候再去评估工具的数据边界（是否支持私有化部署）、迁移能力（能否从现有工具平滑迁移历史项目）、以及配置灵活度（门禁三组条件能否被真实配置出来），会比较有针对性。

最后提醒一句：阶段划分方案定下来之后，前六个月不要去改它。我见过太多团队在一个季度内改了三次阶段定义，结果是所有历史数据都无法对比，也永远不知道自己到底改对了没有。给它至少六个月，用真实的延期率、返工工时和否决次数来验证，这比任何流程评审都更有说服力。