團隊廣義上講是一個集體的描述。狹義上講是開發(fā)人員的集體，我們這里只討論廣義的概念。團隊里面的主要成員是人，但也包括所使用的工具，設備等等資源，。這個概念任何書本上都沒有澄清，但在我描述壓力下的團隊建設之前必須先要談談這個概念，以及這個概念所引發(fā)的一些經驗。

　　一、團隊的概念

　　團隊是為達到統(tǒng)一目的集體的總和。它由集體中的人、工具、設備、以及一些輔助資源，比如說某些特定信息等等來構成。因此團隊是具有獨立工作能力的，有獨立思維環(huán)境的一個團體。如果有人告訴我，他和朋友組成了一個開發(fā)office的團隊，沒有固定的工作環(huán)境，在互聯(lián)網進行信息交流。我當然不會相信，因為他們不具備環(huán)境，是個不完整的，沒有開發(fā)能力的協(xié)助而已。他們只能做一個完整團隊的一部分。這里大家不要把團隊局限在軟件行業(yè)，一臺計算機幾套盜版的開發(fā)環(huán)境就可以了。因此為了使團隊正常運作起來，關鍵部分就是環(huán)境的構建，人在團隊的角色只是創(chuàng)造性勞動者。因此團隊建設中針對人的部分可以描述為：為創(chuàng)造性勞動構建環(huán)境的過程；針對環(huán)境的部分可以描述為：為重復性勞動構建環(huán)境的過程。所以前者需要靈活，自由與嚴謹，后者需要穩(wěn)定、快速與準確。簡單的實例：比如軟件開發(fā)中人員是相對自由的，他們可以自由交談，可以自由調節(jié)休息時間等等，使用的計算機應該是快速的穩(wěn)定的，雖然滿足工作就好，但誰又討厭更快的速度呢？信息也是團隊的一部分，比如是面對某個項目要作的前期培訓，應該具備準確的概念與快速入門的性質。這些都是團隊的一部分。而且是缺一不可。至于團隊人員的選擇屬于主觀問題，一言不可盡其極，這里就不再論述了。

　　二、團隊中的軟件工程

　　上面我故意回避了一個問題，就是團隊內部的項目管理。要說明這個問題，必須先要了解軟件工程。軟件工程包括兩方面的內容：第一、軟件的開發(fā)技術。第二、軟件項目管理。軟件開發(fā)技術包括了所有現(xiàn)在的開發(fā)細節(jié)，這個我沒有能力來說明，在這里我只談談軟件開發(fā)的項目管理部分，但一定要明白項目管理只是軟件工程的一部分，而不是全部。

　　下面我談談團隊的軟件工程：

　　團隊的規(guī)模和軟件工程匹配成正比，比如10人以下的團隊，軟件工程中很多問題都可以解釋為人員的交流。而10-25人的團隊則需要很少的中間信息交換的管理，比如使用郵件來發(fā)送任務書等等，25-50人團隊則需要使用更多的中間質量保證，比如使用ClearCase來進行配置管理，vss顯然不適應大規(guī)模軟件開發(fā)。從小團隊到大團隊的過程中增長的不是軟件工程的應用程度的變化，而是對軟件工程的應用方式的改變。團隊的大小和使用軟件工程沒有任何沖突，不同團隊都要確保最終的軟件質量，這個很顯然，我們會在小團隊應用靈活的，直接的交流方式，比如口頭糾正一些膚淺的錯誤，直接互看代碼，直接指出相互在開發(fā)中存在的問題，這樣做因為我們追求效率，質量在遞增的完善中顯的十分完美。大團隊為了避免信息交流的爆炸，必須采用一些中間管理步驟來確保各種團隊信息流的負載平衡。項目管理也就在這樣的需求下很自然的產生了。因此團隊的軟件工程就是完善的軟件工程體現(xiàn)。只是很多情況下不知不覺的錯過了總結的機會，當過程結束就很難再完善的歸納了，畢竟回憶是片段的。我會經常聽到有人說自己參加的都是小項目，沒有軟件工程的經驗，其實你所擁有的是軟件工程的不同表現(xiàn)而已，沒有參加過小項目的人對軟件工程的認識當然也是不完全的。

　　三、壓力下的團隊建設

　　我們不可能總是在開發(fā)大型項目，因此開發(fā)模式中適合小團隊的模式比較多，大團隊的管理模式其實是很成熟的，幾乎所有軟件工程著作都非常適合大型軟件工程。因此我們討論小團隊的團隊建設以適應大部分的情況。

　　壓力下改變的只有團隊中的人。那么，壓力下的團隊是怎樣的呢？

　　最嚴重的問題是他們會感到絕望。由于方方面面的原因都有可能造成團隊成員的情緒變化，而且絕大部分情況都是不可逆的。當時間太短與項目太大之間的情況發(fā)生，團隊必然會發(fā)生對項目能否完成的討論，討論帶來情緒波動，之后是浮躁，心慌，工作效率低下也隨之而來，其實產生這個的原因是因為他們參與了項目管理的討論。在很多情況下團隊所有成員是應該避免參與項目規(guī)劃部分的談論，而更大部分討論應限制在項目本身，比如設計上。我不得不重點強調項目經理的作用，因為他要擔負起不可思議的一對悖論問題的解決，一個根本不可能完美解決的問題的解決方案的設計。但團隊人員很聰明，他們知道團隊面臨的問題，當然就有自己的想法，這個應該由項目經理來解答所有團隊成員的問題。需要解釋的問題重點應該是項目中的技術問題如何解決，使用怎樣的質量控制及軟件工程方法，項目資金問題，加班問題，完成項目的意義，如果沒有按時提交項目的后果等等。

