阶段划分怎么做？研发团队落地方案：项目阶段从0到1

去年冬天，我在一家做工业软件的客户那里待了三天。他们研发负责人拿出一份 27 页的《研发阶段划分规范》，问我一个很具体的问题：为什么这份规范发布两年，项目延期率反而从 31% 涨到了 44%？我翻了他们的项目数据，发现问题不在”划分得不够细”，恰恰相反，他们把阶段划得太细，细到每个阶段都变成了一个独立的汇报单元，没人再为端到端的交付负责。这是我第一次非常清晰地意识到，阶段划分这件事，绝大多数团队做反了方向。

这篇文章不讲教科书上的瀑布模型和敏捷宣言，只讲我在 40 多个研发团队现场看到的真实情况、踩过的坑，以及从 0 到 1 落地阶段划分时真正起作用的判断逻辑。

一、核心结论：阶段划分不是切流程，而是设计决策点

在展开之前，我先把结论摆出来。如果你时间有限，只看这一段也够用。

1. 阶段划分的对象是”不可逆决策”，不是”工作内容”

大部分人理解的阶段划分，是把一个项目从立项到上线的工作切成几块，然后给每块起个名字：需求阶段、设计阶段、开发阶段、测试阶段、上线阶段。这套划分方式的问题在于，它切的是”谁在干活”，而不是”什么时候必须做决定、做了就不能轻易反悔”。

真正有效的阶段划分，切的是决策点。每个阶段的边界，应该落在一个”如果不做决定就回不了头”的位置上。比如技术选型一旦落地上线，更换成本是 20 人月；比如数据模型一旦写入生产库，迁移成本是三个月的回填。这些位置才是阶段的天然分界线。至于”需求分析”和”需求设计”之间要不要设一个阶段，取决于它们之间有没有一个不可逆的决策，而不是取决于它们的名字听起来是不是两件事。

2. 阶段数量与团队规模不成正比，甚至要成反比

这是我踩过的最大的坑。2019 年我帮一个 600 人的研发中心梳理流程，当时领导层的直觉是”团队这么大，流程要细一点”，我们一度设计了 9 个阶段、23 个交付物、14 个评审点。结果半年后复盘，14 个评审点里真正产生过”否决”结论的只有 3 个，其余 11 个全部变成了盖章走过场。

反过来看，同一个时期我在一个 18 人的创业团队看到的是 3 个阶段、2 个决策点，交付效率反而更高。原因不复杂：阶段越多，跨阶段的协调成本增长是超线性的。每增加一个阶段，就多一次交接、多一次信息损耗、多一次”这不归我管”的推诿空间。小团队靠口头同步就能覆盖的损耗，大团队需要开会、写文档、拉群，成本会被放大几十倍。

3. 一个自检标准：能不能说清”这个阶段结束时，谁必须回答什么问题”

我现在判断一个团队的阶段划分是否合格，只问一个问题：请你说出每个阶段结束时，必须被回答的那个问题是什么，以及由谁回答。

如果答得出来，比如”技术方案阶段结束时，架构负责人必须回答：这个方案在峰值 5000 QPS 下的降级策略是什么”，那这个阶段划分是有效的。如果答不出来，只能说”这个阶段结束要输出需求文档”，那基本可以判断，这个阶段划了等于没划，因为它没有约束任何决策。

二、真实场景：阶段划分为什么在大多数团队里会失效

我见过太多”规范很漂亮、执行很糟糕”的案例。把它们的共同点抽出来，大致是三件事。

1. 阶段划分是在会议室里想出来的，不是在项目现场长出来的

2022 年我参与过一个金融科技团队的流程改造。他们的规范是三位流程经理花了两个月写出来的，参考了行业标准、咨询公司模板和竞品拆解。规范发布当天，我随机问了五个一线开发：”你们项目现在在哪个阶段？”五个人给了四个不同答案。

