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