怎樣能促使技術團隊實現高效、緊密的合作？該如何處理團隊中的“壞蘋果”？知名技術博客作家、Stack Overflow創始人Jeff Atwood有三十多年的職業編程經驗，通過他的切身經歷分享，幫助讀者成長為高效能程序員。
今天你開了多少個會？這個星期呢？這個月呢？再自問一下，那些會議中有多少是值得參加的？如果把相同的時間用在工作上，你又能完成多少事情？我們究竟為什么要開會？
盡管有些會議是不可避免的，甚至是必需的。我們應該以懷疑的態度去看待會議，把它當成是一種降低工作效率的風險。事實上，會議往往只是在浪費寶貴的工作時間。就我而言，我采用以下幾個原則，以確保我的會議是真正有用的。
對于任何會議，第一個并且最重要的約束就是時間，因為它在任何公司都是最寶貴的資源。如果你不能把會議限制在大約一個小時內，那一定是有什么事情錯得離譜了。你應該首先修正這個錯誤。
可能是會議牽涉了太多的人，也可能是會議討論的范圍太寬泛了，或者就是整體上缺少一個能使會議不偏離軌道的必要的焦點。我不相信有人可以記住在長達幾個小時的會議里發生的任何事情。當其他的一切都無法做到時，請至少把會議開得簡短些！
你開會要達到什么目標？你能用簡潔的一句話來說明你召集會議的目的嗎？我不想推薦你使用“議事日程”和“日程事項”，因為“議事日程”這個詞暗示著一個巨大而乏味的分項列表——包含太多事情了！只要確保每個人都很清楚會議的目的，剩下的事自然會水到渠成。
既然你的會議有了一個清晰的目標聲明，那么每個與會者都應該提前知道他們將要討論和分享的內容，并且在走進會議室之前都已做好了準備。只有這樣，我們才能把會議控制在一個小時之內。如果你沒有預先做好功課，你就不應該參加這個會議。如果沒有任何人做功課，那么這個會議就應該被取消。
“強制”的會議是站不住腳的。每一個出現在會議上的人都應該是因為他們想要在那里，或者他們需要在那里。一種讓你自己對會議負責的可靠方法就是讓每個人自行決定是否要參加你的會議。想象一下舉行一次大家都真正想要參加的會議，那一定是因為真的很有用，或者很有趣，或者很娛樂。
假設你的會議從未召開過，會有什么后果呢？如果你誠實地回答“幾乎沒什么后果”，那么也許你的會議根本就沒必要開。任何一個真正有成效的會議都會做一些決定，然后就直接導致某些事情的發生。
作為一個負責任的與會者，你應該把你需要做的事情都記錄下來，而且為了表明大家的責任心，參加會議的每個人最好在離開會議室之前都概括一下他們的待辦事項，這樣做對所有人都是有益的！
我們必須認識到會議固有的風險，并且努力使我們必須要開的為數不多的會議開得更有效率。讓我們快速干活，少說廢話，抓住工作的重點。
Robert Mieson發來了個關于項目病理學的故事。
我所在的團隊曾經開發過一個基于互聯網的職位申請以及篩選系統（客戶稱之為“職位零售亭”）。我們的團隊和客戶商定了采用Windows、Apache、PHP5和ZendFramework來實現這個“職位零售亭”——所有的團隊成員都達成了一致意見，除了一個人，我在這里就叫他“Joe”。
在整個技術審議階段，Joe不停地鼓吹采用JavaScript，即便客戶很明確地表示他們希望“職位零售亭”的絕大部分實現都采用服務器端技術，并且所有的校驗都應該采用服務器端技術來完成。
事實上，客戶已經就這個問題簽字確認了。然而，這沒能阻止Joe鼓吹JavaScript——他的方式還很粗暴。每當我們的項目在前進的道路上遇到點麻煩，Joe就會發表他的長篇大論。他宣揚，如果我們采用了JavaScript來實現這個“職位零售亭”，我們的日子就會輕松很多。
Joe會不停地吵吵嚷嚷，說我們如何如何完全做錯了，因為我們沒有采用JavaScript。他甚至不屑于了解我們實際正在使用的技術。而且每當團隊中有人試圖溫和地把Joe帶回到大部隊時（通常通過電子郵件的方式），他就會沖著那個可憐的家伙大發雷霆。
以Joe這種力挺JavaScript到了偏執的程度，他經常會發出諸如“好吧，如果我們用JavaScript來做的話……”之類的評論。他已經令人討厭到了這種程度，以至于如果他直接退出（或者辭職，或者被解雇），整個項目組的境況將會更好。
讀完這個故事后，我努力克制自己的身體不往前傾。我把手放在下巴下做沉思狀，皺著眉頭，然后想問問：你們試過用JavaScript嗎？
Robert認為這是一個關于技術依賴的警示性故事，但我看到了另外的一些東西：一個有問題的團隊成員，也就是一個典型的“壞蘋果”。如果把一個壞蘋果留在一筐好蘋果里，結果你將得到一筐壞蘋果，這就是“壞蘋果法則”。一個人的態度將影響到一個團隊。如果想使你的企業成功，那么你就必須有一個積極進取的團隊。
我相信Joe曾經有過最好的意圖，但當你積極地對項目宣戰并以你的團隊成員為敵時，你就成了項目的一個負擔。
問題員工對于項目的損耗是很嚴重的，我們應該如何識別問題員工呢？這并不像想象的那么困難。我有一個朋友曾經把他團隊中的某個人比喻成“癌癥”。當你或者團隊中的任何其他人使用像“癌癥”這樣一個詞來比喻某個團隊成員時，你的項目就已經有嚴重的病變了。你不必和團隊中的每個人都成為朋友，當然那有一定的幫助，但對個人和職業一定程度的基本尊重才是任何團隊正常運轉所必需的。
Steve McConnell列舉了一些警報信號，用以識別你的團隊中是否有“壞蘋果”。
他們掩飾自己的無知，而不是盡力去向他們的團隊伙伴學習。他們會說：“我不知道該怎么解釋我的設計。我只知道它能正常工作。”或者“我的代碼太復雜了，沒辦法測試。”
他們對個人隱私有著過度的渴望。他們會說：“我不需要任何人來查看我的代碼。”
他們很在意自己的地盤。他們會說：“我代碼里的問題沒人能修復。但我現在太忙了，沒時間去管它們。我打算下周處理它們。”
他們抱怨團隊所做的決定，并且在團隊已繼續前進了很久之后還會重拾舊題。他們會說：“我還是認為，我們應該回過頭去修改上個月討論的那個設計。我們當初選擇的那個是行不通的。”
所有其他的團隊成員都在傳說關于同一個人的俏皮話或者抱怨他。軟件開發人員通常不會直接抱怨，因此當你聽到很多俏皮話時，你必須去查探是否有什么狀況發生。
他們不會積極投入團隊的行動。在我經歷的一個項目中，就在我們第一個重要的截止日期的前兩天，有個開發人員突然要求請一天假。原因是什么呢？他想那天去參加鄰城的一個男裝展銷會——那清晰地表明他并沒有融入整個團隊。
讓我把我的觀點說得清清楚楚：如果你的團隊主管或者經理沒有處理項目中的“壞蘋果”，那他就是玩忽職守。
你絕不應該害怕去調動（甚至解雇）那些從內心不為團隊利益考慮的人。你可以培養一個人的技能，但很難培養出積極的態度。這些具有破壞性的人格在一個項目里逗留得越久，它們的影響就會越大。它們會以代碼、關系和交流的形式，慢慢地把毒害傳播到項目的每一個角落。
把某個人從團隊中調走是很痛苦的。這件事對任何人來說都沒有趣。但當你意識到你本應該在六個月前就把某人調走時，此時你就更加痛苦了。
有一期《美國生活》采訪了華盛頓大學的一位教授Will Felps，他曾經組織過一次社會學實驗來證明“壞蘋果”出奇強大的影響力。
大學生們每4人一組，組建了幾個團隊，并被指派了一個任務：在45分鐘之內完成一些基本的管理決定。為了激勵團隊，他們被告知，表現最好的那個團隊每人都能得到100美元的獎勵。
然而，他們始料未及的是，其中某些組里的第四位成員并不是學生。他們是被雇來扮演“壞蘋果”的演員，并且具備下面其中之一的性格。
沮喪的悲觀主義者。他會抱怨任務太無趣，并且公開質疑團隊的取勝能力。
混球。他會說其他人的想法不夠好，但自己又拿不出更好的方案。他還會說：“你們這些人都應該聽我這個專家的。”
懶鬼。他會說“隨便”以及“我無所謂”。
對于實驗中的這些人物性格，傳統的觀點認為它們完全不會對團體有太大的影響。團體是強有力的，“團體動力”是強大的，因此團體應該主導個人，而不是反過來。如果追溯到幾十年以前，有太多的研究表明，個人是遵從團體的價值觀和準則的。
但是，Will Felps發現了相反的結果。
毫無疑問，有“壞蘋果”的團隊會表現得比較差。盡管他們所在的有些團隊非常有天賦、非常聰明、非常友愛，但這些都無濟于事。Will Felps發現“壞蘋果”的行為有著深刻的影響——有“壞蘋果”的團隊比其他團隊表現得差30%～40%。在有“壞蘋果”的團隊中，人們會爭吵甚至打起來，他們沒有共享相關的信息，交流得也比較少。
更糟糕的是，其他團隊成員開始呈現“壞蘋果”的特征。當“壞蘋果”是一個混球時，其他團隊成員也開始表現得像混球。當他是一個懶鬼時，他們也開始懈怠。而且他們不只是針對“壞蘋果”才有這樣的反應。他們相互之間也會像“壞蘋果”那樣彼此對待，足見“溢出效應”在起作用。
簡而言之，他們的發現就是，團隊的績效可以從團隊里最差的那位成員身上準確地預測出來。不管團隊里最好的成員有多棒，也不管團隊里的普通成員怎么樣，這些都無關緊要。根本的決定因素是要看團隊里最差的那位成員怎么樣。擁有最差成員的團隊也會表現得最差勁。
自我認知永遠都是第一步。如果你不能判斷出誰是團隊里的“壞蘋果”，那他有可能就是你自己。反思一下你在自己團隊里的行為吧——你是否“失足”掉進了這些負面的“壞蘋果”行為模式，哪怕只有一點點？最顯然的解決辦法是從源頭上解決問題——除掉害群之馬。
即使你自己就是那匹害群之馬！
更多信息歡迎登陸3W點SOIROC點COM
