寫這篇文章的想法是在一次會議上冒出來的，那次會議上我們知道了我們的主管要離開公司去尋找新機會了。一位同事對此感嘆，我們最懷念的就是隨着這位領導一同離去的那些知識。

不幸的是，事情就是這樣：我們不僅失去了一位同事，而且還失去了很多寶貴的知識和經驗。然而，這樣的故事並不只是發生在我的主管身上，也發生在了我的導師身上。

所有在各自領域中成爲專家的人們都在重複這樣的故事。他們熟諳通向成功的路徑，也知道如何避開那些通向災難性失敗的方向。當他們離開我們的身邊，會帶走很多我們在任何書籍、筆記或 Jira 票證中都找不到的知識。

這就引出了一個根本性的問題：如何才能避免這種知識“黑洞”？我們如何確保知識不會隨着它們的擁有者一起消失？這篇文章討論的就是這樣一個主題。

有些人作出了業務決策……但並沒有告訴我們理由 

我專門爲本文創建了一個術語，名爲“生物數據存儲（Biological Data Storage）”或簡稱“BDS”。公司中的幾乎每一位員工都適用於這條術語。我知道沒有人希望自己被視爲一種單純的資源，當然也不想被視爲“生物數據存儲”的一部分。然而，從公司資源的視角來看，員工可以比作某種技術數據的存儲庫，但除了技術數據外還有着價值很高的上下文。

我想從工程師的角度從更大的層面上來研究這個問題。我們經常聽到有人提到康威定律：

任何組織在設計一個系統（廣義定義）時所做出來的設計結構，都是組織內部溝通結構的副本。我認爲知識的流失其實是溝通不暢的結果，這最終會導致組織所創建的系統出現缺陷。 

工程方法的特點就是我們致力於衡量各種事件的影響，並使用特定指標評估事件的真正意義。在應對員工離職的挑戰時，請考慮以下指標來評估組織的有效性：

解決問題的時間：

衡量解決問題或挑戰的速度，並幫助確定問題解決過程的效率。

知識轉移率：

衡量新員工開始獨立產生價值所需的時間，並表明知識轉移和新人培訓的效果。

我認爲這些指標爲組織效率及其無縫整合新的團隊成員的能力提供了寶貴的見解。在康威定律的背景下，知識的流失成爲了不僅影響組織內部溝通效率，而且影響公司內部系統設計的關鍵因素。

考慮一下：當擁有豐富知識和專業知識的團隊成員離開時，他們帶走的不僅是事實和數據，還有他們獨特的見解、解決問題的方法以及對組織複雜性的理解。缺乏此類知識可能會擾亂團隊內部和跨部門的信息流動管道。結果，組織的溝通結構可能會因此動搖，影響組織有效應對挑戰的能力。

此外，系統的設計也會受到深遠的影響。掌握寶貴知識的工程師和開發人員可能會基於他們的專業知識做出設計選擇。這些決策可能沒有被其他人記錄下來或清楚地理解到位，當它們的作者離開時，決策本身就可能會變得不透明。這可能會導致維護和開發這些系統出現困難，可能導致效率低下和漏洞叢生。

現在，當我們將知識轉移率指標引入這種背景時，很明顯，衡量新員工開始獨立產生價值所需的時間是至關重要的。這個時間越長，知識漏洞就會越明顯，進而影響組織溝通和系統設計。組織必須認識到知識不僅僅涉及數據，還關係到對數據的理解和數據的上下文，它的流失會嚴重阻礙團隊的順利運作和系統的發展。

組織沒有記憶 

你可能會問，“失去這些知識對公司又能有什麼影響？”業務流程是不是會因爲流失的知識而像沙土堆一樣崩潰呢？創新也會失去翅膀？公司的運轉效率會像秋風冷雨中的落葉一樣直線下降？在 98% 的情況下，上述問題的答案當然是否定的，因爲我們可以管理此類風險。公司有很多應對這些問題的方法，但他們真的成竹在胸嗎？

Trevor Kletz 的著作《災難的教訓》中引用了《組織沒有記憶》中的一句話，該書強調了組織記憶這一概念，以及由於組織內缺乏從過去的錯誤中有效學習的能力，而導致事件和事故再次發生。Kletz 教授強調，組織無法從事故中吸取教訓，即使是在公司內部發生的事故也是如此。有時我覺得當知識離開我們的公司時也會出現類似的模式。也許是因爲它不能輕易地用金錢來衡量，所以它常常被低估。

雖然 Kletz 的著作講的是化學工程的領域，但我從中看到了一些適用於任何情況和行業的普遍真理。例如，另一句話“你沒有的東西，是不能泄漏的”與“你沒有的代碼是免維護的，並且不會有錯誤”的想法非常相似。我們的領域可能存在類似的原則。

