Bug / 缺陷如何做好优先级？项目经理落地方案与操作步骤

Bug 优先级失控，通常不是因为团队不会给缺陷打分，而是因为“严重程度”“业务紧急程度”和“谁声音最大”被混成了一个结论。结果是，发布前一周几十个问题都被标成最高优先级，真正影响核心交易的缺陷反而排在队列中间。我的判断是：优先级不是给 Bug 贴标签，而是把有限的修复能力投向最需要保护的用户、业务和发布窗口。

一、先讲核心结论：优先级要回答“先修什么”，不只是“问题有多严重”

1. 把严重程度与优先级分开管理

严重程度描述缺陷造成的技术或功能影响，例如服务不可用、数据丢失、页面错位；优先级描述团队在当前时间、当前版本里应该多快处理它。前者主要回答“坏到什么程度”，后者回答“现在要不要先做”。两者相关，但不能直接画等号。

一个只影响 3% 用户、但恰好阻断月底结算的缺陷，技术影响范围不一定最大，却可能需要当天处理。相反，一个在内部测试环境中稳定复现、尚无客户触达的低频兼容问题，严重程度可以不低，但如果存在可靠绕行方案，修复时间也许可以排在后续版本。

我的核心规则是：先确认风险是否真实，再判断影响有多大，最后结合时限、绕行能力和修复成本安排顺序。任何单一字段都不应自动决定优先级，尤其不能让“严重程度高”成为无需讨论的通行证。

2. 用“硬门槛加排序评分”，不要只靠一个总分

我建议先设置少量硬门槛，再对其他问题做相对排序。硬门槛处理不能被平均分稀释的风险，例如生产环境大面积不可用、数据完整性受损、权限越界或法定期限内无法履约；其余缺陷再用统一评分比较。

• 硬门槛：触发安全、合规、数据安全或核心业务中断条件时，进入专门的紧急处理通道。
• 风险评分：评估受影响用户、业务损失、发生概率、可绕行性和时间窗口。
• 资源校验：确认修复成本、回归范围和上线风险，决定立即修复、临时规避还是延后处理。

硬门槛的价值，是防止少数高后果风险被平均值冲淡；排序评分的价值，是让剩余问题能够比较。把这两件事分开，通常比设计一个看起来精密的单一公式更可靠。

3. 优先级必须附带责任人、时间点和复核条件

“P1，尽快处理”不算可执行结论。一个有效的优先级决策至少要说明谁负责、何时给出判断、下次何时复核、什么变化会让优先级上调或下调。否则，优先级只是缺陷列表上的颜色，无法推动资源调度。

例如，某个支付失败问题暂列高优先级，业务方提供了“受影响交易占比低于 0.2%、存在人工补单、补单在两小时内完成”的证据后，团队可以决定先启用监控与补偿流程，再安排当天修复。决策不是把问题说轻，而是把风险控制措施一并写清楚。

二、为什么优先级容易失真：真实场景里，缺陷不是孤立的

1. 同一个缺陷，在不同发布阶段有不同价值

开发阶段发现的布局偏差，可能只影响一个低频内部页面；临近大促上线时，同样的偏差如果出现在下单按钮上，就可能直接影响转化。缺陷本身没有变，用户暴露量、修复窗口和变更风险变了，优先级自然应该重算。

这也是为什么我不把优先级视为一次性字段。提单时的判断只是初始判断；进入灰度、收到客户反馈、发现影响范围扩大或获得绕行方案后，都可能改变决策。团队如果只在创建缺陷时评一次级，缺陷队列很快就会和业务现实脱节。

2. 不同角色看到的是风险的不同切面

测试人员通常能提供复现条件、影响范围和回归线索；研发人员能判断根因、修复复杂度和引入新风险的可能性；产品经理能说明用户任务与产品承诺；客服或客户成功团队能补充真实客户影响。项目经理的职责不是替每个角色做专业判断，而是把这些证据拼成可执行决策。

常见冲突并非谁不专业，而是大家回答了不同问题。研发说“修复成本很低”，不代表业务影响小；产品说“客户很着急”，也不能直接证明影响面广。会上应先让每个人明确自己提供的是哪类证据，再由决策人综合判断。

3. 资源稀缺时，队列会暴露团队的真实选择

假设一个四人研发小组本周有 20 个缺陷待处理，但考虑需求开发、代码评审、联调和回归后，实际只能交付 8 个修复。此时给 20 个问题都标高优先级，既没有增加产能，也没有保护业务，只是把取舍推迟到开发人员各自的工作台上。

