Bug / 缺陷严重程度全流程：研发团队协同管理与一文讲清

一个 P1 缺陷在测试环境复现了三次：开发说这是 P3 的边缘场景，测试说这是 P1 的数据丢失风险，产品经理说先放着明天再看。三天后它进了生产环境，影响 2.3% 的日活用户，回滚加修复耗掉 4 个小时。复盘会上所有人都在问同一个问题：当时到底是谁把它的严重程度定错了？真正的问题是谁都没有定义过「定错」的标准，也不存在一条让这个判断被执行、被复核、被追溯的路径。缺陷严重程度这个看起来最不起眼的字段，实际上是研发团队里信息密度最高、争议最多、后果最不可逆的一个决策点。

它决定一个 Bug 今晚是否有人加班，决定发版窗口是否推迟，决定测试资源投向哪里，也决定线上事故复盘时谁被追问。这篇文章我会把它拆成一条完整链路：怎么定义、谁来判、怎么流转、怎么复核、怎么回收、在什么规模下该松、在什么规模下该紧，以及我实际踩过的坑和观察到的数据。

一、核心结论：严重程度是一条决策链，而不是一个下拉框

先给结论，后面再论证。如果你只想要一句可以直接拿去开会的话：缺陷严重程度失控，几乎从来不是「员工不用心」，而是「组织没有把定级当成一个需要被设计的流程」。我见过太多团队的缺陷管理停留在给字段加下拉选项这一步，然后在半年内被现实反复打脸。

1. 结论一：严重程度描述损失，优先级描述顺序，两者必须分离

这是所有问题的源头。严重程度是客观属性，回答「这个缺陷造成了多大、多广、多难挽回的损失」；优先级是主观决策，回答「在当下这批资源里，我们第几个做它」。一个 P0 级别的资金对账错误，如果只在内部测试账号可触发，优先级可能低于一个影响全部用户的 P2 界面错位，因为后者正在制造客服工单。

把两者合成一个字段的团队，一定会陷入两种死循环：要么严重程度被优先级污染，所有「领导关心的」都变成 P0；要么优先级被严重程度绑架，开发只能按严重程度排序，无法做任何业务判断。分离之后，两者的关系才可解释。

2. 结论二：严重程度必须在生命周期的三个节点各判一次

很多人以为定级是一次性动作，提交时填完就完事。实际有效的做法是三次判定：提交时的初判（基于复现现象）、复现后的确认（基于根因和影响面）、闭环时的回判（基于真实影响数据）。三次判定之间的差异，本身就是团队认知校准的最好素材。

我在一个两百人规模的研发组织里做过统计：提交时被评为 P0/P1 的缺陷，经过复现确认后仍保持 P0/P1 的比例不到四成；而提交时被标为 P3 的缺陷里，有约 9% 在闭环时被回判为 P1 及以上。初判的偏差不是失误，是信息不足的必然结果，流程要做的不是消灭偏差，而是让偏差在造成损失之前被发现。

3. 结论三：定级标准要写「证据门槛」，不要写形容词

「导致系统不可用」这种描述在真实场景里几乎没有约束力，因为每个人对「不可用」的想象不同。可执行的标准必须绑定可验证的证据：是否影响全部租户、是否造成数据写入失败、是否可通过重试自愈、是否有可用的临时绕过方案、影响用户数的量级区间。

我坚持的一条原则是：任何一个定级结论，都必须能指向一条证据，而这条证据必须是别人可以复核的。做不到这一点的定级，本质上是在投票，不是在判断。

4. 结论四：跨团队协同的瓶颈不在定级本身，而在定级权的归属

单团队内部，谁定级吵两句就过去了；一旦涉及前端、后端、中间件、算法、客户端多团队，一个缺陷的严重程度会直接决定哪个团队今晚要出人。这时候定级就不再是技术判断，而是资源博弈。我在规模超过一百人的组织里反复看到同一个现象：争议最激烈的从来不是 P0，而是 P2 和 P3 的边界，因为 P0 全公司都认，P2/P3 才是可以被推走的那一档。

5. 结论五：严重程度的最终价值在回收，不在提交

