进化：从孤胆极客到高效团队(txt+pdf+epub+mobi电子书下载)

作者：布莱恩·菲茨帕特里克（Brian Fitzpatrick）

出版社：人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

进化：从孤胆极客到高效团队试读：

O'Reilly Media, Inc. 介绍

O'Reilly Media 通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自 1978 年开始，O'Reilly 一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来，而我们关注真正重要的技术趋势——通过放大那些“细微的信号”来刺激社会对新科技的应用。作为技术社区中活跃的参与者，O'Reilly 的发展充满了对创新的倡导、创造和发扬光大。

O'Reilly 为软件开发人员带来革命性的“动物书”；创建第一个商业网站（GNN）；组织了影响深远的开放源代码峰会，以至于开源软件运动以此命名；创立了 Make 杂志，从而成为 DIY 革命的主要先锋；公司一如既往地通过多种形式缔结信息与人的纽带。O'Reilly 的会议和峰会集聚了众多超级极客和高瞻远瞩的商业领袖，共同描绘出开创新产业的革命性思想。作为技术人士获取信息的选择，O'Reilly 现在还将先锋专家的知识传递给普通的计算机用户。无论是通过书籍出版、在线服务或者面授课程，每一项 O'Reilly 的产品都反映了公司不可动摇的理念——信息是激发创新的力量。业界评论“O'Reilly Radar 博客有口皆碑。”——Wired“O'Reilly 凭借一系列（真希望当初我也想到了）非凡想法建立了数百万美元的业务。”——Business 2.0“O'Reilly Conference 是聚集关键思想领袖的绝对典范。”——CRN“一本 O'Reilly 的书就代表一个有用、有前途、需要学习的主题。”——Irish Times“Tim 是位特立独行的商人，他不光放眼于最长远、最广阔的视野，并且切实地按照 Yogi Berra 的建议去做了：‘如果你在路上遇到岔路口，走小路（岔路）。’回顾过去，Tim 似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”——Linux Journal

本书赞誉

　“献给我的祖父，Alvin‘Nick’Fitzpatrick，他教我如何讲故事，如何聆听。”——Fitz

本书旨在提高人与人合作的能力，帮助人们将更多时间投入创新，而非浪费时间争斗。

第二版前言

本书的第一版《极客与团队》取得了巨大的成功。第一版面世后的四年间，人们逐渐认识到团队合作在工作中的重要性。在一些地方，合作甚至成为了大学课程以及领导力培训课程的一部分。（我们的书经常被用作教材！）

但我们也意识到本书第一版或许过于关注软件工程领域，因此对第二版进行了扩展，以同时面向非技术读者，并将书名改为了《进化：从孤胆极客到高效团队》。虽然仍然使用工程领域的范例，但减少了与软件开发工具相关的具体细节。基于读者的持续反馈，第二版扩展了许多讨论并使其更加一般化。我们也针对较新话题增加了一些新的章节，例如开放式办公场所、冒充者综合征，以及更新的沟通和领导技巧。

希望这些扩展内容能吸引和影响各个行业的读者。

　Ben和Fitz2015年9月

简介

生活充满了难以预料的转折。我们两个人从未想过，有一天会写一本关于团队与合作的书。

和当代的许多“创客”（maker）一样，大学毕业后，我们发现自己的兴趣爱好——捣鼓计算机——是极好的谋生方式。和同时代的许多黑客一样，20世纪90年代中期，我们用散件组装个人电脑，用成堆的软盘安装预发布版本的Linux，并且学习如何管理Unix机器。在互联网泡沫初期，我们成为了程序员，泡沫破裂后则为幸存的硅谷公司（例如苹果公司）工作。后来，我们受雇于一家初创公司，全职设计和编写一个开源的版本控制系统，即Subversion。

然而在2000年到2005年间，意想不到的事情发生了。在编写Subversion期间，我们的工作职责逐渐发生了变化。我们不再整天一门心思地编写代码，而是领导一个开源项目。这意味着我们要整天呆在聊天室里与十几个编程志愿者进行沟通，了解他们的工作情况，还要基本靠一个邮件列表来协调新功能的开发。在此过程中，我们发现，项目成功的关键不仅仅是编写优秀的代码，人们为实现最终目标而采取的合作方式也同样重要。

2005年，我们组建了谷歌的芝加哥工程办公室，继续我们的程序员事业。此时，我们已经和开源世界建立了密切的联系，不仅参与了Subversion的开发，还效力于Apache软件基金会。我们将Subversion移植到谷歌的BigTable架构上，并在Google Code旗下启动了一个与SourceForge类似的开源托管服务项目。我们参加了各种开发者大会，如OSCON、ApacheCon、PyCon以及后来的谷歌I/O，并开始在大会上发表演讲。由于同时拥有在大公司和开源项目的工作经历，我们在不经意间了解到软件工程团队的许多趣闻轶事并获得了大量宝贵经验。关于糟糕开发过程的一系列幽默故事（“Subversion Worst Practices”）最终演变为关于如何保护团队不受有害之人侵扰的演讲（“How Open Source Projects Survive Poisonous People”）。听众越聚越多，我们的演讲简直变成了软件开发者的“集体治疗”（group therapy）。

在一次又一次地发表关于创新合作的社会挑战的演讲后，O'Reilly Media的编辑建议我们把这些演讲内容集结成书。接下来的事情就不用多说了。本书为谁而写

本书最初是写给软件开发者的，写给那些想发布优秀软件并获得职业发展的人。但在修订第二版的时候，我们发现书中的内容并不仅仅适用于软件开发者，而是可以适用更广泛的群体。只要与他人合作从事创新工作，书中的经验就对你有所帮助。你可以是社区俱乐部的一员，也可以是某个教会团体、联谊会、委员会或架构师小组的一员。我们对本书读者有两点重要假设。● 与他人一起从事创意工作，就职于公司或其他组织。● 喜欢制造新东西，认为这件事很有趣并且值得去做。如果工

