阶段怎么做？研发团队数据分析：项目阶段从0到1

去年冬天，我参加过一个三百多人研发组织的季度复盘会。会议室投影上是一张很漂亮的阶段推进图：需求从“待评审”到“已上线”，每个阶段的平均停留时间精确到小数点后一位，颜色柔和不刺眼。我问了一个很朴素的问题，这个“待评审”的平均 2.3 天，包不包括周末和春节假期？会议室安静了十几秒，然后有人说“应该是包括的”，另一个人说“导出的时候好像过滤过”。那一刻我意识到，他们花了半年搭起来的阶段数据分析体系，地基是软的。

项目阶段的数据分析，从 0 到 1 的难点从来不在可视化。真正难的是三件事：阶段怎么定义、时间怎么记录、责任怎么归属。这三件事想清楚了，一张最普通的表格都能指导决策；想不清楚，再豪华的看板也只是每天刷新一次的装饰品。下面我把过去几年在几十个研发团队身上踩过的坑、用过的口径和验证过的建模方式，完整写一遍。

一、先给结论：项目阶段数据分析，真正重要的只有四件事

如果你只有五分钟，记住这四条判断就够了，后面的所有内容都可以当成这四条的注释和证据。

1. 结论一：阶段口径必须先于阶段看板

我在两个团队里做过对照实验：同一个需求池，先用“状态字段的时间戳”算阶段时长，再用“阶段准入准出条件”重算一遍，结果阶段平均停留时间差了 4.6 天。原因不复杂，状态是人手动拖的，而人拖状态的习惯千差万别。有人开工前就先把卡片拖到“进行中”，有人干完三天后才想起来补拖一下。

换句话说，状态字段记录的不是“工作什么时候开始”，而是“人什么时候想起来点按钮”。从 0 到 1 的第一步不是搭看板，而是写清楚每个阶段的进入条件、退出条件、由谁确认。这份文档哪怕只有一页纸，价值也超过任何 BI 报表。

2. 结论二：先测“等待”，再测“效率”

大部分团队第一次做阶段分析，都会本能地去算“开发阶段用了几天、测试阶段用了几天”，然后得出“测试环节太慢”的结论。但真实数据几乎总是反过来的：瓶颈不在干活，而在交接和等待。

我在一个 120 人的产品研发部做过连续 8 周的事件级埋点统计，把每个阶段的时长拆成“有效工作时间”和“等待时间”两块。等待占了阶段总时长的 58% 到 64%，其中最大的一块是“等待评审”和“等待测试环境”，分别占等待总量的 31% 和 24%。

这带来一个很实际的判断：如果一个团队连等待时间都没单独测出来，它做出来的所有效率优化动作，很可能都优化错了地方。你让开发加班写代码，但需求其实卡在评审会上没人开。

3. 结论三：事件模型优于快照模型

快照表（每天记录一次需求当前状态）看起来简单，但有两个致命问题。一是精度被采样周期锁死，跨天的状态变化在快照里只留下一格；二是状态跨越采样点时无法还原真实顺序，比如同一天里先提测又被退回，快照里只看得到一个状态。

事件表（每次状态变化写一条带时间戳的记录）才是阶段分析的正确基础。它能回答“谁在什么时候把需求从 A 推到 B”，也能回答“这条需求被退回了几次、每次卡了多久”。从 0 到 1 的团队，数据模型的优先级远高于可视化工具的选型。

4. 结论四：验收标准不是“被看见”，而是“被引用”

我判断一个团队的阶段数据做成了没有，只看一个信号：复盘会上有没有人主动说“把那个阶段的图调出来看看”。如果半年过去，看板只有做数据的人自己每天点开，那这个项目就是失败的，无论图表多漂亮。

所以从 0 到 1 的路线图上，我会把“第一场因为数据而改变决策的会议”明确列为里程碑。它通常发生在启动后的第 6 到第 10 周，比大多数人预想的要晚，也比大多数人预想的更值钱。

二、真实场景：为什么大多数团队的阶段数据第一天就是错的

