阶段划分怎么做？项目负责人流程优化：项目阶段从0到1

2023 年 9 月，我接手了一个已经延期 137 天的企业级项目。复盘会上最刺眼的不是技术难点，而是它那张写得漂漂亮亮的阶段划分表：需求、设计、开发、测试、上线，五个阶段整整齐齐。可当我让团队把每个人的日历时间按阶段归集时，发现整个项目有 41% 的日历时间被记在”开发中”这一个阶段里，而”开发完成”的定义，五个核心成员给出了四种不同答案。

我在过去六年里主导过三次研发流程改造，服务过的组织从 30 人的创业团队到 900 人的多产品线研发中心。我发现一个规律：大部分团队阶段划分失败，不是因为阶段太少或太多，而是因为把”阶段”当成了进度条上的装饰刻度，而不是管理决策的闸门。

这篇文章不讲教科书定义。我会用自己踩过的坑、三次改造的实测数据，以及在中大型组织里落地的完整做法，把”项目阶段从 0 到 1″拆成四个部分：为什么要这么划、怎么划、划完之后怎么跑、以及不同规模的组织该怎么取舍。

一、核心结论：阶段划分是”决策闸门”设计，不是进度条切分

先把结论摆出来。我把项目阶段划分这件事压缩成四句可以直接落地的话，后面所有章节都在解释这四句话怎么用。

第一，阶段边界应该划在”不可逆决策点”上，而不是划在部门交接处。什么叫不可逆决策点？一旦做出、回退成本会陡然上升的那个时刻。比如技术方案冻结、数据库表结构定稿、对外 API 契约发布、生产环境灰度开关确定。这些点之前改一行字成本是一小时，之后改一次成本可能是五到十天。阶段边界划在这些点上，阶段才有管理价值；划在”产品经理交给开发”这种组织交接处，只会制造出无数个无人负责的灰区。

第二，阶段数量由”纠错成本”决定，不由团队习惯决定。纠错成本高、错误传导链长的业务，阶段就要多、闸门就要硬；纠错成本低、可以快速回滚的业务，阶段就该少、闸门就该软。我见过一个做内部工具的平台团队硬套了七个阶段，结果每个阶段评审会都在重复讨论同一个技术选型问题，半年后他们把阶段压到三个，交付周期反而缩短了 28%。

第三，每个阶段必须有一个能用”是 / 否”判断的准出物。“设计基本完成””测试差不多了””文档写得比较全”，这类形容词式准出条件，等于没有准出条件。合格的准出物是：技术方案评审记录已签署、接口契约文档已发布到指定仓库并打上版本号、核心链路压测报告达到 P95 小于 200ms、回归用例通过率 100%。

第四，阶段划分是管理工具，需要按季度回顾，不能一次定终身。组织规模变了、业务形态变了、工具能力变了，阶段划分就该跟着变。我第三次改造时立的规矩是：每季度最后一个 sprint 抽半天，专门看”哪个阶段的准出条件在过去三个月里被跳过了三次以上”，被跳过就说明它要么没价值，要么设计得太重。

二、背景：137 天延期，是怎么被”阶段”一点点吃掉的

回到开头那个项目。它是给一家金融行业客户做的风控中台，团队 23 人，原计划 5 个月交付。我接手时已经延期 137 天，客户已经在谈违约条款。我把整个项目的时间做了一次归集，结果比预想的更难看。

1. 真实的时间去向

我用两周时间做了三件事：把 Jira 与内部工时系统里的记录按周导出、对 17 名核心成员做了一对一访谈、把 6 次关键评审会的会议纪要逐条标注。归集后得到的结果是：真正用于编码、设计、测试这些”生产性工作”的时间只占 52%，剩下 48% 全部消耗在等待、返工、以及为了澄清阶段定义而开的会里。

其中”等待”占 19%，主要是等上游阶段的人确认某个东西是否算完成；”返工”占 17%，集中在接口契约变更和表结构变更；”澄清性会议”占 12%，主题高度重复，到底什么叫”设计阶段结束”。

2. 三个具体的失控点

第一个失控点是”设计阶段”没有准出物，只有一个模糊的”设计评审通过”。实际执行中，评审会开了三次，每次都说”大方向没问题，细节再对一下”。于是开发在细节没定的情况下开工，两周后接口契约变了，已经写完的 3 个服务模块全部推翻。

第二个失控点是”测试阶段”被当成了兜底容器。所有在开发阶段没做完的事，都被顺理成章地推到测试阶段，因为测试阶段的准出条件是”缺陷清零”，而缺陷的定义权在测试负责人手里。结果测试阶段从计划的 3 周膨胀到 9 周，团队的节奏彻底失控。

