第十三章：機房裡的幽靈

應用理論：心理動力學理論 (Psychodynamic Theory)

隨著團隊在溝通技巧上取得突破，「綠洲計畫」的氛圍看起來充滿希望。然而，艾佛勒敏銳地感覺到，在表層的協作改善之下，依然有一些更深層、更隱蔽的暗流在涌動。某些特定的議題，總能輕易地激發起團隊非理性的、過度的情緒反應。

其中最明顯的一個，就是關於「技術文件」(Technical Documentation) 的議題。

在一次回顧會議上，QA負責人莉莉提出了一個合理的建議：「為了減少溝通成本和重複提問，我們是不是可以要求，所有新開發的API，都必須有對應的技術文件？」

這個建議一提出，會議室的氣氛瞬間降到冰點。幾位資深的後端工程師，包括大衛在內，立刻表現出強烈的抗拒。

「寫文件太浪費時間了！」一位工程師說，「代碼本身就是最好的文件。有時間寫文件，不如多寫幾個單元測試。」

「就是！需求變得那麼快，文件根本不可能跟得上更新，過時的文件比沒有文件更害人！」另一位附和道。

他們的反應之強烈，遠遠超出了對一個普通流程建議的討論範疇，更像是一種觸及了內心禁忌的應激反應。艾佛勒意識到，這背後一定有故事。這不是一個單純的技術或效率問題，而是一個心理動力學 (Psychodynamic) 層面的問題。

心理動力學理論認為，組織和個人一樣，也有其「無意識」的層面。過去的經歷，特別是那些帶有創傷性的事件，會像幽靈一樣潛伏在組織的集體記憶中，持續影響著當下的行為和決策，即使事件的當事人大多已經離開。

為了探尋這個「幽靈」的來源，艾佛勒在之後的一對一訪談中，特意加入了關於「文件化」歷史的問題。他從入職超過五年的老員工那裡，逐漸拼湊出了一個完整的故事。

故事的主角，是一位五年前離職的技術總監，名叫高德。

高德是一位技術能力極強，但管理風格極其嚴苛的管理者。他篤信「流程和文檔可以解決一切問題」。在他任內，他推行了一套極其繁瑣的文檔制度。任何功能的開發，都必須先撰寫長達數十頁的詳細設計文檔，文檔需要經過三級審批，任何一個微小的修改，都必須重新走一遍文檔審批流程。

他會隨機抽查工程師的文檔，如果發現任何格式錯誤或描述不清的地方，就會在團隊的公開郵件組裡點名批評，言辭嚴厲，毫不留情。有一次，一位年輕工程師因為在文檔中用錯了一個UML圖的箭頭，被高德在全員會議上訓斥了近半個小時。

在高德的治理下，「寫文檔」不再是為了溝通和傳承知識，而變成了一種為了免於受罰而進行的、充滿恐懼和痛苦的儀式。工程師們將大量的時間耗費在應付這些官僚流程上，開發效率極低，士氣也降到了谷底。

那段時期，成了許多老員工心中共同的「創傷記憶」。

最終，在高層的干預下，高德離開了公司。他的離開，像是一次解放。團隊為了「撥亂反正」，幾乎是報復性地拋棄了所有與「文檔」相關的流程。他們形成了一個新的、不成文的集體信念：「文檔是邪惡的」、「敏捷就是不寫文檔」。

這個信念，就是潛伏在機房裡的「高德的幽靈」。

即使五年過去了，高德早已不在，但這個幽靈仍然在操控著團隊的行為。每當有人提起「文件」或「流程」這些詞，就會觸發團隊的集體創傷後反應 (PTSD)。他們反抗的，早已不是「寫文件」這件事本身，而是反抗它所喚起的，那種被剝奪自主權、被微觀管理、被公開羞辱的痛苦感受。

在一次與穆拉提和大衛的對話中，艾佛勒分享了他的這個發現。

艾佛勒總結道，「所以，你們現在面對的，不是一群『不願意寫文件』的工程師，而是一群『害怕再次受到高德式傷害』的倖存者。不理解這個歷史，我們所有的討論都只會在表面打轉。」

大衛聽完，長久地沉默了。他是經歷過那個時代的人，他完全知道艾佛勒說的是什麼。他一直以為自己對文檔的反感是出於對「效率」的理性追求，但此刻他才意識到，自己的反應中，夾雜了多少源於過去痛苦的非理性情緒。

「天啊……」穆拉提感到一陣後怕，「我從來不知道還有這段歷史。我只是一直在奇怪，為什麼我們的團隊文化這麼排斥流程。」

艾佛勒說：「這就是組織的無意識。它看不見，摸不著，卻比任何規章制度都更有力量。要驅散這個幽靈，我們不能假裝它不存在，也不能強行去壓制它。我們需要做的，是把它『請』到陽光下，承認它的存在，並與它和解。」

基於這個洞見，艾佛勒設計了一場特別的工作坊，主題就叫「聊聊我們與『流程』的愛恨情仇」。在工作坊中，他邀請老員工分享高德時代的故事，讓新員工理解團隊這份「集體傷疤」的由來。然後，他引導大家討論：

「高德時代的哪些痛苦，是我們絕不希望重蹈覆轍的？」
「拋開那段不愉快的經歷，『好的文檔』和『好的流程』，在理想情況下，應該能為我們帶來什麼價值？」
「我們能否共同創造出一種全新的、屬於我們自己的、輕量級且真正有益的知識管理方式，而不是回到過去的那個極端？」

這場工作坊，像一次集體的心理治療。當那些被壓抑的痛苦和恐懼被公開地、安全地談論時，它們就開始失去了操控人心的力量。團隊成員們第一次能夠將「高德的創傷」與「文檔的價值」分開來看待。

最終，團隊達成了一個新的共識：他們決定試行一種極簡的「README導向開發」(Readme-Driven Development) 模式。在開發任何新組件或API之前，先用簡潔的語言寫一份給未來同事看的說明書。這份說明書不是為了應付檢查，而是為了幫助團隊自己。

「高德的幽靈」並沒有完全消失，但團隊已經學會了如何與它共處。他們不再被無意識的恐懼所驅動，而是開始有意識地、理性地去建設他們真正需要的未來。