项目阶段阶段划分全流程：研发团队数据分析与一文讲清

去年我帮一家 180 人的 SaaS 公司做研发效能诊断，第一周就卡住了。他们把项目分成 12 个阶段，从「需求池」一路排到「客户验收」，流程图贴在墙上看着非常完整。可当我拉出过去 6 个月的流转数据，发现 43% 的工作项在「开发中」这一个状态里停留超过 10 个工作日，而「测试」阶段平均只有 1.8 天，如果只看这份报表，结论必然是「开发是瓶颈，测试很健康」。但真实情况是，测试环境排队平均要等 3.5 天，这段等待被算进了「开发中」。

报表没撒谎，是阶段划分本身把真相藏起来了。

这不是个例。我经手过的几十个研发团队里，阶段划分真正做对的比例不到两成。绝大多数团队把阶段划分当成一次性的流程图作业，画完就扔进 wiki，真正影响决策的数据口径却从来没人定义过。这篇文章会把阶段划分的全流程拆开讲：怎么定、怎么落到工具里、怎么让数据变得可用、以及在什么情况下你应该主动放弃精细化。

一、核心结论：阶段划分的本质是「数据契约」，不是流程图

先把结论摆在前面，后面所有内容都是为了论证它。

我判断一个团队的阶段划分是否合格，只看一件事：能不能仅凭工具里的字段，自动算出一个工作项在每个阶段的停留时长、返工次数和跨阶段回流路径。能，就是合格的；不能，流程图再漂亮也只是装饰。

1. 三句话结论

• 结论一：阶段划分的交付物不是流程图，而是一份可被工具执行的「状态契约」。每个阶段必须有唯一的进入事件、可测量的退出准则、明确的责任人和对应的数据字段，缺一项这个阶段就是不可度量的。
• 结论二：阶段数量由「责任转移点」决定，不由岗位或部门决定。研发组织中 5-8 个主阶段、配 8-15 个子状态，是 100 人以上组织最稳的区间；低于 5 个看不到瓶颈，高于 8 个数据噪音会盖过信号。
• 结论三：阶段划分的质量，大约 70% 取决于退出准则是否可测量，30% 取决于工具配置。很多团队花钱换了工具却毫无改善，就是因为把 100% 的精力花在了那 30% 上。

2. 阶段划分的三层结构

绝大多数团队只做了第一层，然后就抱怨「数据不准」。实际上三层是递进关系，缺一层，下面那层的价值就归零。

我在实际项目里最常做的动作，是先补第二层。因为流程层大家都自认为有，管理层买工具就自带，唯独数据层是真空地带，而恰恰是它决定了另外两层能不能产生价值。

3. 为什么大多数阶段划分在数据分析上会失效

失效的根因可以归结为一句话：阶段边界没有落在「责任转移点」上，而是落在了「动作描述」上。

「编码中」是一个动作描述，「功能开发完成并可提测」是一个责任转移点。前者无法判断什么时候结束，后者可以用「提测单已提交且测试负责人已接收」这个事件精确捕捉。当一个阶段没有明确的结束事件，工具就只能靠人工点击状态按钮来推进，而人工点击的时间点和管理意义上的真实时间点，通常差 1-3 天。

这个误差在单个工作项上无所谓，但当你统计 500 个工作项的阶段停留时长时，它会系统性地把等待时间归到错误的地方，就像开头那个案例，测试环境排队被算进了开发。

二、真实场景：三个阶段划分的翻车现场

下面三个案例都是我实际操作过的，细节做了脱敏，但结构和数字保持原样。

1. 案例A：12 个阶段掩盖了真正的瓶颈

某 180 人 SaaS 公司，阶段设置为：需求池 → 需求评审 → 方案设计 → 技术评审 → 开发中 → 自测 → 提测 → 测试中 → 修复中 → 验收 → 待发布 → 已上线。听起来非常完整，对吧？