作只是为了挣钱，那么可能不会对自我实现或者职业抱负有什么

兴趣。

我们自身的经验来自软件工程实践，因此可以想见，书中大部分的示例都是和软件工程相关的。但几乎我们描述的所有流程和策略（或者与其类似的流程和策略）都可以直接应用于任何从事创意工作的团队。

在讨论工程师如何以最佳方式“与他人合作”的过程中，我们会涉及一些（看上去）似乎超出程序员工作范围的内容。我们会讨论如何有效地领导一个团队、处理组织关系，并与软件使用者建立良好关系。表面上，这些章节的目标读者似乎是“经理”或“产品经理”。但我们可以保证，在职业生涯的某些时候，你会发现自己也会无意中担任了这些职责。不要怀疑，接着往下读！本书的所有内容最终都会与创意工作者相关。警告：这不是一本技术手册

在开始之前，需要设定你的期望值。上进的程序员喜欢阅读用数学表达方式精确解释相关领域问题的书，并且书中每个问题通常都有规定好的程序化解决方案。

本书并非如此。

本书研究的是创意产品开发中与人相关的方面，而人是复杂的。我们在演讲中常说：“人，基本就是一大堆间歇发作的bug。”我们讨论的问题和解决方法都很杂乱，很难进行具有完美逻辑的表述。本书读起来像一系列短文，因为它本质如此。书中每一章都会讨论许多相关问题（通常都是小故事），然后再讨论与整个话题相关的一组解决方法。要想完全理解书中内容，可能需要耐着性子看完好几页，动用右脑融会贯通，或者再多想想。

我们还应该做一些免责声明。我们在演讲时喜欢开玩笑说：“这些仅仅是基于个人经验的个人观点。如果你不同意我们的观点，欢迎你说出自己的想法。”同样，我们也欢迎大家讨论本书中的观点。如果你有任何反馈、更正、新观点或反对意见，请访问http://www.debuggingteams.com。本书的全部内容都来自我们的亲身实践和从错误中吸取的教训。

书中示例使用的人物姓名都经过修改，以保护无辜者（或过错方）。学校里学不到的内容

我们认识的大部分软件工程师都曾在学校花4~10年学习计算机科学和软件工程。但是，几乎没有课程实际教授如何在团队或公司中沟通与合作1。当然，在学习过程中，大部分学生都要参与小组项目。但是，教授某人如何与他人成功合作与强制他参与合作，这两者之间有很大的区别。大部分学生的项目经历并不愉快。

1Tom DeMarco的《人件》（PeopleWare）是一本很好的书，但主要讲述经理如何带出更成功的团队，没有谈到基层员工如何与他人更高效地工作。为什么要读本书

要成为一名成功的程序员，仅靠学习最新的编程语言或写出运行速度最快的代码是不够的。职业编程者几乎都在团队中工作。虽然很多人不愿意承认，但程序员所在的团队会直接影响个人的产能和幸福感。

本书的基本理念很简单：软件编写是一项集体活动，我们认为人的因素和技术因素一样，对项目结果有很大的影响。大部分人可能花费了数十年的时间学习编程技术，却从未真正关注过人的因素。学会合作对成功同样十分重要。学习工程的“软技能”能帮助你达到事半功倍的效果。

致谢

虽然本书封面上只有两位作者署名，但本书是我们在生活和工作中与成百上千位朋友对话的结果。我们想花一点时间感谢几位对本书作出重要贡献的人（当然，书中如有错误，都是我们的责任）。

我们要感谢O'Reilly Media的工作人员。感谢Mike Loukides鼓励我们拓展目标读者，感谢无所畏惧的编辑Brian Anderson和Mary Treseler——没有Mary的鼓励、耐心和不时的鞭策，这本书便不会存在。

感谢http://sunnibrown.com的Sunni Brown和Amber Lewis用如此赏心悦目的插画使本书更加生动——和你们一起工作实属乐事。

感谢技术审阅者提出无数的建议、想法和修改方案，从而使这本书成型。他们是Dustin Boswell、Trevor Foucher、Michael Hunger、Jonathan LeBlanc、Piaw Na和Jack Welch。感谢在本书编写过程中审阅并发现一些严重错误的朋友和同事：Dave Baum、Matt Cutts、Will Robinson和Bill Duane。感谢耐心倾听并提出建议的好朋友们：Karl Fogel、Jim Blandy、Matt Braithwaite、Danny Berlin、Chris DiBona。还要感谢Linda Stone、DeWitt Clinton、Bruce Johnson、Roland McGrath、Amit Patel的想法和建议。

感谢谷歌，特别是谷歌芝加哥工程团队，感谢他们的支持、想法和建议，和这样一群人一起工作实在是棒极了。

特别要感谢几位资深导师和教师，我们只是试图将他们集体智慧的一小部分记录在本书中。他们是Bill Coughran、Steve Vinter、Alan Eustace、Stu Feldman和Eric Schmidt。

特别感谢Brian Robinson和Yvonne Ellison-Sandler的传授、指引和教导。

感谢Apache软件基金会接纳我们，也感谢你们对社区和合作的重视。

感谢所有的好朋友，你们令我们的生活无比富足。不要这样看着我们——你知道我们说的是谁。

在美丽的芝加哥美妙、友好、舒适的Filter Cafe中，我们完成了本书大部分的构思、纲要和成稿。Fitz

衷心感谢我的妻子Marie，感谢她的鼓励、理解和耐心——她的洞察力和同情心永远激励着我。感谢我的母亲，感谢她的支持和热情。特别感谢我的岳母Rita Gumler，感谢她“人同植物一样”的类比。

