Google 的軟體工程之道 (24) — 規模化領導力

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

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

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

總是做出決策

• 總是做出權衡，但仍要保持心態，可能權衡後會有非預期的結果
• 找出盲點，有些專家在多年經驗後，會有思考盲點，變成靠慣性解決問題，需要幫助他們思考問題的現狀，就算有奇怪的應對機制，也可能是新的解決方案
• 決策是需要迭代的，透過一定的頻率去重新評估決策和權衡的因素是否有變化
• 已 Google 搜尋結果的品質優化來說，團隊的優化經驗中，發現總是只在『延遲時間』優化的盲點，因此無法實在解決 root cause。總結來說，應也要考量『系統運算容量』和『使用者收取資料的豐富度』兩個特性，並提供指標來追蹤每次改動在三種特性的影響。

總是保持團隊能獨立運作

• 時時注意巴士問題，思考自己的團隊能夠承受同時多少人不在
• 在根據處理的區塊，劃分不同的團隊時，試著權衡死板與鬆散的團隊邊界，去權衡能夠有清晰專注的任務目標，或是自由面對變化而應對
• 思考自己是否是真正能解決特定問題的人，就算自己是解決起來效率最高的人。去規劃在森林中砍樹的路徑，並把具體砍樹的方法交給團隊
• 花 95% 的時間觀察和傾聽，蒐集資訊，並利用 5 % 的時間的時間在適當的位置做出關鍵的調整
• 讓團隊負責解決特定問題，而不是負責特定產品，這樣在有時代遷移的時候，團隊不會只墨守在特定解決方案

總是試著規模化

• 成功迴圈: 分析問題、面對問題掙扎、前進取得進展、獲得獎勵: 新的問題，並且試著以現有資源，用更有效率的方式處理
• 避免純粹的被動響應需求(緊急但不重要的問題) 而工作，而是花時間面對重要但不緊急的問題。可以透過委派人物、安排專注時間與使用有效率的任務追蹤系統
• 將任務切成 20% 不重要、60 % 有些緊急或是重要、20% 非常重要的工作，並盡量把時間專注在前 20% 的工作 — 只能由自己完成的事。雖然感覺很可怕，但即使是 60% 的事可能由其他人會自動處理掉，或是因為真正重要而回到自己身上
• 試著管理精力，而不是時間。包括給自己真正的放假，不參與工作、降低失聯的成本、在一天中稍微休息一下、如果在低落的情緒中，給自己一個心理健康日

很高興，我們一起來到了 Google 的軟體工程之道系列的最後一個章節。

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

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