拉数据后我做了一次停留时长贡献度分析：前 5 个阶段合计占 21%，「开发中」占 43%，「自测 + 提测」占 18%，「测试中」占 6%，后面全部加起来 12%。管理层的直觉反应是优化开发效率。

但我又做了一次交叉验证：把「开发中」的停留时长与「提测单实际提交时间」做了比对，发现平均有 3.5 天的时间差，而这 3.5 天正好对应测试环境的排队等待。也就是说，团队真正的瓶颈是测试环境容量，而不是开发产能。如果他们按第一版结论去压开发工期，只会让提测量更大、排队更长。

2. 案例B：从别的工具迁移过来时，状态字段不能 1:1 映射

某金融行业客户，原有工具里定义了 28 个工作流状态，因为不同业务线各自维护自己的流程。迁移时最省事的做法是把 28 个状态原样搬过来，但那样度量报表会彻底不可读。

我们实际做的是「先归并、再映射」：把 28 个状态按责任归属归并成 7 个主阶段，保留 11 个作为子状态挂在主阶段下。比如「开发中 / 编码完成 / 待自测 / 自测通过」全部归入「开发」主阶段，但保留子状态用于团队内部看板。

这里有个关键决策点：主阶段用于跨团队度量和汇报，子状态用于团队内部协作，两者共用同一套底层字段。这样既保住了数据可比性，又没有牺牲一线团队的灵活性。他们最终选择在某项目管理平台上落地，一个重要原因是它支持工作流自定义的同时，保留了阶段与状态的父子关系，并且支持从原有工具平滑迁移历史数据，不需要把过去 3 年的记录全部推倒重来。

3. 案例C：硬件与软件混在同一阶段，数据完全不可比

某智能硬件团队，把「样机验证」和「软件联调」放在同一个「集成验证」阶段里。结果是：硬件侧的样机往返平均 23 天，软件侧联调平均 4 天，两者混在一起算出一个 13.5 天的平均值，谁也看不出问题在哪。

拆成两个并行阶段之后，数据立刻清晰了：硬件侧占用整个项目周期的 62%，且波动极大（P85 达到 41 天）。管理层这才意识到，项目延期的主因是硬件供应商的交付节奏，而不是他们一直以为的软件质量。

三、常见误区拆解：八个看起来对、用起来错的做法

这些误区我几乎在每个新接触的团队里都能碰上至少三四个，而且当事人往往觉得自己的做法理所当然。

1. 按部门划分阶段

「需求部 → 开发部 → 测试部 → 运维部」这种划法的问题在于，它描述的是组织架构，不是价值流动。阶段划分的对象是工作项，不是人。当一个工作项同时需要前端和后端两个人处理时，它应该落在哪个部门阶段？答案是：它落在「开发」阶段，而前后端的分工应该由子状态或任务层级去表达。

2. 阶段越细越好

我见过一个团队把阶段拆到 19 个，包括「等待代码评审」「代码评审中」「评审意见修改中」。精细化的代价是填报成本：每一项每次流转都要判断一次该点哪个状态，团队平均每天多花 12 分钟。一个月下来就是 4 个人天，而这些成本换来的信息量，往往还不如一次深度访谈。

3. 阶段名一致就以为口径一致

「测试中」这三个字，在不同团队眼里的含义可能完全不同：有的团队指「测试用例执行中」，有的指「测试人员已接手但还没开始」，有的把修复期也算进去。跨团队汇总数据之前，必须做一次口径对齐工作坊，逐个阶段确认进入条件和退出条件，并且写成文档。

4. 只设进入准则，不设退出准则

进入准则回答「什么时候可以开始」，退出准则回答「什么时候算完成」。后者才是数据可用性的关键，因为没有退出准则，工作项就会一直挂在当前阶段，停留时长无限膨胀，最终所有度量都失效。

5. 把「暂停 / 挂起」当成阶段