优先级体系是否有效，可以从一个简单问题判断：当本周只能修 8 个时，团队能不能讲清楚为什么是这 8 个，以及其余问题用什么措施控制风险？如果不能，说明团队缺的不是更多等级，而是决策依据和容量管理。

三、常见误区：看起来有规则，实际仍然靠声音大小排序

1. 把严重程度直接映射成优先级

把“严重程度高”自动映射为“立刻修复”，容易让技术影响与业务紧迫性混淆。比如，一个后台报表导出失败可能影响数据分析，但有替代查询方式；一个偶发的库存扣减异常看起来频率不高，却可能造成超卖和后续履约损失。直接映射会漏掉后者的业务后果。

技术严重程度仍然重要，但它应该作为风险输入，而不是最终决定。即便采用严重程度等级，也要在旁边记录业务影响、受影响人群、持续时间和补救措施，否则等级本身无法说明修复次序。

2. 把客户声量当成影响范围

客户投诉是重要信号，但投诉人数不是受影响人数。少数客户可能因为业务流程关键而持续反馈；大量用户也可能只是遇到可自行恢复的提示错误。项目经理应要求补充账户数量、受影响交易、触发频率、发生时段和客户任务，而不是按工单数量直接排序。

如果数据暂时拿不到，也可以先标注“影响范围待验证”，安排日志查询、客户回访或埋点核查，并设置明确的复核时间。信息不完整不等于可以忽略问题，也不等于应立即把所有资源投入修复。

3. 用“修起来很快”作为优先级理由

修复成本低确实会影响安排，但它不等于问题重要。一个 10 分钟能调整的文案错误，可能不应该挤掉需要半天修复的权限漏洞；反过来，成本很低且能消除明显用户阻碍的缺陷，也可能适合顺手处理。成本是可行性和机会成本信息，不是影响证据。

我会把“问题价值”和“修复投入”分别记录。先判断不处理会造成什么，再判断处理需要什么。这样可以避免团队因“容易改”而不断积累低价值修复，最后没有时间处理真正的风险。

4. 让所有人都能随意把缺陷升到最高级

最高级别一旦被普遍使用，就失去了区分能力。若每个紧急请求都能直接升级，研发团队就会被迫在多个“最高优先级”之间自行选择，实际排序重新退化为谁先来、谁催得急、谁更容易找到开发人员。

可以允许任何人提出升级，但升级必须补齐证据，并由指定角色确认。触发紧急通道时，要同步说明暂停了什么工作、谁批准了挤占、何时复盘。这样既保留一线发现风险的速度，也避免等级被情绪化使用。

5. 只看新缺陷，不看等待时间和老化风险

一个低优先级问题长期无人处理，可能在产品规模扩大、使用方式变化或替代方案失效后，逐渐变成高风险。缺陷队列不仅要看新进入的问题，也要关注等待时长、复发次数、客户承诺期限和临时方案是否仍然有效。

但“等待得久”也不能自动等于“优先级高”。更合理的做法是把老化作为复核触发器：达到约定时长后重新检查影响、验证绕行方案、确认是否发生变化，再决定升级、继续观察或关闭。

四、专业判断逻辑：先过风险门槛，再做可解释的排序

1. 第一步：检查不可被平均的硬门槛

我通常先问四个问题：是否涉及未授权访问或敏感数据暴露？是否造成数据丢失、错账或不可逆修改？核心交易是否大面积中断？是否触及合同、监管或明确的客户承诺期限？任何一项有可信证据，就先进入高风险评估，不必等待总分计算。

这不意味着只要有人提到“安全”就必须立刻全员停工。团队仍应快速核实证据、确认影响边界并采取遏制措施，但不能用平均分把潜在高后果问题压低。对于安全问题，可参考 FIRST 发布的 CVSS 4.0 方法理解技术严重性；需要注意，CVSS 分值并不等于组织内部的业务优先级。

2. 第二步：把影响拆成可核查的问题

不要只写“影响较大”。至少把影响拆成用户范围、关键任务、业务损失、发生频率和持续时间。数据不一定一开始就精确，但应该标明来源和可信度，例如监控日志、客户工单、受影响账户清单、测试环境复现或业务人员估算。

