严重程度管理方法大全：实施团队Bug / 缺陷落地方案落地清单

严重程度管理方法大全：实施团队Bug / 缺陷落地方案落地清单

严重程度最高的缺陷，不一定最先修；用户喊得最响的问题，也不一定影响最大。实施团队真正容易失控的，往往不是缺陷数量，而是把“影响有多严重”和“现在有多急”混成一个等级：生产数据损坏被标成普通问题，演示环境的小瑕疵却被升成最高级，最后所有人都在抢“最高优先级”。要让缺陷管理落地，团队必须把判级依据、升级条件、响应时限、修复验证和关闭证据连成一套可审计的规则。

一、先讲结论：严重程度管影响，优先级管顺序

1. 严重程度不是“谁更着急”的投票结果

我判断缺陷严重程度时，先问一个问题：如果暂时不修，用户、业务流程、数据或合规会受到什么影响？这个答案决定严重程度。客户催得很急、管理者正在关注、问题发生在发布前，这些因素可以影响修复优先级，却不能单独证明缺陷本身更严重。

严重程度（Severity）描述缺陷造成的影响范围与后果；优先级（Priority）描述组织准备以什么顺序投入资源处理。前者是对影响的分类，后者是当前的决策。两者可以相关，但不应被压成同一字段。

举例来说，某个客户的月度报表导出按钮在特定浏览器上失效，若有稳定替代方式，影响可能是中等；但如果这个客户当天要完成监管报送，业务优先级可能很高。反过来，一项很少触发的权限边界缺陷，当前工单量可能很低，严重程度却可能很高，因为它暴露了敏感数据。

2. 先统一四级影响模型，再允许团队本地化

多数实施团队不需要一开始就设计十几档等级。我更建议先用四级模型：S0 灾难级、S1 严重级、S2 一般级、S3 轻微级。等级名称只是入口，真正起作用的是每一级的触发条件、例外规则和升级责任人。

等级不能只靠“影响多少人”判定。一个用户也可能代表一个关键业务主体；一条错误权限规则也可能比大量页面错位更危险。团队应同时观察影响范围、业务关键性、数据与安全风险、可绕行性和后果是否可逆。

3. 把判级、排期和承诺分成三个动作

我建议缺陷流程中至少保留三个不同判断：严重程度由业务影响事实决定；优先级由产品、交付和业务共同权衡；修复承诺由负责人结合定位难度、风险、依赖和发布窗口给出。若工单只有一个“高、中、低”，团队往往无法判断争议究竟发生在影响评估、业务排序还是排期承诺。

核心规则可以写成一句话：严重程度回答“坏到什么程度”，优先级回答“现在先做什么”，修复计划回答“谁在何时交付什么”。三者分开，团队才能在不篡改事实的前提下调整资源。

二、背景和真实场景：实施团队为何比单纯研发团队更容易判级失真

1. 一个缺陷通常同时牵涉产品、配置、数据和客户现场

实施团队面对的缺陷，常常不是一段代码单独造成的。问题可能来自产品逻辑、客户配置、历史数据、接口映射、权限设置、浏览器环境或操作培训。报障现场看到的是“流程卡住了”，但原因可能是产品缺陷，也可能是配置差异。若未先确认对象，就直接给等级，团队会把原因猜测误当成影响事实。

例如，客户说“审批提交失败”，这句话不足以判为 S1。需要确认：失败发生在哪个环节？是否所有审批人都无法提交？是否只影响一个表单？有没有替代路径？数据是否已写入但页面显示失败？影响是否会持续累积？同一现象背后可能对应完全不同的严重程度。

2. 客户现场的时间压力会扭曲等级

实施人员往往在客户会议、验收、切换或月末结账期间接到问题。此时“今天必须解决”是真实的业务约束，却不必然意味着缺陷影响等级最高。如果把客户的截止时间直接映射成 S0 或 S1，等级很快会失去区分能力；更合理的做法是保留客观严重程度，再单独标注业务窗口和处理优先级。