写给Ben：相识16年，同事三份工，合著三本书，我怀念与你共事的日子。感谢你与我共度这段狂野、古怪而奇妙的旅程，你是我的良师益友。

最后，感谢我21年软件工程生涯中共事过的每一个人。这是一场不可思议的旅程，每一天我都从你们身上学到一些知识。Ben

言语无法表达我对妻子Frances的感激之情——不仅在本书的编写过程中，而且在过去几年的十几个创新项目中，她都给予了我充分的空间。没有她默默而坚定的支持，这些工作都不可能完成。

写给Fitz：现在我们一个人说了上句另一个人就能接下句，简直就像一对老夫妻。我从来不知道和人一起演讲这么有趣，更不用说编软件和写书了。我们获得了多么令人惊叹的机遇啊！感谢你教会我这么多东西。

最后，感谢硅谷所有神奇的人和疯狂的公司：如果没有你们引领我进入这个奇异的世界，这些疯狂经历都不会发生。关于作者

Brian Fitzpatrick是Tock的创始人兼CTO。2005年，Brian和Ben一起组建了谷歌的芝加哥工程办公室，并领导了谷歌的数项全球工程项目，包括Data Liberation Front和Transparency Engineering。Brian还领导过Google Code和Google Affiliate Network团队，也曾担任谷歌开发数据项目的内部顾问。在加入谷歌之前，Brian在苹果、CollabNet以及芝加哥本地的一家开发公司担任过工程师一职。

Brian撰写过许多文章，发表过几十场演讲，合著了《极客与团队：软件工程师的团队生存秘笈》（Team Geek: A Software Developer's Guide to Working Well with Others，http://shop.oreilly.com/product/0636920018025.do）、Version Control with Subversion（已出版第二版，http://shop.oreilly.com/product/9780596004484.do），以及《Unix技术手册》和《Linux技术手册》中的章节。

Brian毕业于芝加哥洛约拉大学，获古典文学学士学位，专业为拉丁文，辅修希腊语，研究领域为工艺美术和陶瓷。他现居芝加哥。

Ben Collins-Sussman曾是Subversion版本控制系统的开发者之一。他参与组建了谷歌的芝加哥工程办公室，启动了Google Code项目，领导过两个展示广告团队，目前管理着运营谷歌搜索架构的团队。他现在担任谷歌芝加哥的工程运营中心主管一职，但依然爱好颇多，包括写交互式小说、演奏蓝草班卓琴和爵士钢琴、谱曲、操作业余无线电台、探索摄影技术。Ben是土生土长的芝加哥人，毕业于芝加哥大学，获理学学士学位，专业为数学，辅修语言学。目前，他依然和妻子、孩子以及猫咪一起住在芝加哥。 第1章天才程序员神话

既然本书要讨论创新开发的社会危机，当然要关注你能控制的一个变数：你自己。

人无完人。但在了解同事们的问题之前，你要先了解自身的问题。在本书中，我们希望你能思考自己的反应、行为和态度，并由此真正了解如何成为一个更高效、更成功的软件工程师，从而用更少的精力处理与人有关的问题，而有更多的时间编写精妙的代码。

这一章的核心内容是：软件开发是一项集体活动。要在工程团队（或任何其他创新合作）中成功，你需要根据三个核心原则重新组织自己的行为：谦虚、尊重和信任。

首先，让我们观察一下程序员的行为模式。请帮我隐藏代码

过去十年，我们在编程大会上作过不少演讲。2006年，谷歌的开源项目托管服务启动后，许多人向我们提出了与此服务相关的问题和请求。到2008年年中，我们注意到这样几类请求。可以让Google Code的Subversion隐藏某些分支吗？可以让新开源项目最初处于隐藏状态，等项目准备好了

再开放访问吗？我想重写全部代码，你们能把历史记录都清掉吗？

发现这些请求的共同主题了吗？

那就是缺乏安全感。人们担心别人看到并评论自己未完成的工作。在某种意义上，这只是人类本性的一部分——没有人喜欢受到批评，尤其是对自己未完成工作的批评。这种态度揭示了软件开发中的一种趋势。实际上，缺乏安全感只是另一个更大问题的表征。天才神话

整个20世纪90年代，我们都住在芝加哥，见证了芝加哥公牛队的辉煌冠军之路。全国媒体铺天盖地地报道关于这支神奇球队的新闻，热度持续了好些年。但电视和报纸真正关注的是什么呢？不是整支球队，而是超级巨星迈克尔·乔丹。世界各地的每个篮球运动员都想成为乔丹。我们看到他在其他球员身边穿梭，看到他出现在电视广告中，看到他出演和卡通人物打篮球的烂电影。他是明星，每个在球场上练习投篮的孩子都暗自希望自己长大后能像他一样。

程序员也有同样的心理——寻找并崇拜偶像。林纳斯·托瓦兹、理查德·斯托曼、比尔·盖茨，这些人都是用伟大事迹改变世界的英雄。林纳斯自己编写了Linux系统，不是吗？

实际上，林纳斯只编写了一个类Unix的概念内核原型，并发布到了一个邮件列表。这不是一项小工程，绝对是很了不起的成就，但这些工作只是冰山一角。Linux系统比这个原型大百倍，是由几百位聪明的程序员开发的。领导这些程序员，协调他们的工作才是林纳斯的真正成就。Linux是集体工作的闪亮成果。（Unix系统本身也不是完全由肯·汤普森和丹尼斯·里奇两个人开发的，而是由贝尔实验室的一群聪明人共同编写的。）