如果一套分级体系运行一年，你无法回答「我们的 P0 定义是否过于宽松」「哪个模块持续产出高严重程度缺陷」「哪些团队的回判偏差最大」，那这套体系只是给报表增加了一个字段，没有产生任何管理杠杆。严重程度真正的价值，在于它是一个可以反向校准研发质量的数据源。

二、背景与真实场景：为什么规模一过百人，严重程度就开始失真

我不太相信「流程要靠文化」这类说法。流程失效通常有非常具体的结构性原因，找到它比喊口号有用得多。

1. 一个真实的周四凌晨场景

先说一个我亲历的场景。某 SaaS 产品在周四凌晨发布了一个版本，早上八点客服开始收到零散反馈：部分企业客户的成员权限在保存后没有生效。测试同学的判断是 P2，理由是「只影响部分租户，且可以再次保存」。开发的判断是 P3，理由是「前端已经提示成功，属于体验问题」。

实际情况是：这是后端一个幂等逻辑在并发下的竞态，再次保存有约三成概率仍然失败，而失败后用户会认为权限已生效，导致越权访问。到中午十二点，这个问题被定为 P0，涉及 17 家企业客户，其中 3 家走了升级流程。

事后拆解，这不是任何一个人的判断力问题，是三个结构性缺口叠加的结果。

（1）缺口一：初判者掌握的信息最少，却拥有最大的定级权

提交缺陷的人往往只看到现象，看不到根因。而根因恰恰决定了影响面。让现象观察者做终局判断，等于让信息最少的人承担最大的决策责任。

（2）缺口二：没有强制要求填写影响面证据

「只影响部分租户」这句话背后其实是「我复现的那个账号是这个情况」，这是不完整的证据。如果表单强制要求填写受影响租户数量或占比，这个缺陷当场就会被升级。

（3）缺口三：跨团队场景下，没人对「最终定级」负责

前端说是后端问题，后端说是数据问题，测试说是需求问题。每个角色都在描述自己视角下的严重程度，但没有人拥有把这个结论合并成一个数的责任。责任真空必然导致定级向下漂移，因为向下漂移对每一方都是成本最低的选择。

2. 规模扩大后，三个可量化的断裂点

我把过去几年在几个不同规模团队里记录的数据做了归并（统计口径为「单个缺陷从提交到严重程度确认所需的沟通轮次」与「确认耗时中位数」，样本来自 5 个研发组织的缺陷流程复盘，属于经验样本而非行业普查，仅供参考）。

3. 三个断裂点的具体表现

（1）断裂点一：术语不再共享

二十人的团队里，「这个挺严重的」是一句有效沟通，因为大家共享同一套上下文。一百人以上，新入职成员、外包团队、跨地域团队进入后，「严重」这个词的锚点彻底分裂。有人参照的是上一次线上事故，有人参照的是自己上一家公司的标准。

（2）断裂点二：判定责任被稀释

人少的时候，定级错了大家记得住，社交压力就是约束。人多了以后，一个定级错误会消失在几百条缺陷记录里，没有任何人感受到反馈。没有反馈的判断，一定会持续退化。

（3）断裂点三：工具里的字段变成摆设

我在做流程诊断时有一个固定动作：随机抽 50 条已关闭的缺陷，看严重程度字段的分布。如果 P2 占比超过 70%，基本可以断定这个字段已经失效，它不是被判断出来的，是被默认值填出来的。这个信号比任何访谈都准确。

4. 严重程度失真的真实成本结构

很多团队觉得定级不准「影响不大」，因为缺陷最终都会修。这个判断忽略了成本的时间分布：定级偏低会把成本推到线上，而定级偏高的成本留在研发内部。两者的量级完全不在一个数量级上。

我做过一次粗略测算：一个在测试阶段被正确识别为 P1 的缺陷，平均修复成本约为 3.5 人时；同样的缺陷如果漏到生产环境，成本会膨胀到 30 至 60 人时，其中大部分不是修代码，而是定位、沟通、客户解释、数据修复和信任修复。这个倍数关系在多个团队里都稳定成立，是流程投入最划算的理由。

三、常见误区拆解：六个把严重程度做废的典型做法

这一节我写得直接一些，因为这六个误区我几乎在每个团队都能见到至少三个。

