研发等待时间指工作项已经具备推进条件、却因等待他人响应、外部依赖或流程闸门而尚未流动的时段。它通常分布在六类环节：排队待评审、评审后待修改与复审、跨角色交接、依赖阻塞、环境与发布窗口等待、返工等待。判断某段时间是否计入，关键看工作项状态、责任是否已交接、推进条件是否已满足这三个要素，而不是凭人员感受估算。
要点总览（TL;DR）
- 研发等待时间指工作项已具备推进条件、却因他人响应、外部依赖或流程闸门而未流动的时段，判断时同时核对工作项状态、责任是否已交接、推进条件是否已满足三个要素。
- 常见等待分布在六类环节：排队待评审、评审后待修改与复审、跨角色交接、依赖阻塞、环境与发布窗口等待、返工等待，每类都有明确起止点。
- 评审等待从提交评审算到有效评审意见返回；交接等待从责任方明确移交算到接收方开始处理；阻塞等待从依赖被标记为阻塞算到依赖解除。
- 周期时间包含等待时间与处理时间，阻塞时长只是等待时间的子集；人员主观感受和单项目进度偏差不纳入流动效率口径。
- 拆解一段流程时先区分处理与等待，再按六类环节归位，并预先约定多类等待同时发生时的归类优先级，避免重复计时。
研发等待时间的定义与判定口径
把等待时间定义为“工作项具备推进条件但未流动的时段”，可以直接用于拆分任意一段流程时长。这个定义包含两个限定：一是工作项本身已经完成上一环节的产出，具备进入下一环节的条件；二是它尚未被下一环节的责任方实际推进。两个条件同时成立的时间段，才计入等待。
落到具体判断上，可以用三个要素逐项核对：
- 工作项状态：工作项是否已进入“待评审”“待处理”“待验证”等表示可推进的状态，而不是仍处于开发、设计等处理中状态。
- 责任方是否已交接：上一环节的责任人是否已明确把工作项移交出去，接收方是否已知悉。责任仍停留在原责任人手中、只是对方暂时没空处理的时间，属于处理环节内部的停顿，不计入跨角色交接等待。
- 推进条件是否已满足：评审所需的材料是否齐全、依赖的接口是否已就绪、测试环境是否可用。条件未满足时，工作项处于阻塞而非普通排队，需要单独归类。
等待时间与处理时间互补。处理时间是责任人实际动手推进的时长，包括编码、写文档、执行测试、修改缺陷等；等待时间是工作项停在某人或某个环节之外、无人推进的时长。两者相加构成工作项从进入到流出的总时长。团队在度量说明中应明确：哪些状态算“可推进”、交接以什么动作作为标志、阻塞如何标记，并把这份说明作为统一口径，避免不同项目各算各的。
等待时间覆盖的六类环节
研发流程中的等待可以归入六类环节，每类都有明确的起止点和识别信号。下表给出清单，便于团队对照现有流程逐项核对。
| 环节 | 起点 | 终点 | 识别信号 |
|---|---|---|---|
| 排队待评审 | 提交评审 | 首次评审意见返回 | 工作项处于待评审状态，评审人尚未给出意见 |
| 评审后待修改与复审 | 评审意见返回 | 修改完成并再次通过评审 | 意见已记录，修改尚未开始或复审尚未完成 |
| 跨角色交接等待 | 责任方明确移交 | 接收方开始处理 | 需求、设计、测试、发布交接后接收方尚未响应 |
| 依赖阻塞 | 依赖被标记为阻塞 | 依赖解除 | 上游接口、数据、第三方或外部团队未就绪 |
| 环境与发布窗口等待 | 工作项具备验证或上线条件 | 环境可用或窗口开启 | 测试环境排队、上线窗口未到、审批闸门未过 |
| 返工等待 | 缺陷或问题反馈提出 | 重新进入处理 | 问题已登记，责任人尚未开始修复 |
这六类环节的共同特征是：工作项已经可以往下走，卡点在于响应、依赖或流程安排。排队待评审和评审后待修改反映评审节奏；跨角色交接反映协作衔接；依赖阻塞和环境窗口反映外部条件；返工等待反映问题反馈到重新处理之间的间隔。团队可以按这六类建立统一的等待原因分类，让每条等待记录都能落到一个具体类别上。
评审、交接与阻塞三类环节的口径细化
评审、交接与阻塞是实际计时中最容易产生争议的三类环节，需要把边界定得更细。
评审等待的计时边界
评审等待以提交评审为起点，以有效评审意见返回为终点。“有效”指评审人给出了可执行的结论，例如通过、需修改并附具体意见、驳回并说明理由；仅表示“已查看”不构成终点。跨时区和节假日需要在度量说明中预先约定：可以按工作日历扣除非工作时间，也可以按自然时间统计后单独标注，两种方式都可行，但同一份报表内应保持一致，避免同一团队不同项目口径不一。
交接等待的计时边界
交接等待以责任方明确移交为起点，以接收方开始处理为终点。明确移交的标志可以是工作项责任人字段变更、交接说明写入工作项、或在协作工具中发出交接通知。接收方开始处理的标志是状态变为处理中或产生第一条处理记录。如果交接后接收方提出澄清问题、原责任人补充信息，这段往返时间仍属于交接等待，因为它反映的是交接信息不完整造成的额外响应时间。
阻塞等待的计时边界
阻塞等待以依赖被标记为阻塞为起点，以依赖解除为终点。起点要求工作项上留下阻塞标记和原因分类，例如上游接口未就绪、第三方资质未批复、外部团队排期未定。终点是依赖实际可用，而不是“对方口头答应”。记录阻塞原因分类的价值在于后续分析：同类原因反复出现，说明问题出在流程设计或资源安排上，而不只是个别工作项的偶发情况。
同一时段属于多类等待时的归类
一个工作项可能同时处于多种等待中，例如提交评审后又被上游依赖卡住。为避免重复计时，团队应在度量说明中约定归类优先级。常见做法是：阻塞优先于排队，因为阻塞意味着推进条件本身不满足；交接优先于评审排队，因为责任尚未落到评审人手中。优先级一旦确定，所有项目按同一顺序归类，保证汇总数据可比。
这些起止点依赖工作项状态和责任人字段的准确记录。在 ONES 中，工作项的状态流转与责任人变更会留下流转记录，团队可以据此还原每段等待的起止时间；ONES 研发效能管理解决方案对交付效率、进度情况等效能数据进行展示，形成量化、实施、分析、改进的闭环，用于定位薄弱环节。具体可用的指标与报表配置，以实际环境为准。
容易与等待时间混淆的相邻概念
等待时间常与几个相邻概念混用，划清边界才能保证度量结果可解释。
| 概念 | 与等待时间的关系 | 使用场景 |
|---|---|---|
| 周期时间（Lead Time） | 包含等待时间与处理时间，是两者之和 | 衡量工作项从进入到流出的整体速度 |
| 处理时间 | 与等待时间互补，指实际动手推进的时长 | 衡量投入与产出，评估工作量 |
| 阻塞时长 | 等待时间的子集，仅指依赖未就绪造成的部分 | 分析外部依赖对流动的影响 |
| 人员主观等待感受 | 属于开发者体验范畴，不作为度量口径 | 通过访谈或问卷了解协作体验 |
| 单项目进度偏差 | 属于项目进度管理，不纳入流动效率口径 | 排期调整与进度纠偏 |
周期时间与等待时间的关系最容易被误用：周期时间是一个包含项，等待时间是其中的组成部分，用周期时间直接代替等待时间会高估等待占比。阻塞时长同理，它只是六类等待中的一类，不能与等待时间整体等同。人员主观感受和单项目进度偏差各有其管理用途，但把它们混入流动效率口径，会让数据失去可比性，也无法指导流程改进。
一个完整例子：从提交评审到合并的等待拆解
下面用一个演示情景说明如何把一段连续流程拆成处理时间与各类等待时间。假设某工作项周一上午完成开发并提交评审，周五下午合并，总时长约四天半。
- 周一上午提交评审至周二下午首次意见返回：计入排队待评审，约一天半。这段时间工作项处于待评审状态，评审人尚未响应。
- 周二下午至周三上午修改：计入处理时间，约半天。责任人按意见实际修改。
- 周三上午提交复审至周四上午复审通过：计入评审后待修改与复审中的复审等待，约一天。复审人尚未给出结论。
- 周四上午至周四下午等待测试环境：计入环境与发布窗口等待，约半天。工作项已具备验证条件，环境尚未释放。
- 周四下午至周五下午合并前等待发布窗口：计入环境与发布窗口等待，约一天。审批闸门与上线窗口未开启。
按此拆解，总时长中处理时间约半天，其余约四天均为等待，且分布在评审、环境与发布窗口两类环节。这个结果指向的改进方向是评审响应节奏和环境窗口安排，而不是开发人员的编码速度。
拆解时常见的误解有三个：把全部日历时间都算作等待，忽略了其中的处理时间；把尚未交接、责任仍在原责任人手中的停顿算作交接等待，导致交接环节被高估；只记录阻塞发生而不记录原因分类，事后无法判断阻塞来自上游接口、第三方还是外部团队。避免这三点，拆解结果才能用于后续的瓶颈分析。
常见问题
等待时间和处理时间在同一个工作项上如何避免重复计算？
以工作项状态和责任人字段为准，把时间切成互不重叠的区间：责任人实际动手推进的时段计入处理时间，工作项停在待评审、待处理、待验证等可推进状态且无人推进的时段计入等待时间。同一时刻只归入一类，两者相加等于工作项从进入到流出的总时长。团队在度量说明中写清哪些状态算可推进，统计时按状态区间切分即可。
评审人只回复“已查看”或提出澄清问题，这段时间算评审等待吗？
“已查看”不构成有效评审意见，评审等待仍在继续，直到评审人给出通过、需修改并附具体意见、驳回并说明理由等可执行结论。评审人提出澄清问题、提交人补充材料这段往返，属于评审环节内部的响应时间，仍计入评审等待，因为它反映的是评审信息不完整带来的额外等待。若团队希望单独观察澄清往返，可在评审等待下再设一个子类，但不要与评审等待并列重复计时。
跨时区或节假日期间，等待时间按自然时间还是工作日计算？
两种方式都可以，关键是同一份报表内保持一致。按工作日历扣除非工作时间，适合评估团队真实响应节奏；按自然时间统计，适合观察工作项从进入到流出的整体日历跨度。跨时区团队还需约定以哪个时区的工作日历为准，并在度量说明中写明。若同一团队不同项目采用不同方式，汇总数据将失去可比性，因此建议在团队层面统一，而不是由各项目自行选择。
一个工作项同时处于评审排队和依赖阻塞中，应该归到哪一类？
需要在度量说明中预先约定归类优先级，常见做法是阻塞优先于排队，因为阻塞意味着推进条件本身不满足，即使评审人响应也无法推进；交接优先于评审排队，因为责任尚未落到评审人手中。优先级一旦确定，所有项目按同一顺序归类，保证汇总数据可比。若团队希望同时观察两类等待的影响，可以在主归类之外记录次要原因，但计时只计一次。
等待时间的数据从哪里来，需要人工逐条记录吗？
等待时间的起止依赖工作项状态流转和责任人变更的记录。在 ONES 中，工作项的状态流转与责任人变更会留下流转记录，团队可以据此还原每段等待的起止时间；ONES 研发效能管理解决方案对交付效率、进度情况等效能数据进行展示，形成量化、实施、分析、改进的闭环，用于定位薄弱环节。具体可用的指标与报表配置，以实际环境为准。若状态字段使用不规范，先统一状态定义和交接动作，再谈统计。
