本节书摘来异步社区《极客与团队》一书中的第1章，作者： 【美】Brian W. Fitzpatrick , Ben Collins-Sussman 译者： 徐旭铭 责编： 陈冀康, 更多章节内容可以访问云栖社区“异步社区”公众号查看。
HRT实战
极客与团队
说了那么多谦虚、尊敬、信任的东西，听起来都像是纸上谈兵。既然这样，我们现在来看看它们和现实是怎么联系起来的。既然我们追求的是实际可操作的建议，所以下面会给出一系列特定的场景实例。其中很多看起来似乎都是显而易见的，可一旦开始仔细思考，你就会发现自己（和同僚们）犯错的频率有多高了。

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

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

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

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

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

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

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

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

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

快速失败；学习；迭代
商业界里有一个著名的（也是说烂了的）段子，说是曾经有一个经理因为犯下大错损失了上千万美金。第二天他非常沮丧地回到办公室开始整理桌子，这时他接到了预料之中的通知，“CEO想要见你”，于是他步履沉重地走进CEO的办公室，默默地递上一张纸。

“这是什么？”CEO问道。

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

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

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

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

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

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

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

• 简要
• 事件的时间线，从发现到调查，再到最终结果
• 事件发生的主因
• 影响和损失评估
• 立即修正问题的步骤
• 防止事件再次发生的步骤
• 得到的教训

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

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

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

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

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

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

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

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