程式設計師應知——團隊精神

大家都知道，現在的軟體開發已經不再是20年前個人英雄主義的時代，一個超級程式設計師就能夠搞定一切的情況已經很少存在了。更多的情況是我們都是以團隊的形式進行系統的設計和開發，因此，團隊精神也變得越來越重要。

    早在我剛剛畢業要踏入到軟體開發這個行業的時候，就在自己的簡歷裡面寫到：具有很強的團隊精神。然而，說句實話，當時對這個詞的理解真的不是那麼透徹，只是覺得人緣好，和別人合得來，就叫做有團隊精神。然而，隨著工作的年頭越來越多，經歷過各種不同的團隊，也帶領過不同的團隊，漸漸地，對於“團隊精神”的體會也越來越深，也越來越覺得並非那麼簡單。

    那麼到底什麼是團隊精神呢，我覺得它包括了下面這些特點：

榮辱與共
交流分享
精誠協作
尊重理解
    下面讓我分別結合自己多年來的工作經歷談下自己的理解，與大家共享，同時也說說自己理想中的團隊的樣子。

 

榮辱與共

    作為一個團隊中的成員，就要把整個團隊的榮辱放在第一位，這似乎是集體主義精神的體現，與當前更為流行的個人為中心的思想有些格格不入，但是，只有把整個團隊的利益放在首位，團隊才能夠發展和進步。而團隊的發展和進步必定會給其中的每個成員帶來好處。

    在這裡我要說個很典型的情況，在團隊中一般都會有開發人員和質量管理人員（也就是我們常說的測試人員），一般來說這兩種角色都是冤家。前者非常怕後者測試的時候測出無數的問題，而後者經常會經常抱怨說“你自己測沒測試啊”。似乎二者之間總是有著不可調和的矛盾。

    想要解決這個問題，其實很簡單，就是要明確榮辱與共這條原則，開發人員的目的是想要高效高質的開發出程式，這首先就要對自己提高要求，如果開發出來的程式質量不高，那麼必然會返工修改，似乎當時是節省了自己的時間，儘快地把程式提交上去了，但實際上，自己後來還需要修改，節省的時間還要再找回來，另一方面，還需要測試人員指出低階的問題，（那些問題只要再稍微細心一些就能夠避免），也會浪費測試人員的時間，結果對於團隊來說，就花費了兩份時間。如果能夠想到為團隊節省時間的話，也就會自覺地提高自己程式的質量了。

    而對於質量管理人員來說，首先當然要仔細地測試，不可敷衍了事，那樣的確可以節省自己的時間，而且容易和開發人員搞好關係，但是必定會導致程式質量的下降。而對於客戶來說，質量才是程式的生命線。其次，不可以因為自己發現很多缺陷就沾沾自喜，的確這意味著作為質量管理人員，工作做得很到位，但是我們的目的是什麼呢？並非是要找到更多的缺陷，而是要想辦法提高系統整體上的質量。我想我們大可以將缺陷總結分類，然後將自己的分析結果提交給整個團隊，指出在哪些地方比較容易犯錯誤，那樣不僅整個團隊的開發質量得到了提高，也節省了自己以後工作的時間，只不過是不會總是找到那麼多的缺陷了。

 

交流分享

    交流在任何工作中都是非常重要的，人和人之間只有充分交流，才能夠更好地工作。這些交流不能僅僅限於開發人員之間，團隊之中每個人之間都應該充分的交流，否則就會在資訊的傳達過程中出現理解上的偏差。比方說，如果上游工程（需求分析、概要設計）的負責人不和下游工程（詳細設計、編碼、測試）的人員充分交流，那麼很可能會得到終端使用者這樣的評價：你們所做的東西不是我要的。這就是由於資訊在傳達的過程中發生了偏差，失之毫厘謬以千里，導致了最終客戶對團隊的惡評。

    團隊的成員應該成為朋友。也許這在現在的職場之中，很難得到認同，甚至還聽到有人說過，不要把同事當成朋友，但是我不以為然，畢竟我們很多的時間都是與同事一起度過的，很多東西需要和同事一起承擔、一起分享。如果不是朋友的話，沒有最起碼的信任，怎麼做事兒呢？的確，有些同事會不值得做朋友，那麼就應該去找到值得做朋友的人，或者在組建團隊的時候就要慎重地挑選所有的成員，儘量讓大家都成為朋友，那樣才更有利於工作的開展。

    分享意味著什麼呢？我覺得它意味著共同進步，知識要分享，經驗要分享，好吃的，好玩兒的都要分享。這也應該是大家成為真正的朋友的前提吧。尤其是知識和經驗的分享，對於組建學習型的團隊非常重要。而最有效的形式，就是在固定的期間內舉辦技術交流會，團隊的所有人儘可能地參加，大家可以把自己工作學習生活中所發現、所學到的知識分享出來，這樣不僅僅有利於大家共同提高，也有利於解決工作中的各種問題。而這也是我一直在致力推行的一種方式，儘管最近有些障礙，呵呵。

 

