徐宥分享Google的技術管理經驗：技術管理豬雞-1 開篇
我是徐宥， Google 軟件工程師. 這個中文博客是我的思考記錄，主要用來幫助我 debug/refactor 我的思想，但本人不對任何因為閱讀造成的后果負責。
一切文章皆為原創， 18 歲以上的網友轉載本博客文章請保留出處。
高效的秘密
我正式走上職業生涯是 2011 年秋天，完成了博士學業，躊躇滿志地加入了 Google。當時，我的理想是做 Google 里生產率最高的軟件工程師。為此，我列了一個高效工程師名單，看他們每天提交的代碼是些什么，以從中學習高效的工作方法。這個名單里有 Jeff Dean, Sanjay Ghemawat, Rob Pike，還有一些 Google 內 7 級以上的工程師。因為 Google 內部源代碼提交全部公開，我可以看到他們每天的工作內容。
很快，從讀這些代碼中我認識到了一點：人每天只有八個小時工作時間，誰都一樣。其中能高效工作的時間絕對不超過 4 個小時。這些工程師編寫的代碼行數絕對不算多，但從事的項目影響大。比如 Pike，大部分時間花在了審查其他成員的 Go 代碼上。而一個剛入行的 Golang 工程師，每天的任務就是寫作 Go 的標準庫，今天寫 http 明天寫 sort，寫的比 Pike 多很多。考核時，高級工程師因為帶領著高效團隊，每季度 OKRs 上都有諸多亮點；而剛入行的工程師，只能報告一些比較瑣碎的成就。
這個觀察近乎于常識，然而對于當時的我來說是一個頓悟：做出 MapReduce 框架的和寫瑣碎 MapReduce 程序的工程師之間的差距并不是他們的工具和編程效率，也往往不是教育背景或者經驗，而是他們各自的杠桿：所帶領的團隊。
問題是，沒有人會給你這個杠桿。于是，我開始觀察別人的杠桿是怎么搭建的。
運用常識
Google 的芝加哥 office 有兩個技術領導：Brian Fitzpatrick 和 Ben Collins-Sussman。他們合寫了一本書，叫做 Team Geek。近水樓臺，我就拿了一本過來看。或許對于 Google 之外的人來說，這本書講了許多有價值的東西，對于 Google 員工來說，基本上書里面說的就是公司每天實踐的，因此讀來覺得都是常識。這讓我突然領悟到，其實所謂的團隊工作，或許說白了就是正確地運用這些常識。
在實踐中運用常識遠比想像中的難。有一次在搏擊課上，師傅讓我和某個拿過法式拳擊世界冠軍的師兄對練。他手腿都很長，出拳又快，根本拿不到破 綻。為了不被首輪打倒，我不得不滿場跑著閃躲。躲著跑過師傅的時候，他就說了一句：“你只管出拳，不出拳永遠贏不了點數”。其實這是每個學搏擊的人都知道 的常識，卻因為一時的恐懼徹底忘了。做技術領導時也是一樣，許多我們知道的常識性的東西，一旦遇到復雜情況，我們往往依賴于舊習慣和情緒反應，忘了要解決 的問題，忘了運用常識做出正確的判斷。
逐漸習得的管理技能
常識是可以習得的，因為每個人都有包容常識的心性。問題是，所謂常識，是名常識，實非常識。根本沒有一本叫做“技術管理常識”的書，讀完就事理 無礙了。在領悟到技術管理其實是運用基本常識之前，我買了一大堆的關于技術管理的書，幻想能夠博聞強記速成。想明白“習得”這一點，讓我輕松了好多：這不 是入學考試，慢慢積累最省時省事。就像練習武術一樣，最強的斗士絕不是看書最多或者理論最強的，而是訓練時間最長的。
我曾經也醉心于一些管理方法。比如說，Kanban 管 理法是照搬了豐田在七十年代的高效率生產模式而提出的。06 年第一次讀這個管理方法的時候崇拜無比。到了 2009 年，豐田汽車在世界范圍內發生了多起質量問題召回的事情，使我重新審視這個問題：任何管理方法都是為了解決某些類問題而催生的。問題變了，不管以前多么神 奇的管理方法都會變得一地雞毛，因為管理方法不能脫離要解決的問題。
也就是這個時候，我重溫了溫伯格的《技術領導之路》。 這本書對于我來說最有價值的一點，是讓我體會到盡管管理方法成千上萬，歸根到底需要一些“元方法”去支配。比如，書中提到了一個大家都明白的元方法：寫日 記。技術領導者每天寫日記，記下每天的活動，反思一些事情。盡管寫日記并不能直接解決技術管理上的難題，卻打開了反思之門，也把許多事情前因后果連接起 來。比如，通過在日記里反思一些會議的效率，我開始有意識地反思高效率的會議和低效率的會議的差別，并主導一些會議的日程。顯然，真正的問題不是要不要設 定議事日程（元方法），而是學會怎樣設定一個特定會議的議事日程（解決問題的方法）。而后者，只能通過設定議事日程學到。
管理模型
我是一個理科生。理科生理解世界的第一工具是模型。世界過于復雜，人腦計算能力有限，只能付諸模型抽象簡化。技術管理作為 技術（工程學）和管理（自然科學）的橫切點，自然免不了各種各樣的模型。技術管理的模型本身多種多樣。人月神話模型，人件模型，豐田模型，溫伯格模 型，Agile 模型，Lean 模型等等不可枚舉。對于一個技術管理人員來說，幸運的是，所有的模型都是錯的，所以即使不知道這些模型，也未必遺漏了什么重要的。不幸的是，有些模型的確 比較有用，所以知道一些還是有好處的。
正因為此，我開始收集一些工作中積累的管理模型 (Pattern)，像 GoF 的 Design Pattern 一樣，列出要解決的問題，模型，和自己的實現。我收集了不少細碎的模型。有時候覺得過于細碎，不足為外人道也；有時候又覺得好像還是有些用處的。
就這樣，在不斷的寫作懶惰癥中過了三四年。直到最近，說來也巧，在檢查一個 bug 的時候發現有某用戶調用 Fitbit 的食物記錄 API 中試圖存下 “????”，這提醒了我那個著名的 The Chicken and the Pig 笑話，以及我的好友 Tinyfool 一直開玩笑說我寫的“編程豬和雞番外篇”系列，促發了我寫作“技術管理豬雞”的想法。這一篇，算是一個很不正式的開頭。
PS: 好友余晟翻譯的溫伯格的《技術領導之路》一書將要再版。這本書里包含了許多技術管理的“元方法”，以及作者提出的 MOI 管理模型（不幸的是這個模型比較有用）。推薦對技術管理（不僅限 IT 行業）有興趣的讀者購買。