缺陷修复逾期时，先别急着催开发。更有效的做法是先统一“逾期”的计算口径，确认是单条缺陷、某个模块还是整体积压，再区分修复逾期与验证逾期。本文按症状界定、原因排查、分类型处置、恢复验证四步展开，帮助你把逾期清单变成可执行的处置路径。
要点总览（TL;DR）
- 先统一逾期口径：按承诺修复日期、SLA时限还是迭代结束日计算，并把修复逾期与验证逾期分开统计，避免不同问题混在一起。
- 用证据核对五类常见原因：排期被挤占、阻塞未解除、责任与交接不清、验证回流、描述不清导致返工，按影响面从大到小逐项排除。
- 处置顺序是先锁定高严重级别逾期缺陷，再重排优先级、解除阻塞、明确责任人与检查点，批量积压按模块分批处理。
- 关闭或降级缺陷须有确认人和回退条件；处置后用状态流转和逾期数量回落验证效果。
- 把承诺修复日期、责任人、阻塞原因设为必填字段，并按严重级别设置逾期预警与升级条件，减少同类逾期复发。
缺陷修复逾期的症状与范围界定
“逾期”在不同团队里可能指三件不同的事：超过承诺修复日期、超过SLA约定时限、超过迭代结束日仍未关闭。三种口径算出的逾期数量和责任归属差别很大，混在一起讨论容易把排期问题和响应问题搅成一团。处置前先选定一种主口径，并在清单中注明每条缺陷采用的是哪一种。
口径确定后，再界定范围。单条缺陷逾期通常是个案，重点查阻塞和交接；某模块集中逾期往往指向该模块的依赖环境、人员集中度或需求变更频率；整体积压则更可能是排期被挤占或验证环节回流严重。范围判断决定了后续处置是逐条跟进还是批量重排。
还要把修复逾期与验证逾期分开统计。修复逾期指开发未在承诺时间内提交修复；验证逾期指修复已提交但测试未在约定时间内完成验证，或验证不通过被重新打开。两类逾期的责任人和处置动作不同，合并统计会掩盖真问题。
建议输出一份逾期缺陷清单，至少包含以下字段：
| 字段 | 用途 |
|---|---|
| 缺陷编号与标题 | 唯一标识，便于逐条跟踪 |
| 严重级别 | 判断处置优先级 |
| 所属模块 | 识别集中逾期区域 |
| 逾期口径与逾期天数 | 区分承诺日期、SLA、迭代结束日 |
| 当前状态 | 区分修复中、待验证、验证不通过 |
| 责任人 | 明确跟进对象 |
清单完成后，记录逾期总数、平均逾期天数、涉及模块分布和严重级别分布。这四个数字构成基线，后续处置是否生效，用同一口径对比即可判断，不需要另建一套指标。
逾期原因假设与排除证据
逾期原因常见的有五类：排期被高优先级需求挤占、阻塞未解除、责任与交接不清、验证回流、需求或缺陷描述不清导致返工。把它们当作假设逐项核对证据，比凭印象下结论更可靠。下面这张对照表可以直接用于排查。
| 原因假设 | 核对证据 | 排除标准 |
|---|---|---|
| 排期被挤占 | 迭代排期记录、人员投入变化、同期插入的高优先级需求 | 该缺陷在排期内有连续可用的开发时间，且未被临时任务打断 |
| 阻塞未解除 | 依赖环境状态、第三方接口可用性、复现条件是否具备 | 阻塞项在承诺日期前已解除，或阻塞不影响修复本身 |
| 责任与交接不清 | 缺陷指派记录、转派次数、首次响应时长 | 责任人明确且响应及时，逾期发生在修复执行阶段 |
| 验证回流 | 重新打开次数、每次验证不通过的原因 | 修复一次通过验证，逾期发生在修复提交之前 |
| 描述不清导致返工 | 缺陷描述完整度、补充信息次数、返工记录 | 描述要素齐全，修复过程中无需反复确认 |
核对时注意一条缺陷可能同时命中多个假设。例如某模块集中逾期，既可能是排期被挤占，也可能是该模块依赖的测试环境长期不可用。此时按影响面排序，先处理能解释最多逾期条目的原因，再逐条核对剩余个案。
证据要能落到具体记录上。排期挤占看的是排期变更和人员投入记录，不是“大家都很忙”的感受；阻塞看的是依赖项的当前状态和解除时间，不是口头说明；交接不清看的是指派和转派记录，不是谁记得更清楚。每条假设给出结论时，注明依据的是哪条记录，方便后续复盘时复核。
排查顺序建议从范围最大的假设开始：整体积压先查排期与投入，模块集中先查阻塞与环境，个案逾期先查交接与描述质量。这样能用最少的核对覆盖最多的逾期条目，避免逐条问一遍却得不到共性结论。
按逾期类型安排处置步骤
原因确认后，处置顺序遵循一条原则：先控制影响面，再恢复节奏，最后处理存量。高严重级别的逾期缺陷优先，因为它们影响用户或核心流程，拖延的代价高于其他缺陷。处置动作按以下顺序推进：
- 锁定高严重级别逾期缺陷。逐条确认当前阻塞点和责任人，给出明确的下一步动作和时间点。涉及线上影响的，先确认是否有临时规避方案，再安排正式修复。
- 重排优先级。与需求方逐项确认哪些缺陷可以延后，延后决定要记录变更原因和新时间点，避免同一批缺陷反复出现在逾期清单里。重排结果同步给开发和测试，确保双方对新的承诺日期有共识。
- 解除阻塞。每条阻塞项指定依赖责任人和解除时间点，环境问题找环境负责人，第三方接口问题找对接方，复现条件缺失则安排补充信息。阻塞解除前，该缺陷不进入修复排期，避免占用开发时间却无法推进。
- 明确责任人与截止时间，设置中间检查点。对逾期缺陷设置比常规缺陷更密的检查点，例如每两天确认一次进展。检查点只看状态是否推进，不要求每次都有完整结论。
- 批量积压按模块分批处置。整体积压时，一次性全量重排会让排期失去可信度。按模块或按严重级别分批，每批处理完再启动下一批，用前一批的实际完成情况校准后续排期。
涉及关闭或降级的操作要格外谨慎。关闭一条逾期缺陷前，确认人应为缺陷提出方或测试负责人，并记录关闭理由；降级严重级别需要说明依据，例如影响范围缩小或已有替代方案。同时约定回退条件：若后续复现或影响扩大，按原级别重新打开，不因降级记录而降低处理优先级。
处置过程中，缺陷状态的流转本身就是进度信号。修复提交、待验证、验证通过、关闭，每个状态变化都对应一个责任人和一个时间点。把这些状态变化记录在缺陷跟踪流程里，处置清单就不需要靠人工同步维护，逾期条目是否在减少可以直接从状态分布看出来。ONES 的缺陷管理工作项支持自定义状态流转、责任人与承诺修复日期等字段，并可按条件筛选逾期缺陷，适合承载上述处置动作；具体字段配置需按团队现有流程设定。
恢复验证与逾期复发预防
处置是否生效，用两个信号判断：逾期缺陷的状态是否按预期推进，逾期数量是否回落到基线以下。验证时沿用S1确定的口径，对比处置前后的逾期总数、平均逾期天数和严重级别分布。状态长期停留在“修复中”或“待验证”的缺陷，说明处置动作没有真正落地，需要回到S3重新确认阻塞点和责任人。
恢复确认后，把触发条件固化为跟踪规则，减少同类逾期再次发生：
- 设置逾期预警阈值与提醒时点。例如距承诺修复日期还剩一天时提醒责任人，超过承诺日期当天提醒责任人和其上级。阈值按缺陷严重级别区分，高严重级别提前量更大。
- 固化必填字段。在缺陷跟踪中要求填写承诺修复日期、责任人、阻塞原因三项。缺少任一项的缺陷不进入修复排期，从源头减少“不知道谁负责、不知道什么时候修”的情况。
- 定期复盘逾期原因分布。按S2的假设分类统计一段时间内的逾期原因，识别反复出现的环节。若某类原因持续占比最高，说明问题出在流程而非个别缺陷，需要调整排期规则或交接方式。
- 明确升级条件。高严重级别缺陷逾期超过约定时限、同一模块连续出现多条逾期、阻塞项超过约定时间未解除，这三种情况触发升级，由更高层级协调资源，避免在原有层面反复沟通。
预警规则和必填字段落地后，逾期清单会从“事后统计”变成“事前提醒”。团队每周用同一口径复核一次逾期数量和原因分布，处置动作和预防规则就能形成闭环：新出现的逾期按S2排查原因，按S3处置，再回到本节验证效果。
常见问题
承诺修复日期和迭代结束日两种逾期口径，应该选哪一种作为主口径？
两种口径回答的问题不同：承诺修复日期衡量的是对具体缺陷的响应兑现，迭代结束日衡量的是整体交付节奏。建议以承诺修复日期作为主口径，因为它能落到单条缺陷和具体责任人，便于逐条跟进；迭代结束日作为辅助口径，用于观察整体积压趋势。选定后在逾期清单中注明每条缺陷采用的口径，后续对比处置效果时沿用同一口径，避免数字忽高忽低。
一条缺陷同时命中多个逾期原因时，先处理哪一个？
按影响面排序，先处理能解释最多逾期条目的原因。整体积压优先查排期与人员投入，某模块集中逾期优先查依赖环境与阻塞，个案逾期优先查交接记录和描述质量。一条缺陷同时命中多个假设时，先解决共性原因，剩余个案再逐条核对。每条结论注明依据的具体记录，便于复盘时复核。
批量积压时一次性全量重排排期，会有什么问题？
全量重排会让新排期缺少实际完成情况支撑，容易再次整体逾期，排期的可信度也随之下降。更稳妥的做法是按模块或严重级别分批处置，每批完成后用实际用时校准下一批的排期。分批期间，未进入当前批次的缺陷保持原状态并注明计划启动时间，避免被误认为已被遗忘。
关闭或降级一条逾期缺陷，需要留下哪些记录？
关闭前确认人应为缺陷提出方或测试负责人，并记录关闭理由，例如已由其他方式规避、影响范围已消除。降级需要说明依据，例如影响范围缩小或已有替代方案。同时约定回退条件：后续复现或影响扩大时按原级别重新打开，处理优先级不因降级记录而降低。这些记录留在缺陷跟踪流程中，后续复盘时可以直接查证。
逾期预警设置后仍然频繁触发，应该调整阈值还是改流程？
先看触发原因分布。若逾期集中在少数模块或少数责任人，问题更可能出在排期与资源分配，调整阈值只会掩盖问题；若逾期分散且多为临近截止才暴露，说明预警提前量不足，可以按严重级别加大提前量。定期按原因分类统计逾期条目，某类原因持续占比最高时，优先调整对应的排期规则或交接方式，再考虑阈值微调。