同样，是斯托曼一个人编写了自由软件基金会的全部软件吗？斯托曼开发了Emacs的第一个版本，但其他几百位程序员开发了bash、GCC工具链，以及Linux上运行的所有其他软件；乔布斯领导一支团队设计了Macintosh；比尔·盖茨编写了早期家用电脑的BASIC解释程序，但他更大的成就是基于MS-DOS创建了一家成功的企业。他们都是集体成就的领导者和象征。

那迈克尔·乔丹呢？

迈克尔·乔丹也是这样。我们将他视为偶像，但事实上，乔丹并非仅靠一己之力赢得每场球赛。乔丹真正的天才之处在于他与球队合作的方式。公牛队的教练菲尔·杰克逊非常聪明，他的训练技术是传奇式的：杰克逊认识到仅靠单个球员永远无法赢得冠军，因此以乔丹为核心组建了一支“梦之队”。这支球队非常优秀，至少和乔丹本人一样出色。

那为什么我们要不断地将这些人偶像化呢？为什么人们要购买名人推荐的产品呢？为什么我们要买第一夫人同款裙子或乔丹鞋呢？

名人效应是主要原因之一。人有一种本能：发现领导者和楷模，将他们偶像化，然后试图模仿他们。我们都需要崇拜英雄以激励自己，编程世界也有自己的英雄。“技术名人”（techie-celebrity）现象几乎演变成了神话。我们都希望编写出像Linux这样改变世界的软件，或者设计出下一个绝妙的编程语言。

在内心深处，我们都希望成为天才。极客的最终幻想就是获得令人称赞的新创意。在山洞里闭关几周甚至数月，努力完美实现自己的创意，然后横空出世，令所有人惊叹不已。同行叹服于你的聪明才智，大众排队使用你的软件，名利随之而来。

等等，该醒醒了。你可能并不是天才。

这话没有不敬之意。我们相信你是一个非常聪明的小伙子（或姑娘）。但是你有没有意识到真正的天才是多么稀有？的确，你会写代码，这是一门挺难的技术，掌握这门技术说明你比很多人都聪明。但即便你真是天才，也未必能够成功。天才也会犯错，拥有绝妙的想法和最好的编程技术并不能保证你的软件一定能成功。职业的成功或失败，取决于你能否与他人很好地合作。

实际上，天才神话只是我们缺乏安全感的另一个表现。大部分程序员不愿意与他人分享自己刚开始的工作，因为分享意味着别人会看到他们的错误，会发现这些代码的作者并不是天才。一位程序员在Ben的博客上写道：如果别人看到我未完成的工作，我会非常没有安全感，

觉得他们会肆意批评我，并认为我是个白痴。

这种心态在程序员中非常普遍。人们对此的本能反应是：躲在没人的地方，工作，工作，再工作。这样就没人会看见你犯错，你还有机会在完成后展示自己的杰作。躲起来，直到一切都达到完美。

另一个常见的现象是：因为害怕其他程序员偷走自己的想法，所以人们把所有的点子都藏着。把想法隐藏起来，就不会失去控制了。

你可能在想：那又怎样？难道人们不应该按自己喜欢的方式工作吗？

实际上，这个问题的答案是否定的。在软件开发中，隐藏想法、独自工作是错误的，而且这种错误很严重。以下将列出原因。隐藏是有害的

如果总是独自工作，失败的风险就会增加，你也会错失成长的机会。

首先，你怎么知道自己努力的方向是正确的呢？

假设你是一位自行车设计爱好者，某天有了一个好点子，想出了一种全新的变速器设计。你订购了零件，躲在车库花了好几周打造原型。当邻居（也是一位自行车爱好者）问你在干什么时，你决定不告诉他，想等到项目完成时再宣布。又过了几个月，原型设计还没完成，因为你遇到了困难，但由于你不与别人讨论这个项目，你也无法向懂机械的朋友寻求意见。

然后有一天，邻居从他的车库里推出一辆自行车，车上装有一种全新的变速器。原来，你的邻居也在研究类似的发明，但他得到了在自行车店工作的朋友的帮助。这时你终于忍不住了，向他展示了你的设计。然后邻居指出了你的设计中存在的一些简单缺陷。如果早点和他沟通，这些问题在工作开始的第一周就可以得到修正。

从这个故事中我们可以得到几个教训。如果将想法秘而不宣，坚持一切尽善尽美才公布，那么你就是在进行一场代价高昂的赌博。在项目早期很容易出现基本的设计错误，你可能会重复进行已有的设计1，同时还放弃了合作的好处。请注意你的邻居是如何与他人合作而进展神速的。这就是为什么人们在跳入深水池前要先试试水：你需要确定自己努力的方向是正确的，采取了正确的方法，并且没有重复他人的工作。项目早期出现错误的可能性非常大。早期获得的反馈意见越多，出现错误的可能性就越小2。请记住一句经验之谈：早失败，快失败，常失败。失败的重要性将在后面章节讨论。

1英语中将此称为“重新发明轮子”。在自行车设计中，这一比喻就写实了。

2注意：在项目过程中，过早获得太多反馈意见有时是危险的。这一点将在后面章节详述。

尽早与他人分享想法不仅可以避免个人失误，验证想法的正确性，而且可以增加所谓的项目的巴士因子（bus factor）。

巴士因子：项目中多少人被巴士撞死会导致项目完全无法进行下去。

在你的项目中，知识和方法的分散程度如何？如果只有你一个人理解项目的原型代码是如何工作的，那你的工作可能会牢靠，但这也意味着如果你被车撞了，项目就结束了。但如果你和一位朋友一起工作，那项目的巴士因子就翻了一倍。如果一支小型团队一起设计和构造原型，情况就更理想了，项目不会因为失去某个队员而停顿。记住：项目成员可能不会真的出车祸，但仍会发生其他无法预知的事件。项目成员可能会因为结婚、搬家、辞职或需要照顾患病的亲人而离开。你需要管理巴士因子，以保证项目未来的成功。

