缺陷等级确认责任要解决的是：一条缺陷从提交到形成可执行的等级结论，谁提供依据、谁给出初始等级、谁在分歧时做最终裁定，以及结论如何留痕。把这三层责任固定下来，定级就不再依赖个人经验或临时争论。需要说明的是，等级确认只判断严重程度与影响范围；缺陷派给谁修、先修哪一条属于分诊与责任分配，响应时限属于优先级与SLA管理，这三类事项分开设置责任人，才能避免互相顶替。
要点总览（TL;DR）
- 缺陷等级确认采用三层分工：提交人提供可复现事实，模块负责人或测试负责人给出初始等级，产品负责人或质量负责人对争议等级和高风险等级做最终裁定。
- 定级按提交、初始定级、等级确认、争议裁定、结论归档五步执行，每步都有输入、动作、输出和完成标志，结论才算成立。
- 等级确认只判断严重程度与影响范围；派给谁处理属于分诊与责任分配，响应时限属于优先级与SLA管理，三类事项分开设置责任人。
- 争议等级由双方先写明依据，再提交产品负责人或质量负责人裁定，裁定结论和依据写入缺陷记录，上报路径不宜层层加签。
- 机制落地的标志是每条缺陷都能查到等级、依据、确认人和确认时间，等级结论可被后续环节直接引用而无需重新争论。
缺陷等级确认责任的核心答案与操作步骤
核心判断是：缺陷等级确认采用三层分工。提交人负责提供可复现的事实，初始定级人负责依据等级定义给出建议等级，最终裁定人对争议等级或高风险等级做确认。三层各自有明确输出，定级结论才算成立。
把定级做成固定环节，可以按以下五步执行。每一步都写明输入、动作、输出和完成标志，便于团队照着落地。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交缺陷 | 缺陷现象、复现步骤、环境信息、影响范围描述 | 提交人按模板填写，尽量给出可复现路径和受影响的用户、功能或数据范围 | 一条信息完整的缺陷记录 | 复现步骤可被他人按描述重现，影响范围有具体描述 |
| 2. 初始定级 | 缺陷记录、等级定义与判定依据 | 模块负责人或测试负责人对照等级定义，给出建议等级并写明判断理由 | 初始等级与定级依据 | 等级有对应条款支撑，理由可被复核 |
| 3. 等级确认 | 初始等级、影响范围、业务背景 | 产品负责人或质量负责人复核初始等级，对高风险或存疑等级做确认 | 确认后的等级、确认人、确认时间 | 缺陷记录中可查到确认人与确认时间 |
| 4. 争议裁定 | 分歧双方的定级理由 | 提交裁定请求，由最终裁定人依据等级定义和影响范围作出结论 | 裁定结论与裁定依据 | 裁定记录可追溯，分歧关闭 |
| 5. 结论归档 | 确认或裁定后的等级 | 将最终等级、依据、确认人、确认时间写入缺陷记录 | 完整的定级留痕 | 后续处理可引用该等级，无需重新争论 |
需要划清的边界有三条。等级确认回答“这条缺陷有多严重、影响多大”；分诊与责任分配回答“由谁处理、转给哪个模块”；优先级与SLA回答“多快响应、排在第几位”。三者可以由不同角色负责，但等级结论应当是分诊和优先级判断的输入之一，而不是被它们反向改写。
定级角色与交付物分工
角色分工的关键是每个角色都有明确交付物，交接时以交付物为准，减少口头确认和责任悬空。下表给出常见分工，团队可结合规模调整兼任方式，但职责本身不宜合并到无人负责。
| 角色 | 职责边界 | 在定级环节的交付物 |
|---|---|---|
| 提交人 | 提供事实，不负责最终等级判定 | 复现步骤、环境信息、影响范围描述、必要的截图或日志 |
| 测试负责人 | 从质量视角判断缺陷的严重程度与影响面 | 初始等级建议、判断依据、需要补充的验证信息 |
| 模块负责人 | 从技术实现视角说明影响范围与触发条件 | 影响模块说明、技术影响评估、对初始等级的意见 |
| 产品负责人 | 从业务影响视角确认等级，尤其是用户可见影响 | 业务影响判断、等级确认意见 |
| 质量负责人 | 对争议等级或高风险等级做最终裁定，维护等级定义的一致性 | 裁定结论、裁定依据、确认人与确认时间 |
争议等级的上报路径应当简短且固定：初始定级人与模块负责人意见不一致时，先由双方各自写明依据；仍无法达成一致的，提交给产品负责人或质量负责人裁定。裁定人依据等级定义和影响范围作结论，并将裁定理由写入缺陷记录。上报路径不宜层层加签，否则定级会变成等待审批，拖慢后续处理。
在缺陷记录中保留确认人、确认时间和定级依据，是责任可追溯的基础。使用 ONES 管理缺陷时，可以在缺陷工作项中设置等级字段，并通过字段记录或评论保留确认人与确认时间，让定级结论随缺陷一起流转，后续分诊和处理都能引用同一份结论。
缺陷等级确认的示例：一条支付缺陷如何定级
以下为演示情景，用于说明定级责任的流转方式，不代表任何真实项目数据。
某电商系统在测试环境中发现：部分用户在提交订单后，支付页面偶发白屏，刷新后可恢复。提交人在缺陷记录中写明复现步骤、涉及的浏览器版本、出现频率，以及受影响的下单流程环节，并附上错误日志。这一步的交付物是可供他人复现的事实描述。
测试负责人对照等级定义，判断该缺陷影响支付主流程且用户可见，给出较高的初始等级，并写明依据：影响核心交易环节、存在用户流失风险、出现频率尚不稳定。模块负责人补充技术影响说明，确认问题出在前端支付组件加载环节，影响范围限于特定浏览器。双方对等级没有分歧，进入确认环节。
产品负责人从业务影响角度复核，认可初始等级，并在缺陷记录中填写确认意见、确认人和确认时间。若模块负责人认为影响范围有限、应降低等级，则由双方写明理由后提交质量负责人裁定，裁定结论和依据一并记录。最终，这条缺陷带着确定的等级进入后续分诊和处理，处理人无需再次争论严重程度。
这个示例说明两点：定级依据要具体到影响对象和触发条件，避免只写“严重”或“一般”；确认与裁定都要留下人和时间，使等级结论在后续环节可被引用和复核。
定级机制落地与完成检查
判断团队的定级责任机制是否真正执行，可以按以下清单逐项核对。清单中的每一项都对应可观察的记录或产物，而不是笼统的“沟通顺畅”。
- 等级定义与判定依据已书面化，包含每个等级对应的严重程度、影响范围和典型示例，团队成员能引用同一条款讨论。
- 每条缺陷记录中都能查到确认人和确认时间，确认动作有明确的责任角色。
- 出现等级分歧时，有裁定记录，包含分歧点、裁定结论和裁定依据。
- 定级与分诊、优先级分开管理，等级结论不会被处理排期反向改写，也不会用响应时限替代严重程度判断。
- 提交人的缺陷描述包含复现步骤和影响范围，初始定级人能在不反复追问的情况下给出等级建议。
- 定期抽查已关闭缺陷，确认等级、依据、确认人三项信息完整，缺失的记录能被补正并说明原因。
检查时若发现多数缺陷只有等级、没有依据和确认人，说明定级仍停留在个人判断阶段，需要回到步骤表补齐输入与留痕；若发现等级频繁被处理排期改动，说明定级与优先级边界不清，应重新明确两类事项的责任人。机制落地的标志是：一条缺陷的等级结论可以被他人直接引用，而无需重新组织讨论。
常见问题
团队规模较小、角色由一人兼任时，定级责任还能怎么分？
可以兼任，但职责本身要保持可区分。例如测试负责人同时承担初始定级和等级确认时，仍应在缺陷记录中分别写明初始等级建议和确认意见，确认人与确认时间照常填写。产品负责人和质量负责人由同一人担任时，争议裁定记录中要写清裁定依据，避免确认与裁定混成一次口头决定。兼任的底线是：提交事实、给出等级、最终裁定这三个动作在记录上能分开追溯。
缺陷已经进入处理阶段，发现等级定错了怎么办？
按争议裁定路径处理，而不是由处理人自行改等级。由提出异议的一方写明理由和新的影响范围证据，提交给最终裁定人复核；裁定人依据等级定义作出结论，并把修改原因、裁定人和时间写入缺陷记录。等级变更后，分诊和优先级可以据此重新判断，但等级结论本身仍以裁定记录为准。保留变更历史，便于后续抽查时区分正常修正和随意改动。
等级定义写多细才够用？
够用的标准是：初始定级人对照条款能给出等级并写明理由，其他人复核时能判断理由是否成立。每个等级至少写明严重程度、影响范围（用户、功能、数据）和典型示例，并对边界情况给出说明，例如主流程偶发问题与边缘功能稳定故障分别归入哪一级。等级定义过于笼统会导致定级依赖个人经验，过于细碎则难以执行，建议先用典型缺陷案例校准一轮再定稿。
定级确认和缺陷分诊在同一次会议上完成，会不会混淆责任？
可以同场讨论，但输出要分开记录。会议中先形成等级结论，写明依据、确认人和确认时间；再基于该等级讨论由谁处理、排在什么位置。记录上区分“等级确认”和“处理分配”两个动作，避免用处理排期反推等级，也避免因为没人接单就压低等级。若会上无法就等级达成一致，按裁定路径单独处理，不把分歧带入分诊环节。
怎么抽查定级责任是否真的在执行？
定期抽取已关闭缺陷，核对三项信息：等级是否有对应条款支撑的依据、是否有确认人和确认时间、出现分歧时是否有裁定记录。再抽查等级是否被处理排期改动过，若有改动是否走了裁定路径。多数记录只有等级、缺少依据和确认人，说明定级仍停留在个人判断，需要回到步骤表补齐输入与留痕。
