部落知識的隱性成本

部落知識（Tribal knowledge）是指僅存在於資深員工腦海中的非正式、未記錄的對事物運作方式的理解。例如：為什麼計費系統會以這種方式處理退款？關於舊版 API 該找誰討論？三月份發生的那次事件中發生了什麼，從而塑造了目前的警報設置？哪些配置值是起支撐作用的，哪些是可以安全更改的。

在一個小團隊中，部落知識是高效的。大家都互相認識，背景資訊透過近距離接觸和日常對話得以共享，正式文件的開銷實際上帶來的阻礙大於幫助。這個「部落」足夠小，知識得以自然流傳。

問題在於部落知識無法擴展，而它停止擴展的臨界點通常在團隊意識到之前就已經到來。

擴展的斷裂點

這種斷裂通常發生在團隊擁有 10 到 20 名工程師之間。在 10 人以下時，大多數工程師對整個系統都有一個合理的心理模型，並且知道該向誰詢問任何特定的組件。當人數超過 20 人時，系統的增長超出了任何個人的理解範圍，團隊中包含了剛加入、缺乏歷史背景的新人，而掌握部落知識的工程師則在自身工作與解答問題的日益沉重負擔之間被拉扯得越來越緊。

症狀顯而易見：開會的主要目的變成了分享背景資訊，而不是做出決策；在 Slack 討論串中，有一半的討論是在解決實際問題之前先重建背景；入職培訓需要幾個月的時間，因為新員工必須透過耳濡目染而非閱讀來吸收背景知識；決策被重新審議，因為沒有人記得（或者目前的團隊從不知道）同一個問題在六個月前就已經討論並解決了。

這些症狀中的每一項都有其成本，而這些成本加起來遠比大多數團隊所認識到的要大得多，因為每一個單獨的實例看起來都很微不足道。

為什麼它會阻礙異步工作

部落知識與異步工作本質上是不相容的。當做出決策所需的背景資訊存在於某人的腦袋中時，只有在該人有空分享時才能做出決策。這迫使所有事情都進入同步管道：會議、即時 Slack 對話、拍肩膀打擾。

在分佈式或混合團隊中，這種不相容性更加尖銳。身處不同時區、需要支付系統背景資訊的工程師必須等待掌握該背景的工程師上線。原本可以透過文件異步做出的決策，卻卡在了日曆上的會議時間段中。

將部落知識轉化為可搜尋的文件可以解鎖異步決策，因為任何人在任何時候都可以獲得背景資訊，而不需要知識持有者在場。一個能夠閱讀決策日誌以了解支付系統為何如此構建的工程師，不需要為了弄清楚這件事而安排一次會議。

轉化難題

將部落知識轉化為文件的挑戰在於，持有這些知識的人通常是團隊中最忙碌的人：資深工程師和早期員工，他們的時間最寶貴、也最超載。要求他們坐下來寫下他們所知道的一切，無異於要求他們在現有工作之外承擔一項龐大且無止境的任務。

自動編寫的文件透過從已經在共享知識的管道中擷取部落知識來解決這個問題。當資深工程師在 Slack 中解釋一個設計決策時，該解釋就會被擷取並結構化。當一場會議涵蓋了系統目前架構背後的歷史時，該討論就會成為文件的一部分。當 PR 描述解釋了為什麼選擇特定方法時，其推導過程就會與代碼一起被保存下來。

資深工程師不需要撰寫文件。他們照常進行日常工作，而文件便會從中自然產生。

常見問題

我們如何識別我們的部落知識？ 尋找那些被反覆提及且只能由特定人員回答的問題。尋找在提出實際問題之前，前幾條訊息都在建立背景資訊的 Slack 討論串。尋找那些旨在分享資訊而非做出決策的會議。這些都是知識應該被記錄但未被記錄的症狀。

最先擷取哪些部落知識最具價值？ 系統架構決策（為什麼要以這種方式構建）、事件歷史（出了什麼問題以及因此做了哪些更改）以及集成邊界（不同服務如何通信以及原因）。在這些領域中，缺失背景資訊會導致最昂貴的錯誤。

部落知識可以被完全消除嗎？ 不行，也不應該這樣做。有些知識本質上是與特定情境相關的，並透過實踐經驗發展起來，這是文件無法完全捕捉的。我們的目標是減少僅存在於人們腦海中的關鍵運營知識的比例，而不是完全消除非正式的知識傳遞。

相關閱讀：巴士係數、文件債、為什麼工程文件很重要。相關頁面：自動編寫文件、知識保留、適用於工程團隊。