除了巴士因子，还需要考虑项目的整体进度。人们很容易忘记，独自工作经常困难重重，进度迟缓，虽然大家都不愿意承认。独自工作时你能学到多少知识？进展速度又如何呢？网络上充满了各种观点和信息，却无法替代真实的人际体验。与他人合作可以直接提升集体智慧。当你卡在某个荒谬的错误时，要花多长时间才能迈过去？如果有几位同伴发现你的问题，并立即告诉你错误在哪里以及该如何解决，那情况该有多么不同啊！这就是为什么软件工程公司里项目团队总是坐在一起（或者进行结对编程），因为人们经常需要旁观者的意见。

打个比方，请思考一下编译器的使用方式。在编写大型软件时，你会花好几天编写10 000行代码，写完改好，然后才第一次按下“编译”按钮吗？当然不会。你能想象这会带来多大的灾难吗？程序员在使用小型的反馈循环时工作效果最好。写一个新函数，编译；增加一个测试，编译；重构一些代码，编译。这样在写出代码后可以尽快修正拼写错误和缺陷。我们希望工作时编译器能随时陪伴在身边，帮助我们。有些编译环境甚至可以在程序员输入代码时即时编译。这样才能保持优秀的代码质量，确保软件一点一点正确地演化。

不仅在编写代码时，整个项目也需要这种快速反馈循环。大型项目演化速度很快，必须随时调整以适应环境变化。项目可能会遇到无法预知的设计障碍或政治灾难，或者事情未按计划进行。需求也会发生意想不到的变化。那么如何使用这种反馈循环，在计划或设计需要变更时立即了解情况呢？回答是：团队。人们经常引用埃里克·雷蒙德的一句话：“众人的审视使缺陷无所遁形。”一种更好的说法也许是：“众人的审视使项目保持其相关性，并按计划进行。”在山洞里闭关修炼的人可能某天醒来后发现，软件原型完成了，但世界变化如此之大，自己的产品已经毫无用处。工程师和办公室二十年前，传统观念认为工程师需要一间自己的封闭办

公室才能保证工作效率。据说只有这样工程师才能拥有大段

不受干扰的时间，可以集中注意力编写更多的代码。在我们看来，对于大部分工程师3而言， 私人办公室并

不是必需的，甚至是危险的。如今的软件由团队而非个人编

写，与团队其他成员保持高带宽的即时联系甚至比保持互联

网畅通更有价值。拥有不受干扰的时间并没有错，但用这些

时间来做错误的事情就是浪费时间。不幸的是，当今的科技公司似乎走向了另一个极端。走

进这些公司的办公室，你经常会看到大办公室里坐了一大群

工程师（50或100人），中间连隔墙都没有。这种“开放格

局”现在引起了很大的争论。在开放格局办公室里，最简短

的谈话都会影响别人。人们为了避免干扰临近的十几个人，

最后干脆连话也不说了。这简直跟私人办公室一样糟糕！我们认为折中做法最好。公司可以把6~12人的团队安

排在小房间（或大办公室）里，这样人们可以比较容易（而

且不感到尴尬地）发起谈话。当然，在任何情况下，单个工程师还是需要屏蔽噪声和

干扰的方法。因此大部分团队都想出方法来表达“我们很忙，

请勿打扰”。我们以前的一个团队有一个有声打扰协议：如

果你想说话，就要说“中断Mary”，Mary就是你想打扰的人

的名字。如果Mary可以停下手头的工作，她就把椅子转过

来听你说话。如果Mary当时特别忙，就简单说一句“知道

了”，你就先做别的事情，等她结束手头的工作。其他团队给工程师发放降噪耳机，以消除背景噪声的干

扰。实际上，在很多公司，一个人戴上耳机的意思就是“闲

人勿扰”。另外一些团队把某种标记或毛绒玩具放在显示器

上，以此表示“请勿打扰”。请不要误解，我们仍然认为工程师需要不受干扰的时间

来专心写代码，但他们同样需要与所在团队建立高带宽低摩

擦的沟通渠道。你需要找到适当的平衡点。

3但我们承认，比起大多数人，性格特别内向的人可能需要更多安静、平和的独处时间。私人办公室或比较安静的环境可能更适合他们。

总结一下：独自工作一定比多人合作更具有风险。你可能会担心别人窃取你的想法或者认为你笨，但你更应该担心的是大量时间浪费在错误的事情上。

不幸的是，这种“不愿分享想法”的问题并非软件工程领域所独有，而是普遍存在于各个领域。例如，学术界本应进行自由开放的信息交换，但由于“不发表则消亡”的严酷现实，以及对研究基金的激烈竞争，导致结果适得其反。伟大的思想者不愿分享想法，而是紧紧抓住这些想法不放，独自进行研究，沿路隐藏所犯的错误，最终发表一篇论文，把整个过程描述得轻松而明显。这种做法的结果往往是灾难性的：他们无意中重复了他人的工作，或者在研究早期犯下了错误而未察觉，又或者研究结果因过时而毫无用途。由此浪费的时间和精力是悲剧性的。

不要再犯这种错误而成为又一个统计数据。团队为王

让我们回过头，把前面的内容总结一下。

我们一直强调的是：编程领域极少出现独行侠，即便真有，他们也不是在真空中完成超人创举的。他们的惊世之作几乎都是灵感的火花以及优秀团队协作创造的结果。

我们真正的目标是打造一支超级明星团队，而这一目标极难实现。最好的团队能让明星队员发挥极大的作用，而团队整体的能力又总是大于各个队员的能力之和。