1. 误区一：把严重程度当成「催促工具」

这是破坏力最大的一个。当团队发现提高严重程度可以更快拿到资源，严重程度就变成了谈判筹码。三个月内，P0 占比会从 2% 涨到 10% 以上，然后所有人开始对 P0 脱敏，真正的高危缺陷被淹没在噪音里。

判断一个团队是否陷进去了，看一个指标就行：P0 缺陷中最终被确认为 P0 的比例。低于 40% 说明这个等级已经在通胀。

2. 误区二：严重程度等于优先级

前面已经讲过，这里补一个具体的后果。当两者合并，产品经理会失去排序权，因为任何「严重程度高」的问题都必须优先处理；同时开发会失去业务判断，因为严重程度高的往往是技术债类的隐蔽问题，而非当期业务最需要的修复。最后的结果是所有人都觉得流程僵化。

3. 误区三：靠培训和一页文档解决定级一致性

我试过。给一个一百二十人的研发团队做过两小时的定级标准培训，覆盖率 100%，当场测试的一致率有 78%。三个月后重测，同一批案例的一致率掉到 51%。

原因很简单：培训改变的是知识，流程才改变行为。没有强制填写的证据字段，没有定期校准机制，没有偏差回溯，知识会在三个月内被日常习惯冲掉。

4. 误区四：追求「一次判对」

有些团队在设计流程时追求提交即准确，于是把表单做得极其复杂，要求填写十几个字段。结果是提交者开始敷衍填写，或者干脆不提交缺陷、转为线下沟通，数据质量反而更差。

正确的思路是接受初判必然不准，把资源投入到「低成本纠偏」上：一个能在十分钟内完成升级的复核环节，价值远高于一个复杂的提交表单。

5. 误区五：只看提交端，不看消费端

严重程度有生产者也有消费者。生产者是测试和提缺陷的人，消费者是排期的人、发版决策的人、看报表的人、以及线上值班的人。如果消费者拿到的严重程度不可信，他们会自发建立一套并行判断，比如看标题里的感叹号、看是谁提的、看群里有没有人 @ 自己。

我在一个团队里观察到的错配率数据很能说明问题：不同角色对同一批缺陷的定级偏差，差异远超预期。

6. 误区六：把严重程度锁死在缺陷模块里

很多团队只在「缺陷」这个工作项类型上定义了严重程度，但没有把它和需求、发布、线上事件打通。结果是一个 P0 缺陷修完了，复盘时找不到对应的发布记录和影响范围，下一次同类问题的定级又要从零开始讨论。

严重程度必须是一个跨工作项流通的语义，它在缺陷上产生，在发布决策中被引用，在事故复盘中被打磨，最后回到缺陷模板里成为新的判定依据。

四、专业判断逻辑：一套可以直接落地的判定框架

到现在为止都在讲问题，这一节讲方法。我用的框架核心只有一句话：用两个正交维度把定性判断压成可对齐的结构，再用证据门槛把主观空间收窄。

1. 两个正交维度：影响面 × 失效程度

第一个维度是影响面，衡量有多少人在受影响，从单个用户到全部租户分五档。第二个维度是失效程度，衡量功能坏到什么地步，从轻微体验到数据损坏不可恢复分五档。两个维度独立打分，不互相补偿。

之所以要正交，是因为绝大多数定级争议都来自把两个维度混为一谈。「只有三个人遇到」和「这三个人数据全丢了」是两个不同的严重信号，混在一起讨论就永远吵不出结果。

（1）影响面分档

• A0 单点：单一用户、单一账号，可自助恢复
• A1 小范围：单一租户或单一区域，占比低于 1%
• A2 局部：多个租户，占比 1% 至 10%
• A3 大面积：占比 10% 至 50%，或涉及核心付费客户
• A4 全局：占比超过 50%，或全量不可用

（2）失效程度分档

• S0 表现层：文案、样式、对齐，不影响任务完成
• S1 体验层：功能可用但明显受阻，有绕过方案
• S2 功能层：核心功能不可用，无绕过方案
• S3 数据层：数据错误、丢失、越权，且不可自动恢复
• S4 系统层：服务不可用、雪崩、资损、合规风险

2. 判定矩阵：从两个维度得出严重程度