挂起是一种状态属性，不是流程阶段。正确做法是给工作项加一个「阻塞标记」字段和一个「阻塞原因」字段，而不是把它挪到一个叫「已挂起」的阶段里。否则你的流程会变成一个死胡同，挂起之后往哪走？很多团队为此不得不加一条「恢复」的反向路径，把状态机搞得极其复杂。

6. 阶段划分一次定终身

团队 30 人时的阶段划分，到了 150 人一定不适用。我在 2021 年给一个团队定的 6 阶段模型，他们 2023 年扩到 200 人后，光「开发」一个阶段的停留时长分布就从单峰变成了明显的双峰，因为前后端两个子团队的节奏差异被混在了一起。后来拆出两个子状态才看清楚。建议每 6 个月或团队规模变化超过 30% 时，重新评估一次阶段划分。

7. 用平均周期做决策

平均值是研发度量里最危险的指标。一个团队的平均交付周期 12 天，听起来还行，但 P85 可能是 34 天。真正影响客户体验和交付承诺的，是分布的尾部，不是中心。我的建议是每个阶段至少同时看 P50 和 P85 两个分位数。

8. 把阶段数据和绩效挂钩

这是最致命的一条。一旦阶段停留时长进入个人考核，数据会立刻开始失真：研发人员会在下班前批量点状态，会在周五集中提测，会把工作项长期挂在「开发中」以便随时开工。数据一旦被污染，就再也回不来了。

四、专业判断逻辑：阶段划分的四条硬判据

上面讲了这么多问题，那到底怎么判断一个新设计的阶段划分方案是不是合格？我用四条判据，每一条都可以在半小时内验证。

1. 判据一：唯一交付物原则

每个阶段必须有且只有一个可验收的核心交付物。需求阶段交付「评审通过的需求说明」，设计阶段交付「通过评审的技术方案」，开发阶段交付「可提测的构建产物」，测试阶段交付「测试报告与缺陷清单」。

如果一个阶段说不清交付物是什么，那它大概率不是一个阶段，而是一种状态。我做过一个快速测试：让团队成员用一句话回答「进入下一个阶段的那一刻，我们手里多了什么」，如果答案超过三种，这个阶段就需要拆或需要合并。

2. 判据二：可自动采集原则

阶段的进入和退出时间，必须能从工具的客观事件中自动获取，而不是靠人工点击。比如「开发完成」可以由代码提交或构建成功事件触发，「测试通过」可以由测试计划状态变更触发。

这里有个现实约束：大部分团队的自动化程度不足以做到 100% 自动采集。我的建议是把「自动采集率」作为一个明确指标来管理，先做到 60%，再逐步提升，而不是一开始就追求全自动导致方案无法落地。像支持开放 API 和 Webhook 的项目管理平台，可以先从构建、部署、测试这几个环节切入。

3. 判据三：责任转移原则

阶段边界应该落在责任发生转移的时刻。谁在什么时刻把什么交给了谁，这个交接点天然就是阶段边界。

用这条判据检验：如果两个相邻阶段之间没有发生责任转移，那它们其实是一个阶段；如果一个阶段内部发生了两次以上的责任转移，那它应该被拆开。这一条能解决八成以上的「阶段该分几个」的争论。

4. 判据四：规模匹配原则

阶段数量必须与团队规模、发布频率匹配。下面这张区间表是我从实际项目中总结的，可以直接作为参考基准。

五、数据观察：一个 150 人团队的六阶段度量结果

下面这组数据来自我在一个 150 人研发组织做的阶段划分改造项目，样本是改造前后各 6 个月的工作项流转记录。为了让数据可读，我把口径统一为「工作日」并剔除了被取消的工作项。

1. 改造前的数据画像

改造前他们用 11 个阶段，报表上看不出明显瓶颈，因为每个阶段停留时长都在 2-4 天之间，非常均匀。这种「均匀」本身就是危险的信号，真实的研发流程不可能这么均匀，均匀说明数据被平均化了。

