來源：infoq
開發團隊是一個整體，穩定的、溝通無礙的團隊文化非常重要。好的文化氛圍應該包括基於共識決策的開發模式、高質量的程式碼、程式碼審查，以及能讓人放心嘗試新事物或者快速失敗的環境。Brian和Ben是Google的兩位開發主管，他們在《極客與團隊》書中列舉了軟體開發團隊的典型不良行為，提醒開發者時刻保持警惕，並提出了一些實際的解決辦法。
Brian和Ben指出，團隊的注意力和專注力是最容易受到威脅的。團隊規模越大，編寫軟體和解決有趣問題的能力就越強—不過這種能力畢竟是有極限的。要是你不去主動保護它們，很容易就會被害群之馬引入歧途。團隊最終會爭論不休，變得心煩意亂、身心疲憊。所有人都會把注意力和專注力放到那些編寫優秀軟體以外的事情上去。
根據我們的經驗，很少會有人故意幹壞事（也就是存心搗亂的那種）。我們管這種行為叫作“釣魚”，通常無視這種人就可以了。而大多數人在行為出格的時候，要麼是沒有意識到自己過分了，要麼就是根本不在乎別人的感受。無知和冷漠其實比蓄意更嚴重。
他們列舉了一些典型的不良行為。第一條就是不尊重別人的時間 ，總會有一些人搞不清楚專案的狀況，他們的危害通常是浪費團隊的時間。他們寧可不斷地拿那些很容易就能找到答案的問題去騷擾整個團隊，也不願意自己花點時間去讀一讀最基本的專案文件、任務宗旨、FAQ，或是最近的郵件討論。 這裡有一個現實當中的例子：
我們在Subversion專案裡就曾經碰到過這樣一個人，他把開發主論壇當成了自己每天報流水賬的地方。查理實際上沒有貢獻什麼程式碼，但他每隔兩三個小時就會發布自己最新的異想天開。這樣就無可避免地產生了很多回復，去解釋為什麼他的想法是不正確的，不可能的，已經在開發中了，之前已經討論過了，或者是已經有文件記錄了等。更糟糕的是，查理甚至開始回答那些臨時使用者的問題，而且都答錯了。這樣，我們的核心成員只好不斷地去更正他的回覆。過了好久我們才反應過來，這位和藹可親的熱心人其實是好心辦壞事，大家被他牽扯了太多的精力。
第二條是自負，這裡“自負”可能不是最恰當的詞，Brian和Ben想要表達的是那種無法接受多數人決議，無法傾聽和尊重其他觀點，以及不願作出妥協的人。這種人常常會重新挑起些早就已經結束（並且保留在郵件存檔裡）的討論，僅僅是因為當時她不在場。這種人不肯去讀存檔，也壓根不想去思考，她只會要求為了自己重啟爭論。她常常會就專案的前途作出極端的評價，聲稱除非按照她的思路走，否則失敗就在眼前。
過分索求是另外一種不良行為。每當有陌生人跟你要求做什麼的時候，一定要提高警惕。這樣的人把所有的精力都用來抱怨軟體功能不足，卻不願意自己動手作點貢獻。有時候等天上掉餡餅的心態會演變成過激行為。在運營Google的專案託管服務時，Brian和Ben就遇到過這樣的例子:
當時有一個專案作者要求我們封掉一個使用者，因為他的所作所為實在是太討厭了。這是一個開源的電視遊戲模擬器專案，而這個使用者最喜歡的遊戲卻無法在上面正常執行，於是他在問題跟蹤系統裡提交了一個口氣相當粗魯的bug報告。開發人員禮貌地解釋了那個遊戲跑不起來的原因，還告訴他相當一段時間裡可能都沒辦法修復那個問題，結果那個人接受不了，每天都來騷擾開發人員。他不斷地提交同樣的bug報告，裡面充斥著各種不滿，還在其他bug報告裡評論說拒絕修復他的問題的程式設計師是個“蠢貨”。儘管專案人員和Google管理員屢次警告，他的用詞卻反而越來越不堪。不管我們怎麼努力去消除他的這種破壞性行為，他就是冥頑不靈，萬般無奈之下，我們只好祭出最後一招—徹底把他封掉了。
除此之外，還有兩種行為需要警惕：
- 幼稚或是莫名其妙的交流——這樣的人不會用真名。他們常常會用一些幼稚的暱稱，比如“SuperCamel”、“jubjub89”，或是“SirHacksalot”之類。更糟糕的是，這樣的人往往會在不同的地方用不同的暱稱—E-mail一個，即時訊息裡又是另外一個，可能提交程式碼的時候還有一個。更有甚者，你會看到他們用火星文、黑客語、全部大寫，甚至含有大量標點符號的溝通方式！
- 偏執妄想——在上面的例子裡我們看到，有時候不切實際要求會直接轉變成對專案的惡意。我們無數次看到它徹底演變成偏執。當團隊和訪客的意見不一時，這種心懷惡意的人就會丟擲某種陰謀論。要是太把他當真，去花精力和時間反駁的話就實在是太滑稽了。而且如果你已經建立起一條開放透明的溝通渠道的話，這種指控只會顯得更加可笑，因為所有的談話內容都是有公開記錄的。我們的建議是根本就不用去理會這種指控。當這種人真的做到這一步的時候，你說什麼都是沒用的，既然這樣幹嘛還費這勁呢？還不如把時間用來寫程式碼。
最後一條是完美主義。乍看之下，完美主義者根本就是無害的。儘管時不時地會有一些奇怪的強迫症型別的行為出現，但是總體上這樣的人都是謙虛有禮貌的，而且願意傾聽別人的意見，看起來滿是良好的本意。那麼問題出在哪裡呢？答案就是太追求完美會變得瞻前顧後、猶豫不決。現實當中的例子：
帕特里克是一名非常出色的工程師。他做的設計非常出色，程式碼和測試的質量也很高，人也非常容易相處。但是每當要設計新軟體的時候，他就會無休止地調整、改進自己的設計。他從不滿足，好像永遠也不會開始寫程式碼一樣。儘管他對我們所面臨的問題有非常好的見解和洞察力，但是團隊裡的其他成員最後都被折騰到不行。這樣下去就沒法工作了，我們幾個考慮了很久要怎麼辦。一方面，對團隊來說帕特里克是巨大的財富；另一方面，他也妨礙了團隊前進的步伐。每次我們打算開始編寫程式碼的時候，他就會很有禮貌地否定我們的方案，指出其中只在理論上成立的潛在問題，而且都是一時半會不會產生什麼影響的問題，不知不覺中他讓我們整個陷於癱瘓狀態。
Brian和Ben提出了一些實際的解決辦法：
- 寫一份明明白白的任務宗旨。這樣可以隨時保持專注，知道哪些是目標，哪些不是。
- E-mail討論要有禮儀。保留歸檔，要求新人研讀，防範那些“嘈雜的少數人”。
- 所有歷史都要有記錄。這不單指程式碼歷史，還有設計決策、重要的bug修復，以及過去犯下的錯誤。
- 有效地進行協作。利用版本控制，程式碼改動要儘可能的小，方便進行審查，擴大“公車因子”，避免出現領地感。
- 修復bug，測試，釋出軟體要有清晰的政策和流程。
- 降低新人加入時的壁壘。
- 依賴基於共識決策，在無法達成共識的時候也要準備好化解矛盾的方法。