把两个维度放进矩阵，严重程度就从矩阵的落点读出来。这张表我在多个团队推行过，最大的价值不是精确，而是把争论从「我觉得」转移到「它落在哪一格」。

矩阵必须允许一档上浮和一档下调的人工修正，但修正必须写明理由。允许例外、但要求例外留痕，这是让标准能活下来的关键设计。完全不允许例外的标准，最后一定被绕过。

3. 证据门槛：每一档严重程度对应的必填证据

光有矩阵还不够，因为影响面和失效程度的判断同样依赖证据。我的做法是给每一档配一个最小的证据清单，缺证据就默认降档，而不是默认升档或让提交者自由裁量。

这里有一个反直觉的经验：P0 之所以要双签，不是为了审批，而是为了让两个视角的信息合并。测试掌握复现路径，研发掌握根因和影响面，单方定级必然片面。双签的成本是十分钟，收益是避免一次误判。

4. 角色分工：谁在什么时候拥有定级权

跨团队协同里，定级权归属不清是最常见的病灶。我用一张简化的责任表来解决，注意它不是平均分配，而是每个阶段有唯一的主责。

5. 争议裁决机制：把吵架变成流程

有争议是健康的，没有出口才是不健康的。我通常设三条规则：

1. 争议升级有时限。超过 24 小时未达成一致的，自动按较高档位处理并进入排期，同时记录一次「未决争议」。这条规则的心理学作用远大于管理作用，它让「拖着不定」变成有成本的选项。
2. 争议结论必须留痕。在缺陷记录里写清双方观点和最终依据，不是追责材料，而是下一次校准会的训练样本。
3. 争议按季度统计。如果某个模块或某两个团队的争议数量持续排名靠前，问题不在人，在接口设计或需求边界，要往上游查。

6. 判定框架的落点分布观察

框架是否好用，看缺陷在矩阵上的落点分布就知道。如果绝大多数缺陷挤在一两个格子里，说明分档粒度太粗或填写者在走捷径；如果均匀散开，说明团队真的在用。

五、案例与数据观察：一次跨五个团队的定级治理

方法和案例要分开讲，因为方法可以复制，案例里的坑往往更值钱。

1. 场景背景：多产品线、多团队、共享缺陷池

这家公司的研发组织规模在三百人上下，五个研发团队共用一套缺陷池，产品线之间有大量共享组件。他们的问题很典型：缺陷池里 P2 占比 68%，P0 每季度只有个位数，但线上事故每季度有 4 到 6 起，且每次事故对应的缺陷在池子里都被标为 P2 或 P3。

换句话说，他们的严重程度体系已经和真实风险完全脱钩了。这不是判断能力问题，是体系失效。

2. 治理动作：四步走

（1）第一步：用历史事故反推标准

我们没有从零写标准，而是把过去一年 19 起线上事故拉出来，逐个还原它当初在缺陷池里的定级、复现路径和影响面描述。做完这一步，标准几乎自己浮现了，19 起里有 14 起的描述里都出现了「部分用户」「偶尔」「重试可恢复」这类模糊词，而它们实际的影响面都是 A2 及以上。

标准的最佳来源不是行业模板，而是你自己过去犯过的错。这一点我越来越确信。

（2）第二步：把证据字段做成必填

在缺陷提交表单里增加了「受影响范围」「是否可绕过」「是否涉及数据变更」三个必填项，并根据填写内容自动给出建议档位。注意是「建议」而非「强制」，保留人工修正权，但修正需填写理由。

这里用了项目管理平台的能力。PingCode 这类面向中大型研发组织的平台，优势在于缺陷、需求、迭代、发布在同一个对象模型里，可以给不同工作项类型配置不同的字段必填规则和流转条件。我们把 P0 的流转条件设成「必须双签才能进入修复中」，把 P2 以上的回判字段设成关闭时必填。这类约束靠文档是做不到的，必须落在工具里。

如果团队还在用表格管理缺陷，我的建议是先别急着上工具，先把矩阵和证据清单跑一个月，确认这套判定逻辑在你们的业务里成立，再考虑固化。先有能跑通的判断，再谈工具承载，顺序反了就是花钱买形式。

（3）第三步：建立双周校准会

