评审等待时间统计的关键，是先确定“进入待评审”和“评审实际开始”这两个时间点，再决定按工作项还是按评审轮次汇总。本文给出一套可复算的口径：定义起止事件与分母、说明状态记录和评审记录的取数方式、处理退回重审与缺失值，并用数值示例演示计算过程，最后说明结果在瓶颈定位中的解释边界。
要点总览（TL;DR）
- 评审等待时间的起止事件定义为：工作项进入“待评审”状态的时间点，到评审实际开始或评审结论产生的时间点；两个端点需来自同一条可追溯的状态流转记录。
- 统计粒度分工作项与评审轮次两种：工作项粒度合并多轮等待，分母为进入过待评审的工作项数；轮次粒度每轮单独成条，分母为评审轮次数。
- 退回重审按新的评审轮次重新计时，不并入首轮；缺失起止时间的样本单独标记并按固定规则剔除，补录数据与系统时间戳样本分开统计。
- 汇总优先报告中位数与75、90分位数，均值作辅助；分母为零的周期标注“无样本”而非记为0，结果用于定位流动瓶颈，不设通用达标线、不作绩效结论。
评估目标：评审等待时间要回答什么问题
评审等待时间服务于一个具体的流动问题：工作项在等待评审这件事上消耗了多少时间，这些时间集中在哪些环节、哪些类型的评审上。它回答的是“流动在哪里停住了”，为后续排查评审资源安排、评审触发机制、工作项提交质量提供线索。
这个指标与相邻指标分工明确。评审时长衡量评审开始到结论产生之间的实际评审工作量，反映评审本身的投入；评审通过率衡量评审结论的分布，反映提交质量与评审严格程度；评审等待时间只覆盖“已提交、尚未被处理”的区间。三者组合使用，才能区分“评审排不上”“评审做得慢”“反复返工”三类不同问题。
需要提前划定的边界是：本文不评估人员的主观协作体验，也不用于单个项目的进度纠偏。等待时长偏长可能来自评审人负荷、提交时机、批次集中提交等多种原因，指标本身只提示位置，不给出归因结论。
指标与范围：起止事件、统计对象与时间窗
评审等待时间定义为：工作项进入“待评审”状态的时间点，到评审实际开始（或评审结论产生）的时间点之间的时长。两个端点必须来自同一条可追溯的状态流转记录，避免用人工填写的日期替代系统时间戳。选择“评审开始”还是“结论产生”作为终点，取决于团队能否稳定记录评审启动动作；若只能记录结论，则终点取结论产生时间，此时指标实际覆盖了等待加评审的合并区间，需在口径说明中写明。
统计对象有两种粒度，分母不同，结论含义也不同：
| 粒度 | 一条样本 | 分母 | 适用判断 |
|---|---|---|---|
| 工作项 | 一个工作项的全部等待时长（多轮合并） | 时间窗内进入过待评审的工作项数 | 看整体流动中等待占比，适合与周期时间对比 |
| 评审轮次 | 一次进入待评审到该轮评审开始或结论产生 | 时间窗内发生的评审轮次数 | 看单次评审响应速度，适合定位评审触发与排期问题 |
时间窗按工作项进入待评审的时间归属，而不是按结论时间归属，这样同一批提交的工作项不会被拆到两个统计周期。纳入规则为：时间窗内进入过待评审、且起止时间均可追溯的工作项或轮次。排除规则需明确写出，常见的有：测试性工作项、被取消且未实际评审的工作项、起止时间缺失且无法补录的样本。单位统一用小时或工作日，全篇保持一致，跨时区团队建议用绝对时间戳计算后再换算。
数据口径与证据：状态记录、评审记录与缺失处理
取数来源主要有两类：工作项状态流转记录，提供每次状态变更的时间戳、变更前后状态和操作人；评审记录，提供评审轮次、评审人、评审启动与结论时间。两类记录需要能通过工作项标识关联。若团队在代码托管平台或评审工具中完成评审，还需确认该侧记录能否回写到工作项，否则会出现“系统里没有评审开始时间”的情况。
状态跳变和多次进入待评审是最容易出错的地方。识别方法是按工作项分组、按时间排序状态变更，找出每一次“进入待评审”的事件，并检查其后是否紧跟“评审中”或“已评审”状态。若工作项从待评审直接跳到已完成，说明评审动作未被记录，该样本应标记为口径异常而非直接计入。同一工作项多次进入待评审，按轮次粒度统计时每轮单独成条；按工作项粒度统计时合并为总等待时长，同时保留轮次数作为辅助字段，便于识别返工密集的工作项。
缺失值的处理规则建议固定为三条：起点缺失的样本剔除并记录数量；终点缺失但工作项仍处于待评审的样本不计入本期，留待下期；补录数据需标注补录来源和补录人，与系统时间戳样本分开统计，避免补录口径污染整体分布。所有原始记录保留导出快照，抽样复核时能回到具体工作项和具体时间点。
计算与评估步骤：从原始记录到可解读结果
计算按以下步骤执行，每一步都产出可检查的中间结果：
- 提取时间窗内所有进入过待评审的工作项，形成样本清单，记录纳入与剔除数量。
- 对每个样本按时间排序状态变更，定位每次进入待评审的起点，以及对应的评审开始或结论时间。
- 逐条计算区间时长，单位为小时；跨天、跨周末的区间按实际经过时间计算，不做工作日折算，除非团队统一约定折算规则并写入口径说明。
- 按选定粒度汇总：轮次粒度直接对每条区间求均值、中位数和分位数；工作项粒度先合并同一工作项的多个区间，再汇总。
- 计算分母并单独报告：样本数、剔除数、无样本周期数。
- 抽样复核：随机抽取若干样本，回到原始状态记录核对起止时间，检查是否存在漏识别轮次或终点错配。
汇总方式上，优先报告中位数和75分位、90分位数，均值作为辅助。等待时长通常呈右偏分布，少数长时间挂起的工作项会显著拉高均值，中位数更能代表典型体验，高分位数则暴露长尾问题。分母为零的周期（时间窗内没有评审样本）应标注为“无样本”，不能记为0，否则会人为压低趋势线。口径一致性校验可在每次统计时用同一批样本重跑一遍，确认结果可复现。
例子：一个工作项与一组工作项的算法演示
以下为演示情景，数值为构造数据，用于说明算法而非真实团队表现。
单个工作项A：3月1日10:00进入待评审，3月1日15:00评审开始，首轮等待5小时；评审后于3月2日9:00被退回，同日9:00重新进入待评审，3月2日14:00第二轮评审开始，第二轮等待5小时。按轮次粒度，A贡献两条样本，各5小时；按工作项粒度，A的总等待为10小时，轮次数为2。若把退回后的等待并入首轮，会得到一条10小时的样本，掩盖了两次独立的评审响应过程。
一组工作项：假设时间窗内有5个工作项，按轮次粒度共7条样本，等待时长分别为4、6、8、10、12、20、48小时。均值约为15.4小时，中位数为10小时，75分位约为16小时，90分位接近48小时。均值明显高于中位数，说明存在长尾样本；此时用中位数描述典型等待、用高分位数描述最差情况，比单看均值更稳妥。
分母为零与缺失样本：若某周没有任何工作项进入待评审，该周等待时间记为“无样本”，趋势图中留空。若工作项B的终点时间缺失且仍处于待评审，B不计入本期分母，在数据质量栏记录1条未完成样本。若工作项C的起点为补录数据，C单独统计并标注，不与系统时间戳样本混合计算分位数。
解读与限制：结果能说明什么、不能说明什么
评审等待时间能说明等待发生在哪些评审类型、哪些工作项类型、哪些时间段，从而提示评审资源是否与提交节奏匹配。它不能直接说明等待的原因，更不能作为人员绩效结论。设计评审与缺陷修复评审的等待时长通常不可直接比较，不同工作项类型（需求、缺陷、技术任务）的评审复杂度不同，横向对比前应先分层。
使用时有几点需要注意：不设通用达标线，不同团队、不同评审类型的合理等待区间差异很大，达标线应由团队基于自身历史分布确定；单指标不进入绩效考核，否则容易诱发提前改状态、拆分工作项等规避行为；等待时长与开发者体验、项目进度属于不同问题，前者关注流动结构，后者关注个体感受与交付节点，应分开分析。
当团队在ONES中管理工作项时，状态流转和评审记录会随日常操作留存，ONES Performance 可自动收录系统内流转的研发数据并形成分析指标，支持多维度、精细化的自定义分析，也提供场景化卡片模板和仪表盘共享。团队可以据此按上述口径提取待评审区间、按轮次或工作项汇总，并把结果与评审时长、通过率放在同一视图中对照，用于定位流动瓶颈；具体指标字段与模板配置仍需以团队实际使用的系统记录为准。
常见问题
评审等待时间按工作项统计和按评审轮次统计，结果差异会很大吗？
差异通常明显，尤其在返工较多的工作项上。按工作项统计时，同一工作项多次进入待评审的等待时长会合并为一条样本，分母是工作项数；按评审轮次统计时，每轮单独成条，分母是评审轮次数。一个被退回两次的工作项，在工作项粒度下只贡献一条较长的样本，在轮次粒度下贡献三条样本。
选择哪种粒度取决于要回答的问题：看整体流动中等待占多大比重，用工作项粒度；看单次评审的响应速度、定位评审排期问题，用轮次粒度。两种粒度可以同时报告，但需在口径说明中写清分母，避免跨期比较时混用。
评审在代码托管平台完成，工作项里没有评审开始时间，还能统计吗？
可以统计，但需要先确认两侧记录能否通过工作项标识关联。若评审工具侧记录了评审启动与结论时间，可将其回写到工作项或按标识关联后取数；若只能取到结论时间，则终点取结论产生时间，此时指标实际覆盖等待加评审的合并区间，应在口径说明中明确写出，不能与仅含等待区间的数据直接比较。
两侧都无法提供可追溯时间戳时，该样本应标记为口径异常并剔除，同时记录剔除数量，避免用人工填写的日期替代系统时间戳。
某个统计周期内没有任何工作项进入待评审，趋势图上应该怎么处理？
该周期应标注为“无样本”，趋势图中留空，不能记为0。记为0会人为压低趋势线，让后续周期的上升看起来像突然恶化，干扰对流动变化的判断。
同时建议在数据质量栏记录无样本周期数，与剔除样本数分开呈现。连续多个周期无样本时，应先检查取数范围和时间窗设置是否正确，再判断是否属于评审活动本身减少。
评审等待时间偏长，能直接说明是评审人不够吗？
不能直接归因。等待时长只提示流动在哪个环节停住，可能的原因包括评审人负荷、提交时机集中、工作项提交质量不足导致反复退回、评审触发机制不清晰等。要区分这些原因，需要把等待时长与评审时长、评审通过率放在同一视图中对照：等待长而评审时长短，更接近排期与响应问题；等待与退回次数同时偏高，更接近提交质量问题。
归因结论应结合具体工作项和评审类型的抽样复核得出，指标本身不提供原因判断。
不同评审类型（如设计评审与缺陷修复评审）的等待时长可以直接横向比较吗？
不宜直接比较。不同评审类型的参与人数、评审深度和触发频率不同，等待时长的合理区间本身就有差异。横向对比前应先按评审类型和工作项类型分层，在同类样本内部比较，再观察各层的变化趋势。
跨团队比较同样需要谨慎：各团队的提交节奏、评审约定和历史分布不同，达标线应由团队基于自身历史分布确定，不宜套用统一数值。
