工程領導者面臨的主要挑戰之一是識別知識孤島。如果不加以識別和解決，這些孤島會演變成對個別人員的依賴，這些人可能（無意中，甚至可能是無意識地）開始拖慢團隊的進展。在我職業生涯的某個時期，我記得我被指派去改變我們的 iOS 應用在 Apple Store 中的配置細節。通常，我們優秀的創始 iOS 工程師會負責這項任務，但這次他正在休產假，因此這項任務落到了我身上。
當我開始時，我很快意識到我無法完成這項任務 —— 不管是一小時、一整天還是一週。為什麼？因為負責的工程師在離開之前沒有將憑證上傳到密碼管理系統。畢竟，為什麼要麻煩呢？他是做所有與 iOS 相關工作的專家，快速且出色。然而，在這種情況下，工作是緊急的，因為我們意識到我們一直在做一些非法的事情（因為我們最近才開始有法律團隊），所以需要迅速完成 —— 但我們卻無法做到。
你看到了嗎？一個知識孤島讓我們陷入困境！那麼問題是：你如何避免這樣的知識孤島和隨之而來的個人依賴呢？我有幾個想法可以分享。
但首先，為什麼知識孤島會出現？#
在公司早期，只有一個人知道如何做某些事情或只有一個人擁有正確的權限是正常的。理想情況下，這些情況是可控的，並且不是關鍵任務。例如，只有一位 CSS 專家能夠非常快速地將動畫 “調整到位” 是可以的。然而，只有一個人知道如何回滾部署就不行。
同樣，在團隊中也有一些情況，沒有討論或流程來決定誰將負責某項任務。相反，角色是隱性的 —— 用內部名稱如 “DevOps 專家” 或 “後端女孩” 來稱呼。還有一些情況，當工程經理或產品合作夥伴需要緊急完成某項工作時，會直接找特定的工程師。這樣做時，他們往往會繞過團隊流程和儀式。
這些情況往往表明：如果不加以注意，它們有可能打開潛在的知識孤島。
你如何識別知識孤島？#
關鍵在於尋找，或者更確切地說，傾聽個人依賴。為此，留意以下短語，這些短語表明你有單人依賴：
👉 “我不想做那項任務，因為 非常資深的工程師 X 在度假”
👉 “我需要請 創始工程師 Y 來部署，因為他們是唯一有權限的人”
👉 “我在等待 DevOps 專家 Z 的審核後再合併，因為他們是基礎設施即代碼的專家”
簡而言之，任何時候因為某個人無法參與而導致事情未能如預期進行，都表明你可能有問題。
避免知識孤島的三個有效方法#
現在你知道知識孤島可以輕易產生單人依賴，並且會慢慢變成一種困擾，這裡有三個想法可以幫助你避免它們：
1. 設計考慮知識孤島的團隊#
避免僅有功能專家的團隊。至少要有一些全棧工程師或多個能夠處理團隊可能執行的任何類型任務的人。這將幫助你創造一種文化，使所有團隊成員都能舒適地嘗試任何類型的任務。
為此，在低層次的團隊設計中，始終明確詢問以下問題：是否有多於一個人能夠處理這個團隊所做的每種類型的工作？
2. 組織團隊輪換#
另一個最佳實踐是組織團隊輪換或團隊 “野外考察”，讓成員永久（或暫時）加入組織內的其他團隊。這有助於促進團隊之間的知識共享，讓人們有機會向之前未合作過的其他人學習。
好處是，團隊輪換不僅幫助員工學習新知識，還鼓勵個人發展對他人工作方式的同理心 —— 在整個組織中創造對彼此工作的尊重感。由於只有一兩名特定團隊的成員在這些野外考察中與另一個團隊合作，因此每個團隊仍然可以正常運作。
3. 確保所有關鍵任務由兩個人完成#
最後，確保至少有兩個人能夠完成將軟件投入生產所需的所有關鍵任務。即使只有其中一個人能夠很好地完成工作，讓兩個人了解任務的來龍去脈也能避免知識僅限於一個人。
同時，確保這些關鍵任務的 “如何做” 有文檔支持，並且所有人都能訪問。這樣，大家都能獲得知識 —— 幫助你減少對單個人的依賴。
知識共享實踐#
優秀的團隊將知識共享作為一種實踐。這可以通過多種方式進行：
投資於文檔#
制定關於如何正確記錄的指南，包括所有文檔的托管位置和信息打包格式（例如，短的屏幕錄製解釋視頻或檢查清單）。但請記住，文檔需要時間。此外，文檔可能會迅速變得過時、重複或令人困惑。
設置文檔的指南並為創建知識共享文檔預留時間將有所幫助。定期更新這些文檔的時間也很重要，否則所有的工作都可能迅速浪費。
組織知識咖啡會議#
這些是 “展示與告訴” 的會議，團隊成員分享他們如何完成某項任務。在這些知識共享會議中包括問答時間，可以在你的組織中創造一個富有成效的同伴學習環境。
這些會議的唯一缺點是，有時對內向者來說可能會令人畏懼，對於喜歡通過實踐學習的人來說，價值可能不那麼高。通過請願意進行展示和告訴的人成為演講者來克服這一點。至於團隊中的內向者，詢問他們是否希望鍛煉公共演講的能力，以便激勵他們主辦這樣的會議。
團隊合作#
這是我最喜歡的知識共享方式 —— 團隊合作（集體編程或成對編程）。在這樣的知識共享會議中，所有員工都有機會通過實踐來學習。這使其成為創造學習文化和防止知識囤積的最有價值的方式之一。
不過，對此的常見抱怨是？這會減慢團隊的速度。在某些情況下，是的，這可能會，但僅在短期內。例如，如果 Java 搖滾明星必須與前端新手配對，那麼深入研究 JVM 垃圾收集的後端任務可能會完成得更慢。
然而，這僅僅是在特定任務上短時間內降低了最大速度，因為在接下來的一周，你會看到同樣的前端新手參與後端任務 —— 讓你不必專門為他們創造低價值的工作。同樣，Java 搖滾明星可能會離開去其他公司工作，而在你聘請新搖滾明星之前，前端新手將繼續推進產品。
簡而言之，忍受小幅減速將會在未來幫助你節省大量時間 —— 使一切都值得。
結語#
沒有人會在一年中的每一天工作，並且很少有人會希望永遠留在你的公司。這使得防止知識孤島和拯救組織免受單人依賴變得重要。你需要投資於文檔，舉辦知識共享會議，並組織團隊輪換。最重要的是，設計考慮知識共享的團隊。
如果你仍然發現自己在降低知識共享的優先級，我建議你假設在你最大的生產緊急情況或最關鍵的客戶緊急功能請求的那一天，你的 MVP 工程師將會高興地慶祝孩子的出生或結婚。
有了這樣的假設，你將走上防止知識孤島的道路。