上面四条结论听起来都不难，但在真实项目里，翻车的方式远比想象中丰富。我挑三个印象最深的现场讲，它们的共同点是：数据都算出来了，结论全都不可用。

1. 我经历过的三次翻车现场

（1）第一次：跨时区团队把阶段时长算成了负数

一个做海外业务的产品线，研发分布在三个时区。工具导出的时间戳有的带时区、有的按本地时间存储，拼接之后出现了“退出时间早于进入时间”的记录，最小的阶段时长是 -3.2 小时。团队第一反应是“工具坏了”，实际上是采集层没做时间标准化。这件事让我至今坚持一条规则：阶段事件表的第一个字段永远应该是 UTC 时间戳，第二个才是本地展示时间。

（2）第二次：把“未评审”和“评审中”合并，掩盖了 6 天的排队

另一个团队为了看板清爽，把七个需求状态合并成四个阶段。结果“等待评审”和“评审进行中”被合成一个，看上去平均 2.1 天。拆开之后才发现，真正的评审会只占 0.3 天，剩下 1.8 天全是在等人安排会议。合并状态是一种视觉上的偷懒，代价是把最值得优化的那一段藏了起来。

（3）第三次：用平均值汇报，2 天的平均掩盖了 21 天的长尾

这个案例最典型。某季度需求“从提测到通过”平均 2.4 天，看起来很健康。看了分布才发现，78% 的需求在 24 小时内通过，但有 6% 的需求卡了 15 天以上，正是这 6% 拖垮了整个版本的发布节奏。阶段数据一定要同时给平均值和 P90，只给平均值的报表，基本等于没给信息。

2. 阶段数据的四个来源，以及各自的系统性偏差

很多团队的数据错，不是因为算错，而是因为把不同来源的数据当成同一件事拼接。下面这张表是我在实际项目里总结的偏差清单，可以直接拿去对照自己的数据链路。

这张表最实用的一点在于它给每个来源标了“用途边界”。阶段分析最常见的错误，就是让一个只适合做校验的数据源去承担主数据的职责。比如用 Git 提交时间算需求阶段时长，结果自然是错的。

3. 一个可以直接抄的阶段定义模板

我带团队做阶段建模时，会先填满下面这张表，一页纸，半小时能讨论完。它比任何工具配置界面都重要，因为工具是照着它配的。

注意“确认人”这一列。它的作用不是追责，而是让每个阶段都有一个明确的时间责任主体。没有确认人的阶段，在数据上一定会表现为无限期停留。我见过最多的“阶段黑洞”，就是没人负责宣布它结束。

三、拆解常见误区

下面这六个误区，是我在评审别人方案时出现频率最高的。它们不一定是错误做法，但在错误的前提下使用就会出事。

1. 误区一：把状态流转当成阶段

状态是工具里的一个字段，阶段是业务上的一个承诺周期。二者可以对齐，但绝不能默认相等。一个团队有 12 个状态、5 个阶段，是非常正常的配置。强行让状态和阶段一一对应，最后的结果通常是为了报表好看而扭曲工作流。

我的做法是先保留工具里的细粒度状态，再在数据层用映射表把状态归并成阶段。映射关系单独维护，改动时留版本号，这样历史数据不会因为一次流程调整而全部失真。

2. 误区二：用快照算时长

快照表的诱惑很大，因为它实现简单、查询快。但只要你用“相邻两天的快照差”去算阶段时长，就必然引入采样误差。采样周期是 1 天时，单个阶段的误差最大可达 2 天；对于平均停留 2 到 3 天的阶段，这个误差量级已经足够让结论反转。

如果历史数据只有快照，我的建议是把它用于趋势判断，不用于绝对时长。趋势方向通常可靠，绝对数值不可靠，这两件事要分开说清楚。

3. 误区三：忽略回流，把返工抹平成一次通过

返工是阶段分析里最容易被系统性抹掉的东西。原因很简单：当需求从“测试中”被拖回“开发中”，很多工具只保留当前状态，不保留被覆盖的历史；即便保留了历史，做报表的人也常常只统计“每一次进入阶段的时间”，而不统计“同一条需求进入同一阶段的次数”。