精誠協作

    想要達到這一點，首先就不要“事不關己，高高掛起”。儘管有些事兒不是我們份內的事情，但是團隊的事情，我們都應該有責任儘自己所能去做。有人會說，做得多，錯就多，幫別人修改了程式，當這個程式出問題的時候，就會怪罪到自己的頭上。這種情況的確存在，我也遇到過多次，但是我更珍惜的是在這個過程中和其他團隊成員的交流以及所學習到的知識。任何事兒都不可能是完美的，都具有兩面性。而且這樣做非常有利於形成真正意義上的團隊，當出現問題的時候，我們幫助過別人，當我們自己出現問題的時候，也就會有人幫我們。

    也有人會說，讓一個人做別人的工作，修改自己不熟悉的程式，風險會比較高，很可能會出現其他的問題。的確這種情況也存在，因此在涉及到業務領域知識的時候要謹慎，複核一下也是非常必要的。而對於純技術的問題，就不存在這種問題了，一個專案中的程式都應該是風格統一的，程式設計師彼此之間應該可以互相閱讀和修改程式。

    另外，協作要體現在整個團隊之中，需求分析人員、設計人員、開發人員、測試人員之間都要協作。在做自己的工作的時候，都要為別人著想，考慮如何才能夠更有利於讓別人也順利開展工作。

 

尊重理解

    人都有長處，都有短處。這是肯定的，沒有誰能夠是完美的，何況生活中不僅僅是工作，還有很多其它的事情也會對工作造成影響。因此在發現別人犯錯的時候，應該去理解，並且以對事不對人的態度去解決問題。

    比方說，測試人員發現開發人員程式中出現了很多缺陷，那麼不應該去指責，而是應該記錄下來，然後和開發人員一起分析，提醒他以後不要出現類似的錯誤。

    再比方說，當開發人員發現設計人員的設計出現了問題，那麼就應該去商量，找到更好的解決方案。

    再比方說，設計人員發現最終的程式與自己的本意有出入，也應該去溝通，而不是強硬地要求別人重新編寫程式碼，而應該找到為什麼會出現這樣的問題，從而去避免以後理解上出現歧義。

    多一份尊重，多一份理解，才能夠更好地溝通，才能夠更好地協作。

 

    我想，如果做到了上面的四點，我們應該建立起一個比較優秀的團隊，然後接下來要做的就是保持團隊的穩定，並且在一個又一個的專案的磨練中不斷地增進團隊的凝聚力和向心力，並且越來越好地根據每個人的能力來分配工作，做到人盡其用，這樣團隊的工作效率會越來越高，完成任務的質量也會越來越好。

    建立一個理想的團隊，需要很長的時間，需要團隊成員彼此之間不斷地磨合、理解和包容，所以，在建立團隊之前，要確保團隊成員的穩定性，同時，對於人員的增減，都要慎之又慎，必須是完全理解和贊成團隊文化，並且能夠為團隊做出貢獻的人，才會加入到團隊中來。

    上面所述的團隊非常理想化，想要真正實現會很困難，而且保持下去更困難，我們要做的也不是一口吃個胖子，一下子就建立一個超級團隊，而是要在建立團隊的時候就有自己的原則，並且根據這些原則不斷地對團隊進行改善和建設。

 

p.s. 這篇文章在我的草稿箱裡面待了很長一段時間，一直在對其中的內容考慮來考慮去，生怕誤導了大家。不過“醜媳婦早晚要見公婆的”，所以還是在修訂了之後，拿出來與大家分享，大家有什麼意見，只管提出，希望和大家一起討論，:)

 

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/lingyun2005/archive/2010/08/09/5797890.aspx