程式錯誤分流流程圖（bug triage）
程式錯誤分流流程圖：缺陷受理、重現、重複項檢查、嚴重程度與優先次序、呈報、修正、程式碼覆核、QA 驗證與發布上線。
運作方式
把泳道改成你們真實的角色
把報告人、支援、分流負責人、開發與 QA 換成你們自己的職能。小團隊常把支援與分流合併成一條泳道；沒有專職 QA 的團隊通常把驗證交給另一位工程師。按決策者劃分泳道，而不是按人劃分——否則只要有人轉職，圖就不再符合現實。
把你們的嚴重程度與優先次序定義寫在分流步驟上
嚴重程度是缺陷一旦發生所造成的影響；優先次序是它甚麼時候會被處理。為每一個級別配一個具體例子，例如最高級是資料遺失或結帳流程被阻斷，最低級是一處版面錯位。沒有例子，所有報告都會以最高級別抵達，這個欄位也就不再承載任何資訊。
設定呈報的門檻
把籠統的「是否嚴重或生產環境停止服務？」換成你們真實的觸發條件：受影響的客戶數量、被阻斷的收入路徑、面臨風險的資料。寫明誰有權宣布一次事故，以及事故流程在哪裡——分流在那一刻把缺陷交接出去，而缺陷紀錄仍然開啟，等待永久修正。
決定資訊迴路要跑多久
「報告人是否在期限內回覆？」這個決策需要一個寫明的等候期，通常還需要一次催辦。把這個數字寫在步驟上。沒有它，那些從來無法重現的報告會無限期開啟，待辦積壓也就不再反映真實的工作量。
就驗證的含義以及重新開啟的去向達成共識
寫明 QA 是對照報告人最初的重現步驟驗證、對照迴歸測試套件驗證，還是兩者都做。這個範本把驗證失敗退回同一條紀錄上的開發環節，讓歷史留在一處。如果重新開啟的缺陷應當重新排定優先次序、而不是被直接接著處理，就把它改成退回分流。
把它發布出去，並只保留一個現行版本
把圖放在缺陷報告表單旁邊和當值操作手冊裡，取得支援、開發與 QA 的簽署確認，並保留歷史版本，以便看出流程是何時改動的。每當有一個缺陷的解決時間遠超應有水平，就把它拿出來重看一次，修好它卡住的那一步。
常見問題
程式錯誤分流流程包含哪些階段？
在多數團隊裡是五個。受理，報告在這裡登記，細節要足夠支撐後續行動。重現，支援人員在這裡確認缺陷確實存在，而不是設定問題或用戶操作失誤。分流，在這裡連結重複項，並賦予嚴重程度、優先次序和負責團隊。修正，涵蓋開發與程式碼覆核。驗證，QA 在這裡對照最初的報告檢查修正，然後發布並通知報告人。上面的圖正是把這五個階段作為階段欄，其中重現與分流承載了完成大部分工作的那些決策。
嚴重程度與優先次序有甚麼分別？
嚴重程度描述缺陷造成的影響：資料遺失、工作流程被阻斷、外觀問題。優先次序描述它甚麼時候會被處理。兩者回答的是不同的問題，應當保持為兩個獨立欄位。一處已公開價格上的錯字是低嚴重程度、高優先次序；只有兩個客戶在用的功能當機，可能是高嚴重程度、低優先次序。把它們合併成一個欄位，是分流流程失去可信度最常見的原因——因為最後所有東西都堆在量表的頂端。
程式錯誤分流應該多久跑一次，誰需要在場？
對上一次之後新提出的所有內容做一次簡短的例行梳理：面向消費者的線上產品每日一次，發布周期較慢的團隊每周兩次。通常三個角色就足以作決定：一位能說清客戶影響的支援人員，一位對嚴重程度與優先次序負責的分流負責人，以及一位知道哪個團隊擁有相關程式碼的開發負責人。任何嚴重問題或生產環境停止服務都不應等到會上——這也是這張圖把它立即呈報為事故、而不是排進佇列的原因。
無法重現的缺陷應該怎樣處理？
把它結案，但必須在走完一個明確的迴路之後。就缺失的細節索取一次（建置版本、環境、準確步驟、一段螢幕錄影），在寫明的等候期內催辦一次，然後結案為「無法重現」，記下理由，並明確邀請對方在問題再次出現時重新開啟。這個範本把這條迴路畫成報告人泳道中的一個決策，而不是留給個人判斷，因為無法重現卻永遠開啟的報告，正是把待辦積壓變成無人閱讀的清單的東西。