每两周抽 20 条缺陷，覆盖各个团队和高低档位，由测试、开发、产品三方独立定级，然后对比。会议控制在 45 分钟，只讨论分歧超过一档的案例。

这个动作的效果不是线性的。前三次校准会分歧率都在 30% 以上，第五次之后降到 15% 左右，第十次之后稳定在 9% 上下。分歧率不再下降是正常的，剩下的分歧大多来自真实的业务判断差异，而不是标准理解差异。

（4）第四步：把回判数据接进质量看板

闭环时记录的真实影响面，会和初判做对比，形成两个派生指标：高估率（初判高于回判）和漏判率（初判低于回判一档及以上）。这两个指标按模块、按团队、按提交人维度统计，比单纯的缺陷数量有信息量得多。

3. 数据观察：治理前后的变化

治理周期是六个月。以下数据来自该组织的缺陷流程复盘报告，统计口径为治理前 6 个月与治理后 6 个月的同期对比，属于单一样本的经验数据，不能直接外推为行业基准，但趋势我认为有参考价值。

4. 一个具体缺陷的成本拆解

治理过程中有一个 P0 缺陷值得单独说。它是一个跨团队的支付回调幂等问题，在测试阶段被正确识别，但仍然造成了线上影响，原因是修复方案涉及三个团队联调。

我记录了从提交到完全闭环的全部成本，这个拆解对说服管理层投入流程建设非常有用。

5. 缺陷来源的帕累托观察

治理后期我们还做了一件事：按模块统计高严重程度缺陷的来源。结论非常集中，二十多个模块里，三个模块贡献了超过六成的高等级缺陷。

六、行动建议：不同起点的团队该怎么做

同样的方法，在不同成熟度的团队里落地顺序完全不同。下面按四种典型情况给建议，你可以对号入座。

1. 情况一：还没有任何定级标准

不要写文档。先做一件事：拉出过去三个月所有线上事故和紧急修复的缺陷，把它们的原始描述抄在一张表里，逐条讨论当时应该定几级。这个过程通常两小时，产出的标准比任何模板都贴合你们。

然后按第一步的结论，只定义 P0 和 P1 的判定条件，P2 以下先不定。原因很简单：低等级的标准可以先粗，高等级的标准必须精确，因为高等级决定资源调配和发版决策，低等级只影响排序。

1. 第一周：用历史事故反推 P0/P1 标准，控制在十条以内
2. 第二周：在缺陷表单里加三个必填证据字段，不区分等级
3. 第三周：指定每个模块的定级复核人，只做 P1 以上
4. 第四周：开第一次校准会，抽 20 条样本

2. 情况二：有标准，但没人执行

这种情况最常见，本质是标准没有和工具绑定。人的执行力靠不住，约束得落在流程节点上。

具体做法是把「证据缺失」变成流转的硬条件。比如 P0 缺陷在缺少影响面数据时无法进入修复中状态，P2 以上缺陷在关闭时缺少回判字段就无法关闭。这类规则一旦生效，执行率会从三成跳到九成以上，因为绕过它的成本高于遵守它。

{
"workItemType": "defect",

"rules": [

{

"name": "P0 双签才能进入修复中",

"trigger": "status_change: 待修复 -> 修复中",

"condition": "severity in ['P0']",

"require": ["test_owner_approval", "dev_owner_approval"],

"blockMessage": "P0 缺陷需测试负责人与研发负责人双签确认后方可进入修复"

},

{

"name": "高等级缺陷必填影响面证据",

"trigger": "create",

"condition": "severity in ['P0', 'P1']",

"require": ["affected_scope", "reproduce_steps", "workaround_exists"],

"blockMessage": "请补充受影响范围、复现步骤与是否存在绕过方案"

},

{

"name": "关闭时强制回判",

"trigger": "status_change: * -> 已关闭",

"condition": "severity in ['P0', 'P1', 'P2']",

"require": ["final_impact_scope", "severity_rejudge"],

"blockMessage": "关闭前需填写真实影响面与回判等级"

}

]

}

上面这段是规则的结构示意，不同平台的配置方式不同，但逻辑是通用的：触发条件、前置校验、阻断提示。写规则时最容易犯的错是一次加太多，我建议每次只加一条，观察一周再加下一条，否则会引发集体抵触。

