可直接做决策的缺陷分诊
用于确定优先级和负责人的缺陷分诊模板
明确记录每种分诊结果：请求补充信息、接受并分派、合并为重复项、设定复核日期后延期，或说明原因后拒绝。
登录后可查看已填充的视图，再安装带示例数据的应用，以测试关联记录、决策和仪表板。
分诊必须产出的决策
缺陷分诊将一份报告转化为受控的下一步行动。决策应依据可复现性、用户影响和紧急程度，而不是谁的声音最大；最终必须明确负责人、目标版本或复核日期。
- 严重程度与优先级分开判断
- 重复和需补充信息的结果仍保留原背景
- 被接受的缺陷都会指定负责人和目标版本
分诊规则
按相同顺序提出相同问题
一致的分诊方式让积压决策有据可查，也能减少随意抬高优先级。
能否复现？
确认复现路径，或提出明确的信息补充要求并退回。
是否已经存在？
将重复报告合并到同一个标准问题，同时保留其报告背景。
影响有多大？
根据对用户、数据、安全和运营的后果确定严重程度。
何时必须处理？
根据紧急程度、替代方案和发布时间确定优先级。
下一步由谁负责？
指定组件负责人，以及目标版本或复核日期。
不要混为一个决定
严重程度描述后果，优先级决定处理顺序
两者经常相关，但如果有安全的替代方案，高影响缺陷也可以延期；而临近发布时，影响较小的问题也可能十分紧急。
| 维度 | Question | 示例 |
|---|---|---|
| 严重程度 | 缺陷对用户或业务造成多严重的影响？ | 已扣款但未收到确认属于严重问题。 |
| 优先级 | 相较其他工作，团队应多快采取行动？ | 即使尚未大范围出现，发布阻断项也应列为 P0。 |
| 替代方案 | 用户能否通过其他方式安全完成任务？ | 人工对账会降低当下紧急性，但不会降低影响程度。 |
| 目标版本 | 应在哪个候选版本中包含修复？ | Web 4.28.0 必须等到验证通过才能发布。 |
每条记录都应有明确去向
记录缺陷为何流转，或为何保持不变
只有决策能够长期保留并可重新审视，积压队列才真正有用。
需要补充信息
向报告人提出明确的信息要求。
已接受
指定负责人、优先级和目标版本。
重复
关联标准问题，并保留新证据。
已延期
记录原因，以及重新考虑的日期或触发条件。
已拒绝
说明适用边界、预期行为或不受支持的情况。
问题与适用边界
缺陷分诊常见问题
有关判断后果、紧急程度和责任归属的实用建议。
团队应多久进行一次缺陷分诊？
根据报告量和风险安排频率。严重的生产问题需要立即流转；普通报告可由产品团队每天或每周多次审查。
哪些人应参与分诊？
至少应包括了解用户影响的人、熟悉受影响组件的人，以及能够承诺负责人或发布时间的人。
重复报告应该关闭吗？
可以标记为重复，但要保留报告人、背景和证据，并关联到标准问题。重复报告数量本身也能反映影响范围。
延期的缺陷如何处理？
为其记录原因和复核触发条件。没有负责人、只有“以后再说”的状态，只会让积压悄然增长。
让积压决策有据可查
从已填充的分诊结果开始
调整规则前，先查看已接受、需补充信息、重复、延期和重开的示例。