缺陷不是数字，是没被闭环的问题
很多团队开完站会，报一句「还剩二十个缺陷」，就觉得工作做了一半。但数字本身不代表任何事——真正要紧的是：这二十个问题有没有被明确认领、排好优先级、在约定时间内修好并验证关闭。
缺陷追踪要做的，就是把一个模糊的「系统有点不稳」，变成一条可追踪、可度量、可闭环的流水线。
没有被关闭的缺陷，只是一个被记下来的抱怨；只有走完生命周期，它才变成一次质量改进。
本文核心知识点
- 生命周期从发现、认领、修复到验证关闭。
- 严重度区分影响范围，先救哪个火。
- 优先级决定什么时候动手排期。
- 响应 SLA给问题一个明确的时钟。
- 质量度量用数据看清质量走向。
缺陷生命周期：从发现到关闭
一个缺陷被提出来后，会经历几个固定状态。把状态定义清楚，谁在什么阶段该做什么就一目了然，不会出现「这 bug 到底归谁管」的扯皮。
| 状态 | 含义 |
|---|---|
| 新建 | 问题已记录，等待分诊 |
| 已认领 | 有人负责，开始排查 |
| 修复中 | 正在改代码 |
| 待验证 | 改完了，等测试确认 |
| 已关闭 | 验证通过，问题闭环 |
关键是每个状态都要有明确的进出条件，不能出现一个缺陷停在中间没人管。
严重度与优先级：先救哪个火
所有缺陷一起修是不可能的，资源永远不够。所以要把两个维度分开：严重度说的是「影响有多大」，优先级说的是「多晚之内必须修」。
- 严重度高：全站不可用、数据错误、资金损失。
- 严重度低：某个小角落的文案错位。
- 优先级：结合业务影响和修复成本排期。
# 分诊时先问两个问题
这个问题影响多少用户
这个问题不修会怎样
# 严重度回答「有多严重」
# 优先级回答「什么时候修」
# 别把两个问题混成一个标签。严重度和优先级分开，团队才不会在无关紧要的小问题上耗掉修大问题的时间。
响应 SLA：给问题一个时钟
光说「尽快修」是没有约束力的。响应 SLA 给不同严重度的问题定一个明确的响应和修复时限，让大家对「多久算及时」有共同的预期。
| 严重度 | 响应时限 | 修复目标 |
|---|---|---|
| 致命 | 15 分钟内响应 | 当天修复或出补丁 |
| 严重 | 2 小时内响应 | 本迭代内修复 |
| 一般 | 1 个工作日 | 排期到近期迭代 |
| 轻微 | 按需 | 攒一批再处理 |
SLA 不是用来追责的鞭子，而是让客户和团队对等待时间有底的约定。
质量度量：用数据看清走向
缺陷数据攒起来后，就可以用几个简单指标看清质量是在变好还是变差。
# 几个该长期看的指标
- 缺陷发现率：每千行代码引出多少缺陷
- 缺陷逃逸率：上线后被用户发现的比例
- 平均修复时长：从开单到关闭要多久
- 重开率：修好又复发的比例
# 指标要长期趋势看，单月数字意义不大。度量不是为了给人打分，而是让团队看见质量这条曲线是在往上走还是往下滑。
缺陷分析：找出反复出错的根源
有些模块总是出问题，同一个地方反复修。这时候光修单个缺陷不够，要做缺陷分析：把一段时间的缺陷按模块、按类型归类，找出那个总是出事的重灾区。
- 哪些模块缺陷最多、重开率最高。
- 缺陷集中在哪一类错误：逻辑、边界、还是并发。
- 针对重灾区做专项加固和测试补强。
把缺陷从「一个个救火」变成「找出着火点系统性整改」，才是质量度量的真正价值。
让缺陷被看见、被闭环
缺陷追踪与质量度量的最终目的，是让问题不再是「报了就石沉大海」，而是被看见、被认领、被按时修好、被验证关闭、被总结改进。
- 每个缺陷都有明确的状态和责任人。
- 严重度和优先级让有限资源用在刀刃上。
- 度量数据让团队对质量走向心里有数。
当缺陷被闭环成为习惯，团队面对的就不再是失控的数字，而是一条清晰可改进的质量曲线。