用更简单的话说就是：软件开发是一项团队活动。

这个观点与我们内心抱有的天才程序员幻想有直接的冲突，一开始可能很难接受。你可以试着把这句话当口号念上几次。

独自在黑客巢穴里当个超级黑客是不够的，躲起来秘密发明并不能改变世界，也不能赢得百万计算机用户的青睐，你需要与他人一起工作，分享愿景，分工合作，互相学习，从而打造一支优秀的团队。

请考虑一下：你能说出多少个真正由一个人编写而又广泛使用的成功软件？（有人可能会说LaTeX，但LaTeX很难称为“广泛使用的”软件，除非你认为写科学论文的人在所有计算机用户中的统计占比是显著的！）

本书会不断重复团队活动这个概念。高效团队千金难求，是成功的真正关键。你应该尽一切努力实现这一目标，这就是本书所要讨论的内容。三大基石

我们已经强调过了团队工作的重要性。如果团队合作是创造优秀软件的最佳途径，那么如何打造或找到一支优秀的团队呢？

答案并不简单。要达到团队合作的最高境界，首先需要学习和掌握被称为“三大基石”的社交技能。这三大原则不仅可以调和人际关系，还是所有良好交互与合作的基础。

谦虚（Humility）

你并非宇宙中心，并非无所不知，也会犯错，但愿意自我改进。

尊重（Respect）

你要真诚关心同事，以礼相待，欣赏其能力，认可其成就。

信任（Trust）

你要相信别人可以胜任工作并作出正确选择，愿意在合适的时候将权力交给他们。4

4如果你曾经放权给不称职的人并对此经历无法释怀，就极难做到这一点。

我们将这些原则合称为HRT。HRT原则是为了减轻痛苦，而非伤害他人，因此HRT念作heart而非hurt。实际上，我们的主要论点直接建立在这三大基石之上：几乎每种社交冲突的源头最终都可归结为谦虚、尊重或

信任的缺失。

这一论点初听起来可能缺乏说服力，但你不妨一试。想想生活中正在发生的一些令人讨厌或不快的社交问题，在最基础的层面上，每个人是否足够谦虚？人们是否真的彼此尊重？他们相互信任吗？

我们认为这些原则非常重要，甚至本书都是以这些原则为核心构建的。

本书以你为起点，引导你掌握HRT，使你真切意识到如何以HRT为人际交互的核心（这是第1章的内容），随后再由内向外扩展讨论HRT的影响。

第2章讨论基于这三大基石打造团队所要面临的挑战。创造团队文化是通向成功的下一个关键，这里的成功是指之前讨论的“梦之队”。

之后将讨论与团队有日常交互、但可能不属于核心团队文化的人。这些人可能是其他团队的成员，也可能是项目中帮忙的志愿者。他们中很多人不仅不遵循HRT原则，甚至可能对团队有害！应该将保护团队不受有害之人侵扰视为头等大事。但最终目标应该是去掉他们的毒素，将他们吸纳进团队文化，这是扩展团队的极好方法。

大部分团队都位于一个更大的公司架构之中，公司环境常常会和有害之人一样阻碍项目发展。能否应对和处理这些组织机构障碍，可能会决定一个产品最终是取消还是发布。

最后将讨论一下软件用户。有时我们会忘记用户的存在，但他们是项目的命脉。没有用户，软件就失去了目标。在团队中倡导的HRT原则，也应当用于与用户的交互，其收效是显著的。

让我们暂停一下。

当你拿起这本书时，大概没想到自己将加入某种每周互助团体吧。我们对此表示同情。社交问题很难处理，因为人是杂乱、无法预料的，常常很难打交道。与其花费精力分析社交问题，作出行为决策，选择视而不见要轻松得多。比起善变难料的人，编译器好相处多了，难道不是吗？为什么我们要纠结于这些社交问题呢？

下面这段话摘自理查德·哈明一篇著名的演讲。5

5演讲名为“You and Your Research”，全文请参见http://www.cs.virginia.edu/~robins/YouAndYourResearch.pdf。通过“受累”跟秘书讲讲笑话并对他们友好些，我从秘

书那里获得了极大的帮助。例如，一次因为某种莫名的原因

默里山所有的复印服务都排满了队。别问我怎么回事，那天

就是那样。我有一些资料需要复印，然后我的秘书给霍尔姆

德尔的人打了电话后，跳上了公司的车，跑了一个钟头的路

把东西复印了回来。那可真是我长期鼓励她，给她讲笑话，

并对她友善的回报。这就是投之桃李，报之琼瑶。认识到使

用系统的重要性并研究如何让这个系统为你所用，你就学会

了如何驾驭这个系统。

中心思想是：不要低估了社交游戏的能量。社交游戏不是欺骗或操控他人，而是培养完成工作所需的人际关系。即便项目结束，人际关系依然存在。HRT实战

以上这些关于谦虚、尊重、信任的说教听起来像布道词般高大上。让我们说点具体的，考虑一下如何将这些理念应用到实际的生活场景中吧。人们需要的是实际的建议，因此我们将给出具体的行为清单和实例，以供参考。很多建议似乎显而易见，但若仔细一想，就会发现你（和你的同伴）很多时候并未遵循这些建议。放下自我

好吧，放下自我其实就是告诉那些不够谦虚的人别摆架子。没人想和时时表现得自己好似宇宙中心的人一起工作。就算你知道自己是讨论组中最聪明的人，也不要表现得咄咄逼人。例如，对每个话题，你是否总是第一个发表意见或最后要总结陈词？对提案或讨论中的每个细节，你是否都有评论的欲望？或者，你认识这样的人吗？

