如何製作決策流程圖
如何製作決策流程圖：把每個決策寫成一個問題，令出口窮盡且互斥，把判斷準則寫在圖上，並給每一種結果一個結束。附缺陷分流實例示範。
運作方式
先列問題，再列答案
把流程裡包含的每一次選擇都寫成問題。然後按「各自能省掉多少工作量」排序：用最少力氣關掉最多個案的那個問題排在最前。把昂貴的問題問在最前的分流圖，浪費掉的正是它本來要節省的那些力氣。
令每個問題都答得上來
確認讀者能用眼前已有的東西回答它。「這是重複的嗎？」在有一個可搜尋的缺陷追蹤系統時是成立的；「這是已知問題嗎？」則不成立，除非圖上寫明已知問題記錄在哪裡。
把判斷準則寫在決策本身上
把門檻寫進該步驟的備註裡：怎樣的缺陷算嚴重、甚麼算充分的證據、多大金額會觸發那道額外的審批。沒有寫明準則的決策，產出的是看起來一致的圖和實際上並不一致的決策。
檢查出口覆蓋每一種情況——而且只覆蓋一次
對每個決策自問：有沒有哪一種處境不配對任何一條出口？有沒有哪一種同時配對兩條？兩者都是缺陷。三路分支完全沒問題——標準、常規、緊急——只要每一種情況恰好落在一處。
如實地畫出迴環
檢視不通過、驗證不通過、關閉後又重開：它們各自都在某個特定步驟上回到流程之中。假裝工作是線性的，正是令估算最後描述出一個誰也沒經歷過的流程的原因。
拿真實個案來驗證
取上個月走完這個流程的十個個案，逐個放進圖裡走一遍。那些走不通的個案，會告訴您缺了一條出口，或者某條準則其實只存在於某個人的主觀判斷裡。
常見問題
甚麼是決策流程圖？
一種結構以決策點為主、而非以順序活動為主的流程圖：每個菱形提出一個問題，每條標註過的出口通往不同的處理方式。分流、資格審查、升級規則和審批路由，都屬於決策流程圖。真正把它們區分出來的設計約束是：每個決策的各條出口必須把每一種情況恰好覆蓋一次，這樣任何按圖行事的讀者都會走到同一個結果。
一個決策可以有兩個以上的結果嗎？
可以，只要這些結果窮盡且互斥。一個變更申請分成標準、常規、緊急，就是一個乾淨的三路決策。真正會帶來麻煩的，是帶五六條出口的決策，它往往其實是套在一個菱形裡的兩個決策——拆成兩個之後，兩個都更好回答，日後亦更容易修改。
決策準則應該寫在哪裡？
寫在決策本身上，而不是附錄裡。在 QueryChart 中，每個步驟都帶一個備註欄位，門檻、定義或對制度條文的引用就應該寫在那裡。放在另一份文件裡的準則，只會被查閱一次、被大致記住、然後被不一致地使用——這正好抵消了把決策記錄下來的全部意義。
怎樣表示一個向後跑的決策？
把這條出口指向它所返回的那個步驟的行號。程式碼檢視不通過退回開發，或者驗證不通過重開缺陷，兩者都只是一條連回圖中間的連線。迴環是正常的，把它們畫出來，正是令決策流程圖對流程真實包含多少返工保持誠實的方式。