放行與否決策流程：推出就緒決策樹
推出就緒的放行與否決策樹範本：每條問題由誰回答，以及通往放行、附條件放行、限定試行、不放行與中止這五類結果的各條分支。
運作方式
把泳道改成你們真實的決策權
把發佈負責人、研發與品質保證、營運與支援以及高層負責人換成在你們機構裡真正握有答案的角色。泳道只寫由誰回答，不寫誰有參與：如果有三個團隊為同一條問題提供證據、但由一個人拍板，那這條問題就屬於拍板者那條泳道。任何一條你叫不出具體人名或角色的泳道，都應該合併掉。
在需要之前就把門檻寫下來
這棵樹的好壞取決於它的判定。在「缺陷是否在嚴重程度門檻之內？」上，記下今次發佈範圍內每個嚴重程度的上限、誰可以推翻一次超標，以及計數是否包括由此前版本帶過來的已知問題。對「驗收準則是否全部達成？」做同樣的事：在範圍凍結時就把每一條準則標為必須或期望，這樣關卡才不會在當日被重新談判。
界定「回滾已測試」到底指甚麼
「回滾是否已成功測試？」應該意味著在近似生產的環境中演練過、計過時、有指名的人能夠執行，並且有一條寫下來的觸發條件用來決定何時啟動。請把資料問題寫明白，因為往往正是一次資料表結構或資料遷移的變更，把「這次變更究竟能否回退？」的答案變成否，而這條分支是通往中止的唯一一條路。
令附條件放行和試行結果成為真實的結果
只有當每個條件都帶著指名的負責人、一個限期和一條未做到時的後果，附條件放行才與普通放行有分別。試行放行則需要界定好群組、寫下曝光比例或客戶名單，以及擴大範圍的判定條件。把這兩樣都寫進「獲准的範圍有多大？」的備註欄，覆核就無法以一個含糊的點頭收場。
把不放行與中止分開
不放行意味著同一次發佈遲些時候仍然會推出，因此在散會之前需要一個改定的日期和一個具名的阻斷項。中止意味著這次發佈被撤回，其內容退回返工或重新評估。把兩者作為不同的終點，可以避免一次真正的中止被記錄成一次兩星期的延期，然後悄無聲息地重複下去。
把它發佈出去，並在每次關卡之後覆核
把這棵樹發佈到覆核真正發生的地方，與證據包放在一起，並取得泳道所指名那些人的簽署確認。每次發佈之後，檢查是否有問題在沒有證據的情況下被回答了，以及是否欠缺一個你們需要的結果。保留此前的版本，這樣你們可以說明判定準則是甚麼時候改的、為甚麼改。
常見問題
放行與否決策樹和發佈流程圖有甚麼分別？
發佈流程圖回答「接下來會發生甚麼、由誰去做」。它在泳道上按次序展示任務——範圍凍結、建置、測試、部署、監察——並把放行與否這項決定當成一個節點。決策樹回答「我們選哪一個選項、由誰決定」。它的主幹是一連串問題而不是任務，它的分支以「已達成」「超出門檻」「可豁免」或「暫不簽署」這類答案命名，而不是以下一項活動命名，並終止於若干個彼此不同的結果，而不是匯回同一條順暢路徑。兩者都要用：用流程圖看端到端的流程，用這棵樹看流程內部的這道關卡。
放行與否決定應該包含哪些問題？
七條問題覆蓋大部分推出。所有必須達成的驗收準則是否都已達成？未關閉的缺陷是否在約定的嚴重程度門檻之內？依賴項與第三方是否就緒？回滾是否已經過測試，而不只是寫過？支援與營運是否已針對預期用量完成培訓並配齊人手？變更視窗在業務日程表與技術日程表上是否都空出？高層簽署是否到位？每一條問題都應該可以由會前收集的證據得到答案——這也正是這棵樹由一份就緒證據包開始、而不是由第一條問題開始的原因。
放行與否由誰拍板？
應該由一位指名的人主持，通常是發佈負責人或生產環境的負責人，但真正有用的紀律是把每一條問題分派出去，而不是把整項決定交給一個人。研發與品質保證回答驗收與缺陷問題，營運與支援回答回滾與人手問題，發佈負責人回答依賴項與變更視窗，高層負責人回答簽署。這樣寫下來之後，主持人的工作就是把這棵樹跑一遍並記錄結果，而不是親自裁決每一條問題。記錄下誰回答了甚麼，對取證同樣重要：SOC 2 這類控制框架要求變更經過授權、測試、批准並留有文件，而一棵標明了決策權的決策樹是一種直截了當的呈現方式。
甚麼時候應該給出附條件放行而不是不放行？
當遺留事項不會令這次發佈面臨風險，並且推出之後有人接手它的時候。只有當每個條件都帶著指名的負責人、一個限期和一條未做到時的後果，附條件放行才是一個真實的結果；否則它只是多了幾張紙的普通放行。把不放行留給任何會令使用者暴露於風險或失去支援的情況。在這棵樹裡，阻斷性的驗收缺口、一個未達成一致的超門檻缺陷、一項沒有它就無法發佈的硬依賴、一個尚未準備好的支援職能，以及變更視窗衝突，都通向帶改定日期的不放行。
不放行和中止有甚麼分別？
不放行意味著發佈被押後：同樣的範圍在阻斷項清除之後於改定的日期推出。中止意味著它被撤回，內容退回返工或重新評估，而且不附帶日期。把兩者分開之所以重要，是因為一次根本無法回退的發佈，或者一次高層基於業務理由暫不簽署的發佈，並不是在等一個修復——把它記成延期，只會導致兩星期之後拿著同樣的證據再開一次同樣的會。
我應該怎樣把推出限制在試行或小範圍先行群組？
把它當成決定的一個結果，而不是會議室裡妥協出來的折衷。在這棵樹裡，最後一條問題「獲准的範圍有多大？」分出「全量」「附條件」和「僅試行」，因此限定範圍的發佈是在所有就緒問題都得到回答之後被有意選擇的，而不是一種迴避不放行的辦法。覆核之前先界定試行在你們的產品裡意味著甚麼：哪一批群組或多大的曝光比例、運行多久、監察甚麼，以及哪一條判定條件才准許擴大範圍。