如何对付团队中的“害群之马”

        文/Brian W. Fitzpatrick Ben Collins-Sussman

        软件开发中最难的是跟人打交道，防止那些捣乱的家伙破坏你的团队辛辛苦苦建立起来的合作氛围。更重要的是，我们要探讨一下怎么对付那些已经在团队里的害群之马。

        什么是“害群”

        我们已经讨论了培养稳定的、沟通无碍的团队文化有多重要。我们一直在强调，好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查，以及能让人放心尝试新事物或者快速失败的环境。

        同样重要的是还要了解哪些东西不应该包括在文化里面。如果你打算打造一支高效敏捷的团队，那么知道自己不要什么也是非常重要的。虽然优秀的工程 师能让团队更快更有效率，但是有些不好的习惯和做事风格会拖累团队，让公司变得不再那么让人舒服—最终这些都会侵蚀队伍的团结。

        我们刚开始在研讨会上说到软件开发中的社交难题的时候，用的演讲标题是“怎么对付坏蛋”，大会主席建议我们把它改成“项目如何才能在害群之马的 铁蹄下幸存”，希望这种八卦风格的标题能吸引到更多听众。事实上他是有道理的，这个演讲在很多研讨会上大受欢迎，听众多得连站的地方都没有。吸引听众的不 单是“害群”这样非常负面的词汇，还有一个原因就是很多人都有这样不得不和那些叫人恼火的人打交道的经历。演讲到最后几乎肯定会变成一场诉苦大会，听众们 会交换自己的故事，商量对策。

        不过这样其实是很危险的。一般来说，一个人总是让自己沉浸在负面情绪里是不健康的行为—长远来讲，它会侵蚀你的一切，制造更多麻烦。“害群之 马”是很大的帽子，一下子就把“我们”（也就是好人）和“他们”（捣乱的坏蛋）对立了起来。其实完全可以换一个思路来看这个问题。在带领团队的时候，不要 把自己想成是一帮精英，众志成城地要把所有的烂人都轰走，而是要培养一种拒绝容忍负面行为的文化氛围，这才是正确的态度。要剔走的是行为本身，而不是人， 单纯地区分好人和坏人是很幼稚的想法。规定好哪些是不可容忍的行为，然后予以惩戒，才是更有建设性的务实态度。

        简单起见，我们暂时继续采用“害群之马”这种修辞手法来指代那种行为不端的人，但是在日常对话里千万不要轻易使用这个词哦！

        保护团队

        还记得酵母的比喻吗？团队文化和创始人的气质是紧密联系的。对团队文化影响最深的就是创始人，要是创始团队的文化不够强势，那么后来的文化就会压过它。如果创始团队很清楚哪些行为是可以接受的，哪些行为是不可以接受的，那么这些东西就能传承很多年。

        我们两个在开源项目圈子里混了好多年，多年的经验也充分印证了这一点。

        Subversion 是我们接触最多的项目，刚开始的时候它只有很少的成员。大家都非常谦虚，相互之间有一种自然而然的信任感和尊重。十一年来，项目的参与者来来去去至少三四 拨（大部分创始人早就离开了），但是传统还是保留了下来—大家都和和气气的，很有礼貌，相互尊敬。这不但是因为它坚持了高标准，还因为文化总是会进行自我 选择。物以类聚，人以群分。

        自我选择也很容易往坏的方向发展。如果团队一开始就聚集了一帮愤青，那么它就会有越来越多的同类。有些项目我们实在是不愿意提，比如 Linux 内核社区就是典型的例子—无止境的斗嘴，狂妄的发言，还有各种出口伤人。这样的团队或许能完成很多工作，但是总体上的运营效率却叫人怀疑。要是在人身攻击 上没有浪费这么多精力，那么能多做多少事情？如果没有把那些礼貌的人拒之门外，那么他们的潜在贡献有多大？

        我们再次提到这个话题是为了让你明白其中的代价，害群之马会直接危害到你的高效团队。如果容忍了不良行为的存在，不但你的生产力会受到影响，还 会渐渐侵蚀团队的文化。而对抗它的最好办法就是通过一系列强有力的最佳实践和流程来提高团队的抵抗力。这些内容在第二章里都已经讲过了，这里再简单回顾一 下。

        保护团队，抵御不良行为