请注意，态度谦虚并不是说应该完全任人摆布。自信和谦虚并不矛盾，只是别表现得无所不知。更好的心态是追求“集体”自我。不要担心个人表现是否出色，你更应该尝试培养一种团队成就和集体荣誉感。例如，Apache软件基金有一项悠久的历史：以软件项目为核心创建社区。这些社区有异常强大的社区认同感，不接受那些意在推销自我的人加入。

自我的表现形式很多，很多时候自我会影响生产力和项目进度。理查德·哈明演讲中的另一个精彩故事完美诠释了这一点。约翰·图基总是穿着随意。当他走进一间重要的办公室

时，其他人总要花很长时间才能意识到这是一位大牛，然后

才认真听他说话。有很长一段时间，约翰都不得不克服这个

麻烦。这完全是浪费精力啊！我不是说你应该服从。我想说

的是：“表现得服从有很多好处。”如果你选择以各种方式

坚持自我，“我要按自己的方法做”，那么你会在整个职业

生涯中持续不断地付出微小代价。在你的一生中，这些微小

代价会累积为大量不必要的麻烦。认识到使用系统的重要性

并研究如何让这个系统为你所用，你就学会了如何驾驭这个

系统。或者你可以选择不断与之斗争，用一生进行一场微不

足道的无名之战。批评与自我批评

乔刚得到一份程序员的新工作。入职一周后他就开始认真钻研代码库。乔关心业务，因此开始客气地请教其他团队成员代码问题。他通过邮件发送简单的代码审查，礼貌地质询设计假定，或者指出可以改进的逻辑。几周后，老板把乔叫到了办公室里。“出了什么问题？”乔问，“我做错事了吗？”老板面露难色：“有很多关于你的投诉。显然，你对同事太严厉了，总是批评他们。大家都很郁闷。你应该注意一下。”乔完全不明所以。在基于HRT原则的团队文化中，乔的代码审阅意见应该会受到同事的欢迎和认可。但在这个故事中，乔应该注意到这个团队中普遍存在的不安全感，采用更为委婉的方式将代码审阅引入团队文化之中。

在职业软件工程环境中，批评通常只是产品改进过程的一部分，几乎从不针对个人。困难的是如何确保你（以及你周围的人）理解对某人创意结果的建设性批评与赤裸裸的人身攻击有何区别。人身攻击毫无价值，这种行为既卑劣又没法回应。建设性批评通常是有益的，能够指导我们改进。最重要的是，建设性批评是基于尊重的：意见的提出方真切关心意见的接受方，希望他改进自身或工作。要学会尊重同伴，有礼貌地提出建设性批评。如果你真的尊重一个人，就会主动选择使用得体、有益的词句进行交流——这项技巧需要多加练习才能掌握。

作为意见的接受方时，也需要学会接受批评。要做到这一点，不仅需要对自己的技术持谦虚态度，还要相信提出批评的人是真心为你和项目好，而不是认为你笨。编程和其他技术一样，需要练习才能提高。如果一位同伴指出你该如何提高杂耍水平，你会认为这是对你人品和个人价值的攻击吗？估计不会。同样，你的自尊不应该和你写的代码（或创建的任何创新项目）有任何联系。也就是说，你的代码并不代表你。再说一遍，你和你的产品不是一回事。你不仅要自己相信，还得让同事也相信这一点。

例如，如果你与一位缺乏安全感的同事合作，请不要对他说：“哥们，你把这个方法的控制流全搞错了，应该用标准的xyzzy代码模式，大家都这么用。”这条反馈意见充满了反模式：你告诉某人，他做“错”了（就好像这世界非黑即白），要求他修改，还指责他与众人背道而驰（让他自感愚钝）。受批评的人将被迫采取防卫姿态，出现过度情绪化的反应。

同样一句话，这样表达可能更好：“嗨，我不太明白这部分的控制流。我想，如果用xyzzy模式，逻辑是不是更清晰，代码也更好维护呢？”请注意此处是如何善用谦虚的，表明问题在你而不在他。他没有错，只是你不太理解这段代码。你提出的意见只是要让自己更清晰地理解代码，同时有利于项目的长期维护。你也没有提出任何要求——对方可以心平气和地拒绝这个建议。这场讨论仅限于代码自身，不涉及任何人的价值或编程技术。快速失败和迭代

商界有一个流传很广而且很老套的民间传说：有位经理因失误导致公司损失达千万美元之巨，第二天，他沮丧地走进办公室收拾东西准备走人。接到“CEO让你到办公室去”的电话后，他走进CEO办公室，默默地递上一张纸。“这是什么？”CEO问。“我的辞职信，”经理答道，“我想你叫我来就是要辞退我。”“辞退你？”CEO惊讶地回道，“为什么要辞退你？我刚在你身上花了1000万的学费！”6

6网上流传着这个故事的十几个版本，主角各为不同的著名经理人。

当然，这个故事有些极端，但故事中的CEO明白，辞退这位经理并不能挽回1000万的损失，反而会雪上加霜，损失一位有价值的管理人员，而这位管理人员绝对不会再犯同样的错误。

在谷歌，我们最喜欢的格言之一是：“失败是一个选项。”我们认为，如果从来不犯错误，说明你没有足够的创新性去承担足够的风险。在我们看来，失败为下一次的努力提供了学习和改进的最佳机会。实际上，人们经常引用托马斯·爱迪生的话：“发现一万种走不通的路，并不意味着我失败了。我不会气馁，因为每次失败的尝试都是前进的一步。”

在Google X（研发极度前瞻项目的部门，如谷歌眼镜和无人驾驶汽车），失败是精心设计在激励系统中的一部分。人们会提出疯狂的想法，鼓励同事尽快证明这些想法是错误的。部门会奖励个人（甚至提倡竞争），看大家能在固定时间内证明多少想法是错误的或不可行的。当一个概念确实无法被大家驳倒时，它才能进入下一步的初期原型设计。

