您最優秀的工程師剛剛離職了。接下來該怎麼辦？

每個工程團隊都有一位關鍵人物，他知道為什麼部署管線會以這種方式運作、為什麼資料庫綱要會有那個奇怪的命名常規、2023 年發生停機事故期間到底發生了什麼而形塑了現今的監控設置，以及遺留代碼庫中的哪些部分是絕對不能碰的主力承重牆。

當那個人離職時（他們終究會離職的），所有這些背景資訊都會隨之流失。團隊會在接下來的幾週和幾個月裡，透過一次又一次痛苦的事故發現這些漏洞：因為沒有人知道未被記錄的隱藏手動步驟，導致部署失敗；一次重構無意中移除了解決方案，而這個解決方案當初存在的原因現在卻沒有人記得；一名新員工花了三週時間試圖理解一個系統，而離職的工程師原本只需二十分鐘就能解釋清楚。

這就是「公車班次問題」（Bus factor），得名於一個殘酷的問題：「在專案無法繼續進行之前，必須有多少個團隊成員被公車撞到？」對於系統的重要部分，大多數工程團隊的公車因素只有一或二，這意味著只要一兩個人離職就可能導致數週或數月的混亂。

真正流失的是什麼

當一位博學的工程師離職時，代碼還在，PR 還在，Slack 訊息也還在（至少在它們滾出保留期之前）。流失的是「詮釋層」：對事物為何是現在這種狀態的理解、哪些決定是深思熟慮後的權衡、哪些是意外、問題核心藏在哪裡，以及如果你碰了不該碰的東西會壞掉什麼。

這是最濃縮形式的部落知識（Tribal knowledge），也是最難傳遞的一種知識，因為擁有它的人往往沒有意識到自己知道多少。他們是在與系統緊密合作的數月或數年裡累積起來的，其中大部分已經變得非常自動化，以至於即使他們嘗試，也無法產出一份全面的文件。

離職面談和知識轉移會議會有所幫助，但它們只能捕捉到離職人員所知的一小部分。你無法在兩週的通知期內轉移兩年累積的背景資訊。

持續捕捉的替代方案

解決公車因素問題的方法是持續捕捉知識，而不是在離職時手忙腳亂地榨取知識。

自動撰寫文件透過在工程活動發生時，將其轉化為結構化且可搜尋的文件來實現這一點。當工程師在 Slack 討論串中解釋一個設計決定時，該解釋會被捕捉並整合到系統文件中。當 PR 包含對為什麼選擇特定方法的描述時，該推理會與程式碼一起保留。當會議討論遷移計劃的權衡時，討論會被記錄並鏈接到相關系統。

知識並不是在特別會議中從工程師那裡榨取出來的。它是作為他們已經在做的工作的副產品而被捕捉的，這意味著它會持續累積，並隨著系統的演進而保持最新狀態。

當那名工程師最終離職時，他們在任職期間產生的文件依然存在。下一個需要理解部署管線為何如此運作的人可以搜尋文件，而不是透過反覆試錯來尋找答案。

不解決這個問題的代價

沒有足夠的文件記錄，關鍵人物離職所帶來的代價很難精確衡量，但很容易感受到。團隊通常會回報在失去關鍵知識擁有者後，工作效率會降低二到六個月，具體取決於該人對系統的理解程度以及知識的記錄情況。

以資深工程師年薪 180,000 至 220,000 美元計算，即使整個團隊的生產力顯著降低兩個月，也代表著數萬美元的產出損失。對於離職員工是唯一知識擁有者的關鍵系統，代價可能會高得多：生產事故需要更長的時間才能解決、功能被推遲因為沒有人足夠了解系統以安全地進行修改，以及入職培訓需要數月而不是數週，因為新員工沒有任何東西可以閱讀。

公車因素問題是少數幾個解決方案（持續捕捉知識的文件）比其預防的問題更便宜的工程風險之一。

常見問題解答

我們不能只進行知識轉移會議嗎？ 您可以也應該這樣做，但它們只能捕捉到離職工程師能想到的內容，這只是他們所知的一小部分。許多最有價值的知識都是情境性的，只有在應對轉移會議期間不會出現的特定情況時才會浮現。

多少文件才足以降低公車因素？ 專注於決定和推理，而不是實作細節（代碼在實作層面本身就是文件）。如果新工程師可以透過閱讀文件來理解系統為何如此構建，公車因素風險就會大大降低。

這適用於小型團隊嗎？ 小型團隊實際上更容易受到傷害，因為每個人佔總知識的比例更大。一個五人團隊失去一名工程師，就失去了 20% 的集體背景資訊。而一個五十人團隊失去一名工程師，只失去 2%。

延伸閱讀： 部落知識的隱形成本、 文件債、 您的代碼庫有記錄，但您的決定沒有。 相關頁面： 自動撰寫文件、 知識保留、 適合工程團隊。