3. 情况三：多团队共用缺陷池

多团队场景的核心矛盾是定级权的归属。我的建议是明确一条规则：定级权归属于受影响最严重的那个团队，而不是提交方，也不是责任方。

这条规则看起来奇怪，但极其有效。因为受影响方最没有动机低定，也最有能力描述真实影响。它把博弈关系从「谁的责任」转成了「谁的损失」，而损失是可以量化讨论的。

配套动作有三个：跨团队缺陷必须指定一个唯一的定级归口人；跨团队争议必须在 24 小时内裁决；每季度公布各团队的高估率和漏判率排名，只公布不追责。公布本身产生的压力，比任何考核都有效，而且不会引发数据造假。

4. 情况四：交付型或强合规项目

这类项目的特点是合同或监管对缺陷有明确要求，比如遗留缺陷数量、等级分布的上限。这种情况下不能只做内部校准，要把定级标准写进交付物，并且和客户或审计方对齐口径。

我踩过的一个坑是：内部按五级分档，客户按三级验收，结果每次交付都要做一次人工映射，而且映射规则没写清楚，导致同一批缺陷在内部是 P2、在验收报告里变成严重缺陷。后来改成对外统一使用三级口径、对内保留五级，用固定映射表打通。

5. 情况五：想用工具固化的团队

如果前面几步都跑通了，需要把流程固化到平台里，这时候选型要考虑的不是功能多少，而是能不能表达你们的判定逻辑。具体要看三件事。

（1）字段和流转能否按工作项类型差异化配置

缺陷、需求、线上事件的严重程度语义不同，如果平台只能全局配置一套字段，你会发现所有工作项被迫共用一套不适用的档位。

（2）能否设置条件必填和条件阻断

这是把「证据门槛」落地的关键能力。没有这个能力，证据字段永远是可选项，而可选等于没有。

（3）能否把回判数据做成可统计的派生指标

回判字段填了但统计不出来，等于只做了记录没做校准。要看平台能不能按模块、团队、时间维度做交叉统计。

这几条在面向中大型组织的平台里通常都能满足，差别在于配置的灵活度和实施成本。PingCode 在这方面的特点是对象模型统一，缺陷和需求、迭代、发布共享同一套字段体系与权限模型，配置条件必填和流转阻断不需要额外开发，对一百人以上、多产品线的组织比较合适；代价是初次配置需要有人认真梳理一遍流程，不能开箱即用。工具能放大一套好流程，也能固化一套坏流程，这句话值得贴在选型会的白板上。

七、取舍：没有最优解，只有适配当下阶段的解

最后这一节讲取舍。我不太喜欢给「最佳实践」这种说法，因为大多数看起来最佳的做法，换一个组织阶段就是灾难。

1. 取舍一：严格分级还是轻量分级

严格分级的收益是数据可信、风险可控，成本是流程摩擦和填写负担。轻量分级的收益是提交快、阻力小，成本是数据不可用于决策。

我的判断线是缺陷月均提交量。月均低于 50 条时，轻量分级就够用，三级足够，不需要证据门槛；月均 50 到 200 条时，需要五级加 P0/P1 的证据门槛；月均超过 200 条时，必须做条件必填加自动建议档位，否则人工判断会成为瓶颈。

2. 取舍二：集中裁决还是分散裁决

集中裁决（设一个统一的定级委员会）一致性好，但响应慢，容易成为瓶颈。分散裁决（各团队自判）响应快，但一致性差。

我的经验是分层混合：P0/P1 集中裁决，因为数量少、影响大；P2 以下分散裁决，靠抽样复核和回判数据兜底。我在一个团队试过全部集中，结果是每周的定级会占用四个负责人各两小时，而讨论的八成是 P2/P3 的边界问题，投入产出极低。

3. 取舍三：自动化强制还是保留人工判断

把定级完全自动化（按关键词或影响面数据自动生成等级）看起来很先进，但我不建议在初期这么做。原因是定级里包含大量无法结构化的业务上下文，比如「这个客户下周要续约」。

