如何對付團隊中的“害群之馬”

        文/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，徐旭銘譯，由人民郵電出版社出版發行。