这不是员工不配合，而是阶段定义和他们的日常感受之间没有映射关系。规范说的是”详细设计阶段”，开发脑子里的划分是”接口还没定 / 接口定了但没联调 / 联调通了”。后者才是他们真实的工作状态切换点。任何不能映射到一线真实状态切换点的阶段划分，最终都会被架空。

2. 阶段划分没有和”钱”和”人”挂钩，就没有约束力

阶段之所以能约束行为，是因为跨阶段意味着资源投入的升级。立项阶段投入 3 个产品经理，开发阶段投入 30 个工程师，这两个阶段的资源量级差 10 倍。如果组织在阶段切换时不做资源重新审批，那阶段就只是一串标签。

我观察到的有效做法是：阶段切换必须伴随资源承诺的重新确认。上一个阶段批的是 5 个人，下一个阶段要 25 个人，这 20 个人的增量谁批、什么时候批、批了之后如果失败谁负责，把这几个问题解决掉，阶段划分自动就有了牙齿。

3. 工具不承载阶段，阶段就只活在文档里

这是最容易被低估的一条。我在一个 200 人的团队做过统计：他们把阶段划分写进 Word 规范，但日常管理用的是任务看板，看板上只有”待办 / 进行中 / 已完成”三列。结果就是，规范里的 6 个阶段在实际数据里完全不存在，你根本无法从系统里导出”当前处于技术评审阶段的项目有哪些”。

阶段划分能不能落地，很大程度上取决于工具能不能把阶段作为一等公民来建模，能不能按阶段过滤、能不能设阶段门禁、能不能在阶段切换时触发字段校验。这一点我在后面第五部分会用具体平台的实现方式展开讲。

三、五个最常见的阶段划分误区

这一节我按危害程度从高到低排。每一条都能在我的项目记录里找到至少三个对应的失败案例。

1. 误区一：按职能划分阶段

“需求阶段归产品、开发阶段归研发、测试阶段归 QA、上线阶段归运维”，这套划分方式看起来职责清晰，实际上制造了一个巨大的责任真空带：没有任何一个人对整个交付负责。

我见过一个典型症状：需求阶段结束时，产品说”需求文档交付了，我的活干完了”；开发阶段延期，开发说”需求改了三版，是上游的问题”；测试阶段发现严重缺陷，测试说”开发提测质量不达标”。三个部门各自的工作都没问题，项目整体延期三个月。

正确的做法是，每个阶段的负责人应该是”对这个阶段的业务结果负责的人”，而不是”对这个阶段的工作职能负责的人”。技术方案阶段应该由架构负责人对”方案能否支撑未来 12 个月的业务量”负责，而不是由架构师对”方案文档写完了”负责。

2. 误区二：阶段数量越多越专业

我见过最夸张的一个方案有 12 个阶段：预研、立项、需求调研、需求分析、需求评审、方案设计、技术评审、开发、联调、测试、验收、上线。第 4 个和第 5 个阶段之间，实际差别只是”文档写完”和”文档被评审过”，中间隔了不到 48 小时。

阶段设计的核心约束不是”要把事情说清楚”，而是“要让每个阶段都有独立的决策价值”。如果两个阶段之间的决策是同质的，就应该合并。判断方法很简单：把这两个阶段的退出准则写出来，如果内容重合度超过 60%，就合并它们。

3. 误区三：把里程碑当阶段

里程碑是时间点，阶段是时间区间。这个区别听起来简单，但混用极其常见。我在一个团队的规范里看到”阶段：V1.0 发布”，V1.0 发布是个瞬间事件，它不是一个区间，团队在这个”阶段”里应该做什么、什么时候算结束，完全无法回答。

里程碑应该作为阶段的退出准则出现，而不是阶段本身。正确的写法是：阶段”首个可用版本”的退出准则是”V1.0 发布包通过灰度验证，核心链路错误率低于 0.1%”，里程碑 V1.0 是这个准则的验证载体。

4. 误区四：阶段划分与交付物脱钩

很多团队的阶段定义里只写”完成需求分析”，不写”输出什么”。结果就是每个项目的”完成需求分析”标准都不一样，有的输出 PRD，有的输出原型，有的只开了一个会。