我会把客户影响描述写成可核验事实，而不是情绪标签。比如“客户很着急”需要转成“该客户需在 16:00 前完成 2,400 条订单对账，当前页面无法批量导出，人工逐条处理预计 6 小时”。事实能帮助团队做优先级判断，也方便复盘时验证当时的选择。

3. 缺陷等级本身也有成本

最高等级会触发更多人、更快沟通和更频繁汇报。它不是免费的标签。若团队把大量普通问题都标成最高级，工程人员会被上下文切换打断，真正的事故反而得不到清晰响应。另一方面，过度压低等级也会导致风险积累，尤其是数据完整性、权限边界和跨客户影响这类不容易从工单数量看出的隐患。

所以我关注的不只是高等级缺陷的数量，还会看“判级后是否发生降级”“同一模块反复升高”“初判与复核差异”“绕行方案使用次数”。这些过程指标能解释等级制度究竟在分流，还是只在制造标签。

三、常见误区：看似省事，最后会把管理成本转移给全团队

1. 把严重程度和优先级合并成一个字段

这是最常见、也最难在后期修复的问题。团队通常先用“紧急、重要、普通”一个字段，表面上简单，后来发现无法回答两个不同问题：缺陷到底造成了多大影响？为什么它排在其他问题之前？管理者只能在工单评论里追问，数据也无法支持复盘。

当两个判断必须暂时共用一个字段时，我会要求字段说明明确写出当前采用的维度，并设置每周复核，而不是把混合字段当成成熟机制。更好的长期方案是保留严重程度、优先级、目标修复版本或承诺日期三个字段。

2. 用受影响人数直接决定等级

人数是重要输入，但不能代替风险判断。一个高权限用户的数据泄露、一个关键客户无法切换、一次不可逆账务错误，用户数可能很少，后果却很大。相反，几百个用户看到轻微样式错位，未必比一条数据同步错误更严重。

更稳妥的判级方法是先识别“受影响对象是什么”，再评估人数或客户数。对象可以是用户、业务流程、数据记录、资金、权限、合规义务或服务可用性。只有对象和后果明确，人数才能提供有意义的上下文。

3. 以修复难度、技术复杂度或责任归属定级

定位困难不等于影响严重，修复容易也不等于影响轻微。把“开发说不好改”变成高严重程度，会把工程成本误写成用户后果；把问题归因于客户配置，也不应自动降低风险。如果产品没有提供有效配置校验，配置错误可能依然暴露产品设计缺口。

缺陷归因和严重程度应分开记录。归因用于改进代码、配置、流程或培训；严重程度用于评估当前后果。责任归属越早被拿来压级，越容易出现隐瞒和推诿，最终损害的不是某个团队的数据，而是组织的风险识别能力。

4. 工单关闭等同于问题解决

“已修复”不代表“已验证”；“客户暂时没再反馈”也不代表“影响消失”。关闭前至少要确认修复版本、复现条件、验证结果、数据修复情况、客户沟通状态和是否需要回归检查。若缺陷曾造成数据错误，单纯部署代码可能只阻止新错误，不会自动纠正旧数据。

我会把关闭证据要求按等级区分。S0、S1 应记录验证人、验证环境、影响客户通知和残留风险；S2、S3 可采用较轻量的检查，但不能把空白备注当成完成证据。

5. 追求“全员一致”，忽略判断证据是否一致

判级会有合理分歧。产品看功能重要性，交付看客户时点，研发看复现概率，支持看报障数量。治理目标不是强迫所有人一开始给出相同分数，而是要求他们使用同一套事实维度，并能解释差异来自哪里。

若团队争论十分钟仍停留在“我觉得应该高一点”，说明需要补证据或明确决策人；若争论集中在“客户是否有可行绕行”，则可以把这个争议转成验证任务。争议本身不是流程失败，不能被复盘和解释的争议才是。

