我正式走上职业生涯是 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 管理法是照搬了丰田在上个世纪七十年代的高效率生产模式而提出的。2006 年第一次读这个管理方法的时候崇拜无比。到了 2009 年，丰田汽车在世界范围内发生了多起因质量问题召回的事件，使我重新审视这个问题：任何管理方法都是为了解决某些类的问题而催生的；问题变了，不管以前多么神奇的管理方法都会变得一地鸡毛，因为管理方法不能脱离要解决的问题。
也就是这个时候，我重温了温伯格的《成为技术领导者：掌握全面解决问题的途径》。这本书对于我来说最有价值的一点，是让我体会到尽管管理方法成千上万，归根到底需要一些“元方法”来支配。比如，书中提到了一个大家都明白的元方法：写日记。技术领导者每天写日记，记下每天的活动，反思一些事情。尽管写日记并不能直接解决技术管理上的难题，却打开了反思之门，也把许多事情的前因后果连接起来。比如，通过在日记里反思一些会议的效率，我开始有意识地反思高效率会议和低效率会议的差别，并主导一些会议的日程。显然，真正的问题不是要不要设定议事日程（元方法），而是学会怎样设定一个特定会议的议事日程（解决问题的方法）。而后者，只能通过设定议事日程学到。
管理模型
我是一个理科生。理科生理解世界的第一工具是模型。世界过于复杂，人脑计算能力有限，只能付诸模型抽象简化。技术管理作为技术（工程学）和管理（自然科学）的横切点，自然免不了各种各样的模型。技术管理的模型本身多种多样。人月神话模型、人件模型、丰田模型、温伯格模型、Agile 模型、Lean 模型等等不可枚举。对于一个技术管理人员来说，幸运的是，所有的模型都是错的，所以即使不知道这些模型，也未必遗漏了什么重要的东西。不幸的是，有些模型的确比较有用，所以知道一些还是有好处的。
正因为此，我开始收集一些工作中积累的管理模型 (Pattern)，像 GoF 的 Design Pattern 一样，列出要解决的问题，模型，和自己的实现。我收集了不少细碎的模型。有时候觉得过于细碎，不足为外人道也；有时候又觉得好像还是有些用处的。
就这样，在不断的写作懒惰症中过了三四年。直到最近，说来也巧，在检查一个 bug 的时候发现有某用户调用 Fitbit 的食物记录 API 中试图存下 “????”，这提醒了我那个著名的 The Chicken and the Pig 笑话，以及我的好友 Tinyfool 一直开玩笑说我写的“编程猪和鸡番外篇”系列，促发了我写作“技术管理猪鸡”的想法。这一篇，算是一个很不正式的开头。
PS： 好友余晟翻译的温伯格的《成为技术领导者：掌握全面解决问题的途径》已经上市。这本书里包含了许多技术管理的“元方法”，以及作者提出的 MOI 管理模型（不幸的是这个模型比较有用）。推荐对技术管理（不仅限 IT 行业）有兴趣的读者购买。
评论