交付物不是文档，是”可以被下游消费的输入”。需求阶段的交付物应该是”开发可以直接据此拆解技术任务的需求描述”，而不是”一份需求文档”。这个差别决定了交付物是形式主义的产物还是真实的工程输入。

下面是我在一个团队推行过的阶段定义结构，用 YAML 表达，可以直接映射到项目管理工具的自定义字段：

阶段定义:
名称: 技术方案

进入准则:

需求描述已通过评审, 且已知的变更窗口不超过 2 个

已识别出至少 3 个技术风险点

退出准则:

方案通过架构评审, 评审计分 >= 8/10

关键接口的契约文档已完成并可被前端消费

峰值场景下的降级策略已明确

交付物:

架构决策记录 (ADR), 含备选方案对比

接口契约文档 (OpenAPI 或等价格式)

容量与成本估算表

负责人: 架构负责人

必须回答的问题: 该方案能否在不重构的前提下支撑未来 12 个月的业务增长

预计工期: 5-8 人天

5. 误区五：阶段划分一次定终身

阶段划分是随组织演化的。我见过一个团队从 15 人长到 180 人，阶段划分还是三年前那三个。结果就是新来的几十号人无法理解”我们到底在哪个阶段”，因为原来的定义是为 15 人的口头同步场景设计的。

我的建议是做一次年度校准：每年 Q4 复盘一次阶段划分，只问三个问题，过去一年有哪个阶段从未产生过否决结论？有哪个阶段的退出准则被绕过超过三次？有哪个新出现的业务场景找不到对应的阶段？三个问题里有两个命中，就该调整了。

四、专业判断逻辑：怎么判断一套阶段划分是否合格

前面讲了不该怎么做，这一节讲应该怎么做。我把它拆成四个可操作的判断维度。

1. 维度一：阶段边界是否落在不可逆成本上

我给每个阶段边界做一次”反悔成本评估”。假设这个阶段的结论被推翻，需要付出多少代价？如果代价低于 3 人天，这个边界基本不值得设为阶段；如果代价高于 30 人天，这个边界必须设阶段，而且必须有正式的评审。

举个例子。数据库表结构设计，反悔成本取决于数据量：日增 1 万条的表，改结构成本是 2 人天；日增 500 万条的表，改结构成本是 6 周加一次数据回填。所以同一个”数据库设计”动作，在不同系统里的阶段权重完全不同，不能照搬别人的阶段划分。

2. 维度二：阶段数量是否落在团队协调能力区间内

我根据这些年观察总结了一个经验区间（示意基准，非统计结论）：

注意这张表里，阶段数并没有随着规模一直增长。500 人以上反而建议控制在上限附近而不是无限增加，因为此时协调成本已经很高，再增加阶段会让流程本身成为最大的瓶颈。

3. 维度三：每个阶段是否有可验证的退出准则

退出准则的写法有个小技巧：尽量用可测量的判据，避免用”完成””通过””确认”这类无法证伪的词。

对比一下：”技术方案完成” vs “技术方案通过架构评审，评审计分不低于 8/10，且已识别的 P0 级技术风险全部有对应缓解方案”。后者才能被验证，前者只能被争论。

我一般建议每个阶段的退出准则控制在 3-5 条，超过 5 条说明这个阶段该拆了，少于 3 条说明这个阶段的约束力不够。

4. 维度四：阶段模型是否能在工具里被强制执行

这是最实际的一条。你的阶段划分再好，如果不能被系统强制执行，最终都会退化为文档装饰。所谓”强制执行”，至少包含四个能力：

1. 阶段作为独立字段存在，而不是状态标签的别名，可以独立筛选、统计、做燃尽分析。
2. 阶段切换有门禁，比如从开发进入提测，必须填写测试环境地址和提测清单，缺失就无法流转。
3. 交付物与阶段绑定，交付物未上传时，阶段无法推进，或者推进需要特定角色审批放行。
4. 阶段历史可追溯，能查出每个需求在每个阶段停留了多久、被退回几次。