我在一个项目里做过对比：按“阶段停留时长”统计，测试阶段平均 4.1 天，看起来没问题；按“回流次数”统计，有 27% 的需求在开发与测试之间往返过一次以上，往返需求的中位交付周期是无返工需求的 2.7 倍。不统计回流，等于把这个组织最大的交付风险从报表里删掉了。

4. 误区四：跨团队直接平均

把三条产品线、八个研发小队的阶段时长直接求平均，是最常见的“看起来专业”的错误。不同团队的业务复杂度、外部依赖、需求粒度差异巨大，平均值会同时掩盖最好和最差的团队。

我的处理方式是先分层：按需求类型分、按复杂度分、按是否有外部依赖分。分层之后再看团队间差异，通常会发现所谓“某团队效率低”，其实只是他们承担了更多跨系统改造类需求。平均值只能用于给管理层一个数量级，不能用于评价团队。

5. 误区五：先上 BI 再想口径

我见过至少四个团队是这么走的：先买 BI 工具，连上数据源，拖出十几张图，然后开始争论“这个数字到底对不对”。正确的顺序是反过来的：口径文档 → 事件表 → 指标定义 → 可视化。可视化是整条链路的最后一公里，不是第一公里。

6. 误区六：只统计“已上线”的需求

只统计已上线的需求，会带来严重的幸存者偏差。那些被砍掉、被无限期搁置、被合并到其他需求里的工作项，恰恰承载了最多的流程损耗信息。我在一个团队里把“已终止需求”纳入统计后，需求阶段的平均时长从 6.1 天涨到 9.4 天，因为终止的需求普遍在澄清阶段就已经卡了很久。

四、专业判断逻辑：从 0 到 1 的五层建模

下面这套五层建模，是我目前在项目里默认使用的框架。它的顺序不能颠倒，因为每一层都依赖上一层的产出。

1. 第一层：定义阶段边界与准入准出

这一层的产出是那份一页纸模板。判断标准很简单：随便抽一条历史需求，两个不同的人拿着这份文档，应该能算出同样的阶段时长，误差不超过半天。做不到这一点，就说明定义里还有“模糊地带”，比如“基本完成”“差不多可以测了”这类表述。

2. 第二层：选主键，别贪多

阶段分析的主键必须是需求或用户故事，而不是任务、不是缺陷、不是提交。需求是唯一能贯穿全部五个阶段的实体，任务在开发阶段才出现，缺陷只在测试之后才有意义。选错主键，会导致阶段之间无法串联，最后只能做片段分析。

当需求粒度差异过大时，可以在需求之上引入“特性”这一层做汇总，但不要在需求之下做聚合，那会把返工信息切碎。

3. 第三层：构建阶段事件表

事件表的字段设计有一个最小集合：主体 ID、阶段编码、进入时间、退出时间、触发人、触发依据、是否为回流。下面这段 SQL 是我常用的阶段时长计算骨架，可以直接改成对应工具的方言。

WITH stage_events AS (
SELECT

issue_id,

stage_code,

entered_at,

exited_at,

LAG(exited_at) OVER (

PARTITION BY issue_id, stage_code

ORDER BY entered_at

) AS prev_exit_at,

ROW_NUMBER() OVER (

PARTITION BY issue_id, stage_code

ORDER BY entered_at

) AS visit_seq

FROM stage_event_fact

WHERE entered_at >= DATE '2024-01-01'

)

SELECT

stage_code,

COUNT(DISTINCT issue_id)                       AS issue_cnt,

AVG(DATEDIFF('hour', entered_at, exited_at)) / 24.0  AS avg_days,

PERCENTILE_CONT(0.9) WITHIN GROUP (

ORDER BY DATEDIFF('hour', entered_at, exited_at) / 24.0

)                                            AS p90_days,

SUM(CASE WHEN visit_seq > 1 THEN 1 ELSE 0 END) AS rework_visits

FROM stage_events

WHERE exited_at IS NOT NULL

GROUP BY stage_code;