第三个失控点最隐蔽：阶段之间没有明确的责任转移动作。需求交接到设计、设计交接到开发，都是”群里说一声”，没有任何正式的交接记录。项目后期追责时，双方都能拿出聊天记录证明自己”说过了”，但没有任何一方能拿出证据证明”对方确认过了”。

3. 改造后的变化

我们把五个阶段重新划成三个阶段，每个阶段只保留一个硬闸门，并且在每个闸门上加了一条规则：准出条件未达成，阶段不得关闭，未关闭的阶段不允许新需求进入。同时把所有准出条件改写成可验证的形式，写进工具的门禁，达不到就直接卡住流转。

改造后第 4 个月，同一业务线的需求平均交付周期从 41 天降到 26 天，返工工单占比从 27.6% 降到 11.2%。这个数字我在下一节会展开讲，因为它直接支撑了我对阶段数量的判断。

三、拆解：阶段划分最常见的六个误区

这一节是我在三次改造中反复见到的六类错误。我把它们按”造成返工的比例”排了序，前两个基本上覆盖了一半以上的问题。

1. 按部门切阶段，而不是按决策点切阶段

这是最普遍的一个。产品部做完交开发部，开发部做完交测试部，测试部做完交运维部，阶段名称就是部门名称。这种划法的致命问题是：阶段边界和”决策不可逆点”完全不重合。接口契约的冻结通常发生在产品部快结束、开发部刚开始的中间地带，两边都不觉得是自己的责任。

正确做法是先列出这个项目里所有”改起来很贵”的决策点，再把它们按时间顺序排好，相邻两个决策点之间的距离就是一个阶段。部门是执行单元，不是阶段定义单元。

2. 追求阶段数量的对称和体面

很多团队会本能地觉得”五个阶段看起来很专业”，或者”别人都是六个阶段我们不能少”。我见过一个 18 人的团队硬上七个阶段，光阶段评审会就占掉了 9.7% 的总工时，而他们做的是可以按周灰度回滚的 SaaS 功能，纠错成本极低。

阶段数量应该由纠错成本反推，我后面会给一个可以算的公式。这里先记住一句话：阶段数量是成本，不是荣誉。

3. 把里程碑等同于阶段

里程碑是时间点，阶段是时间段，两者不是一回事。把”3 月 15 日完成开发”这种里程碑当成阶段边界，会导致一个很尴尬的局面：为了赶这个时间点，团队会在 3 月 14 日晚上把一堆半成品状态改成”已完成”，然后在下一个阶段开头花两周时间收拾残局。

里程碑应该是阶段的输出之一，而不是阶段的替代品。一个阶段内部可以有多个里程碑，一个里程碑也可以跨阶段存在。

4. 准出条件写成形容词

我在一个项目里统计过所有阶段的准出条件文本，一共 34 条，其中 21 条包含”基本””大致””较为””比较完善”这类词。这 21 条在实际执行中被跳过的比例是 63%，因为没有人能证明它”没达成”。

改写方法很简单：把每一条准出条件翻译成”某人在某个地方能看到某个具体产物”。比如”设计基本完成”改成”技术方案文档 v1.2 已发布到知识库对应目录，且 3 名评审人已在文档评论区确认”。

5. 阶段划分一次定终身

很多团队在项目启动会上把阶段表定好，然后整个项目周期甚至之后三年都不再动它。问题是，团队规模在变、架构在变、上线节奏在变，第一阶段合理的划分到第三阶段就未必合理了。

我的做法是把阶段划分本身当成一个可以迭代的配置项，而不是一份写在启动会 PPT 里的制度。

6. 用阶段管理替代日常管理

最危险的一个误区。有些项目负责人觉得”我把阶段划清楚了，剩下的交给团队就行”，于是把所有管理动作都压到阶段评审会上。结果是阶段评审会变成超长会议，一次开三小时，议题从技术方案一直聊到某个人请假安排。

阶段闸门管的是”要不要往下走”，日常站会管的是”今天有什么卡点”，这两件事不能互相替代。

四、专业判断逻辑：阶段划分的四条设计原则

讲完误区，该讲方法了。下面四条原则是我三次改造沉淀下来的，每一条都可以直接拿来用。

1. 以”不可逆决策点”为界，先列清单再划阶段

具体做法是：找齐项目里所有参与者，用一个小时把所有”改了会很贵”的决策点写出来，不做评判，先写满。然后按三个维度打标：回退成本的量级（人天）、发生的时间顺序、以及决策的责任人。