2. 改造后的数据画像

归并为 6 个主阶段 + 12 个子状态后，数据立刻呈现出明显的长尾特征：开发阶段 P85 达到 16.4 个工作日，而 P50 只有 5.2 天。这个 3 倍以上的差距，才是真正值得管理层关注的东西。

这张表里最值得注意的是测试阶段：返工率 24%、平均返工 0.41 次/项，是全流程最高的。但它不是「测试做得差」，而是前面环节的质量问题在这里集中爆发。这正是阶段划分的价值，它让你能看到质量成本在流程中的迁移路径，而不是把责任简单归给某个岗位。

3. 端到端时间分解

把六个阶段串起来看，改造后的端到端平均周期是 21.4 个工作日，P85 是 42 个工作日。但更有价值的是分解：真正的「加工时间」（各阶段实际工作时间之和）只占 46%，其余 54% 是等待。

这个比例在制造业里叫「增值比」，精益生产里通常追求 25% 以上。研发流程能达到 46% 已经算不错，但如果能通过环境优化、评审前移、并行化把等待压到 35%，端到端周期可以直接缩短 20% 以上。

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

阶段划分没有标准答案，只有匹配当前阶段的答案。下面按团队规模给出具体动作，你可以直接对号入座。

1. 10 人以下：尽量不要划分阶段

这个规模的团队，沟通成本已经足够低，任何流程都可能变成负担。我的建议是只用三个状态：待办、进行中、已完成。唯一需要坚持的是「已完成」必须对应一个可交付的产出，比如一次可部署的构建。度量上只看端到端周期时间，不要拆阶段。

2. 10-50 人：用 4-6 个阶段建立最小可用度量

这个阶段的核心目标是让团队对流程有共识。建议划分：需求 → 设计 → 开发 → 测试 → 发布。每个阶段配 1-2 个子状态即可。度量重点放在阶段停留时长的 P50 和 P85 上，每月复盘一次，找出最长的那个阶段。

3. 50-150 人：进入需要工具支撑的区间

从这个规模开始，手工维护状态已经不现实，必须依赖工具。重点要做三件事：一是建立字段字典，明确每个阶段对应的数据字段；二是把能自动采集的事件接进来；三是建立跨团队的统一口径。

这个区间也是大多数中型企业的典型状态。我一般建议在这个阶段就把度量体系的基础打好，因为再往上扩，历史数据的可比性会越来越难保证。

4. 150 人以上：需要平台化的阶段治理能力

这个规模的组织通常面临多业务线、多产品、混合研发模式（敏捷 + 瀑布 + 硬件）并存的问题，阶段划分不可能只有一套。

此时需要的能力包括：支持多工作流并存、支持阶段与状态的父子关系、支持字段级权限控制、支持历史数据的平滑迁移。主阶段保持组织级统一用于汇报，子状态允许各团队自治用于协作，这是我验证过最稳的架构。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对于正在做国产替代选型、又不想丢掉历史度量数据的团队来说，是一个值得纳入评估的选项。

七、不同情况下的取舍

阶段划分到最终落地时，一定会遇到几组无法同时满足的目标。提前想清楚取舍原则，比事后反复调整更省成本。

1. 细度 vs 填报成本

每增加一个阶段，团队每次流转都要多做一次判断。我的经验阈值是：如果新增一个阶段带来的管理收益，无法在三个月内被清晰的改进动作兑现，就不要加。比如加一个「代码评审中」状态，如果能证明评审是瓶颈，那就值得加；如果加了之后没人看这个数据，那就是纯成本。

2. 组织统一 vs 团队自治

统一口径的好处是数据可比，坏处是团队被迫接受不合适的流程。我的建议是用「主阶段统一、子状态自治」的分层方案：组织层面锁定 6-8 个主阶段的定义和退出准则，团队层面可以在主阶段下自由定义子状态。这样汇报数据始终可比，一线团队也不觉得被绑住手脚。