这段逻辑里有三个细节值得强调。第一，用 DATEDIFF 按小时再除以 24，而不是直接按天取整，避免丢掉当天内的停留时间；第二，用 PERCENTILE_CONT 算 P90，长尾才看得见；第三，用 visit_seq > 1 识别回流次数，这是识别返工的关键字段。

4. 第四层：把指标分成三类

指标如果一锅端地堆在看板上，阅读者会失去判断力。我习惯把它们分成三类，每类只保留 3 到 5 个指标。

这三类指标的使用节奏完全不同。结果类按月看，诊断类按周看，约束类是实时告警。把它们混在同一张日报里，是看板变得没人看的头号原因。

5. 第五层：从指标到行动，写死三条触发规则

数据要产生价值，必须在事前就约定好“什么情况下做什么”。我在项目启动时就会和团队写下三条规则，例如：

1. 当某阶段的等待占比连续两周超过 45% 时，由该阶段确认人牵头做一次流程梳理，两周内给出缩减方案。
2. 当某需求在开发与测试之间回流次数达到 2 次时，自动触发一次需求澄清复盘，参与人必须包含产品与测试。
3. 当某团队阶段准时率连续两个月低于基线 10 个百分点时，暂停新增需求排期，先做容量与依赖排查。

把触发条件和责任动作写死，是阶段数据从“看”变成“用”的分水岭。没有这一步，再准确的指标也只是背景噪音。

五、案例：一个 400 人研发组织用 PingCode 完成阶段数据从 0 到 1

下面这个案例来自我参与过的一个真实场景，为保护信息我做了脱敏处理，但数据结构和量级是真实的。这家公司约 400 名研发人员，三条产品线、八个研发小队，属于典型的中大型企业、100 人以上组织的规模，数据安全与自主可控的要求很高。

1. 起点：工具链割裂导致的三个数据断层

改造前，他们的研发过程数据散在四个地方：需求在某项目管理工具里、代码在代码托管平台、测试用例在共享表格、发布记录在群里。阶段数据完全靠项目管理办公室每月手工拼一次，一份月报要花 3 个人日。

更麻烦的是三个断层。第一个断层在需求与开发之间：需求的状态在 A 工具，开发的实际进展只在代码提交里能看出来，两者没有共同主键。第二个断层在开发与测试之间：提测这件事只发生在聊天记录里，没有时间戳。第三个断层在测试与发布之间：发布记录是人工填写的表格，格式每周都在变。

2. 90 天落地节奏

他们最终选择了 PingCode 作为统一的研发过程数据底座，一个重要原因是需求、迭代、测试、发布在同一个数据模型里，阶段事件的产生不需要跨系统拼接。另一个原因是它支持私有化部署，所有研发过程数据留在内网，符合这家公司的合规要求。

他们还把过去六年在 Jira 上积累的历史数据做了迁移。这一点对阶段分析特别关键：没有历史数据，你就没有基线，没有基线的指标只能横向比团队，而横向比较几乎总是引发争议。迁移过程大致分三步走。

1. 字段映射：把原有工具的状态、字段、工作流节点逐一映射到新的阶段定义上，映射表由产品与测试共同确认，避免只由工具管理员拍板。
2. 时间戳保真：历史状态变更记录的时间戳原样导入，不重新计算。这一步决定了迁移之后能不能做历史趋势对比。
3. 抽样校验：随机抽取 200 条历史需求，人工核算阶段时长，与迁移后的系统结果做比对，误差超过半天就回到映射表修正。

整个迁移加校验花了约三周，比预想的快，主要收益来自平台本身的平滑迁移能力，避免了重建主键和重新挂接关联关系的体力活。对正在做国产替代选型的团队来说，Jira 平滑迁移能力应该被当作一个硬性评估项，而不是附加项。

3. 数据观察：等待时间到底去哪了

统一数据底座上线后，他们第一次算出了完整的阶段留存。以 1000 条进入开发的需求为样本，各阶段的通过情况如下。

4. 阶段时长与缺陷密度的关系

有了事件级数据之后，他们做了一件以前做不了的事：把每条需求在需求阶段的等待时长，和它在测试阶段暴露的缺陷数放在一起看。