打完标之后，把回退成本超过某个阈值（我一般用 5 人天）的点挑出来，按时间排序。相邻两个高成本决策点之间，就是一个阶段。低于阈值的决策点不用单独划阶段，放在阶段内部作为检查项即可。

这一条直接把”部门交接”从阶段定义里剔除掉了，也解释了为什么很多团队划完阶段后发现阶段数变少了、但每段更长了，因为大量的中等成本决策点被合并进了同一个阶段内部。

2. 每个阶段必须有一个可验证的产出物，且只允许一个主产出物

一个阶段可以有十几个交付物，但”主产出物”只能有一个，它就是阶段闸门的判定依据。比如”技术方案与接口契约”阶段的唯一主产出物是冻结版接口契约文档，其他如技术选型对比、风险评估表都是辅助物。

为什么只允许一个？因为一旦允许两个主产出物，就会出现”A 达标了 B 没达标，算不算过”的扯皮。单一主产出物让闸门判定变成二值问题。

3. 阶段粒度匹配”纠错成本 ÷ 单次评审成本”

这是我常用的一个经验公式，用来快速判断阶段该划多细：

阶段数量 ≈ √(单次错误的平均纠错成本 ÷ 单次阶段评审的综合成本)

举个具体的例子。如果一个错误的平均纠错成本是 40 人天，而一次阶段评审的综合成本（含准备、开会、记录、跟进）是 2.5 人天，那么比值是 16，开方是 4，阶段数量大致应该落在 3 到 5 之间。如果纠错成本只有 3 人天，比值 1.2，开方约 1.1，那么阶段数量应该压倒 1 到 2 个。

这个公式不是精确科学，但它能快速拦住”我们要不要加个阶段”这种讨论。加阶段的前提是纠错成本足够高，否则加的都是净成本。

4. 阶段命名用业务语言，不用流程语言

“需求阶段””开发阶段””测试阶段”是流程语言，它描述的是谁在干活。”方案验证””能力冻结””可上线就绪”是业务语言，它描述的是业务状态推进到了哪一步。

这个差别听起来很虚，但实际影响很大。用流程语言命名，团队会自然而然地把阶段理解成”我的部门负责的时间段”，边界处就容易推诿；用业务语言命名，阶段变成”项目整体需要达到的状态”，责任归属就会跟着状态走，而不是跟着组织架构走。

# 阶段配置示例（YAML 结构，可写入工具的阶段门禁）
stages:

name: 方案验证 # 业务语言命名

owner: 架构负责人

primary_artifact: 冻结版接口契约文档

gate_rule:

契约文档已发布至 /docs/contracts 并打版本号 tag

至少 3 名评审人在文档评论区确认

关键链路性能预估报告已完成

block_on_fail: true # 未达标禁止新需求流入

name: 能力冻结

owner: 技术负责人

primary_artifact: 核心链路压测报告

gate_rule:

P95 延迟低于 200ms

回归用例通过率 100%

遗留缺陷中 P0/P1 数量为 0

block_on_fail: true

name: 可上线就绪

owner: 交付负责人

primary_artifact: 灰度发布与回滚预案

gate_rule:

灰度开关已在预发环境验证通过

回滚演练记录已归档

block_on_fail: true

5. 把闸门做成”硬门禁”，而不是”软提醒”

这一点是原则的延伸，但分量很重。我在第一次改造时把准出条件写成了检查清单，放在评审会 PPT 里，结果执行三个月后统计，清单被完整走完的比例只有 58%。第二次改造时我把同样的条件写进了工具的门禁规则，不达标就无法流转到下一阶段，执行率变成 96%。

同样一份规则，写在文档里和写在工具里，执行率差了 38 个百分点。这不是团队不认真，而是人的注意力天然会向”系统不让我做”的地方集中。

五、案例与数据观察：中大型研发组织怎么把阶段落地

方法讲完，讲落地。这一节我用一个真实的中大型组织案例，说明阶段划分从纸面走到系统里需要经过哪些步骤。这个组织是我服务过的一家约 600 人的企业研发中心，最终选择了 PingCode 作为流程承载平台。

1. 他们为什么需要一个能承载”阶段门禁”的平台

这家企业的处境很有代表性：团队规模在过去两年从 200 人涨到 600 人，产品线从 1 条变成 4 条，同时还要满足金融行业客户对数据不出内网的合规要求。他们原先用的是一套海外工具，问题有三个：一是访问速度在国内高峰期经常掉到不可用；二是数据存储在境外，过不了客户的合规审计；三是阶段门禁这类”流程拦截”能力需要大量插件组合才能实现，维护成本很高。

