研发等待时间按工作项处于“已就绪但尚未被处理”状态的时长逐段累加：单段等待等于离开等待状态的时刻减去进入等待状态的时刻，工作项等待时间为各段之和，团队等待时间为统计窗口内所有工作项等待时长之和。要得到可复算的结果，先书面界定哪些状态算等待，再从状态变更记录取数，报告时同时给出分母、时间单位、统计窗口和缺失值处理方式。
要点总览（TL;DR）
- 研发等待时间按工作项处于“已就绪但尚未被处理”状态的时长逐段累加：单段等待=离开等待状态的时刻−进入等待状态的时刻，工作项等待时间=各段之和，团队等待时间=窗口内求和。
- 计算前先书面界定等待状态清单（如待评审、待测试、待分配、阻塞中）、统计单元、起止边界与排除项，并明确非工作时段是否扣除。
- 数据取自工作项状态变更历史或流转日志，必要字段包括工作项ID、状态、变更时间、责任人、所属阶段，需校验时间戳完整、命名统一与时区一致。
- 分母按问题选择：工作项数用于平均等待，总流转时长用于等待占比；报告需同时给出时间单位、统计窗口、缺失值规则，并用P50、P90和阶段拆分定位瓶颈。
- 等待时间长指向队列积压或资源冲突，不直接等于人员效率低；跨团队比较需口径一致，改进验证应固定口径与观察窗口，并配合周期时间、在制品数量解读。
评估目标：等待时间要回答哪个瓶颈问题
等待时间是一项流动指标，用来回答“工作在哪一段停下来、停了多久”。它适合两类用途：一是识别流动瓶颈，找出队列积压最严重的阶段；二是评估改进前后变化，例如调整评审节奏或补充测试资源后，等待是否缩短。把用途写清楚，才能决定统计粒度和拆分维度。
评估对象需要在开始计算前声明，通常有三种：单个工作项，用于查看某个需求或缺陷的等待构成；某个流转阶段，用于比较待评审、待测试等队列的积压程度；团队或价值流，用于观察整体流动状况。对象不同，取数范围和汇总方式也不同，混在一起计算会得到无法解释的平均值。
本指标衡量的是工作项在状态之间的停留时长，不衡量开发人员的主观体验与满意度，也不用于单个项目的进度纠偏和排期调整。若目标是判断某项目是否需要调整计划，应结合里程碑、剩余工作量和依赖关系分析，等待时间只能作为参考信号。
指标与范围：哪些状态算等待
等待状态集合必须书面界定，不能凭印象临时判断。常用做法是把“工作项已具备处理条件、但尚未有人开始处理”的状态列入等待，例如待评审、待测试、待分配、阻塞中等。状态名称各团队不同，关键是判断该状态是否代表“就绪但未处理”，并把判断依据写进口径文档。
起止边界同样要固定：从工作项进入就绪队列开始计时，到被领取或开始处理时结束。若一个工作项多次进出同一等待状态，例如评审退回后再次进入待评审，每次进入都单独计一段，不能只取首次进入和最后离开的时间差。
| 口径项 | 需要明确的内容 | 示例写法 |
|---|---|---|
| 等待状态清单 | 逐项列出计入等待的状态及判断依据 | 待评审、待测试、待分配、阻塞中 |
| 统计单元 | 工作项类型、团队范围、时间窗口 | 需求类工作项，A产品团队，2025年第三季度 |
| 起止边界 | 进入与离开等待状态的判定事件 | 进入待评审起算，进入开发中结束 |
| 排除项 | 不纳入统计的工作项与时段 | 未开始的需求、已关闭工作项 |
| 非工作时段 | 是否扣除周末、节假日、非工作时长 | 按自然小时计，或按工作日历扣除 |
非工作时段是否扣除会显著影响结果，两种口径都可用，但必须全篇一致并在报告中注明。按自然时间计算适合观察真实交付节奏，按工作日历计算适合比较团队内部处理能力。跨团队比较前，先确认双方采用同一口径。
数据口径与证据：从状态变更记录取数
等待时间的数据来源是工作项状态变更历史或流转日志，辅以字段变更记录。每次状态变化应留下一条可追溯的记录，包含变更前后的状态和发生时间。仅有当前状态无法还原历史停留时长，因此取数前要确认系统是否完整保留了流转记录。
必要字段包括：工作项ID，用于关联同一工作项的多条记录；状态名称，用于判断是否属于等待状态；变更时间，用于计算时长；责任人，用于分析队列归属；所属阶段，用于按阶段拆分。若需要按团队汇总，还应取团队或项目字段。
- 时间戳完整性：每条状态变更都有明确时间，缺失的记录不能默认为零时长。
- 状态命名统一：同一含义的状态在不同项目中使用同一名称，或建立映射表。
- 时区一致：跨系统、跨地区取数时统一换算到同一时区，避免出现负时长。
- 重复记录处理：同一时刻的重复变更只保留一条，或按业务规则合并。
- 回退状态处理：评审退回、测试不通过导致的回退，按实际进出重新分段累计。
缺失与异常需要预先约定规则。常见做法是：缺少离开时间的记录标记为不完整并单独统计数量，不纳入平均值；出现负时长视为数据错误，回溯原始记录修正；回退产生的多次等待按段累加，不合并为一段。规则写清楚，结果才能被他人复算。
在研发管理工具中，状态流转记录是这类统计的基础数据。以ONES为例，工作项的状态变更会形成流转历史，团队可以据此导出或查询各状态的进入与离开时间，作为等待时间计算的输入；具体字段与报表形式以团队实际配置为准。取数环节的重点是保证记录完整、命名统一，工具承载的是记录留存与查询，口径仍由团队自己定义。
计算步骤：分段累加与汇总公式
计算分三步。第一步，按工作项ID和时间排序状态变更记录，识别每次进入和离开等待状态的事件。第二步，对每一段等待求时长，单段等待时长 = 离开等待状态的时刻 − 进入等待状态的时刻，单位统一为小时或工作日。第三步，按工作项求和，再按统计窗口汇总。
核心公式如下：
- 工作项等待时间 = 该工作项各段等待时长之和
- 团队等待时间 = 统计窗口内所有纳入工作项的等待时长之和
- 平均等待时间 = 团队等待时间 ÷ 纳入统计的工作项数
- 等待占比 = 团队等待时间 ÷ 同期总流转时长
分母选择取决于要回答的问题。关心“一个工作项平均等多久”，用工作项数作分母；关心“流程中有多少时间花在等待上”，用总流转时长作分母。总流转时长指工作项从进入流程到离开流程的时长之和，需与等待时间使用同一时间窗口和同一批工作项，否则占比会失真。
仅有平均值不足以定位瓶颈，应同时输出分位数和阶段拆分。P50表示一半工作项的等待不超过该值，P90反映长尾积压情况；按待评审、待测试等阶段拆分，可以看出等待集中在哪个队列。报告时注明样本量，样本过少时分位数参考价值有限。
边界情况需要明确处理：分母为零，即窗口内没有纳入统计的工作项时，平均值记为无数据，不写为零；工作项没有等待记录时，其等待时间记为零并单独统计数量，说明这类工作项占比；统计窗口跨越口径调整时，分段报告，不把不同口径的数据合并平均。
算例：一个需求从待评审到待测试的等待
假设某需求类工作项在一个统计窗口内的状态时间线如下，时间单位为小时，按自然时间计，不扣除夜间与周末。
| 状态 | 进入时刻 | 离开时刻 | 时长（小时） | 是否计入等待 |
|---|---|---|---|---|
| 待评审 | 第1天 09:00 | 第1天 17:00 | 8 | 是 |
| 评审中 | 第1天 17:00 | 第1天 18:00 | 1 | 否 |
| 待开发 | 第1天 18:00 | 第2天 10:00 | 16 | 是 |
| 开发中 | 第2天 10:00 | 第3天 16:00 | 30 | 否 |
| 待测试 | 第3天 16:00 | 第4天 09:00 | 17 | 是 |
| 测试中 | 第4天 09:00 | 第4天 15:00 | 6 | 否 |
该工作项等待时间 = 8 + 16 + 17 = 41小时。流转总时长 = 8 + 1 + 16 + 30 + 17 + 6 = 78小时。等待占比 = 41 ÷ 78 ≈ 52.6%。按阶段看，待评审贡献8小时，待开发贡献16小时，待测试贡献17小时，待测试队列是这段流程中等待最长的环节。
若同一窗口内共有20个工作项，团队等待时间合计为820小时，则平均等待时间 = 820 ÷ 20 = 41小时，与上例数值相同仅为演示方便。实际报告应同时给出P50和P90，例如P50为36小时、P90为72小时，说明多数工作项等待在一天半左右，但长尾工作项等待明显更长，需要进一步查看这些工作项卡在哪个阶段。
解读与限制：等待时间能说明什么
等待时间长通常指向队列积压或资源冲突：待评审队列长，可能是评审人时间被占满；待测试队列长，可能是测试环境或测试人力不足。它反映的是工作项在流程中的停留状况，不能直接等同于人员效率低。同样的等待可能来自优先级频繁调整、依赖未就绪或批量处理习惯，解读时应回到具体队列和具体工作项查看原因。
跨团队、跨工作项类型比较前，先确认口径一致：等待状态清单相同、时间单位相同、非工作时段处理方式相同、统计窗口长度相近。口径不一致时，比较结果没有意义。工作项类型差异也会影响可比性，需求与缺陷的处理节奏不同，宜分开统计。
等待时间应与周期时间、在制品数量配合解读。周期时间反映从开始到交付的总时长，在制品数量反映同时进行的工作有多少。等待时间上升而在制品数量同步上升，更可能是队列积压；等待时间上升但在制品数量稳定，则要查看是否存在特定阶段的资源瓶颈。单看一个指标容易得出片面结论。
验证改进效果时，固定口径和观察窗口，比较改进前后同一阶段、同一工作项类型的等待时间与分位数。观察窗口应覆盖至少数个完整的流转周期，避免把短期波动当成改进成果。改进措施上线初期，等待时间可能因流程调整短暂上升，需要结合在制品数量和周期时间共同判断，再决定是否延续该措施。
常见问题
工作项多次进出同一个等待状态，等待时间要合并成一段吗？
不合并。每次进入等待状态都单独计一段，例如评审退回后再次进入待评审，按实际进出分别计算时长，再累加到该工作项的总等待时间。只取首次进入和最后离开的时间差，会把中间的评审、开发等处理时间也算进等待，结果偏大。
回退频繁的团队可以额外统计回退次数和回退产生的等待时长，用来判断问题集中在评审质量还是需求澄清环节。
按自然时间计和按工作日历扣除，两种口径结果差很多，报告时怎么处理？
两种口径都可用，关键是全篇一致并在报告中注明。按自然时间计算反映真实交付节奏，适合观察工作项从就绪到被处理的日历时长；按工作日历扣除周末和节假日，更适合比较团队内部的处理能力。
同一份报告里不要混用两种口径，跨团队比较前先确认双方一致。若统计窗口跨越口径调整，分段报告，不把不同口径的数据合并求平均。
状态变更记录缺失或出现负时长，这些工作项要不要计入平均值？
建议分开处理。缺少离开时间的记录标记为不完整，单独统计数量，不纳入平均值；出现负时长视为数据错误，回溯原始记录修正后再计算。把缺失记录默认为零时长，会系统性低估等待时间。
报告时说明不完整记录的数量和占比，让读者判断结果的可信程度。若缺失比例较高，先补齐数据再发布指标，比直接给出平均值更有参考价值。
等待时间下降就说明流程改好了吗？
需要结合其他指标判断。等待时间下降可能来自队列积压缓解，也可能来自统计范围缩小或工作项被提前关闭。验证改进效果时固定口径和观察窗口，比较改进前后同一阶段、同一工作项类型的等待时间与分位数。
同时查看周期时间和在制品数量：等待时间下降而周期时间同步缩短，改进更可信；等待时间下降但周期时间不变，要确认是否只是等待转移到了未纳入统计的环节。观察窗口应覆盖数个完整流转周期，避免把短期波动当成成果。
需求类和缺陷类工作项可以放在一起算平均等待时间吗？
建议分开统计。两类工作项的处理节奏、评审要求和优先级规则不同，混在一起算平均值会掩盖各自的队列状况。若确需看整体，可先分别计算再汇总，并在报告中注明构成。
跨团队比较同理，先确认等待状态清单、时间单位、非工作时段处理方式和统计窗口长度一致，口径不一致时比较结果没有意义。
