MANAGEMENT / RELEASE DECISIONS

技術準備好了，誰決定可以發布？

Andrew Yuan · 管理觀點與經驗延伸 · 草稿

本文區分實際的內部開發經驗、目前管理做法，以及由此延伸的發布提問。

技術驗證讓我們知道，目前確認了什麼。要決定是否發布，還需要說清楚：誰有權接受剩餘風險，原先的假設不成立時，又由誰處理。

例如，一個韌體版本已完成預定驗證，是否發布卻還沒決定。Engineering 認為剩餘風險可控，QA 希望取得更多證據，Product 則在意交付承諾。這些觀點都可能合理。

領導者要釐清的是：各方的判斷有哪些技術依據，繼續推進會付出什麼代價，以及誰有權做決定。

在我的實務中，決策方式會隨影響範圍改變。事情在團隊的決策權限內，影響也能由團隊承擔，就由團隊決定；涉及跨團隊或對外承諾時，則和相關負責人共同決定。

提出建議時，就應該開始釐清這個界線。

驗證結果，要能支持眼前的決定

程式碼已合併、主要問題已解決、QA 完成預定驗證，都是重要資訊。但要判斷它們是否足夠，仍得看驗證涵蓋了什麼。

測的是哪個版本、哪些相依元件、設定與使用情境？結果能支持什麼結論？尚未涵蓋的部分，會不會改變決定？

工程團隊需要說清楚這些限制。測試通過，支持的是受測條件下的結論，並不代表發布的所有未知都已排除。

接著要問：再補驗證，會不會改變選擇？有時確實需要補測；有時仍有未知，需要相關負責人判斷能否接受，以及如何處理。

如果不清楚要支持什麼決定，測試可能越做越多。期限到了，風險也不會因此消失。討論應聚焦在：哪些未知會影響選擇，可能造成什麼後果，以及繼續推進前必須取得哪些證據。

技術選項的代價，可能由別的團隊承擔

我曾經做過一次開發基準與整合時機的選擇。這是內部開發取捨，並非核准正式發布的案例。

跟進其他團隊的 develop 分支，可以較快取得新功能，也可能增加相依性與整合風險。一旦需要支援，其他團隊就可能得從原本安排的工作中抽出時間。

我決定先從穩定基準開發，接受部分功能晚一點導入。評估時，除了自己的開發排程，我也考慮其他團隊可能增加的整合負擔。當時，功能延後主要影響內部開發與功能排程，沒有更改對外承諾。

這說明我們當時接受了什麼代價，但不代表其他情境也適合延後功能。

決定之後，工作並沒有結束。TL 持續追蹤變更，我們共同評估後續更新與取捨，這種分工沿用到多次更新。功能差距與後續整合，仍需要有人持續處理。

這段經驗讓我在做其他決定時，也會問：代價由誰承擔？從自己團隊的功能與進度來看合理的選項，可能會占用另一個團隊的資源。

誰承擔影響，誰有權接受？

一項建議如果會影響別的團隊的資源或承諾，就需要相關負責人參與取捨。技術專業能提供重要依據，卻不代表有權替別人接受代價。

Technical Lead 說明領域內的證據、實作方案與風險；Engineering Manager 衡量優先順序、資源配置、交付對其他團隊的依賴與跨團隊影響；Product 與其他相關負責人則補充客戶承諾與業務優先順序。

這些都是決策依據。組織仍需釐清：在這個影響範圍內，誰有權做決定？

共同決定之後，也要明確分工。誰接受哪些代價？誰追蹤剩餘風險？條件改變時，誰協調處理？這些責任可以由不同的人負責，但應事先說清楚。

否則，討論可能停在「大家同意了」，後續的難題卻沒有人負責。

分歧，可能讓遺漏的資訊浮現

發布討論中，各方掌握的證據與承擔的後果可能不同。我會先了解分歧從哪裡來，再判斷如何處理。

大家看的結果是否不同？對失敗機率或嚴重程度的判斷是否不同？同樣的失敗，會不會對各團隊造成不同影響？是否還有承諾或相依關係沒有納入討論？

原因不同，需要的處理方式也不同。補測或許能釐清技術行為，卻未必能解決誰有權接受後果的問題。

會議取得共識，不代表發布已經安全；有人不同意，也不代表發布必然不安全。值得追問的是：分歧帶出了什麼資訊，這些資訊是否改變決定？

對工程領導者來說，釐清這些差異，可能比急著取得共識更有幫助。

決定之後，還要有人負責

在仍有未知時做決定，往往依靠幾個假設：驗證涵蓋了預期的使用情境，剩餘影響可以接受，出現非預期行為時，組織也有能力處理。

新證據可能推翻這些假設。需求改變、影響擴大，或相依元件出現非預期行為，都可能需要重新檢視原來的決定。

我目前的做法，是由 TL 持續追蹤領域內的風險與變化，我們再一起評估如何調整；若涉及其他團隊的資源或承諾，也需要相關負責人參與。

把這個思路延伸到正式發布，還需要討論誰能暫停、如何恢復運作，以及何時改變方向。這些是從經驗延伸的問題，本文沒有提供一個完整的正式發布或恢復案例。

監控、以受控方式發布，以及恢復計畫，可以協助處理未知，但要先確認系統是否支援、實際是否可行。尤其當後果嚴重或難以逆轉時，這些安排不能取代必要的驗證。

因此，做決定時也要說清楚：出現哪些變化，就需要重新判斷？

下一次討論，可以留下這六件事

以下六項可以用來整理發布討論。它們是從經驗延伸的提問，並非上述案例當時使用的固定流程。

1. 決定範圍： 這次要決定的是開發里程碑、一次整合、小範圍部署，還是正式發布？哪些團隊或對外承諾可能受到影響？
2. 已有證據： 哪些項目已完成測試、重現、量測或確認？證據涵蓋哪些版本、相依元件與使用情境？
3. 剩餘未知： 哪裡可能出問題，影響有多大？再取得哪些證據，會改變選擇？
4. 接受代價： 繼續、延後或縮小範圍，各由誰承擔成本？相關負責人是否參與了取捨？
5. 決策與後續責任： 誰提出建議、誰有權接受剩餘風險，以及誰負責追蹤變化、協調處理？
6. 重新檢視條件： 什麼情況需要重新討論？誰有權暫停、恢復發布或調整方向？如果出問題，實際有哪些方式可以回復版本或恢復運作？

這些問題不能保證決定正確，但能讓大家更清楚地檢視理由、權限與責任。

我希望發布討論留下的，是一個理由清楚、責任明確，也能在條件改變時重新判斷的決定。