概述#

組織比網路上的陌生人更了解自身的問題領域，因此應有能力回答大部分內部問題。要達成這個目標，需要兩個要素：擁有答案的專家和散播知識的機制。這些機制從最簡單的「提問與記錄」，到結構化的教學課程都有。然而，最重要的是組織需要一種學習文化，而這需要建立讓人們敢於承認不足的心理安全感（psychological safety）。

學習的挑戰#

在缺乏強健學習文化的情況下，隨著組織規模擴大，容易出現以下問題：

• 缺乏心理安全感（Lack of psychological safety）：人們害怕在他人面前犯錯或冒險，擔心受到懲罰，導致恐懼文化和缺乏透明度
• 資訊孤島（Information islands）：組織各部門之間缺乏溝通，各自發展自己的做法，進而衍生三種問題：
  • 資訊碎片化（Information fragmentation）：每個孤島只看到局部而非全貌
  • 資訊重複（Information duplication）：各孤島重複發明相同的解決方案
  • 資訊偏差（Information skew）：各孤島做同一件事的方式不同，甚至互相矛盾
• 單點故障（Single point of failure, SPOF）：關鍵資訊僅存在於單一人身上，形成瓶頸。源自善意的「讓我來幫你處理」心態，短期效率高但長期可擴展性差，團隊永遠學不會這項技能
• 全有或全無的專業知識（All-or-nothing expertise）：團隊分裂為「什麼都懂」的專家和什麼都不懂的新手，缺乏中間層。專家總是自己處理事務而不培養新人，知識和責任持續堆積在少數人身上
• 鸚鵡學舌（Parroting）：不理解原因就盲目複製模式或程式碼，假設其存在必有未知理由
• 鬧鬼墓地（Haunted graveyards）：因為恐懼和迷信而不敢碰觸或修改的程式碼區域

理念#

軟體工程是多人協作開發多版本程式的過程。人是軟體工程的核心：程式碼是重要產出，但僅是建造產品的一小部分。每位專家都曾是新手，組織的成功取決於對人才的投資與培育。

知識的傳遞有兩種互補的形式：

1. 個人化指導（Personalized advice）：來自專家的一對一建議無可取代，但無法擴展，且當專家離開時團隊會陷入困境
2. 文件化知識（Documented knowledge）：可擴展至整個組織，但較為通用、不一定適用個別情境，且需要持續維護

部落知識（Tribal knowledge） 存在於個人所知與已記錄知識之間的落差。將其文件化後，任何能找到文件的人都能受益，而不僅限於能直接接觸專家的人。

部落知識與書面知識是互補的。即使團隊擁有完美的文件，仍需彼此溝通、與其他團隊協調、隨時間調整策略。沒有單一方法能解決所有學習需求，最佳組合會隨組織成長而改變。

建立基礎：心理安全感#

心理安全感是推動學習環境的關鍵基礎。要學習，首先必須承認有不懂的事物。組織應歡迎這種誠實，而非懲罰它。Google 的研究顯示，心理安全感是高效團隊最重要的因素。

導師制度（Mentorship）#

Google 會為每位新進員工（Noogler）指派一位導師，該導師不是同團隊成員、主管或技術主管，職責明確包含回答問題和協助新人上手。導師的特點：

• 在 Google 任職超過一年的志願者
• 可提供從基礎設施使用到文化融入的各種建議
• 不在同一團隊，讓新人在敏感問題上更自在地尋求幫助
• 扮演安全網的角色

導師制度將學習正式化，但學習本身是持續的過程。健康的團隊中，成員不僅樂於回答問題，也敢於提問，展示自己不知道某些事物並從彼此身上學習。

大群體中的心理安全感#

向大群體提問比向身邊同事提問更令人畏懼，但一對一方案無法擴展。在大群體中營造安全環境的關鍵是讓互動保持合作而非對立。

Recurse Center 的社交規則也很有參考價值：

• 不要假裝驚訝：「什麼？你竟然不知道 stack 是什麼！」會阻礙心理安全感
• 不要「其實呢」（No well-actuallys）：吹毛求疵的糾正往往是為了炫耀而非精確
• 不要旁邊插嘴（No back-seat driving）：打斷現有討論提供意見卻不投入對話
• 不要微妙的歧視（No subtle -isms）：微小的偏見表達會讓人感到不受歡迎

