高效的秘密

我正式走上职业生涯是 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 行业）有兴趣的读者购买。