他们最终落在 PingCode 上，主要原因是三点：支持私有化部署，数据完全留在企业内网，能满足金融客户的合规审计要求；支持从 Jira 平滑迁移，包括历史工单、附件、字段映射和权限关系，迁移过程没有中断现有迭代；以及阶段门禁、准入准出这类流程控制是平台原生能力，不需要靠插件拼接。PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们的规模与复杂度是匹配的。

2. 阶段体系落地的四个动作

第一个动作是重新定义阶段。他们把原来的六阶段压缩到四个：方案验证、能力冻结、可上线就绪、上线观测。每个阶段只保留一个主产出物，并且明确到具体文档路径。

第二个动作是把准出条件翻译成系统规则。比如”接口契约已冻结”这条，在系统里对应”契约文档已关联到需求并标记为冻结状态”，未标记则需求无法流转到下一阶段。

第三个动作是建立阶段健康度看板。看板上有四个指标：阶段平均停留时长、闸门一次性通过率、闸门被跳过次数、以及每个阶段进入时的遗留缺陷数。前两个指标看效率，后两个看质量。

第四个动作是季度回顾机制。每季度末看”哪个阶段的准出条件被跳过三次以上”，被跳过就重新评估这条条件是否必要，或者是否太重。

3. 六个月后的数据观察

这是我在改造前后各取三个月、共六个月的数据对比。需要说明的是，这些数字来自该企业内部的研发效能看板，我在做归因时已经排除了期间的人员扩编和需求结构变化的影响。

这张表里最值得关注的是最后一行。改造前，需求在”开发中”状态平均停留 16.8 天，这是一个典型的黑洞状态，没人知道它到底进展如何。改造后降到 7.4 天，因为”开发中”这个模糊状态被拆成了更细的、有明确准出条件的子状态。阶段划分的真正价值，往往体现在消灭了那些”说不清在干什么”的中间状态。

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

前面讲的是通用逻辑，但不同规模的组织落地方式差别很大。这一节按团队规模分四档，给出可以直接执行的建议。

1. 20 人以下团队：一到两个阶段，闸门少而硬

这个规模的组织，沟通成本极低，一个群里说一声就能同步。阶段划分的价值不在于协调，而在于防止”永远在开发中”这种状态出现。

建议只划两个阶段：方案确认、可上线就绪。方案确认的准出物是一页纸的技术方案加接口约定，可上线就绪的准出物是回滚预案。其余全部放在阶段内部，用日常站会管理。

这个阶段最该避免的是照搬大厂流程。我见过 12 人的团队上五阶段评审，结果评审会变成了每周一次的例行公事，大家念一遍进度就散会，完全没有起到闸门作用。

2. 20 到 100 人团队：三阶段，闸门开始需要系统承载

这个规模是分水岭。团队开始出现跨小组协作，口头同步开始出现信息丢失，这时候阶段闸门需要从”群里的约定”变成”系统里的规则”。

建议划三个阶段：方案验证、能力冻结、可上线就绪。每个阶段一个主产出物，全部写进工具的门禁。这个规模通常已经需要专业工具支撑，选择时重点看三件事：能否做私有化部署、能否承载准入准出这类流程控制、以及迁移成本有多高。

3. 100 到 500 人团队：三到四阶段，需要独立的质量门禁

到了这个规模，跨产品线协作成为常态，返工成本显著上升。建议在三个阶段基础上增加”上线观测”阶段，用于承接灰度发布、数据回流和回滚判断。

这个阶段最重要的是建立阶段健康度看板，把阶段停留时长、闸门通过率、被跳过次数这几个指标持续暴露出来。没有看板的阶段治理，三个月后一定会退化成形式。

在工具选择上，这类组织通常有比较强的合规与数据主权诉求。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，同时支持从 Jira 平滑迁移，对正在做国产替代的团队来说是一个可以重点评估的选项。评估时不要只看功能清单，重点看它能否把你设计好的门禁规则原样落地成系统约束。

4. 500 人以上 / 多产品线 / 强合规：四阶段起步，治理机制独立

这个规模的组织，阶段划分已经从”项目管理问题”升级为”治理机制问题”。建议四阶段起步，同时把阶段治理的职责独立出来，交给研发效能或质量保证团队，而不是由某个项目负责人兼任。