更稳妥的做法是自动建议 + 人工确认 + 偏差记录。自动建议先把人从零开始思考的负担里解放出来，人工确认保留业务判断空间，偏差记录则持续优化建议规则。三轮迭代后，建议规则的采纳率通常能到七成以上，这时候再考虑提高自动化比例。

4. 取舍四：严重程度是否绑定 SLA

绑定 SLA 的好处是响应有保障，坏处是必然引发等级通胀，因为 SLA 是有成本的承诺，人会把问题往响应更快的档位放。

所以我的建议是：SLA 只绑定 P0 和 P1，P2 以下用迭代承诺而不是时限承诺。这样既保住了高危缺陷的响应保障，又避免了低等级缺陷的等级通胀。

5. 取舍五：一次做全还是分批推进

流程建设最常见的失败方式是「一次性上线完整方案」。矩阵、证据门槛、双签、校准会、回判统计一起上，两个月后全员抵触，最后整体回退。

分批推进的顺序我建议是：先证据门槛，再校准会，最后才做统计看板。证据门槛见效最快且不需要改变任何人的判断习惯；校准会需要投入会议时间，见效慢但持久；统计看板依赖前两步产生的数据质量，提前做只会得到一堆不可信的数字。

6. 取舍六：追求一致性还是保留弹性

这两者天然冲突。过度追求一致性会让流程僵化到无法处理特殊情况，过度保留弹性则让标准形同虚设。

我的做法是设置一个例外配额：每个团队每个季度可以有一定比例（比如 10%）的缺陷不按矩阵定级，但必须写明理由。配额用完后，例外需要上一级审批。这个机制的好处是既承认现实的复杂性，又防止例外变成常态。运行一年后回看这些例外记录，往往能发现标准本身需要修订的地方。

八、结语：严重程度是研发组织的一面镜子

写到最后，我想说一个可能有点反常识的判断：一个团队的缺陷严重程度分布，比它的缺陷数量更能说明研发健康度。数量反映产出规模，分布反映判断力和责任心。

如果 P0 常年只有个位数，但线上事故不断，说明标准太松或者在回避冲突；如果 P0 占比超过 8%，说明等级已经通胀，高等级信号失去意义；如果 P2 占比超过 70%，说明字段被默认值填充，整个体系已经空转；如果高估率和漏判率长期都不统计，说明这套体系只被用来排序，没有被用来学习。

这四种状态我在不同团队都见过，而且它们的修复路径完全不同。所以第一步永远不是套模板，而是先诊断自己处在哪种状态。

1. 三个我认为最值得坚持的原则

1. 严重程度和优先级必须分离。这不是形式主义，是让两个不同的决策各自有依据。合并之后，两个判断都会失真。
2. 标准必须绑定证据，而不是形容词。任何无法被第三方复核的定级，都只是投票。证据门槛是把投票变成判断的唯一手段。
3. 必须有回判和校准。没有反馈的判断会持续退化，这是人的认知规律，不是态度问题。校准会的价值不在于统一标准，而在于让偏差被看见。

2. 下一步：这周就能做的四件事

如果你读到这里想做点什么，不用等流程评审，这四件事本周就能启动，而且不需要任何工具投入。

• 抽 50 条已关闭缺陷，统计严重程度分布。十分钟就能看出你们的字段是否已经失效。
• 拉出过去三个月所有线上事故，看它们当初在缺陷池里的定级。这个数字会让所有人心服口服地承认问题的存在。
• 在缺陷表单里加三个必填字段：受影响范围、是否可绕过、是否涉及数据变更。不加等级判断，只加证据采集，阻力最小。
• 约一次 45 分钟的校准会，抽 20 条样本三方独立定级。先看分歧率是多少，再决定要不要改标准。

这四件事做完，你大概率会发现，团队的问题不是不知道该怎么定级，而是从来没有人把定级当成一件需要被设计、被执行、被复核的事。把它当成一件事来对待，剩下的都是细节。

而当你真的把这条链路跑通，会发现收益远不止缺陷管理本身。同一套「用两个正交维度压缩定性判断、用证据门槛收窄主观空间、用回判数据持续校准」的方法，可以直接迁移到需求优先级评估、线上事故定级、技术债分级上。这才是严重程度全流程真正的杠杆所在。