提升個人知識#

提問#

如果你從本章只帶走一件事，那就是：永遠保持學習，永遠保持提問。

Google 告訴新人，適應期大約需要六個月。新手最常犯的錯誤是遇到困難時不尋求幫助。不要陷入「我應該再多試一下才問人」的陷阱——同事往往是最好的資訊來源。

• 沒有一天你會突然在任何情境都知道該怎麼做——永遠有更多東西可學
• 在 Google 工作多年的工程師仍有覺得不確定的領域，這很正常
• 擁抱不知道，將其視為機會而非恐懼
• 領導者更應以身作則：資深不等於全知。公開提問或表達知識缺口，能強化「這樣做是可以的」的訊號

在接收端，耐心和善意地回答問題能營造安全的求助環境。主動徵求問題，讓即使是「瑣碎」的問題也能得到回覆。有針對性的協助讓工程師更快進入生產力狀態，從而讓整個團隊更有效率。

理解脈絡#

學習不只是理解新事物，還包括理解既有設計與實作背後的決策脈絡。面對繼承的遺留程式碼，不要急於從頭重寫，而是深入探究。

乞斯特頓之牆（Chesterton’s Fence）：在移除或改變某樣東西之前，先理解它為什麼存在。如果你不明白某段程式碼或設計的用途，不要急於宣稱「這很糟糕」。先尋求並理解脈絡，然後再判斷你的修改是否仍合理。如果合理就進行修改；如果不合理，記錄你的推理供未來讀者參考。

Google 的許多風格指南會明確包含脈絡說明，讓讀者理解規則背後的原因，而非只是死記規則清單。

擴展提問：向社群求助#

一對一協助頻寬高但規模有限。當你從一對一討論中學到東西時，寫下來——這不僅幫助未來的自己，也幫助未來的新人。

群組聊天（Group Chats）#

• 可以一次向多人提問，快速來回對話
• 分為主題導向（開放、吸引專家、規模大、回覆快）和團隊導向（較小、較安全）
• 適合快速問題，但缺乏結構，不便於事後檢索
• 當需要分享資訊到群組外或日後參考時，應寫成文件或寄到郵件列表

郵件列表（Mailing Lists）#

• 問題觸及大量潛在回答者，任何追蹤列表的人都能從答案中學習
• 比群組聊天更易於分享給更廣泛的受眾，有可搜尋的存檔和更好的結構
• 找到答案後應回覆到列表上，讓未來需要相同資訊的人受益
• 缺點：不適合快速來回交流；舊討論串的答案可能過時；訊噪比可能較低

問答平台（YAQS）#

Google 內部類似 Stack Overflow 的系統，結合了郵件列表的優點並加以改進：

• 有用的答案會被提升至介面上方
• 使用者可以編輯問題和答案，保持準確和有用
• 部分郵件列表已被 YAQS 取代，其餘則演變為更廣泛的討論列表

擴展知識：你總有可以教的東西#

教學不限於專家。專業知識是多維向量——每個人在不同領域都有不同程度的專業。這也是多元化對組織成功至關重要的原因之一。

辦公時間（Office Hours）#

定期排定的活動，一或多人在固定時段回答特定主題的問題。特別適用於：

• 問題仍然模糊，工程師尚不知道該問什麼
• 問題過於專業，缺乏相關文件

缺點是有急迫問題時需等待下次場次，且主持者需投入時間。

技術講座與課程（Tech Talks and Classes）#

Google 有豐富的內部和外部技術講座文化。g2g（Googler2Googler） 計畫讓員工自願報名教授或參加同事的講座和課程，主題從高度技術性到趣味性都有。

課程最適合在以下條件下開設：

1. 主題夠複雜，是常見的誤解來源
2. 主題相對穩定，不會快速變化
3. 主題受益於有教師即時回答問題和提供個別協助
4. 有足夠需求能定期開課

文件（Documentation）#

文件是以幫助讀者學習為主要目標的書面知識。

