团队才是王道

在编程领域里，真正的独行侠是很罕见的——就算他们真的存在，他们的非凡成就也不是凭空而来的。这些改变世界的成就几乎都是集体智慧努力得来的结晶。

因此建立一支全明星团队才是真正的目标，不过想达成这个目标，难度高得惊人。最好的团队能充分利用好队里的巨星是没错，但是集体的力量一定是大于个体力量之和的。

用一句话来说就是：软件开发是集体项目。

乍看之下这个理念很难让人接受，毕竟这和我们心里的天才程序员幻想是相抵触的，所以先记下来再慢慢理解吧。

记住，软件开发是集体项目

一个人躲在自己小黑屋里抖聪明是没用的。光靠自己神神秘秘地搞创造发明是不可能改变世界，令千百万用户受益的。你需要合作，告诉别人你的想法，让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。

社交技巧“三支柱”

既然团队合作才是开发成功软件的捷径，那么如何才能打造出（或者找到）这样优秀的队伍呢？

答案是很难。要达到合作无间的境界，你首先要学习理解所谓的社交技巧“三支柱”。这三项原则不但是人际关系中的润滑剂，更是所有良性互动与合作的基本。

谦虚

没有人是宇宙中心。谁也不是万能的，谁都会犯错。你必须不断地提高自己。

尊重

你必须真心实意地关心同事。他们都是活生生的人，他们的能力和成绩都需要得到肯定。

信任

要相信别人的能力和判断力，在适当的时候懂得放权。

我们把这些原则简称为HRT。发音是“heart”而不是“hurt”，因为它是要减轻痛苦而是不是伤害别人。事实上我们的论文就是直接基于这些原则的：

基本上所有的社交摩擦最终都是由于缺乏谦虚、尊重，或是信任而造成的。

乍听之下似乎有点难以置信，但请姑且相信我们。你不妨仔细回想一下生活中遇到过的各种令人难受的社交场景。先不说别的，当时大家是不是都有保持有礼有节？是不是真的有尊重对方？是不是有相互信任？

我们相信这些原则至关重要。

然后我们会讨论那些每天会和团队打交道，但是却不属于核心团队文化的人。他们可以是其他团队的同事，或是项目的志愿者。他们中的很大一部分人不但完全无视HRT，更有甚者，完全就是老鼠屎！学习如何抵御这种人对团队的伤害是你的首要任务。不过你的终极目标应该是拔掉他们的爪牙，让他们融入到你的团队文化中来。这是扩充队伍的最佳方式之一。

拥抱HRT才能合作无间

大多数团队都隶属于更大的公司，这种环境常常和害群之马具有同等危害。你的产品能否顺利发布亦或是最终面临被取消的命运，完全取决于你能不能学会如何避开各种行政障碍。

最后，你的用户也是需要考虑的。我们往往会忘记他们的存在，但就是他们决定了产品的寿命。没人用的软件是没有存在价值的。对团队至关重要的HRT原则同样（也应该）适用于你对用户的态度，你能从中获得的好处是不可言喻的。

说到这儿，让我们先暂停一下。

社交的确是个棘手的难题。人类是混乱复杂的生物，完全无法预料，有些人会让人觉得不愿与之打交道。与其耗费那么多精力去分析各种社交场景，步步为营，还不如干脆完全放弃努力。行为完全可以预判的编译器岂不是容易对付得多？干嘛要跟那些社交的麻烦较劲呢？

这里引用一段理查德·海明的著名演讲：

我花了很多时间给我的秘书们讲笑话，和他们搞好关系，这也让我从他们那里得到了许多好处。比如有一次，不知道什么缘故，梅山3所有的复印机都坏掉了。别问我为什么，反正就是坏掉了。而我正好要复印一些文件。于是我的秘书给霍姆德尔的朋友打了个电话，跳上公司的车，开了一整个小时去帮我复印，然后再开车回来。这就是我花了那么多功夫讲笑话逗她开心，表示友善得来的回报。真可谓投之桃李，报之琼瑶。也就是说，通过使用系统并研究如何让系统帮你做事，你就学会了调整系统，让它按照你的意愿工作。

这个故事告诉我们：不要低估社交的力量。社交不是勾心斗角，或是操纵别人，它是通过建立起人与人之间的关系来把事情做成功，而且这种关系延续的时间肯定比项目本身更长。

