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

　　一、團隊的概念

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

　　二、團隊中的軟件工程

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

　　下面我談?wù)剤F隊的軟件工程：

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

　　三、壓力下的團隊建設

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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