严重程度与优先级是什么
严重程度（Severity）衡量缺陷对系统的影响：功能失效范围、数据是否损坏、有无绕行方案；优先级（Priority）决定修复的先后顺序：业务窗口、客户影响、发布计划都是输入。两者相互独立——崩溃但影响面小可能优先级不高；关键入口的文案错误看似轻微，也可能因为品牌与合规风险被排到最前。分开评估，修复排期与影响沟通才不会互相绑架。
基本信息
| 严重程度维度 | 功能影响、数据损坏、安全风险、有无绕行方案 |
|---|---|
| 优先级维度 | 业务影响面、客户承诺、发布窗口、修复成本 |
| 定责分工 | 严重度由报告者初判、分级会复核；优先级由业务与产品确认 |
| 常见分级 | 阻断/严重/一般/轻微，或 S1-S4，各团队需写清判定标准 |
| 变更规则 | 定级后调整需留下理由与确认人，避免事后扯皮 |
组合
| 组合 | 处理策略 |
|---|---|
| 高严重 + 高优先 | 立即修复，发布阻断 |
| 高严重 + 低优先 | 定期评估并说明理由 |
| 低严重 + 高优先 | 关联品牌与合规风险，按窗口修 |
| 低严重 + 低优先 | 进入常规积压池 |
典型使用场景
- 分派评审：每周定级会校准争议缺陷的严重度与优先级。
- 发布门禁：按「阻断/非阻断」判定本次版本能否放行。
- 排期协商：把优先级带到迭代计划会，与需求排同一张表。
- 客户沟通：以严重度口径向客户解释影响与修复承诺。
- 度量分析：按严重度看缺陷分布，识别质量薄弱模块。
- 积压治理：长期积压的低优先级项定期复核或明确关闭。
严重程度建议由报告者初判、分级会复核；优先级由业务与产品共同确认。
定级标准要写进缺陷模板：各档给出判定例子（如「核心流程不可用」「数据写入错误」），减少临场拍脑袋。
数据损坏与安全类缺陷定级从严：影响不可逆，修复窗口过了代价成倍上升。