Google 的軟體工程之道 (20) — 知識共享

https://innovecs.com/blog/building-software-development-teams/

此系列為 【 Google 的軟體工程之道 】一書的書摘與點評，期待用最精要的文字，帶來豐富的內容分享。預計 2~3 周左右會有一篇更新，歡迎追蹤支持!

【 Google 的軟體工程之道 】全系列: https://medium.com/@johnliutw/list/da301cc31b15

培養學習文化的挑戰

1. 缺乏安全感，擔心透露脆弱
2. 資訊孤島，各自為政，重工嚴重
3. 單點故障 SPOF，某人為瓶頸
4. 只有專家和新手，沒有文件或 Mentor 的習慣
5. 鸚鵡般無意識複製貼上程式碼
6. 技術債嚴重或高風險的部分導致人們不敢做出改變

理想的團隊互動

1. 基本問題或錯誤能被導正 vs 基本問題或錯誤被挑惕與責備
2. 為了幫助別人學習而闡釋 vs 為了炫耀知識而闡釋
3. 友善、耐心的回應態度 vs 居高臨下、刻薄的回應態度
4. 互動為了找出解決方案 vs 互動為了輸贏

良好的組織知識共享文化

1. 需要作出權衡: 文件帶來的規模性知識共享但具有維護成本 ; 或是 Mentor 帶來的個人化學習但難以規模化
2. 完美的文件，仍需要成員去溝通與協調
3. 透過包括 news letter、社群等方式，時時公司內部更新資訊
4. 尊重，且融入績效與 promotion 考核中作為獎勵的一環，並公開讚揚相關行為

如何建立知識共享的文化

1. 建立心理安全避免，承認有些事我們不懂，並有公司資源支持的 Mentor 制幫助新手進入狀況。避免有假裝驚訝 ( 你竟然不知道 xxx !?)、沒有事實根據、會中小會充斥與有偏見的想法
2. 增強好奇心，積極提問。知道得越多，代表不知道的就越多，並且在移除或改變任何存在的行為時，了解其為什麼存在
3. 寫下學到的東西，並跨越交際圈 — 向整個組織或社群請教。Group Chat 或 Mailing list 都能提供幫助，但建議對於有結構化的結論，可以寫成正式的文件紀錄。最後要小心訊息噪音導致組織疲乏於接收新知識的問題
4. 提升內容的可讀性，包括程式碼本身、程式碼結構、API 設計、Common Library 的使用、文件以及測試報告，有效解決資訊孤島的問題。推薦參考筆者之前撰寫的程式碼審查篇:

Google 的軟體工程之道 (5) — 程式碼審查 ( Code Review)

知識共享的方法

1. Office Hour: 固定的分享時間，提供專家面談機會，但不適用於緊急性的問題
2. 技術講座與課程: 成本較高，主題性強烈，且通常難度較深，易於規模化。適用於複雜、發展速度平緩、學員能自我解答且有足夠需求的主題
3. 文件: 不只是建立，還包括更新，且最好還能提供版控與審核機制，以及讀者想做出回饋要非常容易。最後，文件需要被推廣
4. 程式碼: 具有一定可讀性和清晰度的程式碼，本身也是一種文件，能夠跨時空的解釋緣由。Code Review 也能透過此一方法，讓 reviewer 學習

管理知識源

1. 官方的開發者指南，包括 Code Review, Coding Style, Best Practice 的相關指引
2. 良好的縮網址管理，易於分享，且能夠當作第一層的 proxy 代理，就算資訊源有變化也不需要改變入口
3. 對於學習投資資源豐富的組織，也可以考慮 codelabs 的方式

如果喜歡這個系列的話，歡迎將此連結加入你的最愛:

【 Google 的軟體工程之道 】全系列 https://medium.com/@johnliutw/list/da301cc31b15