一、先判定为什么解决不了
1、技术瓶颈:架构硬伤、第三方 SDK / 接口限制、底层改造成本极高、改动风险极大极易引发更多 bug;
2、需求矛盾:历史老旧逻辑,改了会影响老用户数据、存量业务;
3、资源不允许:工作量巨大,排期紧张,短期无法投入人力;
4、环境 / 客观问题:偶现概率极低、无法稳定复现,找不到根因。
二、标准化五步处理流程
1、出具说明
开发写明:问题根因、尝试过哪些修复方案、为什么无法修复、修复代价、潜在风险。
2、三方评审拍板
测试 + 开发 + 产品 + 项目经理共同开会确认,不能某个人私自决定搁置。
3、正式走工具流程归档
缺陷单状态改为:暂缓修复 / 不予修复,强制填写:
遗留风险点
影响用户范围
规避临时兜底方案
是否后续版本规划解决
4、做风险告知与记录
写入测试报告、上线风险清单;
上线前所有干系人确认知悉风险,留签字 / 评论记录;
告知运维、客服,万一用户反馈知道怎么答复。
5、长期跟踪管理
纳入需求池 / 技术债务台账;
每次迭代复盘定期回顾,架构重构、版本大升级时重新评估是否修复;
若后续有条件立即安排修复。
三、不同类型缺陷对应兜底措施
1、高危但修不了
增加前端提示、后台告警、人工监控、后台兜底校验,降低故障影响。
2、低体验、UI 小问题
直接作为优化建议关闭,备注不影响核心功能。
3、极低概率偶现 bug
添加日志埋点,线上监控捕获报错,后续收集更多线索再定位。
四、三条硬性红线
1、不许测试私自关闭、不许开发单方面直接关单;
2、不许只口头说不修,不在缺陷系统留任何文字记录;
3、高危无法修复缺陷不能悄悄上线,必须全员风险告知。