研发交付变慢时，先别急着归因于“开发效率低”。把每项工作从进入队列到交付的日历时长拆成两段——有人正在动手的处理时间，和无人推进、卡在队列或依赖上的等待时间——才能判断瓶颈落在作业环节还是环节之间。本文给出两类时间的口径、验证证据和可执行的状态打点方法，并说明如何用同一口径复测改善效果。
要点总览（TL;DR）
- 处理时间是工作项处于需求分析、编码、评审进行中、测试执行等作业态的时长；等待时间是待排期、待评审、待测试、等待环境或依赖方回复等排队与阻塞状态的时长，两者相加构成交付周期。
- 判断变慢来自哪一侧，先看各状态停留时长分布，再看回流与重开次数，最后看剔除返工后的单件作业耗时；等待状态中位停留时长持续偏高且队列增长，指向等待型原因。
- 落地方法是给每个状态标注作业态或等待态，记录进入与离开时间戳，按状态累计时长，计算等待时间占比与各等待状态分布，回流单独计数。
- 复测沿用同一状态分组与统计公式，连续多个观察窗口比较等待占比与队列长度，状态定义变更时同步历史口径或标注断点，避免前后不可比。
- 两类时间的拆分反映流程结构，适合定位环节间瓶颈，不宜单独用于个人绩效评价，否则容易诱发状态操作失真。
交付变慢的两种时间：先看症状落在哪个环节
处理时间指工作项处于实际作业状态的时长，例如需求分析、编码、设计评审、测试执行；等待时间指工作项处于排队、依赖、待响应状态的时长，例如待排期、待评审、待测试、等待环境就绪、等待他人回复。两者相加构成交付周期，任何一段拉长都会让交付变慢，但对应的改善动作完全不同。
区分两类时间的意义在于避免误诊。如果周期拉长主要来自等待，那么压缩单件作业耗时收效有限，需要处理的是队列长度、交接节奏和资源可用性；如果主要来自处理，才轮到看返工、方案反复、缺陷回流和任务复杂度。把等待误判为处理，常见的后果是给已经满负荷的团队继续加压，等待反而更长。
以下症状可以帮助初步判断问题落在哪一侧：
- 周期明显拉长，但团队人均忙碌度没有下降，工作项大量停在“待评审”“待测试”等状态——指向等待。
- 个别状态的停留时长异常长，且集中在交接点而非作业点——指向等待或交接空档。
- 同一工作项反复回到开发或测试状态，回流次数多——指向处理侧的返工。
- 单件任务的实际作业耗时上升，且与需求复杂度变化同步——指向处理侧。
这些症状只是线索，不能直接当结论。下一节按假设与证据的方式逐项验证。
原因假设与排除证据：哪些迹象指向等待，哪些指向处理
把“交付变慢”当作待验证的问题，先列出两类原因假设，再为每个假设找可观察的证据。这样做的目的是让排查有顺序、有排除依据，而不是凭印象选一个方向就开始改。
等待型假设与对应证据
等待型假设包括：需求进入开发前排队过长；评审环节等待评审人空闲；测试环境或依赖服务未就绪造成阻塞；跨团队交接存在无人负责的空档。对应的验证证据是各等待状态的停留时长分布、队列长度随时间的变化、以及工作项到达速率与处理速率的对比。如果某个等待状态的中位停留时长持续偏高，且队列在持续增长，等待型原因基本可以确认。
处理型假设与对应证据
处理型假设包括：需求理解偏差导致返工；技术方案反复讨论；测试缺陷回流使开发重复投入；任务本身复杂度上升。对应的验证证据是同一工作项的多次回流记录、重开次数、以及单件作业耗时的分布变化。回流次数上升而等待状态时长平稳，说明问题在作业本身。
排查顺序
建议按三步推进，每一步都为下一步缩小范围：
- 先看状态停留时长分布，确认时间主要消耗在哪些状态，以及这些状态属于作业态还是等待态。
- 再看回流次数与重开记录，判断处理时间中是否混入了返工，避免高估正常作业耗时。
- 最后看单件作业耗时，在剔除返工后比较同类任务的处理时间是否真的上升。
这个顺序的好处是先定位大块时间，再处理细节。多数情况下，第一步就能把问题范围缩小到一两个状态，后续排查不必全面铺开。
按状态打点：把周期拆成可计算的两段时间
要让上面的判断可计算，需要为工作项建立状态分组并记录流转时间戳。核心动作是：每个状态明确归属作业态或等待态，每次进入和离开状态都留下时间记录，再按状态累计时长并汇总。
第一步：定义状态分组
把现有工作流中的每个状态归入两类，归属规则要写下来并保持稳定。下表给出常见的归类口径，可按团队实际状态名称调整：
| 状态类型 | 典型状态 | 计入 | 说明 |
|---|---|---|---|
| 作业态 | 需求分析、方案设计、编码、设计评审进行中、测试执行 | 处理时间 | 有人正在对工作项投入实际作业 |
| 等待态 | 待排期、待评审、待测试、等待环境、等待依赖方回复、待验收 | 等待时间 | 工作项已就绪但无人推进，或受外部条件阻塞 |
| 回流 | 测试退回开发、评审不通过退回修改 | 单独计数 | 回流产生的时长单独统计，不并入正常处理时间 |
归类时有两个容易出错的点。一是“评审中”与“待评审”要分开：前者是评审人正在看，属于作业态；后者是排队等评审人，属于等待态。二是阻塞类状态要标明阻塞原因，否则无法区分是环境问题还是依赖方响应问题。
第二步：记录时间戳并累计时长
每次工作项进入某状态时记录进入时间，离开时记录离开时间，两者之差为该状态的一次停留时长。同一状态多次进入则多次累计。按工作项汇总后，作业态时长之和为处理时间，等待态时长之和为等待时间，两者相加应等于从进入到交付的总日历时长，这个等式可以用来校验数据完整性。
第三步：计算占比与分布
在汇总基础上计算两个指标：等待时间占交付周期的比例，以及各等待状态在总等待时间中的分布。前者回答“变慢主要来自哪一侧”，后者回答“等待主要发生在哪个环节”。只看平均值容易掩盖长尾，建议同时看中位数和高分位停留时长，识别少数长期滞留的工作项。
第四步：单独统计回流
回流与重开要单独计数并单独统计时长。如果把测试退回后的返工时长直接计入处理时间，会得出“处理时间变长”的结论，而真实原因是质量回流。回流次数、回流涉及的工作项比例、回流平均耗时，这三项应与两类时间并列观察。
在工具层面，这套打点依赖工作项状态流转记录的可追溯性。ONES 的工作项管理承载状态流转，ONES Performance 自动收录系统内日常流转的研发数据并形成分析指标，可从交付效率、交付质量、资源效率、完成情况四个维度做多维度分析，并提供场景化卡片与仪表盘模板。团队在落地时仍需先确定自己的状态分组口径，再核对工具中的状态停留数据是否与口径一致。
验证改善与防止复发：用同一口径复测
处置动作落地后，验证的关键是口径不变。用与诊断阶段相同的状态分组、相同的统计公式复测，比较等待时间占比、各等待状态分布和周期分布的变化。如果口径中途调整，前后数据不可比，改善与否都无法判断。
设定观察窗口
观察窗口要覆盖足够多的工作项完整走完流程，否则样本偏向短周期任务。建议以周为单位连续观察数个窗口，区分短期波动与结构性改善：单周等待占比下降可能只是队列暂时清空，连续多个窗口下降且队列长度同步回落，才更可能是结构性变化。复测时同时看中位数与高分位，避免平均值被少数快速完成的工作项拉低。
复发预防
针对诊断中识别出的高频等待状态，设置停留时长提醒和队列上限。停留提醒让等待被看见，队列上限迫使团队在队列过长时先处理入口而不是继续加任务。对回流集中的环节，把回流原因分类记录，作为下一轮改善的输入。这些措施的效果同样用等待时间占比和回流次数来检验。
风险边界
状态定义变更时，需同步调整历史数据的归类口径，或在变更点标注断点，避免把不同口径的数据放在同一趋势线上比较。状态分组过细会增加记录负担、降低数据一致性，过粗则无法定位具体环节，建议先覆盖主要作业态和主要等待态，再按需细化。此外，两类时间的拆分反映的是流程结构，不能单独用来评价个人绩效，否则容易诱发状态操作的失真。
常见问题
团队状态名称五花八门，怎么保证作业态和等待态的归类一致？
先把现有工作流中每个状态列出来，逐一写明归属和判断依据，形成一份团队共用的状态分组表，再开始采集数据。归类时抓住一个判断标准：工作项在该状态下是否有人正在投入实际作业。有人动手的计入处理时间，已就绪但无人推进或受外部条件阻塞的计入等待时间。
容易混淆的是“评审中”和“待评审”，前者是评审人正在看，属于作业态；后者是排队等评审人，属于等待态。阻塞类状态要同时记录阻塞原因，否则无法区分是环境未就绪还是依赖方未响应。分组表确定后保持稳定，中途调整会让前后数据不可比。
工作项在等待期间被临时拉去做别的任务，等待时长还算不算？
算。等待时间衡量的是工作项从就绪到重新被推进之间的日历时长，与人员当时在做什么无关。如果因为人员被调走导致工作项停在待处理状态，这段时长仍然计入等待时间，并且可以在阻塞原因中标注为资源占用。
需要避免的是把等待时间与人员空闲混为一谈。等待时间长说明工作项在队列中滞留，改善方向是控制队列长度、明确交接责任和可用性安排，而不是简单增加人手。若同一人员长期在多条队列间切换，可结合资源负载数据一起观察，判断等待是否由容量不足引起。
状态打点需要多细，是否每个子状态都要单独记录？
建议先覆盖主要作业态和主要等待态，能支撑定位到具体环节即可，不必一开始就细分到每个子状态。分组过细会增加记录负担，也容易因不同人理解不一致而降低数据一致性；分组过粗则无法区分是编码慢还是评审排队。
实际操作中，可以先按“分析、开发、评审、测试、验收”几个主环节建立作业态与等待态的对应关系，运行一段时间后，对停留时长异常高的环节再拆分子状态。拆分时同步更新状态分组表，并在变更点标注断点，保证趋势对比有据可依。
等待时间占比降到多少算合理，有没有通用阈值？
没有适用于所有团队的通用阈值。合理的等待占比取决于工作项类型、依赖复杂度和交付节奏，同一团队在不同阶段的基线也会变化。更可靠的做法是以自身历史数据为基线，观察等待占比和队列长度的变化趋势，而不是对照外部数字。
复测时建议连续观察多个以周为单位的窗口，同时看中位数与高分位停留时长。单周占比下降可能只是队列暂时清空，连续多个窗口下降且队列长度同步回落，才更可能是结构性改善。若团队业务节奏发生明显变化，应重新建立基线再比较。
用ONES承载状态打点和时间统计，需要注意什么？
ONES 的工作项管理承载状态流转，ONES Performance 自动收录系统内日常流转的研发数据并形成分析指标，可从交付效率、交付质量、资源效率、完成情况四个维度做多维度分析，并提供场景化卡片与预置仪表盘模板。团队落地时仍需先确定自己的状态分组口径，再核对工具中的状态停留数据是否与口径一致。
需要提前确认的是状态名称与分组表的对应关系，以及回流与重开在工具中如何识别。若工具中的状态划分与团队口径存在差异，应在分析前完成映射，避免把不同含义的状态合并统计。具体指标口径与配置方式以实际使用时的产品说明为准。