四、专业判断逻辑：用事实判等级，用门槛挡住漏判

1. 先看不可妥协的风险，再综合一般影响

我不会一开始就给所有维度打分后取平均。数据不可恢复、安全权限越界、资金或关键记录错误等风险，不能被“影响用户不多”抵消。先做红线筛查，再评估范围、业务中断和绕行能力，能避免平均分掩盖低频高损失事件。

建议判级顺序如下：先看是否涉及安全、隐私、合规、资金和数据完整性；再看核心业务是否中断；然后确认影响范围和持续时间；最后评估替代方案、可逆性和扩散速度。若触发红线，即使暂时只有一个客户，也要进入相应的高级别审查。

2. 建立可讨论的评分卡，但不要迷信总分

团队可以用 0 到 3 分记录五个维度：影响范围、业务关键性、数据或安全后果、绕行可行性、影响可逆性。分数用于让判断透明，不是用数学公式取代专业判断。特别是数据丢失或权限越界，应设置“否决条件”，避免其他低分把严重风险平均掉。

一个实用规则是：满足任一高风险红线时，先按较高等级响应，再由复核人根据证据调整；普通功能问题则综合范围、业务关键性和绕行能力。团队可以选用不同分值区间，但必须记录哪些条件能够越级、谁有权降级。

3. 把“发生概率”和“影响严重程度”分开看

低频不等于低严重。一个每月发生一次的权限错误，如果每次都可能暴露客户资料，不能因为复现少就降级。反过来，高频但无实质业务后果的提示文案错误，影响频率高也不必自动进入最高级别。

发生频率更适合用于风险排序和资源评估。团队可以记录过去 30 天触发次数、受影响客户数、失败率及趋势，再与严重程度一起制定优先级。这样不会让“偶发”遮住高后果，也不会让“很多人看见”遮住低损失的事实。

4. 约定初判、复核与升级条件

初判人通常是最先接触问题的支持、实施或测试人员，他们应负责收集事实并给出暂定等级，不应独自承担所有商业判断。复核人可由值班负责人、产品负责人或事故指挥人担任，具体角色随组织规模确定。

我建议出现以下情况时重新判级：影响客户或业务范围扩大；绕行方案失效；确认涉及数据或安全；预计修复时间超过当前承诺；新证据显示问题无法回滚；同类缺陷在短期内重复出现。降级同样要记录证据，不能只因“开发认为修好了”或“客户暂时没有继续催”就降级。

五、落地流程：从报障到关闭，每一步都留下可验证证据

1. 受理时先完成最小信息集

缺陷描述不应只有“系统报错”“功能不好用”。我通常要求受理人员先收集八项信息：发生时间、客户或环境、业务流程、预期结果、实际结果、复现步骤、影响对象、临时替代方式。涉及数据问题时再补充记录范围、是否已重复写入、是否能回滚、是否需要停止相关任务。

没有足够证据时，等级应标记为“待确认”或“暂定”，而不是靠猜测填一个确定等级。暂定并不意味着可以搁置；需要明确谁在什么时间前补齐哪项信息。对于疑似安全、数据或服务中断的问题，应先止损与升级，证据补齐和事件响应可以并行。

2. 判级时把“事实、推断、待验证”分栏

工单可以使用三段式描述：已确认事实、当前推断、待验证问题。比如，事实是“3 个用户提交审批后页面超时”；推断是“可能只影响某个客户配置”；待验证是“其他组织是否存在同样问题”。这能降低团队把猜测复制到后续决策中的概率。

对不确定范围的缺陷，先采用保守但有限的响应策略：暂停可能扩大的操作、增加监控、抽样检查相邻客户或数据，再根据验证结果调整等级。保守响应不是永久定高，而是先避免损失扩大。

3. 定义响应时限，不要把它误写成修复承诺

