> “工程问题都很简单。人际关系才是最难的。” ——比尔·库格伦，前Google工程部资深副总裁 生活中总是充满了离奇的转折，就好像我们俩从没想过会合作写一本软件工程的书一样。 和大多数电脑狂一样，大学毕业后我们发现自己的兴趣和热情（折腾电脑）居然也是不错的谋生手段。而和那个时代的大多数黑客一样，我们的整个20世纪90年代中期都是在干这些事情，用别人剩下的零件攒机，拿着一大叠软盘安装预览版的 Linux，然后学着操纵 UNIX 机器。我们都是系统管理员出身，然后在互联网泡沫刚起来的时候跑到小公司里去当程序员。泡沫破裂后，我们开始为那些幸存的硅谷企业（比如 Apple）工作，后来又跳槽去了一家创业公司（CollabNet），全心设计开发了一款开源版本控制软件Subversion。 然而2000年到2005年期间，一些意想不到的事情发生了。尽管我们创造了 Subversion，但是我们每天的任务却渐渐发生了变化。我们不再只是天天坐在那里写代码，而是开始领导一个开源项目了。这意味着我们要整天挂在聊天室和一堆程序员志愿者打交道，关注他们都在做些什么。这还意味着要几乎完全通过邮件列表来协调各种新特性。我们逐渐发现一个项目成功的关键不仅仅是写出漂亮的代码：所有人向着同一个目标一起合作也是同样重要的。 2005 年的时候我们一起创建了 Google 芝加哥分部，以程序员的身份继续着我们的职业生涯。这时我们已经完全融入开源世界了——不仅仅是Subversion，还有Apache软件基金会（ASF）。我们把 Subversion移植到 Google的 BigTable架构上，并以Google Code为名发布了一项开源项目托管的服务（类似于 SourceForge）。我们开始参加（后来开始做演讲）各种开发者大会，例如OSCON、ApacheCon、PyCon，还有Google I/O。我们发现同时为企业和开源项目工作的经历让我们无意之间了解到了软件工程团队运作的奥秘。一开始我们做的演讲都是轻松幽默的，大多是批判无用的开发流程（“Subversion最差实践”），后来则开始转向探讨如何保护团队不受害群之马的影响（“开源项目如何应付害群之马”）。越来越多的听众聚集到我们的演讲会场，我们称之为程序员的“集体疗法”。每个人都对我们谈论的问题有着切肤之痛，都想要对大家抱怨一下。 于是，六年来我们做了一大堆反响热烈的和软件开发过程中人际关系有关的演讲。最后奥莱利公司的编辑玛丽·特莱斯勒建议我们干脆把这些演讲写成一本新书。接下来发生的事情就略过不表了。  想要编写出色的软件？这本书就是为你写的 ## 本书的读者 本书是专门写给那些想要更上一层楼以及编写出色软件的程序员看的。CEO、心理学家、管理层\计算机理论学家，还有焊电路板的技师等都不算是我们的目标读者（虽然这些朋友或许也能读得津津有味）。在此我们假设本书的读者具备以下两个重要条件。 • 你需要和团队里的其他程序员合作。无论是为公司企业工作，或是某个开源项目或是学校作业的一员都可以。 • 你喜欢软件工程，并且觉得它应该是一件很有成就感、很好玩的事情。如果你只是应付工作混口饭吃的话，那估计你对实现自我价值和获得职业满足感不会有什么兴趣。 在讨论程序员怎么才能“通力合作”的时候，我们总结出了一些表面上看起来和程序员这份工作风马牛不相及的经验和准则。我们会在各章里谈到怎么才能更好地领导一支团队和企业，怎么才能和用户建立起良性的关系等话题。乍看起来这些章好像是专门写给所谓的“管人的人”或者说“产品经理”看的，但我们可以保证，你的职业生涯到了某个阶段的时候一定会有意无意地担当起这样的角色。所以先放下疑虑，继续往下读吧！这本书里讲到的东西是每个软件工程师最终都会碰到的。 ## 警告：本书不是技术手册 首先我们需要澄清一些事情。好学的程序员通常都喜欢去读一些能将某些个特定问题用纯数学的形式展现出来的书籍，而通常这样的问题都存在完美的流程化的答案。 本书并不属于这种类型。 本书主要关注的是软件开发中有关人的那个方面，而人是很复杂的。正如在我们自己的演讲中说到的那样，“人基本上就是由一大堆间歇性bug组成的”。这里论及的问题和答案都是很凌乱的，很难用完美逻辑来解释。本书读起来像是论文集，而事实上它的确也就是一本论文集。每一章我们都会讨论一系列相关的问题（通常是用案例故事的方式），然后针对整个主题再探讨各种应对方案。你可能需要反复阅读很多页，努力把它们联系起来，甚至思考数日才能融会贯通！ 我们在此还要作一些声明。正如我们在演讲里开过的玩笑，“这里的观点完全是基于我们自己的经验得出的，完全属于我们自己。要是你不同意我们的观点，完全可以去自己做演讲啊”。和我们的现场演讲一样，只要和本书主题相关，任何讨论都是值得鼓励的。我们欢迎各种反馈、修正、新观点，以及反驳：你可以在http://www.benandfitz.com/ 上找到我们。本书的所有内容都来自我们的亲身经历和无数错误中得到的教训。 你还应该注意，我们在例子中提到的都是化名，以保护无辜（或者犯错）的当事人。 ## 本书的内容都是课本里学不到的 我们认识的软件工程师绝大多数都花了4～10年的时间在学校里学习计算机科学和软件工程。截至本书出版为止，我们不知道有任何一门课程¹ 是真正教你怎么在团队和公司里与人合作交流的。好吧，大多数学生都会在学校里被要求参与某个项目，但是教一个人怎么好好地和另一个人协作与把他直接丢到一个迫使他协作的环境里完全是两码事。绝大多数学生最后都不怎么喜欢这种经验。  ## 小结 所谓成功的程序员不仅仅是追逐最新的语言或是编写最快的代码。职业程序员几乎都是要参与团队合作的，而且事实上团队直接影响个人生产力和幸福感的程度超出很多人的想象。 本书的目标很简单：编写软件是集体项目，而且我们认为人的因素对结果的影响不亚于技术因素。大多数人虽然在编程技术上耕耘数载，但是在人际关系上却从来没有下过功夫，而学习与人合作也是成功路上不可或缺的重要环节。只要你能在软件工程的“软技能”上下点功夫，就能达到事半功倍的效果。 * * * * * > ¹ 我们读过汤姆·迪马克的《人件》，的确是一本好书，但它并不是一本专门教工程师怎么与人高效合作的著作，而是一本教管理人员怎么带领团队成功的著作。