以 PingCode 为例，它在这个层面提供了比较完整的支撑：工作项类型可以自定义，状态机可以按阶段配置流转规则，字段级权限可以控制”谁能推动阶段切换”，阶段门禁可以绑定交付物和审批流。对于 100 人以上的中大型团队，这类能力的价值在于把阶段划分从”倡导性规范”变成”系统性约束”。它同时支持私有化部署，对数据合规要求高的行业（比如金融、军工、能源）比较友好。

另外一个实际问题是迁移成本。很多中大型团队原来的研发数据沉淀在 Jira 里，阶段划分改造最大的阻力之一就是”历史数据怎么办”。PingCode 提供 Jira 平滑迁移能力，工作项、状态、字段、附件、评论的映射可以在迁移过程中完成，不需要团队重建历史上下文，这一点在实际落地时省掉的时间通常以周计。

五、落地案例：一个 300 人研发团队从 0 到 1 的阶段划分改造

这一节讲一个完整案例。这是一个做企业级 SaaS 的团队，研发 300 人左右，分 6 条产品线，改造前的问题和大多数中大型团队一样。

1. 改造前的状态

他们原有的阶段划分是 7 个阶段，定义在一份 19 页的规范文档里。我进去做的第一件事是拉数据：过去 6 个月，有多少项目真正走完了全部 7 个阶段的评审？答案是 12 个项目里只有 2 个，其余 10 个都有不同程度的跳过。

更严重的是，我抽样了 30 个需求，问开发”这个需求现在在哪个阶段”，有 19 个的回答和系统里记录的状态不一致。系统和认知的偏离率高达 63%，这意味着阶段划分已经完全失去了管理价值。

2. 改造的核心动作

我们没有推翻重来，而是做了三件事。

第一件，把 7 个阶段压缩到 4 个。合并的判据是退出准则重合度：原来的”需求调研”和”需求分析”重合度 72%，合并；”详细设计”和”技术评审”重合度 68%，合并。压缩后保留了四个阶段：机会评估、方案定型、交付构建、上线验证。

第二件，给每个阶段绑定唯一的问题和唯一的人。机会评估阶段必须回答”这个需求值不值得投入”，由产品线负责人回答；方案定型必须回答”技术方案能否支撑 12 个月增长”，由架构负责人回答；交付构建必须回答”是否达到可上线的质量标准”，由 QA 负责人回答；上线验证必须回答”真实流量的表现是否符合预期”，由 SRE 负责人回答。

第三件，把阶段模型搬进工具并设置门禁。他们在 PingCode 里重新建模了工作项类型和状态机，四个阶段对应四组状态，每组的流转都设了必填字段和审批角色。比如从方案定型进入交付构建，必须填写技术方案链接、接口契约、容量估算三项，缺一项无法流转。

3. 改造后的数据

改造上线 6 个月后，我拿到了这组对比数据。需要说明的是，这些是单个团队的实测值，不能直接外推到其他团队，但趋势值得参考。

我想特别指出交付周期的变化。压缩阶段和减少评审，直觉上应该让周期变短，但真正的贡献来自”等待时间”的消除。我拆解过他们的数据：改造前 48.6 天的交付周期里，纯工作时间只有 19 天，其余 29.6 天都花在等待评审窗口、等待环境、等待上下游响应上。改造后纯工作时间基本没变，等待时间从 29.6 天压缩到 12.2 天。

4. 这个案例里最容易忽略的一个细节

改造过程中最大的阻力不是来自中层，而是来自一线工程师。他们的原话是：”以前我只要把代码写完就行，现在要我填技术方案链接、接口契约、容量估算，这不是增加我的工作量吗？”

我们的应对方式是，把这三项内容从”额外填写”变成”本来就该做的工作的显性化”。技术方案本来就要想，只是以前想在心里；接口契约本来就要对齐，只是以前在群里说。这样一来，新增的填写成本被感知为”把已有工作记录下来”，而不是”额外的官僚工作”。这个认知转换花了我们大概三周，通过三场工作坊和一批模板完成。

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

