程序員應知 團隊精神
寫在前面：前幾天終于看完了《團隊之美》這本厚厚的書，里面敘述了與團隊相關的點點滴滴，當然也包括如何創建并維護優秀的團隊。讓我更深地領略到團隊精神在現在的開發中的重要性。感觸很多，收獲很多，寫在這里與大家一起分享。
大家都知道，現在的軟件開發已經不再是20年前個人英雄主義的時代，一個超級程序員就能夠搞定一切的情況已經很少存在了。更多的情況是我們都是以團隊的形式進行系統的設計和開發，因此，團隊精神也變得越來越重要。
早在我剛剛畢業要踏入到軟件開發這個行業的時候，就在自己的簡歷里面寫到：具有很強的團隊精神。然而，說句實話，當時對這個詞的理解真的不是那么透徹，只是覺得人緣好，和別人合得來，就叫做有團隊精神。然而，隨著工作的年頭越來越多，經歷過各種不同的團隊，也帶領過不同的團隊，漸漸地，對于“團隊精神”的體會也越來越深，也越來越覺得并非那么簡單。
那么到底什么是團隊精神呢，我覺得它包括了下面這些特點：
- 榮辱與共
- 交流分享
- 精誠協作
- 尊重理解
下面讓我分別結合自己多年來的工作經歷談下自己的理解，與大家共享，同時也說說自己理想中的團隊的樣子。
榮辱與共
作為一個團隊中的成員，就要把整個團隊的榮辱放在***位，這似乎是集體主義精神的體現，與當前更為流行的個人為中心的思想有些格格不入，但是，只有把整個團隊的利益放在首位，團隊才能夠發展和進步。而團隊的發展和進步必定會給其中的每個成員帶來好處。
在這里我要說個很典型的情況，在團隊中一般都會有開發人員和質量管理人員（也就是我們常說的測試人員），一般來說這兩種角色都是冤家。前者非常怕后者測試的時候測出無數的問題，而后者經常會經常抱怨說“你自己測沒測試啊”。似乎二者之間總是有著不可調和的矛盾。
想要解決這個問題，其實很簡單，就是要明確榮辱與共這條原則，開發人員的目的是想要高效高質的開發出程序，這首先就要對自己提高要求，如果開發出來的程序質量不高，那么必然會返工修改，似乎當時是節省了自己的時間，盡快地把程序提交上去了，但實際上，自己后來還需要修改，節省的時間還要再找回來，另一方面，還需要測試人員指出低級的問題，（那些問題只要再稍微細心一些就能夠避免），也會浪費測試人員的時間，結果對于團隊來說，就花費了兩份時間。如果能夠想到為團隊節省時間的話，也就會自覺地提高自己程序的質量了。
而對于質量管理人員來說，首先當然要仔細地測試，不可敷衍了事，那樣的確可以節省自己的時間，而且容易和開發人員搞好關系，但是必定會導致程序質量的下降。而對于客戶來說，質量才是程序的生命線。其次，不可以因為自己發現很多缺陷就沾沾自喜，的確這意味著作為質量管理人員，工作做得很到位，但是我們的目的是什么呢？并非是要找到更多的缺陷，而是要想辦法提高系統整體上的質量。
我想我們大可以將缺陷總結分類，然后將自己的分析結果提交給整個團隊，指出在哪些地方比較容易犯錯誤，那樣不僅整個團隊的開發質量得到了提高，也節省了自己以后工作的時間，只不過是不會總是找到那么多的缺陷了。
交流分享
交流在任何工作中都是非常重要的，人和人之間只有充分交流，才能夠更好地工作。這些交流不能僅僅限于開發人員之間，團隊之中每個人之間都應該充分的交流，否則就會在信息的傳達過程中出現理解上的偏差。比方說，如果上游工程（需求分析、概要設計）的負責人不和下游工程（詳細設計、編碼、測試）的人員充分交流，那么很可能會得到最終用戶這樣的評價：你們所做的東西不是我要的。這就是由于信息在傳達的過程中發生了偏差，失之毫厘謬以千里，導致了最終客戶對團隊的惡評。
團隊的成員應該成為朋友。也許這在現在的職場之中，很難得到認同，甚至還聽到有人說過，不要把同事當成朋友，但是我不以為然，畢竟我們很多的時間都是與同事一起度過的，很多東西需要和同事一起承擔、一起分享。如果不是朋友的話，沒有最起碼的信任，怎么做事兒呢？的確，有些同事會不值得做朋友，那么就應該去找到值得做朋友的人，或者在組建團隊的時候就要慎重地挑選所有的成員，盡量讓大家都成為朋友，那樣才更有利于工作的開展。
分享意味著什么呢？我覺得它意味著共同進步，知識要分享，經驗要分享，好吃的，好玩兒的都要分享。這也應該是大家成為真正的朋友的前提吧。尤其是知識和經驗的分享，對于組建學習型的團隊非常重要。而最有效的形式，就是在固定的期間內舉辦技術交流會，團隊的所有人盡可能地參加，大家可以把自己工作學習生活中所發現、所學到的知識分享出來，這樣不僅僅有利于大家共同提高，也有利于解決工作中的各種問題。而這也是我一直在致力推行的一種方式，盡管最近有些障礙，呵呵。
精誠協作
想要達到這一點，首先就不要“事不關己，高高掛起”。盡管有些事兒不是我們份內的事情，但是團隊的事情，我們都應該有責任盡自己所能去做。有人會說，做得多，錯就多，幫別人修改了程序，當這個程序出問題的時候，就會怪罪到自己的頭上。這種情況的確存在，我也遇到過多次，但是我更珍惜的是在這個過程中和其他團隊成員的交流以及所學習到的知識。任何事兒都不可能是***的，都具有兩面性。而且這樣做非常有利于形成真正意義上的團隊，當出現問題的時候，我們幫助過別人，當我們自己出現問題的時候，也就會有人幫我們。
也有人會說，讓一個人做別人的工作，修改自己不熟悉的程序，風險會比較高，很可能會出現其他的問題。的確這種情況也存在，因此在涉及到業務領域知識的時候要謹慎，復核一下也是非常必要的。而對于純技術的問題，就不存在這種問題了，一個項目中的程序都應該是風格統一的，程序員彼此之間應該可以互相閱讀和修改程序。
另外，協作要體現在整個團隊之中，需求分析人員、設計人員、開發人員、測試人員之間都要協作。在做自己的工作的時候，都要為別人著想，考慮如何才能夠更有利于讓別人也順利開展工作。
尊重理解
人都有長處，都有短處。這是肯定的，沒有誰能夠是***的，何況生活中不僅僅是工作，還有很多其它的事情也會對工作造成影響。因此在發現別人犯錯的時候，應該去理解，并且以對事不對人的態度去解決問題。
比方說，測試人員發現開發人員程序中出現了很多缺陷，那么不應該去指責，而是應該記錄下來，然后和開發人員一起分析，提醒他以后不要出現類似的錯誤。
再比方說，當開發人員發現設計人員的設計出現了問題，那么就應該去商量，找到更好的解決方案。
再比方說，設計人員發現最終的程序與自己的本意有出入，也應該去溝通，而不是強硬地要求別人重新編寫代碼，而應該找到為什么會出現這樣的問題，從而去避免以后理解上出現歧義。
多一份尊重，多一份理解，才能夠更好地溝通，才能夠更好地協作。
我想，如果做到了上面的四點，我們應該建立起一個比較優秀的團隊，然后接下來要做的就是保持團隊的穩定，并且在一個又一個的項目的磨練中不斷地增進團隊的凝聚力和向心力，并且越來越好地根據每個人的能力來分配工作，做到人盡其用，這樣團隊的工作效率會越來越高，完成任務的質量也會越來越好。
創建一個理想的團隊，需要很長的時間，需要團隊成員彼此之間不斷地磨合、理解和包容，所以，在創建團隊之前，要確保團隊成員的穩定性，同時，對于人員的增減，都要慎之又慎，必須是完全理解和贊成團隊文化，并且能夠為團隊做出貢獻的人，才會加入到團隊中來。
上面所述的團隊非常理想化，想要真正實現會很困難，而且保持下去更困難，我們要做的也不是一口吃個胖子，一下子就建立一個超級團隊，而是要在創建團隊的時候就有自己的原則，并且根據這些原則不斷地對團隊進行改善和建設。
p.s. 這篇文章在我的草稿箱里面待了很長一段時間，一直在對其中的內容考慮來考慮去，生怕誤導了大家。不過“丑媳婦早晚要見公婆的”，所以還是在修訂了之后，拿出來與大家分享，大家有什么意見，只管提出，希望和大家一起討論。
原文地址：http://blog.csdn.net/lingyun2005/archive/2010/08/09/5797890.aspx
【編輯推薦】