• 用户范围：影响一个账户、一个租户、一类设备，还是所有用户？
• 任务关键性：是否阻断登录、下单、支付、结算、数据导入或其他核心任务？
• 后果类型：是体验不佳、效率下降、收入损失，还是数据和合规风险？
• 发生概率：稳定复现、特定条件触发，还是仅有一次未经验证的报告？
• 暴露时间：已经在线多久，预计还会持续多久？

这些问题的目的不是让每张缺陷单写成调查报告，而是防止“严重、紧急、很多人受影响”这类模糊词代替证据。团队可以先用简短字段记录，再在高风险缺陷上补充详细分析。

3. 第三步：将绕行能力和时间窗口纳入判断

绕行方案需要验证，而不是只写一句“可以手工处理”。我会追问谁来操作、每次耗时多久、最大承载量是多少、是否可能引入新错误、需要客户配合什么，以及该方案可以持续多久。一个理论上可行但每天要人工核对数千条记录的方案，通常不能算低成本绕行。

时间窗口也不只代表距离发布时间有几天。还要看修复后是否留有回归时间、是否进入变更冻结、是否需要客户升级、是否有回滚能力。越靠近关键节点，问题本身的风险和修复引入风险都要同时评估。

4. 第四步：使用透明评分，而不是伪精确的数学

对于通过硬门槛检查的缺陷，可以使用 1 至 5 分的相对评分。建议先分别评估业务影响、受影响范围、发生可能性和时限压力，再单独记录绕行能力与修复成本。下面的权重只是团队启动时的建议基准，不是适用于所有行业的客观规律。

建议排序分 = 业务影响 × 30% + 受影响范围 × 25% + 发生可能性 × 20% + 时间窗口压力 × 15% + 用户承诺压力 × 10%。每项按 1 至 5 分打分，计算后用于同一团队、同一周期内相对比较；硬门槛仍然优先于总分。

绕行能力与修复成本不建议简单反向塞进公式里，否则可能让一个高危但难修的缺陷因成本高而被压低。它们更适合作为决策修正项：绕行可靠，可以改变处理策略；修复风险高，可以优先采取遏制措施并安排分阶段修复。

评分要服务于讨论，而不是代替讨论。若同一团队连续出现大量 4 分和 5 分，应回头检查尺度是否失真；若评分与最终处理顺序长期不一致，也应检视权重或硬门槛是否设置不当。

5. 第五步：把分数翻译成团队可执行的响应承诺

团队可以建立 P0 至 P3 等级，但等级名称本身没有通用标准。重要的是每个等级对应什么响应动作、由谁确认、多久复核，以及是否影响当前计划。建议根据团队支持时段和交付节奏定义服务目标，而不是直接照搬其他公司的时间承诺。

上表的时间节奏是管理建议，不是行业标准。生产事件应遵循组织既有值班和事件管理约定；普通缺陷的响应时限，则要根据支持覆盖、团队人数和客户承诺共同确定。

五、项目经理落地方案：从提单到复盘的操作步骤

1. 建立最小可用的缺陷信息模板

字段越多不等于信息越完整。很多团队的缺陷表单包含几十项必填字段，结果提交人用默认值快速填完，评审者仍然要重新追问。我的建议是先保证最小证据闭环：问题是什么、谁受到影响、如何复现、发生频率、现有绕行方案、相关版本和证据链接。

• 问题描述：用可观察结果描述，不用“系统异常”“体验不好”代替现象。
• 复现条件：列出账号类型、设备、版本、操作路径和前置状态。
• 影响范围：记录已确认的受影响用户、业务流程与影响时间。
• 证据材料：关联截图、日志、录屏、监控指标或客户工单。
• 临时方案：写明是否存在，以及方案的成本和有效期限。
• 初始判断：由提交人给出建议等级，但明确它仍需评审确认。

在 100 人以上、团队和业务线较多的组织中，可以用 PingCode 这类项目管理平台承载缺陷字段、状态流转、责任人和评审记录。工具的作用是让证据和决策可追溯，不是替团队自动判断哪个问题最重要。

2. 设置入口分流，避免所有问题挤进同一队列

生产事故、普通产品缺陷、需求变更和使用咨询，最好不要只靠一个“Bug”类型混在同一队列。它们所需的响应机制和决策角色不同。入口处可先判断问题类别，再进入相应流程，减少紧急事件被常规排队规则拖慢，也避免咨询类问题挤占缺陷容量。

