面試題：分享一次你在尚未準備好時完成責任交接

1. 題目與使用場景

面試官想知道你能否在人員異動、輪調或專案切換時，把「個人掌握」變成「團隊可持續」。題目中的「尚未準備好」可以是接任者經驗不足，也可以是時間窗口很短；重點不是證明自己不可取代，而是讓責任安全轉移。

Amazon 的 Ownership 原則強調對長期結果負責；Google SRE 的事故材料把明確的交接對象和知識轉移視為降低壓力、保持指揮鏈清晰的機制。回答應體現這兩點。

用「背景—風險—設計—驗證—結果」五句回答：

團隊需要在兩週內把支付對帳服務交給新同事。對方沒有處理過月末結算，我先列出高風險操作和升級聯絡人，接著用一份運行手冊、一次故障演練和一週雙人值班完成漸進式交接。第一輪月末結算由對方主導、我只在預設閾值觸發時介入；結果是交接後連續三次結算無逾期，值班告警也按時關閉。

畫出輸入、決策、輸出、依賴和升級路徑。把「能獨立負責」寫成可觀察條件，例如能完成一次演練、能解釋關鍵告警、能在規定時間內完成回滾。GitHub 的 CODEOWNERS 機制說明，責任邊界應落在明確的檔案或團隊範圍上，而不是只存在於口頭約定。

把知識分為三類：高頻且可逆的日常操作、低頻但高損失的操作、需要跨團隊協調的例外。對第一類用清單和範例；對第二類安排桌面演練和雙人審批；對第三類寫清聯絡人、決策權限與升級時限。不要把所有背景一次傾倒給接任者。

先由接任者觀察，再由其執行、你旁觀，最後由其獨立處理。每個階段設退出條件，例如兩次無提示完成、一次故障演練通過、關鍵指標保持在閾值內。支援窗口應有截止日期，否則責任會長期懸置在原負責人身上。

檢查的不只是接任者是否「感覺有把握」，還包括結果指標：故障回應時間、未關閉告警、回滾成功率、客戶升級數量或交付準時率。交接後一段觀察期內保留稽核記錄，確認問題被發現、歸因並修正。

我負責一個每天處理帳單匯出的作業，原本由我單獨值班。公司安排我在十天後轉到新專案，接任同事熟悉業務但沒有處理過失敗重跑。我的風險判斷是：重複扣款和錯過財務截止時間不能接受，普通格式錯誤可以在當天修復。

我先把責任拆成日常執行、失敗重跑、供應商溝通和最終升級四塊，給每塊寫完成條件與聯絡人；再把過去三次故障整理成運行手冊，並用去識別化資料做一次失敗重跑演練。前三天我示範，接下來四天由同事操作、我旁觀，最後三天由同事主導值班。我只在重複扣款風險或超過十五分鐘未恢復時介入。

交接完成的標準是同事獨立通過演練、能解釋所有關鍵告警，並在兩次真實運行中按時關閉異常。轉移後的三次結算都按時完成，沒有重複扣款；我把觀察期內的兩個小問題補進手冊後正式退出。這個過程讓我理解，責任交接的產物是可驗證的工作系統，不是一次知識分享會議。

把擔憂轉成具體場景，讓對方選擇先演練哪一類風險；必要時縮小權限和範圍，但保持明確的放權時間表。

按事先寫明的階段責任和升級規則處理。複盤關注訊號、決策和機制缺口，不把責任歸因簡化為個人能力。

當接任者滿足預設能力條件，關鍵指標在觀察期內穩定，且團隊知道新的唯一負責人和升級路徑時退出，並保留短期可聯絡但非預設值班的安排。

用「背景—風險—設計—驗證—結果」五句回答：

團隊需要在兩週內把支付對帳服務交給新同事。對方沒有處理過月末結算，我先列出高風險操作和升級聯絡人，接著用一份運行手冊、一次故障演練和一週雙人值班完成漸進式交接。第一輪月末結算由對方主導、我只在預設閾值觸發時介入；結果是交接後連續三次結算無逾期，值班告警也按時關閉。