然而，即使在這個階段，知識獲取的過程也可以加速。有多種方法可以做到這一點，例如創建過程、圖示、表格和文檔。

文檔就像是業務世界中的藏寶圖。創建文檔是一回事，但在組織內（無論其規模如何）保持文檔內容不落伍則是一項挑戰。鼓勵團隊定期更新文檔也是一個挑戰。即使準備得最好的文檔也常常缺乏許多細節，例如特定業務決策背後的基本原理、爲什麼選擇特定數據庫或框架，或者爲什麼我們使用技術 Y 而不是在整個公司內更流行的 X 技術。

因此，雖然文檔就像公司的藏寶圖，但有關公司內部流程、系統和實踐的記錄、組織和結構化信息更多屬於架構決策記錄（ADR）的範疇。ADR 就像我們業務的飛行黑匣子。它們包含了系統設計期間做出的關鍵決策或重大技術選擇的記錄。

爲什麼這很重要？在創造新事物時，我們會做出許多決定，如果日後沒有正確的背景信息供查閱，這些決定可能會顯得很不合理。ADR 就像打開了一個盒子，解釋了爲什麼當時我們要做出這些決定。這是瞭解公司歷史和演變的關鍵。在我們的 BDS 背景下，ADR 就像是專家在做出關鍵決策時的想法記錄。當這些專家離開後，這些記錄就成爲了知識的寶庫，幫助我們避免重蹈覆轍。

一個常見的情況是：負責解決問題的團隊必須投入寶貴的時間來重新發現那些本來被探索過的解決方案、嘗試潛在的修復方法，甚至進行反覆試驗。這不僅會延長解決問題的過程，還會導致解決方案不夠理想、增加挫敗感並對整體生產力產生負面影響。藉助文檔和 ADR，我們可以顯著縮短這一過程。

冗長文檔的替代方案？ 

沒有人讀文檔。如果有人讀了，他也看不懂。如果他理解了，也立刻就會忘記。 

不幸的是，正如上面引用的 Stanisław Lem 的描述一樣，文檔、程序和 ADR 的問題在於人們需要熟悉它們。我想即使在 SpaceX 中，這些內容是否會被認爲是最激動人心的閱讀材料也要打一個大大的問號，或者也許我只是不瞭解他們。無論如何，即使有人設法閱讀文檔，他們也只會保留他們理解的那些內容。我們從文檔中看到了其他人的工作，以及他們強加的思維和決策方式。經常出現的情況是，當下出現的問題沒有人知道答案，而知道答案的人也不再在公司工作了。

由於我們現在很清楚自己的心理存在侷限，因此我們可以使用事件風暴（EventStorming）方法，而不是強迫人們篩選成堆的文檔。這種方法有助於我們理解業務流程、識別事件和活動，並以可理解的方式將知識歸納總結在一起。我們關注行爲、變化的內容以及原因。我們一起開發解決方案並瞭解各種流程，因爲我們是從頭到尾走過這些流程的。通過事件風暴方法理解流程比閱讀文檔更快、更容易。在事件風暴會議期間，大多數問題都能找到答案，而且知識可以同時傳達給許多人，無論他們是否是技術人員。此類會議最重要的成果是，你可以討論爲什麼流程看起來是這樣的，爲什麼要選擇特定的順序，而不是另一個——這本質上是文檔、ADR 和對話交流的合體。我再次強調，對流程的理解是集體層面的——每個人都感覺自己是解決方案的一部分。就我們的 BDS 而言，事件風暴可以讓我們在做出關鍵決策時捕捉到那些專家的想法。

現實生活中的例子 

在 Allegro，我們最近遇到了一種情況，負責某項關鍵服務的整個開發團隊被轉移到了另一個項目。繼承該服務的新團隊有機會與調職的團隊合作一段時間。然而，在這種背景下，我們也進行了事件風暴會議。爲了提供更多細節，這些會議持續了整整兩天，每次持續 8 小時。之前團隊過去五年來積累的知識並不只是濃縮在了兩張繪圖紙大小、每張 6 米長的紙上，更是基本無縫地融入了每一位會議參與者的頭腦中。我相信這一過程有助於新團隊在接管該領域時獲得更大的信心。

有趣的是，你不需要在事件風暴上花費大量時間來發現足夠的業務知識。在前面提到的案例中，會議持續了兩天，但這是整個團隊層面的。對於個人來說，兩個小時的研討會足以瞭解我們流程的整體情況。儘管事件風暴使我們能夠相對輕鬆地吸收一些知識，以瞭解流程中發生了什麼事情，以及爲什麼發生種種變化，但細節決定成敗。要真正瞭解這個過程是如何變化的，最好的入門方法是在有經驗的人的指導下完成一些小的任務。