分流不宜设计得过于复杂。早期可以只区分生产事件、常规缺陷、数据问题和非缺陷请求，并允许评审者纠正分类。若每个类别都要求复杂审批，团队会绕过流程，转而在聊天工具里私下派活。

3. 每天做短分诊，每周做容量决策

高变动产品可以安排每天 10 至 15 分钟的缺陷分诊，只处理新出现的高风险问题、等级变化和阻塞项。常规缺陷不必每天重开会议。每周再结合迭代计划检查可用研发容量、回归能力和业务节点，决定哪些 P1、P2 进入本周期。

分诊会议的目标不是逐张念缺陷描述，而是做三种决策：缺什么证据、谁去补；是否需要升级或降级；本周期的容量是否允许处理。不能在会上决定的事项，应明确负责人和截止时间，不要用“再看看”结束讨论。

4. 用固定议程降低争论成本

1. 先看硬门槛：是否涉及服务中断、安全、数据完整性或不可延期的承诺。
2. 核对证据：影响范围、发生频率、复现条件和绕行方案分别由谁确认。
3. 比较相对风险：将新增问题与当前队列中的候选项对照，而不是单独判断。
4. 校验修复代价：评估估算、依赖、回归范围、上线窗口和回滚方案。
5. 明确结论：记录等级、负责人、目标时间、复核日期和升级条件。

如果一个问题反复讨论仍缺少关键证据，最合理的结论可能是“先做影响核查”，而不是立刻争出一个等级。明确下一步调查动作，往往比在会上用推测给缺陷定级更有效。

5. 让优先级调整有记录、有触发条件

每次升级或降级，至少记录变更人、时间、依据和后续动作。尤其是优先级下调时，要写明风险由什么措施控制，例如已完成回滚、受影响版本已关闭、客户已成功绕行或监控数据证明触发率明显降低。

可以预先约定自动复核条件：影响账户数量超过阈值、同类问题一周内重复出现、绕行失败、进入发布冻结期、客户承诺日期临近或修复成本发生明显变化。条件触发后重新评估，不代表系统自动升级，而是提醒责任人重新作出决定。

6. 把关闭标准与修复质量一起管理

代码合并不等于缺陷已经解决。关闭前至少确认修复版本、回归结果、受影响范围、是否需要补数据或通知客户，以及监控是否恢复正常。若采用临时规避而非根因修复，也应将事项标记为风险接受或分阶段处理，避免状态“已关闭”掩盖仍然存在的技术债务。

对线上问题，可以在恢复服务后再补根因修复，但需要区分“事件恢复”和“缺陷永久修复”两种状态。这样既不拖延恢复确认，也不会因为临时回滚就把后续工作从队列中消失。

六、案例推演：同样是“高严重度”，为什么最终处理顺序不同

1. 场景设定：一次发布前发现三个问题

下面采用匿名化情景推演，数据为示意值，不代表真实客户或产品统计。一支负责订阅制业务的团队计划在周五发布新版本，周二分诊时发现三个问题：支付偶发失败、管理报表筛选结果不准确、移动端长标题显示截断。研发本周最多能完成两个修复并充分回归。

仅看“严重程度”可能会让三个问题都争到高等级。为了做出可解释选择，团队先核实发生频率、受影响对象、业务后果、绕行能力和修复风险，再决定是否要改动本周计划。

支付问题虽然不是影响人数最多的一项，却靠近真实交易并且时间窗口紧，应先处理。报表问题的优先级取决于“月底结算”具体发生时间；团队不能因为客户说“很急”就跳过核实。标题截断有明确影响，但存在可行替代方式，当前不应挤占两个高价值修复名额。

2. 把“先修问题”与“先控风险”分开

支付修复可能涉及第三方接口和重试机制。如果周五前无法完成充分回归，团队不应只在“立即上线”与“完全不管”之间二选一。可以先扩大监控、限制重复提交、增加失败告警，并在确认回滚路径后进行小范围灰度，再决定是否扩大发布。

报表问题可以先由数据负责人提供人工复核表，明确复核覆盖的租户、字段和截止时间。如果人工方式每天需要数小时且容易漏项，就不能把它当成可靠绕行；这时应把工时和误差风险纳入优先级判断，重新与支付问题比较。

3. 决策记录要能解释“为什么不是另一个”

评审记录可以简短写成：“本周优先支付失败与报表筛选；支付因交易时限与潜在重复提交风险先修，报表因月底结算节点暂列本周，数据负责人周三确认实际结算日期；移动端样式问题因核心任务不受阻，进入下个常规迭代。若支付影响扩大或人工复核超出约定工时，立即重新排序。”