HRT实战

说了那么多谦虚、尊敬、信任的东西，听起来都像是纸上谈兵。既然这样，我们现在来看看它们和现实是怎么联系起来的。既然我们追求的是实际可操作的建议，所以下面会给出一系列特定的场景实例。其中很多看起来似乎都是显而易见的，可一旦开始仔细思考，你就会发现自己（和同僚们）犯错的频率有多高了。

放下自负

好吧，说得更直白一点，就是让某些缺乏谦逊的人收敛一点儿。没人喜欢和总是以自我为中心的人合作。哪怕你真的是会议室里最聪明的那个，你也没必要到处炫耀。例如，你是不是总是觉得自己对于每个话题都要抢先发表意见，或是要作总结性发言？你是不是觉得自己需要在一项议案或是讨论中对每个细节发表评论？或是你总是要知道谁在干什么？

注意，“表现得谦逊一点”和人见人踩的懦弱完全不是一回事：自信并没有错。只是不要过了头，非要弄得自己好像无所不知一样。其实更好的思路是想办法促成“集体”荣誉感。不要去担心你的个人形象是不是高大，而应努力去营造一种团队和集体荣誉感。Apache软件基金会在围绕软件项目经营社区上已经有很长的历史了。这些社区对自己都有很强的认同感，根本不欢迎对那些只关心自己往上爬的人。

自负这个东西有很多种解释，就看你怎么理解，但很多时候它都会妨碍你的工作，让你进步缓慢。这里从海明的演讲里再摘取一段小故事来证明我们的观点：

“约翰·图基几乎总是不修边幅的模样。每次他参加重要会议的时候，对方总是要好一会儿才反应过来原来这是位大人物，应该认真听他说。有好长一段时间约翰都要面对这种麻烦。这实在是太浪费时间了！我不是说你应该屈服，我说的是，‘作出妥协的样子能给你带来很多好处’。如果非要由着自己的性子来，‘我就是我行我素的人’，那么你就在整个职业生涯里不断地付出一些不大但是很讨厌的代价。日积月累就会变成原本没必要的***烦。……通过使用系统并研究如何让系统帮你做事，你就学会了调整系统，让它按照你的意愿工作。不然的话，你就得终其一生去和这种潜规则作斗争。”

学会批评和接受批评

乔是一名程序员，他最近找到了一份新工作。在上了一星期的班以后，他开始深入地学习了解团队的代码。出于责任心，他开始以温和的方式对同事的代码提出疑问。他通过E-mail的方式发出代码审查，礼貌地询问设计初衷或是指出逻辑上可以改进的地方。两个星期后他被叫到了主管办公室。“出什么事了？”乔问道，“我是不是什么地方做错了？”主管看起来不太高兴：“乔，最近有很多人投诉你，说你对同事太苛刻了，把他们说得左也不是右也不是。大家都很不爽，你最好低调一点。”乔因此大受打击。若是在一个完全以HRT为基础的环境里，乔的代码审查应该是可以被接受的，同事们也会认同这种做法。但是在这个例子里，乔就应该对团队里弥漫的不安全感多加小心，在引入代码审查的时候应该更谨慎一点。

在职业程序员这个行当里，人身攻击是相当罕见的——批评通常都是为了产品好。其中的诀窍就是要确保你（和你周围的人）认识到对某人的创造性工作提出建设性批评和人身攻击之间的区别。后者是毫无意义的——这种攻击不但显得小气，而且几乎不可能有什么建设性。而前者通常都是有益的，对改进具备指导性。最重要的是，它蕴含着对对方的尊重：只有真正关心对方的人才会提出建设性意见，希望对方在自身或是工作上有所进步。所以学着尊重对方，礼貌地给出建设性批评吧。如果你真的尊重一个人，那你就会自发地选择有技巧有帮助的措辞——这种技巧需要很多练习才能学会。

作为谈话的另一方，你也应该学会接受批评。这不是说你在技术上要谦虚，而是说你要信任对方，相信他是从心底为你好（当然还有你的项目），完全没有把你当傻瓜的念头。编程和所有技能一样，都需要熟能生巧。如果你的同事提出的做法比你现在的好，你会把它当成是对你的性格或是人生价值观的攻击吗？我们真心希望你不会。同样，你的自尊和你的代码不应该有什么联系。换句话说，你和你写的代码是两回事。你应该不断地告诫自己，你和你写的代码是两回事。不但你自己要相信这个观点，还要让你的同事也认同它。