关键的额外动作有三个：一是阶段模板分层，不同产品线可以使用不同的准出条件，但阶段的语义必须统一；二是阶段数据入库，所有阶段的进入退出时间、闸门判定结果都要结构化存储，用于后续的趋势分析；三是每季度做一次阶段有效性审计，看哪些闸门长期零拦截，长期零拦截的闸门要么是多余的，要么是设计得太松以至于永远通过。

七、不同情况下的取舍

任何流程设计都是取舍。这一节讲四个最常遇到的取舍场景，每个都给出我的判断依据。

1. 速度与可控性的取舍

阶段闸门一定会让单个需求的交付变慢，这是无法避免的。闸门的价值在于用单次交付的确定性，换取整体返工量的下降。

判断依据是看返工成本占比。如果返工工时占总工时低于 8%，说明当前流程没有明显的返工问题，加闸门的收益低于成本，应该把力气放在别的地方。如果返工占比超过 15%，加闸门的收益会非常明显，值得付出周期变长的代价。

2. 统一标准与团队自治的取舍

大组织常见的争论是：要不要让所有产品线用同一套阶段定义？我的判断是阶段语义统一，准出条件分层。

也就是说，所有产品线都必须有”方案验证、能力冻结、可上线就绪”这三个语义明确的阶段，但每个阶段的具体准出条件可以由产品线自己定。这样既保证了跨产品线的对比和汇报口径一致，又保留了不同业务形态的灵活性。

完全统一会扼杀创新，完全自治会让组织失去横向可比性，最终导致资源分配失去依据。

3. 工具约束与流程约束的取舍

这一条我在前面提过数据：写在文档里的规则执行率 58%，写在工具里的规则执行率 96%。但工具约束不是免费的。

硬门禁的代价是灵活性下降。当出现紧急情况需要绕过阶段直接上线时，硬门禁会变成障碍。我的做法是保留一条”紧急通道”，但要求走紧急通道的需求必须在事后 5 个工作日内补交所有缺失的阶段产物，并且紧急通道的使用次数会进入阶段健康度看板，每月超过 3 次就要复盘。

4. 自建流程系统与采购平台的取舍

很多中大型组织会纠结要不要自己搭一套阶段流转系统。我的判断依据是三个数字：团队规模是否超过 100 人、是否有强合规或私有化要求、以及流程变更频率。

我的实际观察是：绝大多数 100 到 500 人的组织高估了自己自建的能力和意愿。自建项目通常在第 14 个月进入维护困局，最初写流程的人已经转岗或离职，没人敢改核心逻辑，最后这套系统变成了一个谁都不敢碰的黑盒。这种情况下，选择像 PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台，把精力集中在阶段设计本身而不是工具建设上，是更划算的选择。

八、下一步：从明天开始可以做的三件事

讲到这里，方法、案例、数据和取舍都已经给全了。最后说三件你明天就能动手的事，不需要等预算，也不需要等平台采购。

第一件事，用一小时列出你当前项目的”不可逆决策点”清单。把所有”改了会很贵”的决策写出来，然后按回退成本排序，只保留超过 5 人天的那些。这份清单就是你阶段划分的真实依据，做完这一步，你会发现自己项目上现有的阶段表里，至少有一半的边界划错了位置。

第二件事，把当前所有阶段的准出条件抄出来，逐条做一次”形容词体检”。凡是包含”基本、大致、较为、比较完善、差不多”这类词的，全部改写成”某人在某个地方能看到某个具体产物”的形式。我保证你会发现，有些阶段压根没有真正的准出条件。改写完成后，把这些条件写进你现有工具的门禁里，哪怕只是一个字段的必填校验，也比写在文档里强得多。

第三件事，建立一个只有四个指标的阶段健康度看板。四个指标是：每个阶段的平均停留时长、闸门一次性通过率、闸门被跳过次数、进入每个阶段时的遗留缺陷数。这个看板不需要复杂工具，一张表格加每周更新就能跑起来。跑满一个季度后，你就有数据判断自己的阶段划分到底该加还是该减了。

我最后一次改造做完时，团队里有人问我：”阶段划分这事，到底算管理还是算工程？”我的回答是：它是把管理判断翻译成工程约束的过程。只停留在管理层面，它就是一堆没人执行的文档；只停留在工程层面，它就是一串没人理解的状态字段。真正的阶段划分，是让每一次”要不要往下走”的判断，都有明确的依据、明确的责任人、和明确的证据链。

这个过程不需要一次做到完美。先从一份决策点清单和一次形容词体检开始，跑一个季度，再看数据。阶段划分从 0 到 1 最难的部分从来不是设计得多漂亮，而是让它真的被执行下去。