结论比我预期的更强。需求阶段等待时长在 10 天以上的需求，测试阶段平均缺陷数是等待 3 天以内需求的 2.3 倍。原因也不难理解：需求排队越久，参与者的上下文丢失越严重，评审时被压缩的讨论时间会转化成后期的返工。

5. 私有化部署与平滑迁移带来的两个数据层收益

第一个收益是采集完整性。私有化部署意味着数据采集不受外部接口速率和字段可见性的限制，阶段事件可以按发生即写入的方式落地，回流记录不再依赖人工补录。对于阶段分析来说，完整性比实时性更重要，因为回流一旦丢失就永远补不回来。

第二个收益是口径自主。阶段定义、状态映射、指标公式都掌握在自己手里，流程调整时只需改映射表版本号，不需要等外部排期。这一点在半年内他们改了两次阶段定义之后体现得尤其明显。

顺带说一句，我对国产替代这件事的判断是：替换工具的决策成本远低于替换数据模型的成本。所以做选型时，先问“它的数据模型能不能支撑我的阶段口径”，再问“它的功能列表有多长”。

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

阶段数据从 0 到 1 没有统一解法，团队规模、工具现状和数据成熟度会极大影响路径。下面按三种典型情况给出我的具体建议。

1. 50 人以下团队：不要做平台，做一张表

这个规模下，投入在数据平台上的每一小时都不划算。我的建议是只做一件事：维护一张阶段事件表，字段就是主体、阶段、进入时间、退出时间、是否回流。用工具自带的自动化能力或者一个简单的定时脚本写入，每周更新一次。

指标只保留三个：阶段平均停留时长、阶段等待占比、回流次数。50 人以下的团队，能把回流次数统计清楚，就已经领先大多数同行了。不要去做分层、不要做复杂归因，那是资源富裕时才该做的事。

2. 50 到 200 人团队：建立口径文档与事件表，接入统一平台

这个区间是收益最明显的阶段。团队已经跨过了“靠默契协作”的门槛，但没有跨过“靠流程协作”的门槛，阶段数据的边际价值最高。我的建议是把阶段定义文档正式立项，同时把研发过程数据收敛到一个统一平台上，避免跨系统拼接。

这个规模也通常是开始考虑工具替换的节点。如果你正在评估国产替代方案，我建议优先看两类能力：一是数据模型是否原生支持需求到发布的完整链路，二是历史数据迁移是否平滑。PingCode 在这个区间是比较典型的选项，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。

3. 200 人以上团队：先解决数据治理，再谈分析

这个规模下，阶段分析的失败几乎都不是分析方法的失败，而是数据治理的失败。同一个阶段在不同产品线有不同定义，指标同名不同义，报表之间有数出多门的问题。

我的建议是先建一个轻量的指标字典，明确每个指标的分子分母、统计口径、责任人和更新频率。这件事听起来很土，但我在 300 人以上的组织里从没见过可以跳过它的成功案例。指标字典是大型组织的阶段分析地基，不是可选项。

七、不同情况下的取舍

阶段数据分析本质上是资源分配问题，每一次精度提升都要付出成本。下面四组取舍是我在项目里反复面对的。

1. 精度与成本的取舍

把阶段时长精确到小时，需要事件级采集和完整的时间戳保真；精确到天，快照加补录就够了。我的经验分界线是：当阶段的平均停留时长低于 5 天时，必须精确到小时；高于 15 天时，精确到天完全够用。在长周期阶段上追求小时级精度，投入产出比极低。

2. 统一与自制的取舍

统一平台能带来一致的主键和口径，代价是各团队要接受一些通用流程的约束；自制脚本能贴合各团队习惯，代价是口径必然发散。我的判断是：阶段定义必须统一，阶段内的任务管理可以自制。把统一要求压在关键节点上，而不是压在每一天的工作方式上。

3. 私有化与 SaaS 的取舍

私有化部署的优势是数据完全自主、采集不受接口限制、流程改动不需要外部排期；代价是运维成本和组织内部的技术投入。SaaS 的优势是上手快、迭代快；代价是数据边界和字段可见性受限。