别把你的自尊和你的代码等同起来

举个例子，假如你有一个比较敏感的同事，那么下面这样的话是万万不能说的：

“老兄，你完全把这个方法的控制流程给弄错啦。你应该和大家一样用标准的xyzzy代码模式才对。”这段话全是反模式的东西：首先你告诉他，他“错了”（好像这个世界非黑即白一样），然后要求他作出修改，最后还指责他写的东西和所有人都不一样（让他觉得自己很傻）。可以预见，这样会让对方变得很抵触，得到的回应也肯定是没有什么理智的成分。

好一点的版本：

“嗨～我有点看不懂这段代码的控制流程。要是用xyzzy代码模式的话会不会更清楚一点？维护起来也方便？”注意这里，你谦虚地把问题归到自己头上，而不是他。他没有错，只是你理解代码有困难而已。另外提出的建议也只是提供了一种方法让可怜的你能理解代码，或许还能在项目长期维护上有所助益。你也没有提出任何要求——你的同事完全可以谢绝这个建议。讨论的范围被限定在代码上，没有涉及任何人的价值观或是编程技术。

快速失败；学习；迭代

商业界里有一个著名的（也是说烂了的）段子：

曾经有一个经理因为犯下大错损失了上千万美金。第二天他非常沮丧地回到办公室开始整理桌子，这时他接到了预料之中的通知，“CEO想要见你”，于是他步履沉重地走进CEO的办公室，默默地递上一张纸。

“这是什么？”CEO问道。

“我的辞呈，”这位高管答道，“你叫我来就是要炒我鱿鱼的吧。”

“炒鱿鱼？”CEO一脸狐疑地答道，“我为什么要炒你鱿鱼？我刚刚才花了一千万来培训你！”

当然，这个段子很极端，但是故事里的CEO心里明白，就算炒鱿鱼也不能挽回这一千万的损失，而且还要损失一名很有价值的高管，因为他以后肯定不会再犯这种错误了。

我们俩都在Google工作，而我们最喜欢的Google的格言之一就是“失败是可以接受的”。广泛的认识是如果没有经历过失败的话，就说明你的创新还不够，或者你承担的风险还太小。失败是更上一层楼的绝佳机会。事实上，托马斯·爱迪生曾经说过：“即便我找到了一万种行不通的办法，也不代表我失败了。我并不会因此而泄气，因为每次试错都是在前进。”

Google通常都采用这样一种（我们之前讨论过的）理念，“不要等到完美的时候再出来”：只要产品大致可用，就立刻把它按照原样公开给大众。这就是Google Labs的使命。这种办法使得成功和失败的地方得以立即显现出来，这样编程团队就可以尽快从中学习，迭代，然后发布新版本。它的缺点是Google常常会被揶揄说他家的产品总是在“beta”阶段，比如Gmail就“测试”了四年多。而它的优点在于可以迅速做出调整以适应变化，在很短的时间内就能做出惊艳的产品。所有的这一切都要求谦虚的特质——把不完美的软件展示给用户是可以接受的，另外还需要一些信任，即用户真的会认同你的努力，并且期望迅速看到改进。

从错误中学习的诀窍是要记住自己摔倒的地方，按商业用语来说就是“事后检讨”。但是要特别小心，千万不能把事后检讨的文件变成一堆无用的道歉和借口——这不是它的目的。真正的事后检讨应该包含有关“学到了什么”以及“怎么改正”等经验教训的详细注解。然后要保证把它放在一个随手可及的地方，并且认认真真地按照上面所写来实施改进。记住，正确地记录错误还能让其他人（不管现在还是将来）方便地了解事情的原委，以避免重复历史。不要抹掉自己的足迹——像跑道一样点亮它们，为后来人指路吧！

一份出色的事后检讨应该包含以下内容：

• 简要

• 事件的时间线，从发现到调查，再到最终结果

• 事件发生的主因

• 影响和损失评估

• 立即修正问题的步骤

• 防止事件再次发生的步骤

• 得到的教训

• 为学习预留时间

