缺陷延期处理的关键，是把“先放一放”变成一次有记录的流程决策：缺陷负责人提交延期申请，写清新目标版本或日期、影响范围、临时规避措施和风险接受人，经评审角色确认后更新状态与字段，并在到期前设置复查点。本文按步骤、原因分类、角色分工、记录字段、复查机制和检查清单展开，适用于希望建立或规范缺陷延期规则的研发团队。
要点总览（TL;DR）
- 缺陷延期处理是一次有记录的流程决策：判断是否构成延期、提交申请、评审确认、更新状态、设置复查点，五步缺一不可。
- 延期原因至少分为排期冲突、依赖未就绪、信息不足三类，不同原因对应不同的审批要求与复查周期。
- 延期记录必须写清原因分类、新目标版本或日期、影响范围、临时规避措施、风险接受人和复查安排，缺少风险接受人或复查点的延期视为未完成。
- 延期生效后要在新目标日期前复查，复查结论只有按计划修复、继续延期、关闭三种；继续延期需重新评审，多次延期应升级处理。
- 按季度或按版本回顾延期数量、原因分布和超期未复查比例，可反映排期与依赖管理的薄弱环节。
缺陷延期处理的核心步骤
延期处理要解决的是“这个缺陷本轮不修，但必须有明确交代”。触发条件通常有三类：当前版本排期已满、修复依赖的外部条件尚未就绪、缺陷信息不足暂时无法定位。满足任一条件时，缺陷负责人应发起延期申请，而不是自行把状态改为挂起或口头告知测试。
整个流程可以拆成五步，每一步都要有明确输入、动作、输出和完成标志，便于团队照着执行，也便于事后核对。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 判断是否构成延期 | 缺陷当前状态、所属版本排期、依赖情况 | 对照触发条件，确认本轮无法按原计划修复 | 延期意向与初步原因 | 负责人明确“本轮不修”并说明原因类别 |
| 2. 提交延期申请 | 缺陷记录、影响范围评估、临时规避方案 | 填写延期字段：原因、新目标版本或日期、影响范围、规避措施、风险接受人 | 一条完整的延期申请记录 | 必填字段齐全，风险接受人已指定 |
| 3. 评审确认 | 延期申请、缺陷严重程度、版本计划 | 由缺陷评审角色（如测试负责人、版本负责人）确认理由是否成立、目标是否合理 | 评审结论：同意、调整后同意或驳回 | 评审意见记录在缺陷上，结论明确 |
| 4. 更新状态与字段 | 评审结论 | 将缺陷状态改为“延期”，写入新目标版本或日期、延期原因分类 | 状态与字段更新后的缺陷记录 | 状态、目标版本、原因字段与实际结论一致 |
| 5. 设置复查点 | 新目标日期、版本节奏 | 在目标日期前设定复查时间，指定复查人 | 复查任务或复查提醒 | 复查时点、复查人已记录，到期可被触发 |
关闭条件同样要提前写清：缺陷在新目标版本中修复并验证通过，或经评审确认该缺陷不再需要修复（例如场景已下线），才可关闭延期状态。仅把日期往后推、不设复查点的处理，等于让缺陷无限期挂起。
延期原因分类与处置规则
不同原因对应不同的审批要求和处置动作。把所有延期走同一套宽松流程，会让真正需要关注的缺陷被稀释。建议至少区分以下三类，并在缺陷字段中固定为可选值。
| 原因类别 | 典型情形 | 处置动作 | 审批要求 |
|---|---|---|---|
| 排期与资源冲突 | 当前版本工作量已满、修复人力被更高优先级任务占用 | 明确新目标版本，评估是否需要在版本计划中预留修复窗口 | 版本负责人确认排期，风险接受人记录在案 |
| 外部依赖未就绪 | 依赖的第三方接口、上游模块或环境尚未提供 | 记录依赖对象与预计就绪时间，约定依赖就绪后的复查节点 | 缺陷负责人与依赖方共同确认时间，评审角色核对依赖真实性 |
| 信息不足或复现困难 | 缺少复现步骤、日志不全、环境差异导致无法定位 | 补充信息收集任务，设定信息补齐的截止时间，而非直接延后修复 | 测试角色确认信息缺口，评审角色同意先补信息再定修复计划 |
审批差异体现在两点：排期冲突类延期重点核对目标版本是否真实可容纳；依赖类延期重点核对依赖时间是否有依据；信息不足类延期则应设置较短的复查周期，避免以“还在排查”为由长期挂起。严重程度高的缺陷，无论哪类原因，都应由更高一级的评审角色确认。
角色分工与交付物
延期处理涉及四个角色，职责边界要清楚，避免出现“谁都同意、没人负责”的情况。
| 角色 | 职责边界 | 在延期流程中的交付物 |
|---|---|---|
| 缺陷负责人 | 对缺陷的修复计划负责，提出延期申请并保证信息完整 | 延期申请记录：原因、新目标、影响范围、临时规避措施 |
| 评审角色（测试负责人或版本负责人） | 判断延期理由是否成立、目标是否合理，不代替负责人做修复决策 | 评审结论与意见，记录在缺陷上 |
| 风险接受人 | 对延期带来的业务或质量风险明确表示接受，通常是产品负责人或版本负责人 | 风险接受记录：接受人、接受时间、接受的风险描述 |
| 测试角色 | 确认缺陷信息是否充分、影响范围评估是否合理，跟踪复查 | 信息补充意见、复查结论 |
风险接受不能只靠口头同意。推荐在缺陷记录中增加“风险接受人”字段，并要求接受人在评审意见中写明接受的具体风险，例如“该缺陷仅影响低版本浏览器的导出功能，接受延至下个版本修复”。这样在复查或版本回顾时，可以追溯到是谁、在什么依据下接受了风险。
当团队使用 ONES 承载缺陷管理时，上述动作可以落在同一条工作项上：延期申请体现为字段填写，评审结论体现为评论或审批记录，状态变更与复查时间体现为工作项状态和到期提醒，减少申请、评审、跟踪分散在多个工具里的情况。
延期记录字段与示例
延期记录的价值在于让后来的人不用问当事人就能看懂。字段分为必填和选填两类，必填项缺失时不应允许状态变更为“延期”。
| 字段 | 必填/选填 | 填写口径 |
|---|---|---|
| 延期原因分类 | 必填 | 从排期冲突、依赖未就绪、信息不足三类中选择，不写自由文本代替分类 |
| 新目标版本或日期 | 必填 | 写到具体版本号或日期，不写“后续版本”“尽快” |
| 影响范围 | 必填 | 说明受影响的用户、功能或环境，以及是否已有临时规避方式 |
| 临时规避措施 | 必填 | 无规避时写明“无”，并说明用户可能遇到的现象 |
| 风险接受人 | 必填 | 填写具体人员，附接受的风险描述 |
| 复查时间与复查人 | 必填 | 早于新目标日期，复查人应为能推动后续动作的人 |
| 关联依赖或补充信息任务 | 选填 | 依赖类延期填写依赖对象，信息不足类填写信息补齐任务 |
以下是一个填写示例（演示情景）：某导出功能在特定浏览器下报错，当前版本排期已满。延期原因填“排期与资源冲突”；新目标版本填“V2.4”；影响范围填“仅影响使用旧版浏览器的用户导出报表，其他浏览器正常”；临时规避措施填“在帮助文档中提示用户升级浏览器”；风险接受人填产品负责人，并注明接受该范围；复查时间设在新版本开发启动前一周，复查人填缺陷负责人。
延期后的跟踪与复查机制
延期生效只是开始，复查机制决定缺陷会不会被遗忘。复查时点建议设在新目标日期之前，并与版本节奏对齐：按版本延期的，在下一个版本规划会前复查；按日期延期的，提前至少一周复查。
复查时要核对四项信息：缺陷当前是否仍可复现、原定的依赖或信息是否已就绪、新目标版本是否仍在计划内、临时规避措施是否仍然有效。核对完成后，复查人给出三种结论之一：按计划修复、继续延期、关闭。
继续延期的判断条件是原延期依据发生变化且新依据可核实，例如依赖方再次推迟并给出新时间。继续延期需要重新走一次评审，不能由负责人自行改日期。关闭的判断条件是缺陷已修复并验证通过，或经评审确认缺陷对应的场景已不存在。对于多次延期的缺陷，应升级到更高一级评审角色处理。
除单条缺陷的复查外，建议按季度或按版本回顾延期数据：延期缺陷的数量、原因分布、平均延期次数、超期未复查的比例。这些数据能反映排期是否过紧、依赖管理是否薄弱，为下一轮计划提供依据。
完成检查清单
以下清单用于判断一次延期处理是否合规完成，可逐项核对，存在阻断项时不应视为完成。
- 申请完整性：延期原因已归入固定分类；新目标版本或日期具体可核对；影响范围与临时规避措施已填写。
- 审批完整性：评审角色已给出明确结论；风险接受人已指定并记录接受的风险描述；高严重程度缺陷已由相应层级确认。
- 记录完整性：状态已更新为“延期”；原因、目标、风险接受人等字段与评审结论一致；评审意见可在缺陷记录中追溯。
- 复查安排：复查时间早于新目标日期；复查人已指定；复查任务或提醒已创建。
- 阻断项：缺少风险接受人、新目标只写“后续版本”、未设复查点，任一项存在即视为未完成。
- 完成条件：以上各项均满足，且复查机制已生效，本次延期处理才算闭环。
常见问题
缺陷延期和把缺陷状态改成挂起有什么区别？
挂起通常表示当前无法推进，缺陷仍留在待处理范围里；延期是一次有结论的流程决策，需要写清新目标版本或日期、影响范围、临时规避措施和风险接受人，并经过评审确认。两者的关键差别在于延期有明确的责任人和复查时点，到期会被重新拉回处理队列，而挂起状态如果没有配套的复查安排，容易让缺陷长期无人跟进。
严重程度高的缺陷能不能走简化流程直接延期？
不建议简化。严重程度高的缺陷影响面更大，延期时应由更高一级的评审角色确认，风险接受人也应记录具体的风险描述，而不是只写“同意延期”。简化流程可以体现在减少评审参与人数或缩短评审周期上，但原因分类、新目标、影响范围、风险接受人和复查安排这些必填信息不能省略。
依赖外部条件未就绪导致的延期，复查时应该看什么？
复查时重点核对依赖对象是否按原定时间就绪、依赖方给出的新时间是否有依据、原定的临时规避措施是否仍然有效。如果依赖方再次推迟，需要拿到新的可核实时间才能继续延期，并由评审角色重新确认。依赖类延期如果长期没有进展，应考虑调整修复方案或评估该缺陷是否还需要修复。
延期缺陷一直没有复查，团队应该怎么处理？
先补齐复查安排：确认新目标日期是否仍然成立，指定能推动后续动作的复查人，并创建复查任务或提醒。对于已经超期未复查的缺陷，建议在版本回顾或季度回顾中单独列出，逐条确认是继续延期还是关闭。如果同一类原因反复出现超期未复查，说明延期规则中的复查环节没有被真正执行，需要检查状态流转是否允许在缺少复查安排的情况下变更为延期。
延期记录里的临时规避措施必须写吗？没有规避方式怎么办？
必须填写。没有规避方式时写明“无”，并说明用户可能遇到的现象，这样测试角色和风险接受人能据此判断影响。把“无规避”明确写出来，比留空更有价值：留空会让后来的人无法判断是遗漏还是确实没有方案，也会影响复查时对风险是否变化的判断。
