缺陷记录里常出现这样的争论：测试认为问题很严重，开发认为当前排不上。分歧往往来自把“影响多大”和“多快处理”当成同一件事。严重程度描述缺陷对系统功能和业务造成的后果，优先级描述团队计划在多长时间内处理它。本文解释两个概念的定义、边界和组合方式，并说明高严重低优先级、低严重高优先级在什么条件下成立。
要点总览（TL;DR）
- 严重程度判断缺陷造成多大影响，优先级决定团队多快处理它，两者分别记录才能让评审有据可依。
- 严重程度不负责排期，优先级不描述技术影响；用优先级高低推断严重程度，容易低估遗留问题风险。
- 高严重低优先级成立的条件通常是当前版本未暴露该风险、存在稳定规避方案或修复成本过高；低严重高优先级多由发布节点、关键客户或低修复成本推动。
- 缺陷分级包含严重程度与优先级两个字段，缺陷分诊负责确认与分配责任，工单优先级与SLA面向服务响应时限，三者管理动作不同。
- 把两个字段分开填写并写明判定理由，可以减少评审会上反复争论“急不急”的沟通成本。
缺陷优先级与严重程度分别指什么
严重程度（Severity）衡量缺陷本身造成的损害：功能是否可用、数据是否出错、用户是否受到明显影响。它回答的问题是“这个缺陷有多坏”。判定依据主要来自缺陷的技术后果和业务后果，例如核心流程是否被阻断、是否造成数据丢失或错误、是否存在可用的替代操作、影响的是全部用户还是少数用户。
优先级（Priority）衡量处理顺序和时间紧迫性：团队应当先修哪个、可以后修哪个。它回答的问题是“这个缺陷多快要处理”。判定依据除了严重程度，还包括发布节奏、缺陷影响的客户或业务线、是否存在临时规避方案、修复成本与依赖关系。同一个缺陷在不同迭代阶段，优先级可能变化，严重程度通常保持稳定。
两个术语的区别可以用一句话概括：严重程度是对后果的判断，优先级是对行动的排序。前者由缺陷的性质决定，后者由团队在当前资源与时间约束下的取舍决定。把两者分开记录，团队才能在评审时分别讨论“问题有多严重”和“现在是否值得优先投入”。
| 对照项 | 严重程度 | 优先级 |
|---|---|---|
| 回答的问题 | 缺陷造成多大影响 | 应当多快处理 |
| 主要判定依据 | 功能阻断、数据影响、体验影响、影响范围 | 发布节点、客户影响、替代方案、修复依赖 |
| 典型判定角色 | 测试、业务方、产品 | 产品、项目经理、研发负责人 |
| 变化频率 | 较低，随缺陷性质确定 | 较高，随排期和发布计划调整 |
两个维度的边界：各自管什么、不管什么
严重程度只管影响判断。它不决定由谁处理、在哪个迭代处理、什么时候上线。一个被定为“严重”的缺陷，仍然可能因为当前版本不涉及该模块、已有临时规避方案而排在后面。把严重程度直接当作排期结论，会让缺陷评审变成对影响程度的反复争论，而真正需要协调的资源与时间问题被搁置。
优先级只管处理顺序。它不描述缺陷本身的技术影响，也不能反过来证明缺陷“不严重”。一个优先级被调高的缺陷，可能影响范围很小，只是因为阻塞了即将发布的版本或涉及关键客户。用优先级高低去推断严重程度，容易在复盘时低估遗留问题的风险。
还需要区分本文不展开的相邻管理动作：缺陷分诊负责判断缺陷是否成立、由哪个模块或团队承接、是否需要补充信息，属于责任分配环节；工单优先级与SLA管理面向服务请求的响应时限承诺，属于服务级别管理。这些动作与缺陷分级相关，但各自解决的问题不同，本文只做概念区分，不展开具体流程与设置规则。
严重程度与优先级如何组合成处理顺序
严重程度分级通常按后果从重到轻划分。常见依据包括：功能完全阻断或核心流程不可用；数据错误、丢失或安全问题；主要功能受损但存在替代操作；界面、文案、体验类问题。具体档位名称各团队可以不同，关键是每一档有可核对的判定条件，让不同提交人给出相对一致的结论。
优先级分级通常按时间紧迫性划分，常见档位包括立即处理、本迭代处理、排入后续版本、择机处理。判定时依次考虑：是否阻塞当前发布、是否影响关键客户或核心业务、是否有可用的临时规避方案、修复是否依赖其他改动。把这些因素写进评审规则，优先级就不再由单个提交人的主观感受决定。
两个维度组合后形成处理顺序。高严重高优先级的缺陷进入当前迭代优先修复；高严重低优先级的缺陷进入遗留问题清单，明确规避方案和计划处理时间；低严重高优先级的缺陷通常因为阻塞发布或影响关键客户而被提前；低严重低优先级的缺陷进入常规排期。
两种看似矛盾的情况都有成立条件。高严重低优先级成立的前提是：缺陷所在功能当前版本未启用、影响用户可通过替代路径完成操作、或修复需要较大架构调整而当前有稳定的规避方案。低严重高优先级成立的前提是：缺陷位于即将发布的对外演示或交付版本的关键路径上、影响的是合同约定的关键客户、或修复成本很低而延迟会带来额外沟通成本。无论哪种情况，都应在缺陷记录中写明理由，便于后续复盘。
容易混淆的相邻概念：缺陷分级、缺陷分诊与工单优先级
缺陷分级是一个更大的概念，包含严重程度、优先级，也可能包含缺陷类型、复现概率等分类维度。严重程度和优先级是分级中的两个字段，不能互相替代。讨论“这个缺陷怎么分级”时，需要分别给出各维度的取值，而不是只填一个综合等级。
缺陷分诊（Triage）是一个管理动作，指对新增缺陷进行确认、去重、补充信息、判断归属模块和承接团队。分诊的产出是“这个缺陷是否成立、由谁跟进”，严重程度和优先级可以在分诊中初步填写，但分诊本身不负责排期决策。把分诊和定级混在一起，容易出现“分给谁就等于多快修”的误解。
工单优先级面向服务请求的响应承诺，与SLA绑定，衡量的是对提出方的响应时限。缺陷优先级面向研发排期，衡量的是修复顺序。两者可能使用相似的档位名称，但判定依据和管理目标不同。ONES Desk 支持评估和定义工单优先级，用于优先解决紧急事件，这属于工单场景的能力；缺陷优先级的判定仍应回到研发排期规则中讨论。
| 概念 | 回答的问题 | 对应的管理动作 |
|---|---|---|
| 严重程度 | 缺陷影响多大 | 影响评估与定级 |
| 优先级 | 多快处理 | 排期与资源分配 |
| 缺陷分级 | 缺陷按哪些维度分类 | 建立字段与取值规范 |
| 缺陷分诊 | 缺陷是否成立、由谁承接 | 确认、去重、分配责任 |
| 工单优先级与SLA | 服务请求多久响应 | 服务时限承诺与跟踪 |
具体例子与常见误解
演示场景一：某后台管理系统的报表导出功能在数据量超过十万行时偶发超时，核心业务流程不受影响，且运营人员可以分批次导出。该缺陷造成数据导出失败，属于较严重的功能受损，可定为高严重程度；由于存在替代操作、当前版本不涉及大批量导出场景，优先级可定为中低，排入后续迭代并记录规避方案。
演示场景二：某对外演示页面的按钮文案错别字，功能完全正常。按影响判断属于低严重程度；但该页面将在两天后用于客户演示，修复只需几分钟，优先级被调高至当前迭代立即处理。这个例子说明优先级可以由发布节点和修复成本推动，而不改变缺陷本身的严重程度。
常见误解之一是“严重程度高就必须立刻修”。严重程度高说明后果重，是否立刻修取决于当前版本是否暴露该风险、是否有规避方案、修复是否会挤占更紧迫的发布任务。把两者等同，会让团队在资源有限时无法做出取舍，也让严重程度字段失去独立的信息价值。
常见误解之二是“优先级由提交人决定”。提交人可以提供影响信息和业务背景，优先级应由产品、项目经理和研发负责人结合排期共同确认。由提交人单方面设定优先级，容易造成各方都把自己的问题标为最高，最终排序失效。
这些误解带来的后果很具体：缺陷列表里大量条目被标为最高优先级，团队无法区分真正需要先处理的问题；严重程度被随意填写，复盘时无法统计真实的质量风险；评审会上反复争论同一个缺陷“到底急不急”，却没有人确认规避方案和计划处理时间。把两个字段分开填写、分别给出判定理由，并在评审中按维度讨论，能减少这类沟通成本。
当团队把严重程度和优先级作为两个独立字段管理时，需要在缺陷工作项中稳定记录取值和判定理由，并让状态流转与排期结果可追踪。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代并跟踪修复情况，也可统计缺陷状态分布，便于团队按分级结果查看缺陷构成。把分级规则落到工作项字段和流转过程中，两个维度的判定才能在每次提交和评审时保持一致。
常见问题
团队规模较小、没有专职测试时，严重程度和优先级由谁来定？
可以由同一人初步填写两个字段，但建议在提交时分别写明判定依据：严重程度写清功能是否阻断、数据是否受影响、影响范围多大；优先级写清是否阻塞当前发布、是否有规避方案。评审时由产品负责人或研发负责人确认优先级，测试或业务方确认严重程度。角色合并时，两个字段仍分开记录，避免一个人凭整体感觉只填一个综合等级。
缺陷修复后严重程度需要重新评估吗？
严重程度描述缺陷本身的性质，修复完成后通常不再变化，保留原值有助于复盘统计。如果修复过程中发现影响范围比最初判断更大或更小，可以更新严重程度并注明原因。优先级则不同，缺陷关闭后不再参与排期，其历史取值可作为后续类似问题的参考。建议在缺陷记录中保留字段变更记录，便于回溯判断是否准确。
同一个缺陷在不同迭代阶段优先级变化，需要重新走评审吗？
优先级随发布节奏调整属于正常情况，不必每次重走完整评审。可以在迭代规划时集中确认一次，由产品负责人或项目经理更新取值并写明调整原因，例如“该功能本迭代对外交付，优先级上调”。严重程度一般不随迭代变化，若同时需要调整，应单独说明依据。关键是变更留痕，让后续查看缺陷的人理解当时的排期背景。
缺陷优先级和工单优先级使用相同的档位名称，会不会造成混乱？
档位名称相似本身不是问题，问题在于两套判定依据被混用。缺陷优先级面向研发排期，依据是发布节点、影响范围和修复依赖；工单优先级面向服务响应时限，与SLA承诺绑定。建议在字段说明中写清各自适用对象，并在跨团队沟通时明确说的是哪一类优先级。ONES Desk 支持评估和定义工单优先级，用于优先解决紧急事件，这属于工单场景的能力，缺陷优先级的判定仍应回到研发排期规则中讨论。
严重程度和优先级都填了，但评审时仍然争论不休，问题出在哪？
常见原因是判定条件没有写成可核对的规则，每个人按自己的理解填写。可以先把严重程度的各档位对应到具体后果描述，例如“核心流程不可用”“数据错误”“存在替代操作”，再把优先级的判定因素按顺序列出，例如是否阻塞发布、是否影响关键客户、是否有规避方案。规则明确后，评审的重点从争论档位转向确认事实和规避方案，沟通成本会明显下降。