更新文件：第一次學習某件事是改善現有文件的最佳時機。此時你最能發現哪些步驟缺失或不清楚。在 Google，工程師被賦權去更新任何文件，不論擁有者是誰，即使只是修正一個錯字。g3doc 工具讓這件事變得更容易。

撰寫文件：隨著專業成長，撰寫自己的文件。任何難以被發現或搜尋到的文件等於不存在。g3doc 將文件放在原始碼旁邊，使其可預測地被找到。

推動文件撰寫：撰寫文件的直接好處包括：

• 節省反覆回答相同問題的時間
• 資訊被正規化為參考文獻，團隊成員可引用並更新
• 正規化的知識可能擴散到團隊之外，幫助其他團隊解決類似問題

確保文件有回饋機制。如果讀者無法輕易指出文件過時或不準確，他們通常懶得通知任何人。在 Google，讀者可以直接從文件本身提交文件 bug 或留下評論。

程式碼（Code）#

程式碼本身就是知識的一種形式。程式碼審查（Code review） 對作者和審查者都是學習機會。Google 透過 Readability 流程（本章末詳述）將程式碼審查中的指導標準化。

擴展組織知識#

培養知識共享文化#

Google 認為先聚焦於文化與環境比只聚焦於產出（如程式碼）能帶來更好的結果。

尊重（Respect）：少數人的不良行為就能讓整個團隊或社群變得不友善。知識共享應以善意和尊重進行。在科技業，對「才華橫溢的混蛋」的容忍甚至崇拜既普遍又有害，但成為專家和保持善良並不互斥。Google 的工程職級標準明確指出：

領導者提升周圍人的素質、改善團隊的心理安全感、營造團隊合作與協作的文化。混蛋不是好的領導者。

激勵與認可（Incentives and Recognition）：好的文化需要主動培養。常見的錯誤是口頭宣揚一套價值觀，卻實際獎勵不符合那些價值觀的行為。Google 的做法包括：

• 績效考核與晉升標準：工程職級階梯明確要求知識共享，越資深越強調更廣泛的影響力
• 同儕獎金（Peer bonus）：任何員工都可以授予其他員工的貨幣獎勵和正式認可，以表彰超越份內的工作
• Kudos：公開表彰較小的貢獻，提升同儕間貢獻的可見度

重要的不是獎金本身，而是同儕的認可。一個讓人們能正式且輕鬆認可同儕的系統，是鼓勵持續優秀行為的強大工具。

建立權威資訊來源（Canonical Sources of Information）#

權威資訊來源是集中化、全公司範圍的知識語料庫，用於標準化和傳播專家知識。適用於與全體工程師相關的資訊，有效對抗資訊孤島。

注意事項：

• 權威內容需被主題專家積極維護和審核，主題越複雜越需要明確的擁有者
• 建立和維護成本高，不是所有內容都需要在組織層級共享
• 在決定投入多少資源時，應考慮受眾範圍：自己？團隊？產品線？全體工程師？

開發者指南（Developer Guides）：Google 有廣泛且深入的官方工程指引，包括風格指南、軟體工程最佳實踐、程式碼審查和測試指南，以及每週技巧（Tips of the Week）。人類專家可以發送連結給同事，省去親自解釋全公司慣例的時間。

go/ 連結：Google 內部的 URL 縮短器。大多數內部資源至少有一個 go/ 連結（如 go/spanner、go/python）。好處：

• 簡短易分享，降低知識分享的摩擦
• 提供永久連結，底層 URL 變更時只需更新 go/ 連結的目標

go/ 連結已深入 Google 文化，形成良性循環：員工查找 Frobber 資訊時會先嘗試 go/frobber，如果不存在就自行設定。

Codelabs：引導式、動手操作的教學，結合說明、最佳實踐範例程式碼和練習。是靜態文件和講師授課之間的有趣中間點——比傳統文件更具吸引力，工程師可按需自行完成，但維護成本高且無法針對學習者的特定需求量身定制。

靜態分析（Static Analysis）：將最佳實踐以程式化方式檢查，是強大的知識共享手段。設定需要前期投資，但一旦就位就能高效擴展——當工具新增一項最佳實踐檢查時，所有使用該工具的工程師都會意識到這項實踐，同時釋放工程師的時間去教授其他事物。