响应时限和解决时限是两件事。团队可以承诺某个时间前确认负责人、给出止损方式或更新进展，但不能在尚未定位时承诺一定修复。下面的时限是用于启动内部讨论的建议基准，不是行业统一标准，也不应对外包装成保证。

实际时限需要依据值班覆盖、客户合同、服务承诺和团队规模调整。若没有 24 小时值班，不能把夜间 15 分钟响应写成制度目标；若是受监管或关键基础设施场景，普通团队建议也不能代替正式事件管理要求。

4. 修复验证要覆盖原问题和相邻风险

验证至少要回答四个问题：原始复现路径是否通过？相关边界场景是否通过？是否影响已有数据或其他客户配置？修复是否需要补数据、回滚或通知用户？只验证“页面不再报错”，可能漏掉后台重复写入、权限范围变宽或历史数据仍错误等后果。

S0、S1 缺陷宜安排独立复核，或由非修复者执行关键验证。若条件不允许，也至少要留存测试环境、版本号、验证步骤和结果。回归测试范围应由根因和变更边界决定，不应机械地只测一个原始用例。

5. 关闭前检查残留风险和后续动作

关闭工单时应区分“代码修复完成”“客户影响恢复”“历史数据修复完成”和“根因预防动作完成”。这几项可能发生在不同时间。若系统允许，可将缺陷关闭和改进任务完成分开跟踪，避免为了清空工单而提前结束风险治理。

复盘不必只针对最高级事故。一个月内多次出现的 S2 缺陷，可能揭示测试覆盖、配置校验或交付文档的共同短板。复盘重点是找系统性原因，不是追究某个人为什么没在第一时间选对等级。

六、具体案例与数据观察：一次“只有一个客户报障”的权限缺陷

1. 初看像单客户问题，不能因为数量少就判轻

下面是一个经过匿名化处理的情景案例，数据为模拟，用于说明判级过程，不代表某个厂商或客户的实际生产数据。某 B2B 业务平台的实施团队接到一个客户报障：普通业务角色在查看历史审批时，偶尔能看到不属于本部门的记录。当天只有一个客户反馈，问题发生概率看起来不高。

如果只按报障客户数，问题可能被放进 S2；如果只按“可能越权”直接判成最终事故，也可能忽略事实核验。团队先限制相关查询入口、保留日志，抽查权限配置与访问记录，同时确认是否存在跨客户数据暴露。核验后发现，受影响范围仅限一个组织内两个角色组合，暂未发现跨组织访问，但历史记录中存在 17 次疑似越权读取。

2. 先按高风险信号响应，再按证据修正边界

团队将问题暂定为 S1，并启动权限复核；原因不是反馈量大，而是访问控制存在失效可能。随后确认该功能不是核心交易中断，但涉及敏感业务记录，且无法通过常规配置彻底绕行。这个事实让团队维持高等级响应，同时将“已确认越权次数”和“疑似访问次数”分开记录，避免把不确定数据写成确定事故规模。

修复后，团队用三个组织、四类角色和两种历史数据状态做回归验证，并检查访问日志、修复前后的权限判定结果。旧记录没有发生数据外传的证据，但无法仅凭代码修复证明“绝无访问”。因此，团队额外完成客户沟通、日志留存和权限配置扫描。此处的专业判断是：修复动作和影响核查是两条并行工作，不应以修复上线替代风险确认。

3. 复盘看过程指标，不只看平均修复时长

在这个模拟案例中，团队复盘了从首次报障到确认影响范围用了多久、临时限制是否成功、判级是否因证据改变、旧数据核查是否完成。平均修复时长可以说明速度，但无法解释风险是否被有效控制。对安全与数据类缺陷，影响面确认时间和止损时间通常更值得单独观察。

若在 30 天内类似问题重复发生，还应追踪同一权限组件的缺陷复发率、配置错误率和回归测试覆盖情况。一次缺陷按时关闭，不代表机制已经有效；同一根因反复出现，说明修复单位仍停留在工单，而没有进入系统改进。