辛蒂曾经是超级巨星——在她的领域里她绝对是大师级的程序员。被提升为技术指导后，责任随之变大，而她也接受了这个挑战。很快她就能领导周围的每个人并指导他们工作了。她出席各种大会并就自己的领域作演讲，不久之后她已经能掌管好几个团队了，她也非常享受“专家”这个头衔。但是她却开始厌倦这种生活了，不知不觉地她不再学习新东西，成为所有人之中最聪明、经验最丰富的专家的这种新鲜感开始褪去。尽管表面上光鲜亮丽，但是总好像缺了点什么似的。直到有一天她终于意识到自己的领域不再尖端，人们开始转向其他更有兴趣的课题。她到底出了什么问题？

我们来分析一下：成为人群中最睿智的人的确很让人高兴，而且能够指导别人绝对可以带来了不起的成就感。但是问题在于一旦攀至顶峰，人们往往就会停止学习了。而当一个人不再学习的时候，她就会开始觉得厌倦，一不小心还会变得落伍。虽然当领导很过瘾，但是只要能放下一点骄傲，你就能开阔眼界，接触新鲜事物。这说穿了其实还是谦逊的问题和是不是愿意像指导别人一样接受别人的指导。偶尔应该跳出自己的舒适区，在更大的舞台上接受各种挑战。这样你才能长久地保持愉快的心情。

学习保持耐心

傅攀勃在多年前写过一个把CSV仓库转到Subversion（以及后来的Git）上去的工具，由于RCS和CSV的行为异常古怪，他不断地发现各种诡异的bug，比如CVS会默默地吃掉明明是非法的RCS文件。而他的老朋友和同事卡尔对CVS和RCS都非常了解，他们决定一起来修复这些bug。

可是就在他们开始结对编程的时候发生了一个问题：傅攀勃喜欢自底向上的工作方式，他会深入项目，通过快速尝试各种情况来梳理细节。而卡尔却是喜欢自顶向下工作方式的工程师，他会先搭好框架，构建好调用栈里每个方法的实现后才会考虑bug的问题。这就引发了两人之间巨大的冲突和分歧，有时甚至会产生激烈的争执。傅攀勃和卡尔尽了极大的努力和专注，还恪守了HRT的原则才得以完成这项任务。HRT最终不但拯救了项目，也保住了他们之间的友谊。

对影响保持开放的态度

你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮。这两句话看起来有点自相矛盾。但是每个人都碰到过某个同事，固执到叫人恼火。无论怎么试图说服他都没用，越劝越不听。最后怎么样？就我们的经验来讲，大家最后就会自然而然地把他当成障碍物“绕道而行”，再也不会有人听取他们的观点或反驳。没人希望这种事情发生在自己身上吧？所以请记住这一点：接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了，要别人听你说话，首先是要学会当一个听众。注意在被影响的时候，如果你要听取意见，一定要在你下定决心或是确定宣布你已经做好决定之前——要是你的主意老是改来改去的，别人会觉得你这个人没什么立场。

说到示弱，初看之下也有点奇怪。如果一个人承认自己对某个东西一无所知，不知道要怎么解决问题，那他还能得到多少团队的信任么？示弱就是暴露弱点，这不是在摧毁自己的自信吗？

其实不是。承认自己犯错或是无知从长远来讲其实能提升你的形象。事实上它蕴含了HRT的全部方面：它对外表示了“谦虚”，这是有责任心、负责的态度，这也是表示“信任”别人意见的态度，同时作为回报，别人也会因为你的诚实和坚强而“尊重”你。所以有时候最好的答案就是：“我不知道。”

诚实和谦虚不是氪气石

想想那些政客吧。这帮人之所以讨厌是因为无论他们错得多离谱，或是对件事物表现得有多无知，他们也从来不会承认，所以很多人都觉得政客的话是不可信的。这种现象主要是因为政客经常暴露在对手的攻击下。但是写软件的时候就用不着总是抱着防备的心态了——你的同事是合作者，不是竞争者。

若能读到这里，说明你已经在掌握“与人合作”的艺术的征途上跨出了第一步，你已经检视反省了自己的行为。只要能在日常生活中运用这些策略，你就会发现合作将变得更自然，工作效率也能大大提高。

重要的改变要由自己做起，然后慢慢影响其他人。

本文节选自《极客与团队》