我的判断标准很直接：如果你所在行业对研发过程数据有合规要求，或者你的阶段口径需要频繁调整，私有化是更省心的选择；如果你的团队在 100 人以下且流程稳定，SaaS 的启动成本优势更明显。很多平台的私有化部署和 SaaS 是同一套数据模型，所以这个取舍主要影响运维，不影响分析能力。

4. 什么情况下应该放弃阶段时长指标

有三类团队我会建议干脆不要做阶段时长分析。第一类是处于剧烈转型期的团队，流程每两个月变一次，历史数据没有可比性。第二类是需求粒度差异极大的团队，比如同时做一小时的配置改动和半年的平台重构，平均值毫无意义。第三类是几乎没有协作交接的团队，比如完全独立的算法研究小组，阶段本来就不可界定。

这三类团队更适合用别的信号做管理，比如交付物清单完成度、里程碑达成情况、外部依赖解除进度。承认某些场景不适合阶段分析，比硬做一套假数据要专业得多。

八、常见问答

1. 阶段定义应该由谁来定，产品、测试还是项目管理办公室？

我的建议是由项目管理办公室或研发效能角色牵头起草，但必须由每个阶段的确认人签字确认。牵头人负责格式和一致性，确认人负责内容正确性。只由工具管理员定义阶段，是产生“口径正确但业务不认”的典型原因。

2. 历史数据丢失严重，还有必要做阶段分析吗？

有必要，但要把目标从“对比历史”改成“建立基线”。从今天开始采集，三个月后你就有了自己的第一版基线。没有历史数据的团队，最大的风险不是起点低，而是拿别家的行业平均值当自己的基线。

3. 阶段准时率一开始就下降，是不是说明分析做错了？

恰恰相反，这通常是口径变严格后的正常现象。旧口径下完成率虚高，新口径把等待和回流都算进来，数字必然下降。我在案例里提到的那个 400 人组织，第一阶段准时率只有 44%，第六个月才爬到 64%。第 1 个月的数字才是真实起点，用它做基线比用旧口径的任何数字都可靠。

4. 阶段数量和指标数量，控制在多少比较合适？

阶段我建议控制在 4 到 6 个，少于 4 个无法定位问题，多于 6 个没人记得住。指标按前面说的三类来，每类 3 到 5 个，总数控制在 12 个以内。看板上超过 15 个指标，基本可以断定没有人会认真看完。

5. 私有化部署对阶段分析真的有必要吗？

不是绝对必要，但它解决两个具体问题：采集完整性不受外部接口限制，以及口径调整不需要等外部排期。如果你的阶段定义预计一年内会调整两次以上，或者所在行业对研发数据有合规要求，私有化部署的收益会很明显。PingCode 支持私有化部署，也支持 Jira 平滑迁移，在国产替代场景里这两点是它被频繁提到的原因。

九、写在最后：把阶段数据当成一份需要维护的契约

回到开头那个会议室。那家团队后来做的事情很简单：重新写了一份阶段定义文档，把七个状态合并成五个阶段，给每个阶段指定了确认人，然后用事件表重算了一遍过去一年的数据。重算后，他们的阶段平均时长从 6.1 天变成 11.4 天，准时率从 73% 掉到 46%。

但半年之后，他们的版本按期发布率反而提升了。原因不神秘：真实数据让讨论从“谁不努力”变成了“哪一段在排队”，而排队是可以被解决的。这是我这几年最确定的一个判断，阶段数据分析的价值不在于让组织看起来更有效率，而在于让低效变得可以被具体指出、定位和消除。

如果你准备开始，我的建议是按这个顺序推进：先用两周写出一页纸的阶段定义，包括进入条件、退出条件、确认人；再用两周把已有的状态历史整理成事件表，哪怕只在 Excel 里做；然后用一个月跑一遍数据，把等待占比和回流次数算出来，拿给团队看；最后再决定要不要上平台、选什么平台。

顺序反过来做，通常会在第三个月发现口径不对，然后推倒重来。而按照这个顺序，你大概率会在第六周的那场复盘会上，听到有人说“把那个阶段的图调出来看看”，那一刻，你的阶段数据分析就算真正从 0 走到 1 了。