正在尋找類似 UML 的替代方案？ 

不幸的是，事件風暴並不能解決所有與知識流失相關的問題。雖然我不懷疑這個工具的出色效果，但通過它獲得的知識只會留在參與者的腦海中。如果不以某種方式以文檔或 ADR 的形式保存下來，這些知識依舊可能會像離職員工一樣轉瞬即逝。關於這一問題我們還能做些什麼？我們最初的想法可能會推動我們創建某種形式的描述或文檔，正如我們所知，這一過程中會遇到很多關於文檔準備的挑戰，還會讓試圖吸收新知識的人們出現認知超載。

看來，在處理知識流失及其有效轉移問題時，值得一提的是像 BPMN（業務流程模型和表示法）這樣的工具。BPMN 提供業務流程的標準化圖形表示。通過使用 BPMN 圖，我們可以直觀地映射工作流程和過程。這種方法不僅簡化了對複雜流程的理解，而且有助於全面記錄。當與其他知識共享技術（例如事件風暴）結合使用時，BPMN 可以成爲保存和傳輸關鍵業務知識的強大資產。

然而，BPMN 有一套複雜的符號和符號規則，這可能會讓某些人創建和解釋圖表的過程變得頗爲複雜。創建高級 BPMN 圖並充分利用符號的潛力需要專業的知識和經驗。不熟悉 BPMN 的人們可能很難有效地使用它。儘管存在這些不便，BPMN 仍然是許多組織中建模和記錄業務流程的寶貴工具。我相信它是對前文提到的技術的完美補充。

只需記住，你應該在你的武器庫中準備正確的工具，更重要的是根據具體情況選擇合適的工具，同時充分衡量其優點和缺點。

還有一件事…… 

解決問題的時間指標是組織應對挑戰時的效率的一項明確指標。解決問題的時間較短意味着問題得到迅速解決，最大限度地減少干擾並確保組織平穩運行。知識轉移率指標是一種量化和解決知識損失的方法，揭示了其對組織內溝通結構和系統設計的影響。

這兩個指標都直接受到文檔、ADR、事件風暴或 BPMN 等工具的合理使用的影響。我也在前文嘗試揭示了它們在知識轉移方面的優點和缺點。

然而還有另一項挑戰——改變公司文化。員工必須知道他們擁有哪些工具，並認可分享知識是成功關鍵這一觀念。領導力在這裏起着至關重要的作用，因爲領導者需要積極促進和參與知識共享和開放溝通過程。如果公司領導積極認可並參與知識共享，其他員工就更有可能效仿他們。然而，改變組織文化是一個耗時的過程。在新的行爲和信念戰勝舊的行爲和信念之前，耐心和毅力至關重要。

世上無難事 

作爲組織中的工程師，無論規模大小，你都可以採取一些積極主動的步驟來促進知識轉移。首先也是最重要的，我們應該積極與同事進行開放的溝通。我們應該鼓勵討論和信息共享，尤其是在你的專業領域內，以確保大家共享的是有價值的見解。其次，指導可以是一個強大的工具。我們可以主動指導初級團隊成員或向更有經驗的同事尋求指導。此外，我們可以參與公司內部的知識共享活動，例如棕包會議、研討會或跨職能項目。最後，我們應當考慮創建內部文檔和存儲庫或對其作出貢獻。這些資源可以作爲你的同事和未來團隊成員的寶貴參考，確保知識保留在組織內。通過積極參與這些實踐，你可以在組織內保存和傳播關鍵知識方面發揮關鍵作用。

小結 

在本文中，我討論了從工程師的角度來看，公司中的知識流失是如何出現的，以及爲什麼它會構成威脅。生物數據存儲這個術語可能聽起來很不傳統，但它強調了每個團隊成員在保存和轉移知識方面所發揮的關鍵作用。重點在於，我們要記住員工不僅僅是資源，更是寶貴的信息、經驗和專業知識的活寶庫。在 BDS 的世界中，每個成員都爲集體知識體系做出貢獻，塑造組織的溝通結構。當我們告別離職的同事時，讓我們也一同告別知識應該侷限於個人頭腦的觀念。相反，讓我們採用開放溝通、積極知識共享和正確工具（例如事件風暴和 BPMN）的文化，在整個組織內捕獲、保存和共享關鍵知識。

原文鏈接：

https://blog.allegro.tech/2023/10/battle-against-knowledge-loss.html

本文來自微信公衆號“InfoQ”（ID:infoqchina），作者：Krzysztof Przychodzki ，36氪經授權發佈。