3. 度量精度 vs 心理安全感

度量越精细，团队感受到的监控压力越大，数据失真的风险也越高。这一组的取舍原则是：度量数据只用于改进流程，不用于评价个人。并且尽量用团队级聚合数据，避免下钻到个人。我在落地时通常会明确写进团队章程：任何个人级阶段时长数据不进入绩效讨论。

4. 自动采集 vs 人工录入

自动采集准确但改造周期长，人工录入灵活但容易失真。实际做法是分层：关键节点（构建、部署、测试执行）优先自动采集；判断性强、难以自动化的节点（设计完成、方案评审通过）保留人工录入，但要求录入时必须填写简短说明。这样既保证了核心数据的客观性，又不至于让流程卡死。

八、落地：一张设计表 + 八步动作

讲完逻辑，最后给一套可以直接拿去用的东西。下面这张表是阶段定义模板，每个阶段填满一行，阶段划分方案就算设计完整了。

1. 八步落地动作

1. 拉历史数据：导出过去 6 个月的工作项流转记录，先看看当前阶段划分下能算出什么、算不出什么。
2. 识别责任转移点：把流程里所有「谁交给谁」的交接动作列出来，通常会有 6-10 个。
3. 归并主阶段：把交接点相邻的合并，最终收敛到 5-8 个主阶段。
4. 补退出准则：为每个主阶段写一条可被第三方验证的退出准则，写完自己反推一遍能不能自动判断。
5. 设计子状态：让各团队在授权范围内定义子状态，但要求映射回主阶段。
6. 配置工具与自动化：把能自动触发的节点接上构建、部署、测试系统，优先做采集率高的事件。
7. 建立报表口径：明确每个指标的计算方式和统计范围，写进文档，任何人拉出来的数字应该一致。
8. 设复盘节奏：每月看一次阶段停留分布，每季度评估一次阶段划分是否仍匹配团队规模。

2. 一份可直接落地的阶段契约示例

下面是我在某项目管理平台里配置阶段字段时使用的结构，去掉平台相关的字段名后，可以直接作为字段字典的模板。

{
"stage": "development",

"display_name": "开发",

"deliverable": "可提测的构建产物 + 自测报告",

"entry_event": "tech_review_passed",

"exit_criteria": [

"build_smoke_test == passed",

"test_request_submitted == true",

"test_owner_accepted == true"

],

"owner_role": "dev_lead",

"sub_states": ["coding", "self_test_pending", "self_testing", "ready_for_test"],

"metrics_fields": {

"entered_at": "timestamp",

"exited_at": "timestamp",

"blocked_flag": "boolean",

"blocked_reason": "enum",

"reopen_count": "integer"

},

"auto_transitions": [

{ "trigger": "build_succeeded", "target_sub_state": "self_testing" },
{ "trigger": "test_request_created", "target_sub_state": "ready_for_test" }
]
}

这份契约的价值在于，它把「开发阶段」从一个模糊的概念变成了一组可执行的判断条件。任何人拿到它，都能判断一个工作项现在在不在开发阶段、什么时候该出去、出去了该记什么数据。

3. 下一步怎么做

如果你读到这里，我建议你先做一件最小的事：打开你现在的项目管理工具，导出过去 30 天的工作项流转记录，尝试算一算每个阶段的 P50 和 P85 停留时长。

如果能算出来，说明你的阶段数据层是健康的，接下来只需要检查阶段数量是否匹配团队规模。

如果算不出来，或者算出来的数字你自己都不信，那就说明问题不在流程图上，而在数据契约上。这时候不要急着换工具，先把退出准则和字段字典补齐，再回头看看数据能不能对上。

至于 150 人以上的组织，如果同时面临国产替代、私有化部署和 Jira 历史数据迁移三件事，我的建议是把「阶段划分与历史口径的兼容性」写进选型评估表的第一行，而不是最后一行。因为流程可以改，数据断了就真的断了。