如何製作決策流程圖
如何製作決策流程圖：把每個決策寫成一個問題，令出口窮盡且互斥，把判斷準則寫在圖上，並給每一種結果一個結束。附缺陷分流實例示範。
決策流程圖描繪的是一連串選擇：每個決策都是一個問題，每條出口都標上一個答案，而這些答案合起來，恰好把每一種情況覆蓋一次。
簡而言之
- 每一個菱形裡都是一個問題，而且要寫成讀者答得上來的樣子。
- 出口窮盡且互斥——每一種情況恰好配對一條。
- 判斷準則屬於圖上，不屬於作者的腦裡。
- 寧可用兩個清晰的決策順序排開，也不要一個帶五條出口的決策。
- 把問題排序，令最省事、最能排除的那個排在最前。
怎樣的決策圖在壓力下仍然好用
決策流程圖的讀者，是那個必須作出選擇的人——通常很急，而且往往沒有作者當初掌握的背景。這比流程圖面對的讀者要苛刻得多。這意味著：問題必須能用讀者手上真正有的資訊回答，出口必須覆蓋每一種情況，判斷準則亦不能只存在作者腦裡——「這個算不算嚴重？」只有在圖上寫明甚麼叫嚴重時，才算一個決策。
技術上的要求是：每個決策的各條出口必須窮盡且互斥，每一種情況恰好配對一條路徑。「窮盡」失敗時，讀者的處境不在清單上，於是他自己發明一條路。「互斥」失敗時，兩條路徑都說得通，兩位讀者看著同一張圖卻作出不同判斷——這看起來像團隊不一致，實際上是圖本身的缺陷。
以下的示例是一個缺陷分流流程，由頭到尾幾乎全是決策：能否重現、之前是否已經報告過、嚴重程度如何、修復是否通過檢視、是否通過驗證。六個決策，其中四個可以把個案打回上一環。
六個決策，一個缺陷
缺陷分流，由呈報到關閉。幾乎每一步都是一次選擇，而其中大多數都能把個案打回上一環。
最省事的問題排在最前
能否重現？在這個問題得到回答之前，下游的任何事情都不值得做，所以它排在最前。按「能省掉多少工作量」為決策排序，是您能為一張分流圖帶來的最大一項改善。
給死胡同真正的結束
呈報人沒有回覆，個案以「無法重現」關閉；重複的缺陷連結到原始紀錄後關閉。這兩者都是正當的結果，各自有自己的終止點——一張只以「已修復」收尾的分流圖，描述的並不是分流。
按嚴重程度分流，並寫明嚴重程度的含意
嚴重級會觸發一次生產事故並跳過待辦佇列；標準級則轉交負責的團隊。把「嚴重」的定義寫在這個決策旁邊，否則兩個人為同一個缺陷分流會分出兩種結果，而且兩人都能說自己是照著圖做的。
會向後跑的決策
程式碼檢視和驗證都會把不通過的情況送回開發，而驗證不通過是重開個案而非關閉它。正是這些迴環，令決策流程圖對返工的多少保持誠實。
運作方式
先列問題，再列答案
把流程裡包含的每一次選擇都寫成問題。然後按「各自能省掉多少工作量」排序：用最少力氣關掉最多個案的那個問題排在最前。把昂貴的問題問在最前的分流圖，浪費掉的正是它本來要節省的那些力氣。
令每個問題都答得上來
確認讀者能用眼前已有的東西回答它。「這是重複的嗎？」在有一個可搜尋的缺陷追蹤系統時是成立的；「這是已知問題嗎？」則不成立，除非圖上寫明已知問題記錄在哪裡。
把判斷準則寫在決策本身上
把門檻寫進該步驟的備註裡：怎樣的缺陷算嚴重、甚麼算充分的證據、多大金額會觸發那道額外的審批。沒有寫明準則的決策，產出的是看起來一致的圖和實際上並不一致的決策。
檢查出口覆蓋每一種情況——而且只覆蓋一次
對每個決策自問：有沒有哪一種處境不配對任何一條出口？有沒有哪一種同時配對兩條？兩者都是缺陷。三路分支完全沒問題——標準、常規、緊急——只要每一種情況恰好落在一處。
如實地畫出迴環
檢視不通過、驗證不通過、關閉後又重開：它們各自都在某個特定步驟上回到流程之中。假裝工作是線性的，正是令估算最後描述出一個誰也沒經歷過的流程的原因。
拿真實個案來驗證
取上個月走完這個流程的十個個案，逐個放進圖裡走一遍。那些走不通的個案，會告訴您缺了一條出口，或者某條準則其實只存在於某個人的主觀判斷裡。
應避免的錯誤
準則含糊
「嚴重」「緊急」「重大」——每位讀者都會自帶一套門檻，於是這張圖交付的是標準化的外觀，而沒有標準化的實質。
出口彼此重疊
如果一個個案確實可以走兩條路，兩個人就會把它分往不同方向，而且兩人都有道理。把分支劃成互斥的。
只有一條出口的決策
如果只畫了一條路，那它就不是決策。要麼把另一種結果也畫出來，要麼把它改成一個普通的流程步驟。
五層深的決策嵌套
長長的決策鏈既難以追蹤，也更難修改。當這棵樹確實很闊時，在圖旁邊配一張決策表，通常比再加幾個菱形更清楚。
製作您自己的決策流程圖
把缺陷分流示例作為您自己的圖表開啟，然後把裡面的問題換成您的團隊實際會作的那些決策。
相關指南
常見問題
甚麼是決策流程圖？
一種結構以決策點為主、而非以順序活動為主的流程圖：每個菱形提出一個問題，每條標註過的出口通往不同的處理方式。分流、資格審查、升級規則和審批路由，都屬於決策流程圖。真正把它們區分出來的設計約束是：每個決策的各條出口必須把每一種情況恰好覆蓋一次，這樣任何按圖行事的讀者都會走到同一個結果。
一個決策可以有兩個以上的結果嗎？
可以，只要這些結果窮盡且互斥。一個變更申請分成標準、常規、緊急，就是一個乾淨的三路決策。真正會帶來麻煩的，是帶五六條出口的決策，它往往其實是套在一個菱形裡的兩個決策——拆成兩個之後，兩個都更好回答，日後亦更容易修改。
決策準則應該寫在哪裡？
寫在決策本身上，而不是附錄裡。在 QueryChart 中，每個步驟都帶一個備註欄位，門檻、定義或對制度條文的引用就應該寫在那裡。放在另一份文件裡的準則，只會被查閱一次、被大致記住、然後被不一致地使用——這正好抵消了把決策記錄下來的全部意義。
怎樣表示一個向後跑的決策？
把這條出口指向它所返回的那個步驟的行號。程式碼檢視不通過退回開發，或者驗證不通過重開缺陷，兩者都只是一條連回圖中間的連線。迴環是正常的，把它們畫出來，正是令決策流程圖對流程真實包含多少返工保持誠實的方式。