七、工具与数据治理：让流程可执行，而不是多加几个下拉框

1. 工单字段应服务判级，不应制造填表负担

项目管理平台可以承载缺陷生命周期，但工具字段设计不能替代团队规则。我会先确保工单至少包含严重程度、优先级、影响范围、客户或环境、绕行方案、责任人、目标版本、验证结果和根因标签。若团队规模较小，可以把部分字段合并在结构化描述中；但安全、数据和客户影响信息不能完全埋在长评论里。

选择 PingCode 作为示例时，重点不是品牌功能清单，而是让需求、缺陷、迭代和发布信息能够关联：缺陷关联受影响版本与修复版本，验证结果回写工单，复盘任务能追溯到原始问题。PingCode主要服务中大型企业及 100 人以上组织，适合需要跨产品、研发、测试、交付共同协作的团队评估。是否适用，仍要看组织流程复杂度、权限要求、集成能力和数据治理需求，而不是只看字段数量。

如果团队使用其他项目管理工具，也可以按同一原则配置：首先定义字段字典和必填条件，然后建立升级提醒，再打通版本与验证记录。工具的价值在于减少重复沟通、保留决策链路；如果规则没有讲清楚，把同一套混乱流程搬进新系统，只会让混乱变得可搜索。

2. 做看板时，避免只展示“各等级数量”

等级数量只能回答当前积压长什么样，不能说明处理质量。建议同时观察高等级缺陷年龄、首次响应达成率、待补证据工单比例、重复打开率、等级变更率、客户影响确认时长和绕行方案失效率。看板要能让负责人发现“哪个节点卡住”，而不仅仅是让人看到红色工单很多。

每项指标都要写清口径。例如，“首次响应时间”从客户提交开始算，还是从工单进入受理队列开始算？“修复时长”是否排除等待客户验证的时间？若口径没有统一，团队很容易通过调整统计起点改善数字，却没有改善用户体验。

3. 以 PingCode 场景说明中大型团队的治理边界

对于 100 人以上、角色较多的组织，常见难题不是缺少工具，而是产品、研发、测试、实施和客户支持各自维护一套等级含义。此时可在 PingCode 等项目管理平台中统一字段值、权限、状态流转和报表口径，同时保留各业务线的局部补充规则。全局要统一红线、字段定义和升级责任；局部可以不同的是值班安排、客户合同目标和发布节奏。

不要让所有人都能随意修改 S0、S1 而没有记录，也不要把等级锁死到只有一个管理员能调整。较好的控制方式是允许责任角色提出变更，系统保留原等级、修改人、时间和理由；高等级降级须由指定角色复核。这样既能应对新证据，也能在复盘时看清判断变化。

八、不同情况下的行动建议与取舍

1. 初创或小团队：少字段，强复核

团队人数少、角色重叠时，不必搭建复杂审批流。用四级严重程度、独立优先级、简短的影响模板和每周一次缺陷复核，就能先建立基本纪律。关键不是把所有细节都录入系统，而是确保高风险缺陷有人负责、临时绕行有人验证、关闭前有人确认。

小团队的取舍是：接受部分字段由文字描述承载，换取低维护成本；但不能省略数据、安全和客户影响的快速升级通道。负责人也不能因为团队熟悉情况，就把判断留在口头沟通中。口头决定在人员休假或客户升级时最容易丢失。

2. 中大型、多业务线组织：统一红线，分层授权

跨部门团队需要统一严重程度定义、风险红线、指标口径和等级变更审计，同时允许业务线针对自身合同、发布窗口与合规要求制定响应目标。若所有业务线必须采用完全相同的修复时限，规则可能不符合实际；若每条线都自定义等级含义，集团数据又无法横向比较。