　　壓力下的項目管理過程就是人的管理過程。軟件工程這個時候變的尤其的脆弱，我曾經經歷過一個程序員因為椅子不合適而拒絕加班的情況，當然他很憤怒。執(zhí)行項目管理的時候應該小心翼翼，甚至可以根據每個不同的人執(zhí)行不同的軟件管理方法。讓團隊感到前所未有正面情緒。在這個期間項目經理的責任就是一個關鍵問題了，不同人的管理模式會讓工作量成幾何級數(shù)的增長，協(xié)作方式的管理復雜化，優(yōu)化了團隊生產效率，增加了大量的管理負擔。有壓力的項目應該有很大的利潤空間，因此增加項目管理資源應該也不是問題。比如每周出去一起出去吃飯，喝茶，打球等等項目活動都會讓團隊忘記壓力，輕松的心態(tài)是取勝的關鍵保證。這種活動是必須的，從心理健康學上講這個是一種必須要保持的平衡關系。還可以增加管理人員，來跟蹤團隊每個開發(fā)人員的開發(fā)細節(jié)來及時反饋。

　　到現(xiàn)在我還是沒有提到加班問題。其實在壓力下，加班是難免的，但我確實不能說提倡加班，因為造成團隊在高壓下工作應該是公司領導們的事情，強加到團隊身上是侵犯人權的表現(xiàn)。每個人都有一定的工作能力，最重要的是我們不能把團隊的理想強加到團隊成員的身上，因為他們是自由的。加班問題這個矛盾我們還是回避了吧！

　　下面是一些壓力下團隊建設的原則：

　　1、給團隊最大的自由度：這個指管理上的自由。不必受公司內部制度的限制，因為壓力下的團隊管理本身就是畸形的。

　　2、給團隊配備最穩(wěn)定的設備：這個我就不解釋了，最穩(wěn)定在這個情況下比最快速更重要。

　　3、給團隊更多的可支配資金：應變很多資源和人員需求上的變化，比如需要購買書籍，配備外協(xié)人員等等，這些都需要快速以減少團隊額外的時間上的浪費。普通項目則允許資金申報過程。

　　4、項目經理要有一定經驗：這中情況下的團隊讓新手進行管理會是災難性的。而且項目經理經驗要非常豐富才可以勝任。普通項目中此條款也可以不遵循。

　　5、團隊成員共同設計：項目應該由所有成員一起進行設計工作，以便盡快確定可行的設計方案，所有成員對設計也應該有很深的了解，方便以后的交流。此條款在普通項目中根據實際情況實施。

　　6、針對不同成員設計有針對性的優(yōu)化開發(fā)方案：這種方法只是針對這個項目進行，可以按照個人愛好，能力，資源調配等等方面制定。這種方式是不適合公司發(fā)展的，人員變動后對項目影像比較大，因此普通項目不得按照此管理方式。

　　7、解決團隊成員生活問題：在團隊解決能力范圍內的問題，要在項目開始之前首要解決。原因很明白。在普通項目中里面包含了冗余時間，項目進度可以承受成員處理生活上和其它方面的問題，這里最關心的是效率，因此此條款也不適合普通項目開發(fā)。

　　8、采用敏捷開發(fā)模式。這是輕量級程序的開發(fā)模式，項目經理的都應該具備這些知識了吧。

　　9、項目培訓應提早進行：在合同簽署之后的第一件事就是項目中的技能培訓，比如行業(yè)、前沿技術等等。這個直接關系到項目進度、用戶需求與穩(wěn)定性的指標。

　　10、讓管理層遠離團隊：如果是有經驗的團隊都有這樣的經歷，管理層的很多意見不適合壓力下的技術開發(fā)，讓他們離開團隊才是團隊正常運轉的保證。很多情況下他們都愿意做你潛在的客戶，他們會這么說，然后來參與到你的團隊中，然后他們有很多意見，然后他們會以領導的身份告訴團隊應該如何改進，而不是客戶的身份。相信我，讓他們離開你的團隊，他們一般不會做好這樣的角色互換，因為他們不知道客戶要干什么，不是所有，是大部分。

　　上面所述只針對純軟件公司的小團隊開發(fā)。如果要論述各種情況有點不切實際，這里我只論述了大部分公司存在的問題。但大家一定要明白，如果盲目利用這種方式去開發(fā)不可能完成的項目，結果還是失敗的，因為你的出發(fā)點就錯了，這種方法只是糾錯，就象我們明天要提交軟件了，今天晚上通宵了一樣，是時間壓縮，而不是真的效率提升，一般這種開發(fā)過后我都會給團隊放一定的假期，因為他們?yōu)楣�司做出了效益，這是他們應得的。