衡量评审意见处理及时性，建议以单条评审意见为统计单元，建立一组围绕“从提出到被回应、被关闭或被明确驳回”的时间指标：意见响应时长、意见处理周期、超时意见占比、按严重级别分层的处理时长分布，并用重开率与返工率校验处理是否真正解决问题。计算前需固定时间戳、状态流转、工作日历和分母口径；解读时把关闭速度与重开、缺陷逃逸结合看，避免团队为压低时长而形式化关闭意见。
要点总览（TL;DR）
- 以单条评审意见为统计单元，用意见响应时长（首次回应−提出）和意见处理周期（关闭或驳回−提出）回答“多快”，两者都取中位数与P90。
- 用超时意见占比（超时意见数÷有效意见总数）和按严重级别分层的处理时长分布，描述有多少意见拖过约定阈值、慢尾集中在哪一层。
- 用重开率与返工率校验有效性：关闭后被重新打开、同一问题在后续评审中再次出现的比例，能识别形式化关闭。
- 计算前固定时间戳来源、状态流转（已解决、已驳回、重开分别计入）、工作日历与排除项；分母为零或样本过小时只呈现样本数，不下结论。
- 不设通用达标线，以团队自身历史数据形成观察基线；关闭速度要与重开率、缺陷逃逸组合解读，避免为压低时长而批量关闭。
评估目标：及时性要回答哪两个问题
评审意见处理及时性要回答两个问题：一是多快，即一条意见从提出到有人回应、再到被关闭或明确驳回用了多长时间；二是是否有效，即关闭动作是否真正消除了问题，还是只把状态改掉。两个问题必须一起看，单独回答任何一个都会失真。只统计速度，团队可能通过批量关闭、直接驳回把数字做漂亮；只统计关闭率，又无法区分一条意见是当天解决还是拖了两周才处理。
评估单元是单条评审意见，而非整个合并请求或评审轮次。一个合并请求里可能包含十几条意见，严重程度、涉及文件、需要改动的工作量各不相同，按合并请求统计会把简单意见和复杂意见混在一起，掩盖真实分布。以意见为单元，才能按级别分层、按评审人分层，也才能识别某类意见长期积压。
需要区分相邻主题的边界。评审等待时长关注的是“提交评审后多久有人开始看”，属于研发流动效率与瓶颈分析；代码优化关注改动本身的质量。本文聚焦意见提出之后的回应与处理过程，不展开评审排队、合并等待等流动效率指标，也不讨论具体代码改法。边界清楚，指标才不会被混算成一个大而全的“评审效率分”。
指标与范围：及时性指标组及统计口径
及时性无法用单一数字概括，建议用一组指标共同描述：两个时长指标回答“多快”，一个占比指标回答“有多少拖过了约定时间”，分布指标回答“慢的那部分慢到什么程度”，有效性指标回答“处理是否真的解决问题”。下表给出可直接复算的定义。
| 指标 | 定义与公式 | 分子 / 分母 | 单位与呈现 |
|---|---|---|---|
| 意见响应时长 | 首次回应时间 − 意见提出时间 | 逐条计算，汇总取中位数与P90 | 小时或工作日 |
| 意见处理周期 | 关闭或驳回时间 − 意见提出时间 | 逐条计算，汇总取中位数与P90 | 小时或工作日 |
| 超时意见占比 | 超时意见数 ÷ 有效意见总数 | 分子为处理周期超过团队约定阈值的意见数；分母为统计窗内有效意见数 | 百分比 |
| 分层处理时长 | 按严重级别（如阻断、重要、建议）分别计算处理周期的中位数与P90 | 各层内逐条计算 | 小时或工作日 |
| 重开率 | 关闭后被重新打开的意见数 ÷ 已关闭意见数 | 分母为统计窗内关闭的意见数 | 百分比 |
| 返工率 | 同一问题在后续提交或后续评审中再次出现的意见数 ÷ 已关闭意见数 | 分母同上，需定义“同一问题”的匹配规则 | 百分比 |
统计范围需要事先写清。时间窗可按周、按迭代或按季度，同一份报告内保持一致；意见来源区分人工评审意见与自动化检查意见，两类意见的处理动作差异大，混算会扭曲结果；排除项通常包括机器人评论、纯格式类意见和重复意见，排除规则要固定并记录，不能每次取数临时调整。超时阈值由团队根据自身评审节奏约定，例如阻断级意见一个工作日内处理、建议级意见三个工作日内处理，阈值写进口径文档，作为观察线使用。
数据口径与证据：时间戳、状态与缺失值怎么定
指标能否复算，取决于三类时间戳是否可靠：意见提出时间取意见创建记录的时间；首次回应时间取第一条人工回复或第一次状态变更的时间，机器人自动回复不计入；关闭或驳回时间取状态流转到终态的时间。三类时间戳应来自同一套评审记录，避免一部分手工补录、一部分系统生成，导致时长口径不一致。
状态流转要区分三种终态并分别计入。已解决表示意见被采纳并完成修改，计入处理周期；已驳回表示评审双方确认该意见不适用，同样计入处理周期，因为驳回也是一次明确处理，但不能与已解决混为一类，报告里应分列数量；重开表示关闭后问题再次出现，重开的意见回到处理中，其处理周期从重开时间重新起算，同时计入重开率。只统计已解决会高估效率，把驳回排除在外则会漏掉一类真实处理动作。
工作日历与跨时区规则需要统一。明确按自然日还是工作日计算，跨时区团队统一换算到同一时区基准，否则夜间和周末会把时长放大，同一团队在不同季节的数据也不可比。若团队约定按工作日计算，需固定节假日表，并在报告中注明。
缺失与异常数据的处理方式要单独规定：缺失时间戳的意见单独标记，不进入时长计算，但在报告中披露缺失条数；批量关闭的意见需核查关闭时间是否集中在极短区间，若属于集中清理，应单列说明；机器人评论和自动检查结果按来源过滤。分母为零时呈现“本期无有效意见”，不计算比率；样本量过小时同时给出样本数，并提示结论仅供参考。
这些状态与时间戳需要被稳定记录，指标才有取数基础。在 ONES 中，评审意见可以作为工作项承载，提出、回应、关闭、驳回、重开对应明确的状态流转，处理过程的时间记录随状态变更留存，度量时按意见逐条导出即可复算上述指标；意见的严重级别也可作为字段用于分层统计。工具承担的是记录与流转，阈值和口径仍由团队约定。
计算与评估步骤：从原始记录到可解读结果
从原始记录到可解读结果，可以按以下五步执行，每一步都有明确的产物。
- 整理意见粒度记录。按意见逐条导出字段：意见编号、所属合并请求、提出时间、首次回应时间、关闭或驳回时间、当前状态、严重级别、提出人与处理人。清洗异常值，标记缺失时间戳、批量关闭和机器人来源，形成一张可复算的明细表。
- 计算两个时长。逐条算出响应时长与处理周期，再按统计窗汇总中位数与P90。中位数反映典型情况，P90反映慢尾，两者一起看才能判断是整体偏慢还是少数意见拖尾。
- 分层统计。按严重级别分别计算处理时长的中位数与P90，必要时再按评审人或处理人分层，观察是否存在固定环节积压。分层后每层都要标注样本数。
- 计算占比与交叉分析。算出超时意见占比、重开率、返工率，并把处理时长短的意见与重开率交叉看：处理极快且重开偏高的组合，提示可能存在形式化关闭。
- 建立观察基线。用团队自身过去几个迭代或季度的数据形成基线，本期结果与基线对比，观察趋势变化。基线随团队节奏调整，不套用外部通用达标线。
完成标志是：明细表可被他人按同一口径复算，汇总结果包含样本数、中位数、P90和占比，且每个异常处理都有记录。达到这个状态，指标才具备讨论价值。
例子：一个迭代内的评审意见及时性测算
以下为演示情景，数据为虚构，仅用于说明计算过程，不代表任何真实团队。
某迭代内共记录有效评审意见40条，按严重级别分布为：阻断级4条、重要级12条、建议级24条。团队约定阻断级意见1个工作日内处理、重要级2个工作日、建议级3个工作日，按工作日计算。剔除机器人评论3条、重复意见2条后，进入统计的有效意见为40条。
响应时长方面，40条意见的首次回应时间中位数为4小时，P90为20小时；处理周期中位数为1.5个工作日，P90为4个工作日。分层看，阻断级4条的处理周期中位数为0.5个工作日、P90为1个工作日；重要级12条中位数为1.5个工作日、P90为3个工作日；建议级24条中位数为2个工作日、P90为5个工作日。慢尾主要集中在建议级。
超时意见共6条，其中建议级5条、重要级1条，超时占比为6 ÷ 40 = 15%。已关闭意见38条，其中关闭后被重开3条，重开率为3 ÷ 38 ≈ 7.9%；返工匹配到2条同一问题再次出现，返工率为2 ÷ 38 ≈ 5.3%。
从这组结果可以读出的信号是：阻断级意见处理及时，建议级存在慢尾，超时主要来自低级别意见；重开率接近8%，说明部分关闭动作之后问题又出现，需要抽查这几条意见的关闭理由。不能直接下的结论是：不能因为整体中位数1.5个工作日就判断评审质量好，也不能因为超时占比15%就认定团队执行力差——样本只有一个迭代，且建议级意见本身处理优先级较低，需要连续几个迭代对比基线后再判断趋势。
解读与限制：为什么不能只看关闭率
关闭率高、处理时长短，未必说明处理及时有效。批量关闭、集中驳回都会让时长骤降，数字好看但问题仍在。校验方法是把关闭速度与重开率、返工率、后续缺陷逃逸数据放在一起看：若某段时间处理时长明显下降而重开率同步上升，或关闭后同类问题在后续评审中反复出现，就应抽查关闭记录，确认关闭理由是否成立。驳回意见也应单独统计数量与理由分布，避免把“驳回”当成快速清空待办的手段。
单指标不能代表评审质量或团队绩效。响应时长短可能因为意见本身简单，处理周期长可能因为改动复杂，这些差异需要按级别和意见类型分层后才能比较。把及时性指标直接用于个人考核，容易诱导挑简单意见先处理、把复杂意见往后拖，反而拉长真正的解决周期。
样本量小和意见类型差异会带来不可比问题。一个迭代只有几条意见时，中位数和P90波动很大，应呈现样本数并避免下结论；不同团队的意见构成不同，前端团队与基础架构团队的建议级意见占比差异大，跨团队横向排名意义有限，更适合各自与自身历史基线对比。
建议把及时性指标与有效性证据组合使用：时长指标描述过程，重开率、返工率和缺陷逃逸描述结果，两者结合才能回答“处理得又快又好”还是“只是快”。指标用于发现问题和改进流程，作为观察工具而非绩效裁决依据，结论才站得住。
常见问题
团队刚开始度量，意见量很少，这些指标还能用吗？
可以用，但要调整呈现方式。意见条数少时，中位数和P90波动很大，一条意见的差异就能让P90翻倍。建议在报告中同时给出样本数，把统计窗从单个迭代拉长到季度，并只做趋势观察，不据此下结论或排名。等积累了几个统计窗的数据，再形成基线做对比。
驳回的意见算不算“已处理”？会不会拉低及时性数字？
驳回是一次明确的处理动作，应计入处理周期，但需要与“已解决”分列统计。如果把驳回排除在外，会漏掉一类真实处理；如果混在一起，又看不出团队是在解决问题还是在快速清空待办。建议在报告中分别给出已解决数量、驳回数量及驳回理由分布，再结合重开率判断驳回是否合理。
跨时区团队按自然日算还是工作日算？
两种都可以，关键是全团队统一并写进口径文档。按工作日计算更贴近实际处理节奏，但需要固定节假日表；按自然日计算更简单，但夜间和周末会把时长放大。跨时区团队还应统一换算到同一时区基准，否则同一团队在不同季节的数据也不可比。口径一旦确定，同一份报告内不要中途更换。
处理时长很短但重开率偏高，应该怎么排查？
这种组合提示可能存在形式化关闭。可以先抽查重开意见的关闭记录，看关闭理由是否具体、是否附有修改说明；再看关闭时间是否集中在某个短区间，判断是否存在批量操作。排查后如果确认是流程问题，应调整关闭动作的要求（例如必须填写处理说明），而不是直接收紧时长阈值。
这些指标能不能直接用于个人绩效考核？
不建议直接用于个人考核。响应时长短可能因为意见本身简单，处理周期长可能因为改动复杂，按个人比较会诱导挑简单意见先处理、把复杂意见往后拖。更合适的做法是把指标用于团队层面的流程观察，发现积压环节后改进协作方式；个人层面可以看意见处理说明的完整度等过程证据，与时长指标分开使用。