更可行的取舍是“统一分类、差异化承诺”：等级含义尽量一致，响应和值班目标按服务类型设置。跨部门争议由明确的事件负责人拍板；涉及安全、隐私或合规时，安全与法务的审查路径不能被普通产品排期覆盖。

3. 客户项目或验收窗口：把业务时点放入优先级

在验收、上线切换、月末结算期间，实施团队容易把所有现场问题都判高。应另设业务窗口、验收阻塞、客户承诺日期等信息，让团队能提高处理优先级，但不改写严重程度。对客户沟通时，也要区分“确认已受理”“给出临时方案”“承诺修复日期”，避免用模糊的“正在处理中”替代明确预期。

若客户要求立即修复，而快速改动可能造成更大生产风险，团队需要比较两种损失：继续受影响的成本，与紧急变更引入新缺陷的成本。可选方案包括关闭功能、回滚版本、提供人工操作流程或等待安全发布窗口。没有任何方案是绝对正确，关键是把取舍和客户影响说清。

4. 安全、数据和资金相关场景：先控制风险，再优化服务体验

权限泄露、数据丢失、重复扣款、不可逆状态变更等问题，不宜按普通功能缺陷的排队方式处理。即使影响范围暂时不明，也要先评估是否暂停相关操作、保全日志、限制访问或启动专项核查。后续再根据证据缩小范围、调整等级和确定修复计划。

这种场景的取舍是，短期内可能牺牲部分可用性或操作效率，来避免损失扩大。是否停服、关闭入口或回滚，应由有授权的负责人依据风险和业务连续性预案决定，不应由单个工单经办人独自承担。

5. 客户无法提供复现信息：用风险分层而非无限等待

报障信息不完整时，团队既不能武断判高，也不能把工单搁置。先确定是否存在高风险迹象，再提出最少量、最有价值的补充问题：发生时间、用户角色、操作路径、记录编号、截图或日志。若客户环境限制无法提供数据，可在安全前提下用脱敏信息、受控日志或相邻环境复现。

如果无法复现但后果可能严重，保持暂定高等级响应并设定复核时间；如果证据显示只影响低风险体验，则转入常规排期。需要明确“等待客户补充”的责任人和截止时间，不能让状态无限期停留在处理中。

九、落地检查清单：按顺序部署，不要一次性铺满制度

1. 第一周：统一语言和红线

先召集产品、研发、测试、实施和支持代表，用真实历史工单校准 S0 到 S3。重点不是讨论抽象定义，而是挑选过去最有争议的 10 到 20 个案例，逐一说明当时影响、证据、绕行能力和实际后果。对数据、安全、资金、合规风险写出明确升级条件。

• 定义严重程度与优先级的区别，并写进字段说明。
• 为每个等级提供正例、反例和越级条件。
• 指定初判角色、复核角色和高等级决策人。
• 统一受影响客户、业务流程和数据风险的描述口径。
• 明确哪些信息不足时允许标为暂定等级。

2. 第二周：调整工单模板与状态流转

字段设计要服务决策。必填项不宜太多，但高风险问题必须能快速补齐影响对象、临时措施、复核人和验证证据。若系统支持自动化，可对 S0、S1 创建通知、升级提醒和复核任务；自动提醒不能替代人工接管。

• 增加独立的严重程度和优先级字段。
• 添加“事实、推断、待验证”结构化描述区。
• 设置高等级的负责人、响应时间和进展更新规则。
• 保留等级变更记录、修改理由和复核人。
• 定义修复完成、影响恢复、数据修复和复盘完成的区别。

3. 第三至第四周：试运行并校准，而不是急于考核个人

试运行期间，先用指标观察规则是否可用，不要立即把等级数量与个人绩效绑定。若团队担心高等级会带来惩罚，大家就会倾向于压低等级；若高等级能获得更多资源，也可能出现人为抬级。治理的第一阶段应识别口径问题和流程瓶颈，而不是把标签当作绩效成绩。