这段记录比单独填写三个等级更有用，因为它保留了决策理由和变化条件。下次有人询问为何标题问题没有先做，团队不需要重新从头争论；如果关键前提发生变化，也能清楚知道该改哪项决定。

4. 用结果验证判断，不用结果倒推惩罚个人

发布后，团队应核对支付失败率、重试恢复率、报表人工复核耗时和标题问题反馈量。若支付修复后失败率没有下降，可能是根因判断错误；若人工复核耗时远高于预估，报表问题的优先级可能被低估；若标题问题引发大量任务中断，则说明原先对页面关键性的判断不充分。

复盘的目的不是证明某位评审者“排错了”，而是校准证据和规则。缺陷决策本来就建立在有限信息上，好的流程允许更新判断，并从偏差中提高下一次估算质量。

七、不同情况怎么行动：按风险形态选择处理方式

1. 生产环境正在影响核心服务

先进入事件响应，目标是遏制损失和恢复服务，而不是在故障最严重时争论最终优先级分数。负责人应明确影响边界、受影响版本、回滚或降级选项、对外沟通口径和下一次更新时间。修复、回滚、流量切换或关闭功能，需按组织事件机制授权执行。

服务恢复后，再区分短期恢复措施与根因修复。若回滚解决了用户影响，不代表缺陷可以直接关闭；团队还要判断是否需要补数据、通知客户、补充监控、修复根因以及验证不会在下次发布时重现。

2. 涉及安全、权限或敏感数据

先限制暴露范围并保留调查证据，避免在宽泛渠道传播敏感细节。由安全、研发、法务或合规负责人按组织规则参与判断，确认受影响资产、数据类型、访问范围和报告义务。普通产品评分不能替代安全事件处理机制。

如果只是怀疑存在越权，而尚未确认影响，也应安排快速核验。暂时关闭高风险入口、收紧权限或暂停特定功能，可能比仓促发布未经验证的补丁更稳妥。是否对外通知，应由具备授权的负责人依据事实与适用规则决定。

3. 只影响一个重要客户或单一业务流程

用户数量少不代表价值低。评估时要看合同承诺、客户关键流程、替代流程是否真实可用、影响持续时间以及问题是否会扩展到其他客户。对于重要客户问题，应区分“个别配置错误”和“产品共性缺陷”，避免为单一数据特例做出会伤害其他用户的全局改动。

必要时可先建立客户级缓解方案，同时保留产品级问题排查。项目经理要协调客户沟通与研发排期，但不能在没有授权的情况下承诺具体修复日期。可以承诺下一次更新时间、临时处理措施和升级联系人，避免把尚未验证的估算包装成保证。

4. 只在低频设备或特定版本复现

不要因为复现频率低就直接降级，也不要因为难复现就把它长期挂起。先核对设备、系统版本、应用版本、网络条件、账号权限和操作路径，再增加针对性日志或采样。若问题涉及不可逆数据损失，即使概率低，也可能需要更高等级处理。

如果影响只出现在已停止支持的旧版本，团队要结合用户升级能力、维护政策和安全承诺判断。明确支持边界后，可以提供升级建议、临时方案或限期维护，而不是让缺陷一直留在“待确认”状态。

5. 临近版本冻结或重大活动

冻结期的判断必须同时考虑“不修的风险”和“改动的风险”。一个低影响缺陷可能不值得在冻结后引入大范围改动；一个影响支付或数据正确性的缺陷则可能无法等到下一周期。任何冻结期例外，都应说明变更范围、回归方案、审批人、回滚条件和监控责任。

对于可接受的体验问题，可以通过关闭入口、调整文案、提供操作指引或隐藏不稳定功能短期控制。对于无法规避的核心风险，要么修复并验证，要么调整发布范围或延期。按时发布不是唯一目标，受控发布才是。

6. 缺陷积压多、团队容量不足

先把队列分成风险处置、近期承诺、常规改善和待证实问题，而不是机械地从最高等级一路往下清。设定本周期缺陷容量时，要明确研发、测试和发布支持各自能投入多少，避免只计算编码时间而忽略回归与上线成本。

如果每个周期都没有容量处理存量缺陷，团队要检查新增缺陷率、重复缺陷率、返工时间和功能开发占比。持续只做新需求，短期看起来交付快，长期可能让故障、客户支持和变更回归成本逐渐上升。具体是否设置固定维护比例，应按实际趋势验证，而不是套用统一百分比。

