高效的秘密

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