从错误中学习的关键是将失败记录在案。你需要编写我们所说的“事后分析报告”。请注意，事后分析报告的目的不是罗列无用的道歉或借口。一份合格的事后分析报告应该包含学习经验的结果，解释学到了什么，计划作出什么改变。然后要确保将这份文档放在一个随手可得的地方，并按照文档提议的内容作出改变。请记住，将失败完备地记录下来，还可以让别人（在现在及将来）更容易了解当时发生了什么并避免重复历史。不要擦除你的足迹，照亮来路，以便后来者追随！

一份完备的事后分析报告应包含以下内容：● 概述● 从发现问题，调查问题，到解决问题的时间线● 事件发生的主要原因● 影响和损失估计● 立即解决问题的一系列措施● 预防事件再次发生的一系列措施● 吸取的经验教训留出学习的时间

辛迪是一位超级巨星——一位在所属领域才能卓越的软件工程师。她晋升为技术组长后，承担了更多的责任，并积极应对挑战。不久之后，辛迪开始指导周围的人，在专业会议上发表演讲，很快成为多个团队的负责人。辛迪享受作为“专家”的感觉，但是，她开始感到无聊。在成长的过程中，她不再学习新事物，作为最聪明、最有经验专家的新奇感逐渐消退了。虽然辛迪在外表上依然是领域专家，享有成功，但总觉得缺少了什么。一天，她意识到自己的领域不再那么重要，人们已经转到其他方向。那么辛迪哪里出了问题呢？

我们需要面对一个事实：成为团队中最博学的人很有趣，指导别人也极为有益，问题是一旦成为团队中技术最强的人，你就不再学习了。如果停止学习，你就会觉得无聊，或者无意间变得落伍。成为最佳队员这件事很容易上瘾，但只有稍稍放下自我，才能改变方向，接触新事物。再次强调，你还是需要变得更加谦虚，既愿意传授知识，也愿意学习。请间或跨出自己的舒适区域，找一个有更多大鱼的池子，接受未知的挑战。最后，你会变得更快乐。学会忍耐

很多年前，Fitz在编写一个将CVS库转换到Subversion（后来转到Git）的工具时，由于CVS的问题，他不断发现各种奇怪的缺陷。Fitz的老朋友兼同事Karl对CVS很熟悉，因此两人决定一起修复这些缺陷。

Fitz和Karl开始结对编程时遇到了一个问题：Fitz习惯自底向上，一头扎进代码，快速进行各种尝试，略过细节；而Karl习惯自顶向下，先摸清大局，了解调用栈中的每个方法，然后再着手解决问题。两人习惯的不同导致了一些严重的冲突、矛盾，偶尔还发生了激烈的争吵。到最后两人干脆不再结对编程了，因为这实在是太令人沮丧了。

虽说如此，但Fitz和Karl毕竟有着对彼此的长期信任和尊重，再加上耐心，他们想出了新的合作办法。Fitz和Karl会一起坐在计算机前，确认缺陷，然后分头从两个方向（自顶向下和自底向上）攻克这个问题，再回来一起研究各自所得。他们充满耐心，愿意采取新的工作方式，这不仅挽救了项目，也挽救了与彼此的友谊。接受改变

越愿意接受改变，就越能引起改变。越是脆弱的人，越表现得坚强。这些话听来很怪，似乎自相矛盾。但是每个人都可以回想一下一起工作过的特别固执的人。别人越是试图说服他，他反而更加固执。这样的团队成员最后会怎样？按我们的经验，最后大家会把他们视为障碍物，“绕开”他们，不再听他们的观点或反对意见。你肯定不想陷入这种境地，因此必须记住：自己的观点可以受别人影响。并不是每件事情都必须坚持己见，要谨慎选择需要坚持的事情。记住，你要先聆听别人的意见，别人才会听取你的意见。在宣布自己的立场或观点前最好先听取别人的意见，如果你不断改变观点，别人会认为你优柔寡断。

关于脆弱的说法初听起来也有点奇怪。如果一个人承认自己不懂或不知道如何解决一个问题，他会给大家留下什么印象？脆弱是软弱的表现，会导致失去信任，是这样吗？

并非如此。从长远来说，承认自己的错误或能力不够可以提升地位。实际上，这也是HRT原则的表现：对外表现出谦虚的态度，不仅可以显示出可靠性和责任感，还说明你信任别人的观点，最后，人们也会尊重你的诚实和能力。有时，最好的做法就是直接承认：“我不知道。”

想想那些政治家，他们最为人诟病的就是，即便事实明显，也从不承认自己的错误或无知。正因为如此，大多数人不相信政客说的任何一句话。政客拒绝承认自己的错误，主要是因为他们不断受到对手的攻击。但当你写代码时，就没必要时时处于防御状态了——队友是合作者而非竞争者。下一步

读到这里，你已经掌握了“与他人合作”的艺术。你必须开始检视和反省自己的行为。一旦将这里讨论的策略应用到日常生活中，你将发现合作变得越来越自然，工作效率也明显提高。

重要的改变应当从自身开始，由内及外。下一章将讨论如何在所在团队中打造HRT氛围。 第2章打造团队文化

团队文化种类多样，反映出不同的价值观和任务优先级。有些团队文化促进成功，有些则导致很大的失败。但是，即使在成功团队中，团队文化也不尽相同。有些团队文化极为高效，将绝大部分注意力放在当前的任务上；有些却提供很多与当前任务无关的活动。这一章将讨论团队文化，主要关注成功所需要的各种沟通技术，并阐述如何将这些技术用于团队之中，从而更高效地创造产品。

试读结束[说明：试读内容隐藏了图片]

下载完整电子书