缺陷延期处理要解决的是“先拖一拖再说”带来的失控：同一缺陷反复延期、目标版本无人确认、受影响方最后才知道。可行的做法是把延期变成一条有判定依据、有审批、有交付物、有复核时点的流程，让每次延期都能说明原因、影响和新目标，并能在到期前被重新检查。
要点总览（TL;DR）
- 缺陷延期处理先区分三类情形：无法在原目标版本或日期内交付的延期、不再修复的关闭、严重程度下调的降级，三者走不同审批与记录路径。
- 处理按固定顺序推进：原因确认、影响评估、审批、设定新目标、同步受影响方、设置复核点，每步都要有输入、输出和完成标志。
- 审批层级按严重程度、影响客户范围、是否阻塞发布组合确定，产品、研发、测试、发布负责人各判断自己负责的部分。
- 延期记录必填原因、影响、原目标、新目标、审批人、审批结论和复核日期；复核日期要早于新目标日期，多次延期需上调审批层级。
- 机制是否可运行看三点：延期记录字段齐全、复核按时执行、发布评审汇总延期缺陷清单。
缺陷延期处理的核心答案与操作步骤
延期处理的第一步是判定情形。缺陷进入延期流程，通常指它无法在原定目标版本或目标日期内完成修复并验证；如果团队决定不再修复，应走关闭或转为已知问题记录的路径；如果只是严重程度下调、修复优先级后移但仍计划处理，应走降级并重新排期。三类情形对应不同的审批和记录要求，混在一起处理会让延期记录失去可比性。
判定之后按固定顺序推进：原因确认、影响评估、审批、设定新目标、同步受影响方、设置复核点。每一步都要有明确输入和输出，避免流程停在“已经口头说过了”。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 原因确认 | 缺陷记录、复现信息、当前修复进展 | 确认延期属于修复难度、依赖未就绪、资源冲突还是需求变更导致 | 延期原因说明 | 原因可归类，且能指向具体阻碍项 |
| 2. 影响评估 | 缺陷严重程度、影响客户范围、所在版本与发布计划 | 判断是否阻塞发布、是否影响已交付客户、是否存在临时规避方案 | 影响范围与风险说明 | 明确受影响版本、客户或业务场景 |
| 3. 审批 | 原因说明、影响评估、拟延期时长 | 按分级规则提交对应层级审批 | 审批结论与审批人 | 审批状态为通过，或按驳回意见重新处理 |
| 4. 设定新目标 | 审批结论、排期容量 | 确定新的目标版本或目标日期，写明修复与验证的预计完成时间 | 新目标版本或日期 | 新目标具体到版本号或日期，不停留在“下个版本” |
| 5. 同步受影响方 | 新目标、影响范围 | 通知测试、发布负责人、客户接口人等相关方 | 同步记录 | 关键受影响方已知悉并确认 |
| 6. 设置复核点 | 新目标日期 | 在到期前设定复核日期和复核人 | 复核任务或检查项 | 复核日期早于新目标日期，且有人负责 |
这张表可以直接作为团队的操作口径。需要强调的是，第4步和第6步常被省略：只写“延期”不写新目标，缺陷就会失去排期约束；只改日期不设复核点，同一缺陷可能连续延期而无人汇总。把这两步作为必填项，延期流程才具备闭环条件。
延期审批的分级规则与角色分工
审批层级不宜一刀切。建议按三个维度组合判断：缺陷严重程度、影响客户范围、是否阻塞发布。严重程度高且阻塞发布的缺陷，延期应由产品负责人与项目或发布负责人共同确认；影响外部客户但暂不阻塞当前发布的，可由产品负责人审批并知会发布负责人；一般缺陷的内部排期后移，由研发负责人或测试负责人确认即可。这样既保证高风险延期有人把关，也避免所有延期都挤到同一层级。
| 情形 | 典型特征 | 审批层级 | 必须知会 |
|---|---|---|---|
| 阻塞发布的严重缺陷延期 | 影响核心功能，当前版本无法按原计划交付 | 产品负责人 + 项目/发布负责人 | 测试负责人、客户接口人 |
| 影响外部客户但不阻塞当前发布 | 客户可感知，存在临时规避方案 | 产品负责人 | 发布负责人、客户接口人 |
| 内部一般缺陷排期后移 | 影响范围有限，无客户侧承诺 | 研发负责人或测试负责人 | 测试执行人 |
| 降级处理 | 严重程度下调，仍计划修复 | 测试负责人确认降级依据 | 产品负责人 |
| 关闭或转已知问题 | 不再修复，需保留说明 | 产品负责人确认 | 测试负责人、客户接口人 |
角色职责要写清楚，避免申请人和审批人之间出现空档。延期申请人通常是缺陷当前负责人或测试负责人，负责提交原因、影响和拟延期时长；审批人负责判断延期是否可接受、新目标是否合理；记录人负责把审批结论、新目标和复核日期写回缺陷记录；复核人负责在复核日期检查进展，判断是否需要再次升级。产品、研发、测试、项目或发布负责人在其中的分工可以概括为：产品判断业务影响和客户承诺，研发判断修复可行性和排期，测试判断验证风险和回归范围，项目或发布负责人判断对发布计划的影响。
申请人与审批人的交付物也要区分。申请人提交的是延期申请，包含原因、影响、原目标、拟新目标和临时规避方案；审批人给出的是审批结论，包含是否通过、附加条件、新目标确认和复核要求。两者都进入缺陷记录，后续复核时以审批结论为准。
延期记录字段与示例
延期记录的价值在于可回溯。字段设计不必复杂，但要保证任何人打开缺陷都能回答四个问题：为什么延期、影响了谁、原定什么时候完成、现在由谁在什么时候复核。
| 字段 | 必填/选填 | 填写要求 |
|---|---|---|
| 延期原因 | 必填 | 归类到修复难度、依赖未就绪、资源冲突、需求变更等，并补充一句具体说明 |
| 影响范围 | 必填 | 写明受影响版本、客户或业务场景，是否阻塞发布 |
| 原目标版本/日期 | 必填 | 填写延期前的承诺目标 |
| 新目标版本/日期 | 必填 | 具体到版本号或日期，避免“待定” |
| 审批人 | 必填 | 按分级规则确定的审批角色与姓名 |
| 审批结论 | 必填 | 通过、有条件通过或驳回，附条件说明 |
| 复核日期 | 必填 | 早于新目标日期，明确复核人 |
| 临时规避方案 | 选填 | 有客户侧影响时建议填写 |
| 关联需求或发布 | 选填 | 便于发布评审时汇总查看 |
示例：某支付项目的缺陷“订单退款状态同步失败”，原目标版本为 V2.3，严重程度为高，影响已接入的两个外部客户。延期原因填写为“依赖的第三方接口联调未完成，修复代码已提交但无法完成端到端验证”；影响范围填写为“V2.3 发布范围内，两个客户可感知，存在人工对账的临时规避方案”；原目标版本 V2.3，新目标版本 V2.4，审批人为产品负责人与发布负责人，审批结论为“有条件通过，需在 V2.3 发布说明中标注已知问题并提供人工对账指引”；复核日期设为 V2.4 开发启动后的第三個工作日，复核人为测试负责人。这条记录把原因、影响、承诺和复核责任都固定下来，后续任何人查看都能判断延期是否仍在受控状态。
延期后的跟踪、复核与升级
延期批准只是开始。跟踪的重点是复核时点：复核日期应设在新目标日期之前，留出调整排期的时间；复核人要在到期前检查修复是否按计划推进，若发现再次无法完成，应触发升级而不是直接改日期。到期提醒可以借助缺陷记录中的复核日期字段或团队例行缺陷评审会实现，关键是有人对“到期未复核”负责。
多次延期需要明确升级规则。建议同一缺陷第二次延期时，审批层级上调一级，并要求说明首次延期后的实际进展；第三次延期时，提交发布评审或缺陷治理会议讨论，判断是否转为关闭、降级或调整发布范围。升级规则的作用是让反复延期暴露出来，而不是让每次延期都看起来像独立事件。
延期缺陷还要与发布评审衔接。发布前应汇总当前版本内所有延期缺陷，逐条确认新目标是否影响本次发布范围、是否需要写入发布说明、是否有客户侧沟通动作。把延期清单作为发布评审的固定输入，可以避免“批了延期但发布时没人记得”的情况。
- 复核检查点：复核日期是否早于新目标日期；复核人是否明确；到期未复核是否有提醒。
- 升级检查点：同一缺陷延期次数是否被统计；第二次延期是否上调审批层级；第三次延期是否进入发布评审或治理会议。
- 发布衔接检查点：发布评审是否汇总延期缺陷；客户可感知的延期是否进入发布说明；临时规避方案是否同步给支持团队。
在工具承载上，ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；延期原因、新目标版本、审批结论和复核日期可以作为缺陷记录的一部分随状态流转保留。ONES ALM 方案把测试用例、缺陷、版本和发布过程关联到需求链路中，便于在发布评审时按版本汇总延期缺陷并定位影响范围。具体字段与审批流的配置方式，需结合团队实际流程在选型或实施时核验。
完成检查：延期处理机制是否可运行
判断机制是否落地，不看文档写得多完整，而看几件事能否稳定发生：每次延期都有判定、有审批、有新目标、有复核，且记录能被汇总查看。以下清单可用于上线前自查或阶段性复盘。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 流程完整性 | 延期、关闭、降级三类情形是否有区分 | 每类情形有对应处置路径，不混用同一审批 |
| 流程完整性 | 延期步骤是否覆盖原因、影响、审批、新目标、同步、复核 | 六个步骤均有责任人和输出物 |
| 记录可追溯性 | 必填字段是否齐全 | 原因、影响、原目标、新目标、审批人、复核日期均可查到 |
| 记录可追溯性 | 同一缺陷的多次延期是否可连续查看 | 历史延期记录不被覆盖，可回溯每次审批结论 |
| 复核与升级 | 复核日期是否早于新目标日期 | 抽查延期缺陷，复核日期均满足要求 |
| 复核与升级 | 多次延期是否有升级动作 | 第二次延期审批层级上调，第三次进入发布评审或治理会议 |
| 发布衔接 | 发布评审是否汇总延期缺陷 | 每次发布前有延期缺陷清单及处理结论 |
阻断项包括：延期无审批记录、新目标为“待定”、复核日期缺失、同一缺陷多次延期无汇总。出现任一阻断项，说明机制尚未可运行，应先补齐记录和复核责任再扩大适用范围。完成条件可以设为：连续一个发布周期内，所有延期缺陷均具备完整必填字段，复核按时执行，且发布评审中包含延期清单。满足这些条件，延期处理才算从口头协商转为可复核的管理流程。
常见问题
缺陷延期和缺陷关闭、降级有什么区别，能不能用同一套审批？
三者对应不同处置结果，建议分开审批。延期指缺陷仍计划修复，只是无法在原目标版本或日期内完成；关闭指团队决定不再修复，需要保留说明并处理客户侧沟通；降级指严重程度下调、修复优先级后移但仍计划处理。混用同一套审批会让延期记录失去可比性，也无法统计反复延期的情况。关闭和降级通常由产品负责人确认，延期则按严重程度和影响面分级审批。
延期申请被驳回后应该怎么处理？
驳回意味着当前延期理由或新目标不被接受，缺陷应回到原目标继续推进，或由申请人补充信息后重新提交。常见驳回原因包括原因归类不清、影响范围未说明、新目标仍是“待定”。重新提交时应补齐这些内容，并按原审批层级再次提交；如果确实无法在原目标内完成，应升级到更高层级判断是否调整发布范围，而不是反复提交同一份申请。
同一缺陷多次延期，审批层级怎么调整？
建议设置明确的升级规则：第二次延期时审批层级上调一级，并要求说明首次延期后的实际进展；第三次延期时提交发布评审或缺陷治理会议讨论，判断转为关闭、降级还是调整发布范围。升级规则的作用是让反复延期暴露出来，避免每次延期都被当作独立事件处理。延期次数应在缺陷记录中可统计，复核时以累计次数为准。
延期缺陷在发布评审时要做哪些确认？
发布前应汇总当前版本内所有延期缺陷，逐条确认三件事：新目标是否影响本次发布范围、是否需要写入发布说明、是否有客户侧沟通动作。客户可感知的延期应同步临时规避方案给支持团队。把延期清单作为发布评审的固定输入，可以避免“批了延期但发布时没人记得”的情况。ONES ALM 方案把测试用例、缺陷、版本和发布过程关联到需求链路中，便于按版本汇总延期缺陷并定位影响范围。
团队规模较小，是否也需要完整的分级审批？
分级审批的层级可以简化，但判定、记录和复核三个动作建议保留。小团队可以把审批合并到一次例行缺陷评审会上完成，由产品负责人和研发负责人共同确认；记录字段仍要写清原因、影响、原目标、新目标和复核日期，否则延期无法回溯。复核可以由测试负责人兼任。机制的价值在于让每次延期都有依据和到期检查，审批层级的多少可以根据团队实际调整。
