可直接做決策的錯誤分流
用於確定優先順序和負責人的錯誤分流模板
明確記錄每種分流結果：請求補充資訊、接受並指派、合並為重複項、設定複核日期后延期，或說明原因后拒絕。
登入後可查看已填充的檢視，再安裝帶範例資料的應用，以測試關聯記錄、決策和儀表板。
分流必須產出的決策
錯誤分流將一份報告轉化為受控的下一步行動。決策應依據可重現性、使用者影響和緊急程度，而不是誰的聲音最大；最終必須明確負責人、目標版本或複核日期。
- 嚴重度與優先順序分開判斷
- 重複和需補充資訊的結果仍保留原背景
- 被接受的缺陷都會指定負責人和目標版本
分流規則
按相同順序提出相同問題
一致的分流方式讓積壓決策有據可查，也能減少隨意抬高優先順序。
能否重現？
確認重現路徑，或提出明確的資訊補充要求並退回。
是否已經存在？
將重複報告合並到同一個標準問題，同時保留其報告背景。
影響有多大？
根據對使用者、資料、安全和運營的后果確定嚴重度。
何時必須處理？
根據緊急程度、替代方案和發布時間確定優先順序。
下一步由誰負責？
指定元件負責人，以及目標版本或複核日期。
不要混為一個決定
嚴重度描述后果，優先順序決定處理順序
兩者經常相關，但如果有安全的替代方案，高影響缺陷也可以延期；而臨近發布時，影響較小的問題也可能十分緊急。
| 維度 | Question | 範例 |
|---|---|---|
| 嚴重度 | 缺陷對使用者或業務造成多嚴重的影響？ | 已扣款但未收到確認屬於嚴重問題。 |
| 優先順序 | 相較其他工作，團隊應多快采取行動？ | 即使尚未大范圍出現，發布阻斷項也應列為 P0。 |
| 替代方案 | 使用者能否通過其他方式安全完成任務？ | 人工對賬會降低當下緊急性，但不會降低影響程度。 |
| 目標版本 | 應在哪個候選版本中包含修復？ | Web 4.28.0 必須等到驗證通過才能發布。 |
每條記錄都應有明確去向
記錄錯誤為何流轉，或為何保持不變
只有決策能夠長期保留並可重新審視，積壓佇列才真正有用。
需要補充資訊
向回報者提出明確的資訊要求。
已接受
指定負責人、優先順序和目標版本。
重複
關聯標準問題，並保留新證據。
已延期
記錄原因，以及重新考慮的日期或觸發條件。
已拒絕
說明適用邊界、預期行為或不受支援的情況。
問題與適用邊界
錯誤分流常見問題
有關判斷后果、緊急程度和責任歸屬的實用建議。
團隊應多久進行一次缺陷分流？
根據報告量和風險安排頻率。嚴重的生產問題需要立即流轉；普通報告可由產品團隊每天或每周多次審查。
哪些人應參與分流？
至少應包括了解使用者影響的人、熟悉受影響元件的人，以及能夠承諾負責人或發布時間的人。
重複報告應該關閉嗎？
可以標記為重複，但要保留回報者、背景和證據，並關聯到標準問題。重複報告數量本身也能反映影響范圍。
延期的缺陷如何處理？
為其記錄原因和複核觸發條件。沒有負責人、只有“以后再說”的狀態，只會讓積壓悄然增長。
讓積壓決策有據可查
從已填充的分流結果開始
調整規則前，先查看已接受、需補充資訊、重複、延期和重新開啟的範例。