严重程度与优先级

“严重程度”不是给 Bug 排队的号码，而是描述缺陷造成多大损害；“优先级”才回答团队应该先处理什么。项目里最常见的失控，不是严重程度分错一档，而是把严重程度、修复顺序、客户情绪和…

同一个缺陷，开发标成“中”，测试坚持“高”，产品认为“上线后再修也可以”，最后却在发布前一天卡住了整个版本。Bug 严重程度之所以经常失真，不是团队缺少一个“高、中、低”下拉框，而…

“严重程度”最容易出问题的地方，不是团队不会填字段，而是同一个词在不同角色眼里代表不同事情：客服把“客户催得急”标成最高级，研发把“程序崩溃”标成最高级，产品则把“影响下个版本发布…

去年秋天我复盘一个 118 人研发团队的缺陷数据时，看到一组很刺眼的数字：过去 90 天共提交 1247 个缺陷，其中 431 个的关闭原因是"无法复现"或&q…

2023 年我接手过一个跨 5 个团队的缺陷治理项目。第一周我做的唯一一件“正确”的事，是把当时那张 47 行的缺陷优先级表撕掉了，不是因为它错，而是因为它已经变成了一份没人看、没…

去年 11 月，我帮一家 130 人规模的研发组织做质量复盘，翻出了他们三个月内关闭的 1,842 条缺陷记录。其中 611 条（约 33%）的描述正文不超过 20 个字，最典型的…

Bug 严重程度最容易出错的地方，不是“严重、一般、轻微”分得不够细，而是团队把影响范围、修复紧急度和个人感受混成了一个字段。结果可能是：一个只影响测试环境的页面错位被标成“致命”…

去年秋天，我陪一家做政企交付的团队做年度缺陷复盘。他们有 62 名实施与技术支持人员，全年在系统里登记了 4217 条缺陷单。团队负责人的第一句话是：“我们修得不慢，但客户还是天天…

一个 P1 缺陷在测试环境复现了三次：开发说这是 P3 的边缘场景，测试说这是 P1 的数据丢失风险，产品经理说先放着明天再看。三天后它进了生产环境，影响 2.3% 的日活用户，回…

去年冬天，我陪一家做本地生活服务的公司做缺陷流程复盘。翻完他们一整年的 Bug 记录，看到一个很别扭的对比：在库缺陷里 62% 的严重程度填的是"严重"或&qu…