八、怎样做取舍：优先级规则的边界、成本与指标

1. 评分会让决策更透明，但不会消除不确定性

公式能帮助大家使用相同语言，却无法让模糊的业务损失自动变精确。一个“影响 4 分”的结论，仍可能建立在不完整日志或经验判断上。因此，每个分数都应附带证据来源或可信度说明；高风险但低可信的问题，应优先补证和控制暴露，而不是假装分数已经准确。

团队也要接受有些问题无法客观排出唯一顺序。当两个缺陷风险接近时，可以考虑依赖关系、修复窗口、合并回归和客户沟通成本，并记录为什么选择其中一个。透明说明取舍，通常比追求虚假的数学精度更能获得信任。

2. 硬门槛要少而清楚，避免人人都走例外流程

硬门槛过多，会让常规问题不断升级；过少，又可能漏掉不可逆风险。建议从数据、安全、核心服务和明确合规期限等少数类别开始，并给每类写出可核验的触发条件、确认角色和退出条件。硬门槛应保留复核，不能变成模糊的“领导关注”通道。

当团队发现某类问题反复触发硬门槛，应该检查常规流程是否有缺口，例如发布前检查不足、监控缺失、灰度策略不完善或责任边界不清。紧急通道不是持续替代基础工程能力的办法。

3. 管理优先级体系时，关注过程质量而非等级分布

不能把“P0 数量下降”单独当成绩效，因为团队可能只是把名称改低；也不能要求 P1 占比固定在某个数字，因为产品风险结构会随业务阶段变化。更有价值的是检查关键决策是否有证据、响应是否按承诺执行、绕行是否有效、复发是否减少，以及高风险问题是否被及时发现。

4. 用图表看队列结构，不要只看总缺陷数

缺陷总量只能说明队列有多长，不能说明风险集中在哪里。管理者应按产品模块、缺陷年龄、根因类别、用户影响、等级变更和修复后复发情况拆开观察。若同一模块不断出现高风险缺陷，问题可能不在分诊，而在架构、测试覆盖或发布控制。

5. 不同规模团队，流程复杂度要跟着调整

小团队可以由项目经理、研发负责人和测试负责人组成短分诊小组，使用简单字段和每周复核即可。角色少、沟通快时，复杂审批的成本可能大于收益。真正要守住的是硬门槛、责任人和决策记录，而不是照搬大型组织的流程层级。

中大型组织，尤其是跨多个业务线的 100 人以上团队，需要统一最低限度的等级定义、字段口径、跨团队升级路径和事件协作机制，同时允许业务线补充自己的风险因子。统一的是共同语言，不应统一所有团队的权重和响应时限。

如果团队使用项目管理平台承载这些流程，应优先配置能够追踪字段变更、责任人、关联版本、复核时间和决策原因的能力。流程上线后先观察一两个迭代：若大家频繁绕过字段、重复登记或手工维护影子表，就要先删掉无效环节，再谈扩大自动化。

九、结尾：好的优先级不是排出漂亮队列，而是把风险变成可执行承诺

1. 把下一步落到一次真实分诊

项目经理可以从本周待处理缺陷中选 10 至 20 个，先统一核实影响范围、复现概率、绕行能力和时间窗口，再标记不可被平均的硬门槛。随后用团队现有容量挑出本周期要做的事项，并为其余问题写明风险控制动作与复核条件。

试运行一个迭代后，回看哪些判断被事实推翻：是影响范围估错、绕行方案失效、修复成本低估，还是发布窗口没有及时反映。把这些偏差转化为字段、测试或监控的改进，不要只通过增加等级数量来修补流程。

2. 记住优先级管理真正要解决的问题

Bug 优先级的核心，不是让所有人同意每一个分数，而是让团队在信息不完整、产能有限时，仍能说清楚先保护什么、暂时接受什么、由谁承担后续风险。严重程度告诉我们缺陷有多坏，优先级则要求我们为当下的选择负责。

当每个高优先级问题都有证据、负责人、处理时限和复核条件，当被延后的问题也有真实可行的风险控制方案，缺陷队列才从“谁催得急就先做”变成项目经理能够治理的交付机制。下一步不必先换工具或重做制度，先让下一次分诊的每个结论都回答：为什么现在做，为什么不是别的，以及什么变化会让我们改主意。