• 写一份明明白白的任务宗旨。这样可以随时保持专注，知道哪些是目标，哪些不是。
• E-mail 讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人”。
• 所有历史都要有记录。这不单指代码历史，还有设计决策、重要的 bug 修复，以及过去犯下的错误。
• 有效地进行协作。利用版本控制，代码改动要尽可能的小，方便进行审查，扩大“公车因子”，避免出现领地感。
• 修复 bug，测试，发布软件要有清晰的政策和流程。
• 降低新人加入时的壁垒。
• 依赖基于共识决策，在无法达成共识的时候也要准备好化解矛盾的方法。

        最重要的是，这些最佳实践越根深蒂固，社区就越不能容忍各种有害行为。等捣乱的人真的出现的时候，你也就做好准备了。

        发现威胁

        要帮助团队抵御害群之马，首先要明白的就是到底什么才算是威胁，什么时候要引起注意。

        团队的注意力和专注力是最容易受到威胁的。

        注意力和专注力是最宝贵的资源。团队规模越大，编写软件和解决有趣问题的能力就越强—不过这种能力毕竟是有极限的。要是你不去主动保护它们，很 容易就会被害群之马引入歧途。团队最终会争论不休，变得心烦意乱、身心疲惫。所有人都会把注意力和专注力放到那些编写优秀软件以外的事情上去。

        这时你大概会问：害群之马到底是指什么样子的人？正所谓有则改之，无则加勉嘛。

        根据我们的经验，很少会有人故意干坏事（也就是存心捣乱的那种）。我们管这种行为叫作“钓鱼”，通常无视这种人就可以了。而大多数人在行为出格 的时候，要么是没有意识到自己过分了，要么就是根本不在乎别人的感受。无知和冷漠其实比蓄意更严重。绝大多数出格的行为都可以归结为缺乏基本的 HRT。

        这里是一些特别值得注意的信号和模式。只要这些东西一冒头，我们就会对这个人亮出黄牌—也就是说，我们会在心里作个记号，记住这个总是做出危害大家行为的家伙，以后和他打交道的时候就会格外小心。

        你必须保护好团队的注意力和专注力

        不尊重别人的时间

        总会有一些人搞不清楚项目的状况，他们的危害通常是浪费团队的时间。他们宁可不断地拿那些很容易就能找到答案的问题去骚扰整个团队，也不愿意自己花点时间去读一读最基本的项目文档、任务宗旨、FAQ，或是最近的邮件讨论。

        我们在 Subversion 项目里就曾经碰到过这样一个人，他把开发主论坛当成了自己每天报流水账的地方。查理实际上没有贡献什么代码，但他每隔两三个小时就会发布自己最新的异想天 开。这样就无可避免地产生了很多回复，去解释为什么他的想法是不正确的，不可能的，已经在开发中了，之前已经讨论过了，或者是已经有文档记录了等。更糟糕 的是，查理甚至开始回答那些临时用户的问题，而且都答错了。这样，我们的核心成员只好不断地去更正他的回复。过了好久我们才反应过来，这位和蔼可亲的热心 人其实是好心办坏事，大家被他牵扯了太多的精力。本章稍后我们会讨论遇到这种情况的时候该怎么办。

        自负

        这里“自负”可能不是最恰当的词，我们想要表达的是那种无法接受多数人决议，无法倾听和尊重其他观点，以及不愿作出妥协的人。这种人常常会重新 挑起些早就已经结束（并且保留在邮件存档里）的讨论，仅仅是因为当时她不在场。这种人不肯去读存档，也压根不想去思考，她只会要求为了自己重启争论。她常 常会就项目的前途作出极端的评价，声称除非按照她的思路走，否则失败就在眼前。

        Subversion 就有过这么一段经历，当时有一名非常聪明的程序员出现在邮件列表里，声称产品的整体设计存在严重缺陷，而自己已经成竹在胸，有一些大刀阔斧的办法来纠正错 误，并且坚持项目应该整个推倒重来。他甚至还毛遂自荐希望能亲自领导重建工作，他宣称要是没有他的领导，项目随时都会有覆巢之险。

        项目的创始人浪费了整个星期的时间，和这个家伙无休止地争论，誓要捍卫自己最初的设计目标。所有的注意力和专注力都涣散了。这个人显然无意作出 任何妥协，也不想把自己的想法融入到现在的产品里，而项目（已经在公测阶段，拥有大量用户）也不可能重新来过。所以我们只能选择不再争论，回到自己的步调 上来。讽刺的是，多年以后，事实表明他的预言在很多方面都是对的，但这并不妨碍 Subversion 的巨大成功—至少在企业级的软件开发上 Subversion 做得很好。这里关键的地方不在于谁对谁错，而是能否和而不同，以及争论是否有继续的必要。一定要提醒自己注意这些问题，有时候你必须作出决定，舍弃一些东 西，继续向前。

        过分索求

        每当有陌生人跟你要求做什么的时候，一定要提高警惕。这样的人把所有的精力都用来抱怨软件功能不足，却不愿意自己动手作点贡献。

        有时候等天上掉馅饼的心态会演变成过激行为。在运营 Google 的项目托管服务时，我们就遇到过这样的例子，当时有一个项目作者要求我们封掉一个用户，因为他的所作所为实在是太讨厌了。这是一个开源的电视游戏模拟器项 目，而这个用户最喜欢的游戏却无法在上面正常运行，于是他在问题跟踪系统里提交了一个口气相当粗鲁的 bug 报告。开发人员礼貌地解释了那个游戏跑不起来的原因，还告诉他相当一段时间里可能都没办法修复那个问题，结果那个人接受不了，每天都来骚扰开发人员。他不 断地提交同样的 bug 报告，里面充斥着各种不满，还在其他 bug 报告里评论说拒绝修复他的问题的程序员是个“蠢货”。尽管项目人员和 Google 管理员屡次警告，他的用词却反而越来越不堪。不管我们怎么努力去消除他的这种破坏性行为，他就是冥顽不灵，万般无奈之下，我们只好祭出最后一招—彻底把他 封掉了。

        幼稚或是莫名其妙的交流

        这样的人不会用真名。他们常常会用一些幼稚的昵称，比如“SuperCamel”、“jubjub89”，或是“SirHacksalot”之 类。更糟糕的是，这样的人往往会在不同的地方用不同的昵称—E-mail 一个，即时消息里又是另外一个，可能提交代码的时候还有一个。更有甚者，你会看到他们用火星文、黑客语、全部大写，甚至含有大量标点符号的沟通方式！

        偏执妄想

        在上面的例子里我们看到，有时候不切实际要求会直接转变成对项目的恶意。我们无数次看到它彻底演变成偏执。当团队和访客的意见不一时，这种心怀 恶意的人就会抛出某种阴谋论。要是太把他当真，去花精力和时间反驳的话就实在是太滑稽了。而且如果你已经建立起一条开放透明的沟通渠道的话（正如我们在第 二章里所推崇的），这种指控只会显得更加可笑，因为所有的谈话内容都是有公开记录的。我们的建议是根本就不用去理会这种指控。当这种人真的做到这一步的时 候，你说什么都是没用的，既然这样干嘛还费这劲呢？还不如把时间用来写代码。

        完美主义

        乍看之下，完美主义者根本就是无害的。尽管时不时地会有一些奇怪的强迫症类型的行为出现，但是总体上这样的人都是谦虚有礼貌的，而且愿意倾听别人的意见，看起来满是快乐的 HRT 和良好的本意。那么问题出在哪里呢？答案就是太追求完美会变得瞻前顾后、犹豫不决。

        就拿我们以前的同事来举例吧。帕特里克是一名非常出色的工程师。他做的设计非常出色，代码和测试的质量也很高，人也非常容易相处。但是每当要设 计新软件的时候，他就会无休止地调整、改进自己的设计。他从不满足，好像永远也不会开始写代码一样。尽管他对我们所面临的问题有非常好的见解和洞察力，但 是团队里的其他成员最后都被折腾到不行。这样下去就没法工作了，我们几个考虑了很久要怎么办。一方面，对团队来说帕特里克是巨大的财富；另一方面，他也妨 碍了团队前进的步伐。每次我们打算开始编写代码的时候，他就会很有礼貌地否定我们的方案，指出其中只在理论上成立的潜在问题，而且都是一时半会不会产生什 么影响的问题，不知不觉中他让我们整个陷于瘫痪状态。在下一节里，我们会讨论该如何应对这种情况。

        对抗有害行为

        我们不鼓励仅仅因为别人有点反社会或是不太礼貌就把他们踢走。我们之前已经提过，拉帮结派地把我们（所谓的好人）和他们（所谓的坏人）对立起来 不是什么好主意。注意在之前的例子里，我们关注的不是批判人，而是批判“行为”。恶意的行为是不可容忍的，如果重复警告之下仍然没有改观，那么只有考虑正 式拒绝了。

        把精力都放在消除恶意行为上常常足以将一个聪明人（虽然可能不太擅长和人打交道）变成团队里的得力干将。几年前我们手下有一个非常出色的工程 师，但是他有一个致命的缺点，就是有时候会惹到团队里的其他人。我们没有直接轰走他，而是把他拉到一边问他有没有意识到自己的言论会让别人对他敬而远之。 他表现得很吃惊，完全不能理解为什么自己说的话会造成这种效果，但是答应说会调整自己以适应团队。事实证明效果非常好，随着他的转变，问题也就自然消失 了。并不是所有的故事都是悲剧收场的！

        好吧，你已经找到了害群之马，可能现在就有人在干扰或是牵扯团队的精力。怎么才能有效地对付这种情况呢？下面是一些行之有效的策略。

        转移完美主义者的注意力

        一旦找到解决问题的办法，哪怕不是最佳方案，但是只要够用，就应该把完美主义者的注意力放到其他问题上去。

        这个办法非常好用，Subversion 就是这样解决完美主义者的难题的。当时实在是没办法了，我们只好把帕特里克叫到一边，告诉他说：“我们决定以这个设计为起点开始工作，看看效果如何。希望 你能帮助我们继续解决在这个过程中出现的各种问题。”出人意料的是，帕特里克对此完全没有异议，转身就继续研究其他难题去了。气氛相当融洽，帕特里克也一 直在贡献自己的力量。

        俗话说，过犹不及。在打造高效团队的时候，一定要时时警惕不要过于追求完美，否则只会适得其反。

        这种转移注意力的办法用在那些花太多时间抱怨和批评的家伙身上也同样有效。有时候对这种人会忍不住回一句“随时欢迎提交补丁”—开源社区里让人 闭嘴的委婉说法，但其实不如引导他去正式参与软件的测试，说不定就能发现一些以前修复过的问题又重新出现。这样，虽然他还在发牢骚，但是会比较有建设性。

        别去搭理那些挑衅的家伙

        这是 Usenet 上流传的一句格言。这对任何蓄意捣乱的家伙来说是最好的手段—这种人会处心积虑地向你和你的团队挑衅。你回复得越多，他就越来劲，结果你就会浪费越来越多 的精力和时间。其实无视就是最好的办法。无论心里有多少警言妙语可以一句话就噎死他，都要克制这种冲动。当他发现没人理他的时候，自然就会意兴阑珊地离 开。忍住、不回应往往是需要很大的意志力的。坚持！

        别太感情用事

        人往往会很容易表现出防备的心态，不管别人是不是蓄意挑衅。当你被人骂说设计做得太烂，或是谋划什么阴谋，又或者浪费了太多时间去回答再简单不 过的问题的时候，的确是很让人郁闷的。但是别忘了，你的任务是写出漂亮的软件，没有义务讨好所有人，也不需要一再去证明自己存在的价值。你越是情绪化，就 越容易浪费宝贵的时间去写一些激昂的回帖，而那些都是不值得你关注的人。应战之前应该谨慎一点，时刻保持冷静，知道哪些人是值得回应的，哪些人是可以无视 的。

        抓住重点

        继续刚才的话题，保持理智的更深一层含义就是要学会抓住重点。一个人在抱怨、发泄情绪的时候，一定要认真听他说。虽然会夹杂一些愤怒和粗俗的 话，但是要相信对方本质上是没有恶意的。他说的到底有没有道理呢？我们是不是可以从他的经验里学到什么？他的想法是不是值得回应？很多时候答案都是肯定的 —那就是虽然他语言上有点刻薄，但背后其实是有亮点的，所以应该尽量把争执再次引向技术讨论。

        我们团队在这一点上做得非常叫人自豪。只要保持绝对冷静，一切以事实说话，发帖人就自然会随着交谈的深入而显得疯狂可笑。到最后没人会相信他说的话，他脸皮再厚也混不下去了。

        对付挑衅要不卑不亢

        除了上面提到的办法（就是保持冷静，摆事实，讲道理），有时候连礼貌也可以拿来当武器吓走敌人！这里是一段 Subversion 在 IRC 频道里的真实记录。

        哈里：Subversion 太烂了，完全用不了。

        萨斯曼：有问题可以问我啊。

        哈里：我想要 cvs 一下某个人的文件。不对，我要抗议一下。那家伙用的是一种叫 Subversion 的东西，他用 svn，不是 cvs。

        萨斯曼：你可以装一个 svn 客户端，然后检出他的代码。

        哈里：所以我就去下了一份 Subversion 啊……结果你以为它可以像 cvs 那样 configure make make install 吗？当然不行。比起 subversion 的人，我怪他比较多。

        萨斯曼：（你）没办法 ./configure; make; make install 不代表软件有严重 bug。每天都有无数人从 svn 源码包编译编译软件。

        哈里：我可没说有 bug。

        萨斯曼：你觉得我们会发布一个像这样的有严重问题的源码包吗？

        哈里：我只是要骂一下这个垃圾（软件）。居然还要我装 expat 和 libxml。（叹气）

        萨斯曼：这些软件在大多数系统上都是预装的。

        萨斯曼：那个人用的是 apache 服务器吗？说不定你只要下载一份编译好的版本就可以了。

        哈里：我不知道，他就说了 svn 而已……

        萨斯曼：你用的是什么发行版？

        哈里：FreeBSD

        萨斯曼：其实你直接到 ports 里去 make 一份就可以了。

        哈里：碰到你我什么脾气都没了……我上来是想要吵架发泄的……你也太和蔼可亲、热心助人了吧。

        萨斯曼：:-)

        哈里：什么时候开始 IRC 频道变成一个这么和谐的地方了？算了不说了。

        哈里退出了频道。

        知道什么时候应该放弃

        有时候，当无论怎么努力都是徒劳的时候，你就应该果断放弃，继续向前。就算你已经花费了大量的精力去纠正有害行为，也要学着去承认失败。

        让我们回到查理的故事，这位友善的哲学家在 Subversion 的邮件列表里发了太多的帖子。我们对所有的讨论做了一个统计，发现他在两个月之内挤进了发帖量的前三名。前两名都是项目的核心，而且他们 70% 的帖子都是在回复查理！尽管查理本身没有恶意，但显然我们的精力和注意力都被吸走了。最后我们只好私底下给他发了一封E-mail，（礼貌地）请求他不要 再这样频繁地发帖。这段谈话进行得很艰难，主要是因为他没有意识到自己造成了多大的干扰。可是几个星期之后情况仍然没有改观，我们的一个同事只好给他打电 话，好好地和他谈了一次（这样的谈话难度更大），要求他彻底停止发帖。最终他还是接受了，虽然有一点难过和不解，但仍然尊重了团队的意愿。大家都觉得有点 内疚，因为他一直都没能理解自己到底做了什么，但是大家也觉得这么做是正确的。要解决好这种事情是很微妙的，我们只有谨守 HRT 的原则才能处理得当。

        关注长远

        通向成熟软件产品的道路上有无数的干扰。要是说在对付害群之马所带来的干扰时最常见的情景是什么，那肯定就是太容易被当时的情况所吸引了。如果你发现了所谓的有害行为，一定要问自己两个关键的问题：

