缺陷严重程度回答的是“这个缺陷对产品、用户和业务造成的损害有多大”，衡量影响本身；修复优先级回答的是“在现有资源和时间下，团队应当先处理哪一个缺陷”，衡量处理顺序。两者相关但不一一对应：严重程度高的缺陷通常会被优先处理，但严重程度低的缺陷也可能因为阻塞发布、影响关键客户或临近上线而被排到前面。理解这两个概念各自回答的问题，是团队在缺陷评审中减少分歧的前提。
要点总览（TL;DR）
- 缺陷严重程度回答“这个缺陷造成的损害有多大”，衡量影响本身；修复优先级回答“在现有资源和时间下先处理哪一个”，衡量处理顺序。
- 严重程度依据功能阻断、数据损坏、体验受损、安全风险等影响维度评估，不包含排期与资源判断；优先级综合影响、紧急度、影响范围、发布节点和资源约束做出排序。
- 严重程度高通常对应高优先级，但存在例外：偶现崩溃可能因修复成本高而暂缓，文案错误也可能因阻塞发布而提前。
- 严重程度与优先级属于缺陷分级范畴，与缺陷分诊（归谁处理）、工单优先级与SLA管理（响应时限）回答的问题不同。
- 把严重程度和优先级分开记录、分开讨论，团队可以先就影响达成一致，再就处理顺序做出决策。
一句话区分：影响有多大与先修哪一个
如果把缺陷管理看作一条从发现到关闭的流程，严重程度和修复优先级分别处在这条流程的两个不同环节。严重程度是对缺陷影响面的评估结论，回答“它有多严重”；修复优先级是对处理顺序的安排，回答“先做哪一个”。前者描述缺陷本身，后者描述团队的行动次序。
这两个概念容易混用，是因为它们经常同时出现在缺陷记录里，且高严重程度往往对应高优先级。但它们的判断依据不同：严重程度依据缺陷造成的功能、数据、体验或安全影响；优先级依据影响、紧急度、影响范围、发布节点和资源约束的综合权衡。一个缺陷的严重程度确定后通常保持相对稳定，而优先级会随着发布临近、客户反馈或资源变化而调整。
可以用一句话建立判断基准：严重程度是“评估”，优先级是“决策”。评估回答影响大小，决策回答处理顺序。团队讨论时先确认严重程度是否达成一致，再讨论在当前条件下如何排序，两个问题分开处理，争议会明显减少。
缺陷严重程度的定义与边界
缺陷严重程度衡量的是缺陷本身对产品、用户和业务造成的影响程度。它针对缺陷这一对象做影响评估，判断依据是缺陷触发后会产生什么后果，与团队何时修复、由谁修复无关。严重程度一旦评估完成，就构成缺陷的一个属性，供后续排序和统计使用。
常见的分级维度包括以下几类：
- 功能阻断：核心功能无法使用，用户无法完成主要任务，影响面通常最大。
- 数据损坏：数据丢失、错乱或被错误写入，后果可能不可逆，需要单独评估。
- 体验受损：功能可用但交互、文案、样式或性能表现影响使用感受，影响程度视场景而定。
- 安全风险：存在越权、信息泄露或其他安全暴露，影响范围可能超出单个用户。
严重程度不包含排期与资源判断。它不回答“什么时候修”“由谁修”“这个版本是否要带上”，这些属于优先级和排期决策的内容。把资源约束写进严重程度，会让影响评估失真：同一个缺陷在不同团队、不同时间被评成不同等级，后续的统计和对比就失去意义。
严重程度也不包括具体由谁处理、何时处理。评估严重程度时，团队只需要回答“如果这个缺陷存在，损害有多大”，不需要考虑当前人力是否充足、修复成本有多高。修复成本属于优先级决策的输入，不属于严重程度。
修复优先级的定义与边界
修复优先级衡量的是团队处理缺陷的顺序，回答“在现有资源和时间下，先处理哪一个”。它是一个排序决策，输出的是缺陷之间的相对次序，而不是缺陷本身的属性。同一个缺陷在不同发布阶段、不同客户背景下，优先级可以不同。
影响优先级的因素通常包括：
- 严重程度：影响越大的缺陷，通常越需要靠前处理。
- 紧急度：缺陷是否正在造成持续损失，是否需要立即止血。
- 影响范围：受影响用户或业务线的数量与重要性。
- 发布节点：是否阻塞当前版本的发布或验收。
- 资源约束：修复成本、所需人员是否可用、是否存在依赖关系。
优先级不改变缺陷本身的影响程度。把某个缺陷排到前面，不会让它变得更严重；把某个缺陷排到后面，也不会让它变得不严重。优先级调整的是处理次序，严重程度记录的是影响事实，两者在缺陷记录中应分别维护。
优先级也不包括缺陷分诊中的责任分配与工单SLA管理。分诊解决“这个缺陷归谁处理”，SLA管理解决“响应和解决时限是多少”，优先级解决“先做哪一个”。三者可能在同一场评审中讨论，但回答的问题不同，混在一起容易导致责任、时限和顺序互相替代。
两者如何联动：从评估到排序的机制
严重程度与优先级在缺陷处理流程中前后衔接：先评估严重程度，形成对影响的事实判断；再结合紧急度与上下文确定优先级，形成处理顺序。这个顺序不能颠倒，否则排序会失去稳定的依据。
联动机制可以概括为三步。第一步，评估严重程度，记录缺陷对功能、数据、体验和安全的影响，形成团队可复用的影响判断。第二步，收集排序所需的上下文，包括是否阻塞发布、影响哪些客户、是否涉及合规要求、修复所需资源是否到位。第三步，综合两者确定优先级，并在缺陷记录中写明排序理由，便于后续复盘和调整。
高严重程度通常对应高优先级，但存在例外。例如一个严重程度很高的偶现崩溃，如果复现困难、定位成本高，团队可能先安排资源收集日志，同时把优先级排在可快速止血的缺陷之后。反过来，低严重程度也可能获得高优先级，常见情形包括：
- 阻塞发布：文案或配置类缺陷影响验收流程，必须在发布前修复。
- 关键客户：缺陷影响重要客户的正常使用，需要优先响应。
- 合规要求：缺陷涉及合规或审计要求，处理时限受外部约束。
在缺陷记录中，严重程度和优先级通常作为两个独立字段维护，并配合状态、指派人和版本信息使用。以 ONES 为例，缺陷工作项可以分别记录严重程度与优先级，并通过筛选和视图按优先级排列待处理缺陷，让影响评估与排序决策各自留痕。团队在评审时可以先核对严重程度是否准确，再讨论优先级是否需要调整，两个动作分开进行。
容易混淆的相邻概念
严重程度和优先级属于缺陷分级范畴，但缺陷管理中还有几个相邻概念，它们回答的问题各不相同。把它们放在一起对照，有助于在评审中准确使用术语。
| 概念 | 回答的问题 | 主要关注点 |
|---|---|---|
| 缺陷严重程度 | 这个缺陷造成的损害有多大 | 功能、数据、体验、安全的影响评估 |
| 修复优先级 | 在现有条件下先处理哪一个 | 影响、紧急度、范围、发布节点、资源的综合排序 |
| 缺陷分诊 | 这个缺陷归谁处理 | 处理归属与责任分配 |
| 工单优先级与SLA管理 | 响应和解决的时限是多少 | 响应时限、解决时限与服务承诺 |
缺陷分诊关注处理归属与责任分配，通常在缺陷提交后尽快完成，决定由哪个团队或个人接手。工单优先级与SLA管理关注响应时限，服务于服务承诺的达成情况。严重程度与优先级属于缺陷分级范畴，服务于影响判断和排序决策。四者可以在同一流程中先后出现，但各自回答的问题不同，不能用其中一个替代另一个。
实践中常见的混淆是把分诊结果当作优先级，或者用SLA时限倒推优先级。分诊确定的是责任人，SLA确定的是时限，优先级确定的是顺序。三者分开记录，缺陷流程中的责任、时限和顺序才都有据可查。
具体例子与常见误解
用具体场景说明两者可能不一致，比抽象定义更容易形成共识。
示例一：界面文案错误。某页面提示文案存在错别字，严重程度评估为低，因为它不影响功能使用，也不造成数据问题。但该页面即将上线对外发布，文案错误会直接影响品牌形象，团队将其优先级排到发布前必须修复的位置。这个例子里，严重程度低而优先级高，原因是发布节点改变了排序。
示例二：偶现崩溃。某功能在特定操作下偶现崩溃，严重程度评估为高，因为崩溃会导致用户任务中断。但该问题复现困难、日志不足，定位需要额外投入，团队先安排收集信息，同时把可快速止血的缺陷排在前面。这个例子里，严重程度高但优先级未排在最前，原因是修复成本和不确定性影响了排序判断。
围绕这两个概念，常见的误解有三类：
- 误解一：严重程度高就等于优先级高。严重程度是影响评估，优先级是排序决策。发布节点、客户影响和资源约束都会让两者出现偏差，高严重程度缺陷可能因为修复成本高而暂缓，低严重程度缺陷也可能因为阻塞发布而提前。
- 误解二：优先级由开发人员凭感觉决定。优先级是团队决策，需要依据严重程度、紧急度、影响范围、发布节点和资源约束综合判断，并在缺陷记录中写明理由。凭感觉排序会导致同类缺陷在不同时间得到不同处理，复盘时难以解释。
- 误解三：两者可以合并为一个字段。合并后，影响评估和排序决策互相污染：严重程度会随排期变化而失真，优先级也失去稳定的评估基础。分开维护两个字段，才能既保留影响事实，又支持灵活排序。
把严重程度和优先级分开记录、分开讨论，团队在缺陷评审中就能先就“有多严重”达成一致，再就“先做哪一个”做出决策。两个问题各自有明确的回答对象，缺陷处理顺序也更容易向相关方解释。
常见问题
严重程度评估完成后，优先级还会变化吗？
会。严重程度记录的是缺陷本身的影响事实，评估完成后通常保持相对稳定；优先级是排序决策，会随发布节点临近、客户反馈变化或资源到位情况而调整。同一个缺陷在版本发布前可能被排到前面，发布后优先级下降，但严重程度不变。团队在缺陷记录中应分别维护这两个字段，调整优先级时不需要改动严重程度。
如果团队对某个缺陷的严重程度判断不一致，应该先讨论什么？
先回到影响事实：这个缺陷触发后会造成什么后果，影响哪些功能、数据和用户，是否涉及安全风险。把讨论集中在后果描述上，而不是修复难度或排期安排。影响事实达成一致后，再进入优先级讨论，结合发布节点、客户影响和资源约束确定顺序。两个问题分开讨论，可以避免用排期理由反向压低严重程度。
低严重程度的缺陷被排到高优先级，需要在缺陷记录中说明理由吗？
建议说明。低严重程度缺陷获得高优先级，通常有明确的外部原因，例如阻塞发布验收、影响关键客户或涉及合规时限。在缺陷记录中写明排序理由，后续复盘时能解释为什么这个缺陷被提前处理，也便于相关方理解处理顺序。理由缺失时，同类缺陷在不同时间可能得到不同处理，团队难以形成稳定预期。
缺陷分诊和优先级排序可以在同一次评审中完成吗？
可以在同一次评审中完成，但建议按顺序分开处理：先确认严重程度，再确定优先级，然后完成分诊指派责任人。分诊回答“归谁处理”，优先级回答“先做哪一个”，两者输出不同。如果先指派责任人再排序，容易出现按团队分工而非按影响排序的情况。分开记录分诊结果和优先级，责任和顺序都有据可查。
工单的SLA时限能否直接作为缺陷修复优先级的依据？
SLA时限可以作为优先级的输入之一，但不建议直接替代优先级判断。SLA管理关注响应和解决的时限承诺，优先级关注缺陷之间的处理顺序。一个临近SLA时限的工单可能需要优先响应，但同期可能存在影响更大、更需要立即修复的缺陷。团队应把SLA时限与严重程度、发布节点、影响范围一起纳入排序考虑，并在记录中写明取舍理由。