阶段划分没有唯一正确答案。我按团队规模和成熟度分几种情况给建议。

1. 20 人以下团队：不要做正式阶段划分

这个规模下，我建议只保留两个决策点：要不要做（价值判断），以及能不能上线（质量判断）。中间过程全部用迭代节奏管理，不要引入阶段概念。

原因很直接：20 人以下的团队，沟通成本接近于零，阶段划分带来的约束收益小于它的形式成本。你花在维护阶段规范上的时间，不如花在多写两个测试用例上。如果一定要有个东西，就用一个简单的检查清单，放在需求卡片的模板里。

2. 20-100 人团队：3 个阶段，书面化但轻量

这个规模的转折点在于，团队开始有人记不清上周决定了什么。这时候需要书面化，但不要重。3 个阶段的建议是：立项、构建、上线。每个阶段只需要一个交付物和一份退出准则清单，不超过一页纸。

工具上，用任何能自定义状态的项目管理工具就够。关键是保证阶段字段能被筛选出来，让管理者看到”现在有多少需求卡在构建阶段超过 15 天”。

3. 100-500 人团队：4-5 个阶段，必须上工具门禁

这是阶段划分真正产生价值的区间。这个规模的团队，跨部门协作成为主要成本，阶段划分的作用是提供一套共同的”坐标系”，让不同部门能对齐彼此的位置。

我的建议是四个阶段，每个阶段必须有：唯一的业务结果负责人、可验证的退出准则（3-5 条）、强制的工具门禁。同时建议做一件事：把阶段停留时长做成一个可观测指标，按月 review 每个阶段的 P90 停留时长。任何阶段的 P90 超过目标值 50%，就说明这个阶段出了问题，要么是准则定得不合理，要么是资源投入不够。

这个规模也通常是开始考虑私有化部署和国产化替代的时间点。以 PingCode 为例，它对标的就是 100 人以上组织，支持私有化部署、支持从 Jira 平滑迁移，在需要数据不出内网或者需要信创合规的场景下，是一个值得纳入选型清单的选项。选型的时候我建议重点验证三件事：阶段字段能不能被自定义和强制校验、阶段停留时长能不能直接出报表、迁移过程中历史工作项和状态能不能无损映射。

4. 500-2000 人团队：区分通用阶段和产品线专属阶段

这个规模的典型问题是”一刀切”。硬件产品线的开发周期是 18 个月，软件产品线是 6 周，用同一套阶段划分必然有一方难受。

我的建议是分层：定义 3-4 个组织级通用阶段作为汇报和预算的基准，允许每条产品线在通用阶段内部定义自己的子阶段。通用阶段保证跨部门对齐，子阶段保证产品线的执行效率。这个分层结构在工具上通常通过”工作项类型 + 状态组”来实现。

5. 2000 人以上：阶段必须与预算和组织汇报线对齐

到这个规模，阶段划分已经不只是研发管理问题，而是公司治理问题。阶段必须能对应到预算科目、季度目标、以及汇报线上。我见过的最有效的做法是，每个阶段切换对应一次预算释放，上一阶段的预算用完，下一阶段的预算需要重新申请和审批。这样阶段划分就不再是软约束，而是硬约束。

七、不同情况下的取舍

任何阶段划分方案都是在几组矛盾里做取舍。我把最常见的四组列出来，并给出我的取舍倾向。

1. 取舍一：阶段数量 vs 管理开销

这是一个近乎线性的交换。每增加一个阶段，大约增加 1.5-3 人天的月度管理开销（评审、文档、协调）。我的取舍倾向是：在能覆盖所有高不可逆成本决策的前提下，取最少的阶段数。宁可少一个阶段让某个中等风险裸奔，也不要多一个阶段让所有项目都在等评审。

具体操作上，我会先按不可逆成本从高到低排序所有候选决策点，然后从上往下取，直到覆盖 80% 的总不可逆成本，剩下的 20% 用轻量的检查清单处理，不进阶段。

2. 取舍二：标准化 vs 灵活性