• 虽然短期之内会损失一些注意力和专注力，长远来讲你真的相信项目会因此受益吗？
• 你相信这些冲突最终会以有益的方式解决吗？

        把注意力放在重要的地方，不要被眼前的东西迷惑

        只要任何一个回答是“不”，你就应该果断介入，中止那种行为。虽然人们常常会自我安慰说暂时忍耐一下换取短期利益是值得的，但其实事实并非如 此：例如，有人或许在技术上贡献良多，可仍然会做出一些有害团队的行为，这时往往就会为了那点技术上的优势而选择对他睁一只眼闭一只眼。但是这时候千万要 三思！HRT 的氛围是无可替代的，而再强的技术也是可以替代的。我们以前有一位同事这样说道：

我有不少朋友都认识他。其中有一个是这样说的，“他常常游走在天才和疯子之间。可问题是，现在天才已经不稀奇了，没人会因此接受这样举止古怪的人了”。—格雷格·哈德森

        这里格雷格说的不是通常意义上的“天才”，他的意思是这个世界上有的是合格的程序员。如果你发现有人在长远来讲会威胁到团队的文化，那么不妨再等另一个出现。

        我们在 Subversion 项目里就曾经遇到过这样的情况。团队有严格规定，不准把名字写到源文件里（这一条我们在第二章里就讨论过了），我们觉得做只会产生领地感。如果代码里有别 人的名字，修改的时候会觉得有点担忧，而且这么做还会人为地降低公车因子。所以在版本控制的记录里认可大家的贡献才是比较恰当的做法，我们在项目的根目录 里放了一个这样的文件，里面有所有贡献者的名字。

        有一天，来了一个非常聪明的程序员，主动写了一个所有人都想要的新特性，工作量还不小。在他提交代码审查的时候，我们只是要求他删掉文件开头的 名字—我们会在和别人一样的地方感谢他的贡献。可是他拒绝了，谈判陷入了僵局。最后，大家决定拒绝接受他的代码，他带着自己的玩具离开了。虽然大家都很失 望，但是我们不愿意仅仅是为了能快点得到新特性，就打破自己的规矩（进而放弃自己的传统）。几个月之后，就有其他人重新实现了这个特性。

        在这里要再次明确强调：为了短期利益而打破规矩不值得—特别是对于那些不懂得尊重 HRT 重要性的家伙来说，再大的天才也没用。

        小结

        我们讨论了很多场景，说到最后似乎会产生一种偏执的感觉。但是别忘了，这个世界里混蛋其实并不多。正如罗伯特·J·翰龙所说的：

        不要把用愚蠢可以解释的行为归结为恶意的。

        这里我们更倾向用“无知”而不是“愚蠢”，但是基本思想还是一样的。就像我们在一开始提到的，把人简单地分成好和坏是很幼稚的。没有什么坏人处 心积虑地想要毁掉你的文化—大多数人只是被误导了而已；又或者只是想要得到认可，同时又不太擅长与人交际罢了。不管怎么样，你的任务不是要培养傲慢的态 度，把那些没有那么聪明的普通人赶出项目；你的任务是拒绝容忍毁灭性的行为，明确自己对 HRT 的期望。有智慧的人才能体会其中的差别，而有能力的人才能真正予以执行。

        本文选自《极客与团队》一书，作者 Brian W. Fitzpatrick Ben Collins-Sussman，徐旭铭译，由人民邮电出版社出版发行。