保持消息靈通（Staying in the Loop）#

電子報（Newsletters）：Google 有多份全公司電子報，包括 EngNews（工程新聞）、Ownd（隱私/安全新聞）和 Google’s Greatest Hits（季度最有趣故障報告）。發送頻率較低但內容更有用時，參與度更高。值得一提的是 Testing on the Toilet 和 Learning on the Loo——張貼在廁所隔間內的單頁電子報，這種獨特的傳播方式讓它們脫穎而出。

社群（Communities）：Google 員工喜歡組成跨組織社群分享知識。Google Groups 有數千個內部群組，涵蓋從故障排除到程式碼健康等各種主題。這些開放管道讓人更容易向直接圈子外的人學習，避免資訊孤島。

Readability：透過程式碼審查進行標準化指導#

在 Google，「readability」不僅指程式碼可讀性，更是一個標準化、全公司範圍的指導流程，用於傳播程式語言最佳實踐，涵蓋語言慣用法、程式碼結構、API 設計、常用函式庫使用、文件和測試覆蓋率。

歷史#

Readability 始於一人之力：Google 早期員工 Craig Silverstein（員工編號 #3）會親自與每位新人坐下來，逐行審查他們第一次重大程式碼提交。隨著招聘速度超過一人能負荷的程度，許多工程師志願投入來擴展此計畫。如今約 20% 的 Google 工程師隨時參與 readability 流程，作為審查者或程式碼作者。

流程#

• 每個變更清單（CL, changelist）都需要 readability 核准
• 已取得認證的作者可隱含地為自己的 CL 提供 readability 核准
• 未取得認證者需要外部合格審查者明確給予核准
• 約 1-2% 的 Google 工程師是 readability 審查者，全為志願者
• 審查者被期待將 readability 視為指導與合作流程，而非門檻或對立流程

為什麼要有這個流程#

• 跨團隊知識曝光：工程師必須將 CL 送至集中化的審查者群組，接觸到的不僅是自己團隊的部落知識
• 全程式碼庫一致性：即使數萬名工程師歷經數十年撰寫程式碼，同一語言的程式碼在整個語料庫中看起來相似。讀者可專注於程式碼做什麼，而非困惑於為什麼格式不同
• 大規模變更：全 monorepo 一致性使跨越數千個團隊的大規模變更更加容易
• 團隊流動性：換團隊時可以確信新團隊使用同一語言的方式不會大相徑庭

成本與權衡#

• 沒有團隊成員擁有 readability 的團隊需向外部尋找審查者，增加摩擦
• 可能需要額外幾輪程式碼審查
• 人力驅動的流程只能線性擴展，無法次線性擴展

此計畫刻意以增加短期程式碼審查延遲和前期成本，換取長期回報：更高品質的程式碼、全 repository 一致性，以及工程師專業的提升。長期效益基於程式碼的潛在生命週期可達數年甚至數十年的預期。

研究結論#

Google 的工程生產力研究（EPR）團隊對 readability 進行了深入研究，結果顯示：

• Readability 對工程速度有淨正面影響
• 擁有 readability 的作者提交的 CL 在統計上顯著地比未擁有者花更少時間審查和提交
• 完成此流程的工程師中有顯著多數對流程感到滿意且認為值得
• 工程師報告從審查者身上學到東西，並改變了自己撰寫和審查程式碼的行為

結論#

知識是軟體工程組織最重要（雖然無形）的資本，知識共享對於讓組織在面對變化時保持韌性和冗餘至關重要。推動開放誠實的知識共享文化，能在組織中高效分配知識並隨時間擴展。對更容易的知識共享的投資，通常能在公司的生命週期中獲得數倍回報。

TL;DRs#

• 心理安全感是培養知識共享環境的基礎
• 從小處開始：提問並寫下所學
• 讓人們能輕鬆從人類專家和文件參考中獲得所需幫助
• 在系統層面，鼓勵和獎勵那些花時間教學並將專業擴展到自身、團隊或組織之外的人
• 沒有銀彈：賦能知識共享文化需要多種策略的組合，最適合你組織的組合會隨時間改變