标准化带来跨团队可比性，灵活性带来执行效率。我的倾向是在组织级阶段上强标准化，在执行级子阶段上给足灵活性。也就是”四个阶段的命名、退出准则、审批角色全公司统一”，但”每个阶段内部怎么拆子任务、用多久、谁来做”由团队自决。

这个取舍的关键是要明确哪些是”不可协商项”。我一般会把退出准则列为不可协商项，把交付物格式列为可协商项。

3. 取舍三：工具约束 vs 文化约束

工具约束见效快但容易催生形式主义，文化约束见效慢但更持久。我的经验是先工具后文化：前 6 个月用工具门禁强制建立习惯，6 个月后逐步放松强校验，靠团队自觉。

具体来说，改造初期把必填字段设得严一些，等团队养成了习惯，可以把部分字段从”强制”改为”建议”。我跟踪过的一个团队，改造 9 个月后把 40% 的强制校验改为建议，而遵守率仍然保持在 85% 以上，说明文化已经形成。

4. 取舍四：一次到位 vs 渐进演进

我的取舍倾向很明确：永远渐进，不要一次到位。我见过的所有”大爆炸式流程改造”案例，成功率都低于 30%，失败原因高度一致，变革幅度超过了组织吸收能力。

渐进的做法是分三步走：第一步只做阶段数量和阶段名称的调整，不改任何交付物和评审要求；第二步增加退出准则和工具门禁；第三步才动审批权限和资源绑定。每一步之间间隔至少一个季度，给团队适应时间。

这也是我在前面那个 300 人案例里采用的方式。我们用了 9 个月完成三步，中间没有出现明显的执行反弹。

八、总结一下，以及下一步你可以做什么

回到文章开头那个问题：为什么一份 27 页、看起来很专业的阶段划分规范，会让延期率从 31% 涨到 44%？答案现在已经清楚了，那份规范优化的是”划分的完整性”，而不是”决策的有效性”。它把每个职能动作都切成了独立阶段，结果是每个人工整地完成了自己那一格，但没有人对整条链路负责。

我想强调三个在这篇文章里反复出现的判断，它们是我这些年最核心的经验：

第一，阶段划分的单位是决策，不是工作。你切分的依据应该是”这里如果不做决定就回不了头”，而不是”这里换了一批人干活”。用这个标准重新审视你的阶段划分，通常会砍掉一半。

第二，阶段的约束力来自资源和系统的绑定，而不是文档的权威性。如果跨阶段不涉及资源重新审批，如果工具里查不到”当前在方案定型阶段的需求有几个”，那你的阶段划分就只是装饰。

第三，阶段数量应该随团队规模先增后减。小团队不需要阶段，中等团队需要 3-4 个，大团队反而要把数量控制在 5-6 个上限，因为每增加一个阶段的协调成本在 300 人以上团队会被放大到惊人的程度。

下一步你可以做什么？我建议按这个顺序来，投入不大但收益明确：

1. 做一次”阶段认知一致性抽查”，随机找 10 个一线工程师，问他们各自负责的需求现在在哪个阶段，然后把答案和系统里的记录比对。偏离率超过 40%，就说明你现在的阶段划分已经失效了。
2. 做一次”不可逆成本排序”，把你项目里所有需要决策的节点列出来，评估每个节点的反悔成本，按从高到低排序，找到覆盖 80% 成本的前几个点，那些就是你真正需要的阶段边界。
3. 检查退出准则的可验证性，把你现有的退出准则逐条读一遍，凡是出现”完成””通过””确认”这类无法证伪的词的，全部改写成可测量的判据。
4. 验证工具承载能力，如果你的项目管理工具无法按阶段筛选、无法设置阶段门禁、无法输出阶段停留时长，那么再好的阶段设计也无法落地，这时候要优先解决工具问题。

阶段划分这件事，做对的标志不是团队说”我们的流程很规范”，而是团队里任何一个人被问到”这个需求现在卡在哪个环节、卡在等谁”时，能在 10 秒内给出准确答案。如果你的团队能做到这一点，阶段划分就已经成功了。