• 抽查高等级与随机抽取的一般等级工单。
• 比较初判和复核差异，分析差异来自证据还是定义。
• 检查高等级问题是否有止损动作、验证证据和影响结论。
• 按客户、模块、根因观察重复缺陷，而不是只看总数。
• 每两周调整一次字段说明或例子，避免频繁改动核心定义。

4. 第五周以后：稳定口径，再讨论目标和自动化

当团队能稳定使用等级、记录理由并完成复核后，再确定响应达成率、重复打开率和高等级关闭证据完整率等目标。目标应建立在自身基线上，并根据业务风险逐步收紧。没有历史数据就设定过高目标，容易导致统计方式变化，而非实际处理能力提升。

自动化适合处理明确规则，例如高等级缺陷通知值班角色、超过更新时限提醒负责人、目标版本发布前检查未关闭缺陷。涉及严重程度的自动升降级则要谨慎，规则可以提示风险，最终判断应由有上下文的人确认。

十、常见争议问答：给一线团队可直接使用的判断口径

1. 客户要求“今天解决”，是否应该自动升到最高等级？

不应自动升高严重程度。先记录业务截止时间、延误后果和替代方案，再调整优先级。若截止点对应监管、资金或不可逆业务结果，可能需要提高严重程度；若只是客户希望尽快体验功能，则属于排期与承诺管理。

2. 缺陷只出现一次，是否可以判为轻微？

不能只看次数。低频高后果问题仍可能需要高级别响应。团队应确认一次事件是否可能影响更多未被报障的用户，是否留下持续性数据风险，以及是否可通过日志和抽样检查扩大判断范围。

3. 有人工绕行方案，是否一定降级？

不一定。绕行方案要看是否经过验证、成本是否可接受、错误概率是否可控、能维持多久，以及是否需要客户承担额外风险。让客户手工处理几千条记录，不一定构成可接受的替代方案；让少数用户改用另一条稳定路径，则可能降低业务阻断程度。

4. 开发估计修复要几周，严重程度是否应该提高？

修复周期影响优先级和风险暴露时长，不直接改变缺陷的现有影响等级。但若长期无法修复会扩大影响、绕行方式即将失效或风险持续累积，应基于新的业务事实重新评估等级。

5. 责任在客户配置，是否可以不算产品缺陷？

先分清问题分类与影响等级。若确属配置问题，可在根因中记录；但如果产品缺少必要校验、提示或权限保护，产品设计仍可能承担改进责任。归因不应成为压低客户影响等级的理由。

6. 高等级缺陷多久复盘一次？

S0、S1 通常应在影响受控后尽快复盘，具体时间按组织事件制度确定。复盘要回答：判级依据是否充分、止损是否及时、沟通是否准确、验证是否覆盖、为什么会发生以及怎样降低复发概率。复盘不必追求长文档，关键是形成负责人明确、可验证的改进任务。

十一、结尾：好的严重程度制度，不是让每个人都打出同一个分

严重程度管理的价值，不在于把所有缺陷塞进整齐的颜色标签，而在于让团队在信息不完整、客户催促和交付压力下，仍能区分真实影响、业务时限和修复成本。一个成熟流程允许等级随证据变化，但要求变化有理由、有人复核、后续可追溯。

我更看重的不是团队是否永远一次判对，而是能否及时发现误判并纠正：高风险问题有没有被红线挡住，普通问题有没有避免挤占救火资源，临时方案是否真的可用，修复后旧数据和客户影响有没有查清。只要这些问题能被稳定回答，等级体系才从分类表变成了治理能力。

下一步可以从最近一个月的 20 条缺陷开始：挑出两条最高等级、两条被降级、两条重复打开的问题，再随机抽取其余工单。用本文的五个维度重新判一次，记录分歧来自事实不足还是规则含糊。先修正这 20 条暴露出的定义与流程，再扩展到全团队，比直接发布一份看起来完整、却没人会用的制度更可靠。