題幹與適用場景
請說一次你在發布前發現隱藏依賴，因而改變原定計畫的經歷。你如何證明風險、協調團隊、決定延遲或分階段發布，並復盤結果？
這道題適合軟體工程、平台、產品和技術專案職位。它考察 Ownership、風險判斷、跨團隊溝通和結果復盤，不要求候選人把每次延期都包裝成英雄故事。Amazon 將 Ownership 描述為對遇到的問題負責並考慮長期價值；Microsoft 也建議準備與職位相關的具體過往經歷。
面試官考察點
- 是否給出具體依賴、發現證據、影響範圍和時間線。
- 是否區分事實、假設與最壞情境，而非憑直覺阻止發布。
- 是否提出可選方案和明確的決策門檻。
- 是否讓依賴團隊參與，並對業務影響承擔溝通責任。
- 是否展示結果數字、後續控制措施和個人學習。
- 是否能在追問中承認當時不知道的內容，不誇大個人貢獻。
30 秒回答框架
「我在發布前透過一項具體訊號發現，功能依賴另一團隊尚未完成的批次處理或權限變更。先用日誌、呼叫圖和小流量驗證確認影響，再把風險分成阻斷項和可接受項。我給團隊兩個方案：延遲並修復依賴，或關閉高風險路徑後分階段發布。最終按約定門檻決定，並向受影響的產品和營運負責人同步時間線。發布後我補上依賴清單、檢查項和監控，結果是沒有發生預期中的事故，後續發布也更可預測。」
分步驟深入解答
第一步：說清楚隱藏依賴是什麼
不要只說「發現風險」。說明依賴的對象、原本計畫、發現時間和證據，例如呼叫了另一團隊尚未完成的權限同步，或資料回填會改變新欄位的預設值。用時間線讓聽眾知道為什麼它此前沒有進入計畫。
第二步：驗證影響而非猜測
透過呼叫圖、日誌、設定、資料樣本或小範圍演練確認依賴是否真實。估算受影響使用者、請求比例、回滾難度和發現窗口。把未知項寫出來，避免用一個未經驗證的最壞情況要求所有人無限延期。
第三步：提出可比較的方案
至少給出繼續發布、延遲修復、關閉部分功能或灰度發布等方案。為每個方案標註風險、成本、時間和可逆性，設定決策門檻，例如關鍵權限同步未通過就不擴大流量。這樣討論圍繞證據和選擇，而不是誰的聲音更大。
第四步：影響利害關係人
向依賴團隊確認交付狀態，向產品和營運說明使用者影響與新時間線，向值班人員說明監控和回滾。使用簡短的決策記錄，寫明事實、選項、負責人、截止時間和升級路徑。承擔壞消息的傳遞，不把延遲歸咎給另一團隊。
第五步：執行可逆發布
若選擇分階段發布，先驗證依賴、啟用開關、限制租戶或地區，觀察錯誤率、權限拒絕、資料新鮮度和回滾訊號。每個階段有繼續、暫停和回退條件。若選擇延遲，保留已完成的工作和新的檢查項，避免下次從同樣的不確定狀態開始。
第六步：復盤並改變系統
結果要包含數字：延遲了多久、覆蓋多少流量、避免或發現了什麼、客戶影響如何。復盤應產出依賴登記、發布清單、契約測試、負責人和提醒機制；如果只是「以後更小心」，就沒有改變系統。也說明哪一項判斷後來被證明錯誤，以及如何修正。
取捨、邊界與資訊增益
這道題的價值在於展示如何把模糊風險轉化為共同決策。高品質回答不把延期本身當成功，也不把按時發布當唯一目標；它用證據比較可逆方案，明確誰承擔什麼影響，並讓組織在下一次發布中少依賴個人記憶。
高品質示範回答
「一次權限中心遷移前，我發現新服務仍依賴舊系統每天生成的角色快照，但發布清單沒有記錄這個依賴。呼叫圖和抽樣日誌顯示約 18% 的管理請求會讀到快照，遷移後可能出現錯誤拒絕；我還驗證了回滾只能恢復程式碼，不能恢復已寫入的新權限。
我整理了三種方案：延遲兩天完成雙寫和校驗；先關閉管理端高風險操作再灰度 5% 租戶；按原計畫全量發布。和依賴團隊、產品負責人和值班同學評審後，把「快照一致性通過且拒絕率無異常」設為擴大流量門檻，選擇灰度方案並公開新的時間線。
灰度期間拒絕率保持基線，未發生客戶事故；兩天後雙寫校驗完成，才擴大到全量。復盤增加了跨服務依賴登記、權限契約測試和發布前抽樣檢查。我的貢獻是發現證據、提出可比較的選項並推動記錄，不把風險歸咎給依賴團隊。」
常見錯誤
- 只說「我阻止了發布」→ 沒有風險證據和替代方案 → 說明驗證、門檻和可逆路徑。
- 把延期歸咎給其他團隊 → 缺乏 Ownership → 共同確認事實並承擔時間線溝通。
- 用最壞情況誇大影響 → 決策無法比較 → 量化機率、範圍和回滾難度。
- 只講按時上線 → 可能隱藏後續事故 → 給出結果數字和客戶影響。
- 復盤只寫「加強溝通」→ 系統沒有改變 → 增加契約、清單、監控或負責人。
- 聲稱個人完成所有工作 → 跨團隊事實不可信 → 明確自己的判斷、協作和未完成部分。
追問及應對
如果產品負責人堅持按原計畫發布，你怎麼辦？
用影響範圍、機率、回滾成本和可觀測性說明風險，提出最小可逆灰度方案與明確停止門檻。若仍選擇發布，把決策、負責人和監控寫入記錄，並準備回退，而不是在口頭爭論中僵持。
你如何證明依賴確實是隱藏的？
展示原計畫、現有文件、呼叫或資料證據，以及依賴團隊之前未被要求的交付項。承認如果線索已存在但自己沒讀到，就把重點放在如何修復發現流程。
如果最後發現你誤判了風險呢？
說明哪條假設被新證據推翻、造成了多少延遲或成本，並更新驗證步驟。及時修正判斷比堅持原結論更能體現學習和責任。
如何讓下一次發布不依賴個人記憶？
把依賴寫入機器可讀的契約或登記，加入契約測試、發布清單、所有者、過期提醒和執行期指標；在演練中驗證失敗時會阻斷或回退。