如何在高壓之下做好團隊建設(shè)

1、如何在高壓之下做好團隊建設(shè)團隊廣義上講是一個集體的描述。狹義上講是開發(fā)人員的集體，我們這里 只討論廣義的概念。團隊里面的主要成員是人，但也包括所使用的工具，設(shè)備 等等資源，。這個概念任何書本上都沒有澄清，但在我描述壓力下的團隊建設(shè) 之前必須先要談談這個概念，以及這個概念所引發(fā)的一些經(jīng)驗。一、團隊的概念團隊是為達到統(tǒng)一目的集體的總和。它由集體中的人、工具、設(shè)備、以及 一些輔助資源，比如說某些特定信息等等來構(gòu)成。因此團隊是具有獨立工作能 力的，有獨立思維環(huán)境的一個團體。如果有人告訴我，他和朋友組成了一個開 發(fā) office 的團隊，沒有固定的工作環(huán)境，在互聯(lián)網(wǎng)進行信息交流。我當然不會相 信，因為他

2、們不具備環(huán)境，是個不完整的，沒有開發(fā)能力的協(xié)助而已。他們只 能做一個完整團隊的一部分。這里大家不要把團隊局限在軟件行業(yè)，一臺計算 機幾套盜版的開發(fā)環(huán)境就可以了。因此為了使團隊正常運作起來，關(guān)鍵部分就 是環(huán)境的構(gòu)建，人在團隊的角色只是創(chuàng)造性勞動者。因此團隊建設(shè)中針對人的 部分可以描述為：為創(chuàng)造性勞動構(gòu)建環(huán)境的過程；針對環(huán)境的部分可以描述 為：為重復性勞動構(gòu)建環(huán)境的過程。所以前者需要靈活，自由與嚴謹，后者需 要穩(wěn)定、快速與準確。簡單的實例：比如軟件開發(fā)中人員是相對自由的，他們 可以自由交談，可以自由調(diào)節(jié)休息時間等等，使用的計算機應該是快速的穩(wěn)定 的，雖然滿足工作就好，但誰又討厭更快的速度呢？信息也

3、是團隊的一部分， 比如是面對某個項目要作的前期培訓，應該具備準確的概念與快速入門的性 質(zhì)。這些都是團隊的一部分。而且是缺一不可。至于團隊人員的選擇屬于主觀 問題，一言不可盡其極，這里就不再論述了。二、團隊中的軟件工程上面我故意回避了一個問題，就是團隊內(nèi)部的項目管理。要說明這個問 題，必須先要了解軟件工程。軟件工程包括兩方面的內(nèi)容：、軟件的開發(fā)技 術(shù)。第二、軟件項目管理。軟件開發(fā)技術(shù)包括了所有現(xiàn)在的開發(fā)細節(jié)，這個我 沒有能力來說明，在這里我只談談軟件開發(fā)的項目管理部分，但一定要明白項 目管理只是軟件工程的一部分，而不是全部。軟件工程論述部分可以參照我在 上的專欄文章軟件設(shè)計深度挖掘一，時間有點久

4、遠，但里面我需要修正的 東西不是很多。用可直接搜索到。下面我談談團隊的軟件工程。團隊的規(guī)模和軟件工程匹配成正比，比如 10 人以下的團隊，軟件工程中很 多問題都可以解釋為人員的交流。而 10-25 人的團隊則需要很少的中間信息交 換的管理，比如使用郵件來發(fā)送任務書等等， 25-50 人團隊則需要使用更多的中 間質(zhì)量保證，比如使用 ClearCase來進行配置管理，vss顯然不適應大規(guī)模軟件 開發(fā)。從小團隊到大團隊的過程中增長的不是軟件工程的應用程度的變化，而 是對軟件工程的應用方式的改變。團隊的大小和使用軟件工程沒有任何沖突， 不同團隊都要確保終的軟件質(zhì)量，這個很顯然，我們會在小團隊應用靈活的

5、， 直接的交流方式，比如口頭糾正一些膚淺的錯誤，直接互看代碼，直接指出相 互在開發(fā)中存在的問題，這樣做因為我們追求效率，質(zhì)量在遞增的完善中顯的 十分完美。大團隊為了避免信息交流的爆炸，必須采用一些中間管理步驟來確 保各種團隊信息流的負載平衡。項目管理也就在這樣的需求下很自然的產(chǎn)生 了。因此團隊的軟件工程就是完善的軟件工程體現(xiàn)。只是很多情況下不知不覺 的錯過了總結(jié)的機會，當過程結(jié)束就很難再完善的歸納了，畢竟回憶是片段 的。我會經(jīng)常聽到有人說自己參加的都是小項目，沒有軟件工程的經(jīng)驗，其實 你所擁有的是軟件工程的不同表現(xiàn)而已，沒有參加過小項目的人對軟件工程的 認識當然也是不完全的。三、壓力下的團隊建

6、設(shè)我們不可能總是在開發(fā)大型項目，因此開發(fā)模式中適合小團隊的模式比較 多，大團隊的管理模式其實是很成熟的，幾乎所有軟件工程著作都非常適合大 型軟件工程。因此我們討論小團隊的團隊建設(shè)以適應大部分的情況。壓力下改變的只有團隊中的人。那么，壓力下的團隊是怎樣的呢？嚴重的問題是他們會感到絕望。由于方方面面的原因都有可能造成團隊成 員的情緒變化，而且絕大部分情況都是不可逆的。當時間太短與項目太大之間 的情況發(fā)生，團隊必然會發(fā)生對項目能否完成的討論，討論帶來情緒波動，之 后是浮躁，心慌，工作效率低下也隨之而來，其實產(chǎn)生這個的原因是因為他們 參與了項目管理的討論。在很多情況下團隊所有成員是應該避免參與項目規(guī)劃

7、 部分的談論，而更大部分討論應限制在項目本身，比如設(shè)計上。我不得不重點 強調(diào)項目經(jīng)理的作用，因為他要擔負起不可思議的一對悖論問題的解決，一個 根本不可能完美解決的問題的解決方案的設(shè)計。但團隊人員很聰明，他們知道 團隊面臨的問題，當然就有自己的想法，這個應該由項目經(jīng)理來解答所有團隊 成員的問題。需要解釋的問題重點應該是項目中的技術(shù)問題如何解決，使用怎 樣的質(zhì)量控制及軟件工程方法，項目資金問題，加班問題，完成項目的意義， 如果沒有按時提交項目的后果等等。壓力下的項目管理過程就是人的管理過程。軟件工程這個時候變的尤其的 脆弱，我曾經(jīng)經(jīng)歷過一個程序員因為椅子不合適而拒絕加班的情況，當然他很 憤怒。執(zhí)行

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

9、生的中間過程而耽誤 過多的時間，幾年前，我曾有過這樣的經(jīng)歷，我給我的團隊骨干（ 2 個人）配備 了專門的技術(shù)秘書，他們負責一切的文檔編寫，單元測試的編寫，以及完成這 兩個人的代碼測試。工作中骨干們甚至是邊開發(fā)邊口述，秘書就及時的記錄下 來相應的細節(jié)，從而整理成文然后再給骨干們審查。一個原本要開發(fā)半年的項 目，三個月就全部完成，相應的開發(fā)成本只增加了 10%.重要的是保證了產(chǎn)品質(zhì) 量。之后他們會風趣的告訴我， “這樣開發(fā)真的很刺激，希望下次不要再經(jīng)歷 了所以我想提醒大家，壓力管理是短暫的一種畸形管理，不可能適合大部分 的開發(fā)。如果團隊連續(xù) 3 次進行這樣的管理過程，我想他們會瘋掉的。到現(xiàn)在我還是

10、沒有提到加班問題。其實在壓力下，加班是難免的，但我確 實不能說提倡加班，因為造成團隊在高壓下工作應該是公司領(lǐng)導們的事情，強 加到團隊身上是侵犯人權(quán)的表現(xiàn)。每個人都有一定的工作能力，重要的是我們 不能把團隊的理想強加到團隊成員的身上，因為他們是自由的。加班問題這個 矛盾我們還是回避了吧！下面是一些壓力下團隊建設(shè)的原則：1、給團隊的自由度：這個指管理上的自由。不必受公司內(nèi)部制度的限制， 因為壓力下的團隊管理本身就是畸形的。2、給團隊配備穩(wěn)定的設(shè)備：這個我就不解釋了，穩(wěn)定在這個情況下比快速 更重要。3、給團隊更多的可支配資金：應變很多資源和人員需求上的變化，比如需 要購買書籍，配備外協(xié)人員等等，這些

11、都需要快速以減少團隊額外的時間上的 浪費。普通項目則允許資金申報過程。4、項目經(jīng)理要有一定經(jīng)驗：這中情況下的團隊讓新手進行管理會是災難性 的。而且項目經(jīng)理經(jīng)驗要非常豐富才可以勝任。普通項目中此條款也可以不遵 循。5、團隊成員共同設(shè)計：項目應該由所有成員一起進行設(shè)計工作，以便盡快 確定可行的設(shè)計方案，所有成員對設(shè)計也應該有很深的了解，方便以后的交 流。此條款在普通項目中根據(jù)實際情況實施。6、針對不同成員設(shè)計有針對性的優(yōu)化開發(fā)方案：這種方法只是針對這個項 目進行，可以按照個人愛好，能力，資源調(diào)配等等方面制定。這種方式是不適 合公司發(fā)展的，人員變動后對項目影像比較大，因此普通項目不得按照此管理 方式

12、。7、解決團隊成員生活問題：在團隊解決能力范圍內(nèi)的問題，要在項目開始 之前首要解決。原因很明白。在普通項目中里面包含了冗余時間，項目進度可 以承受成員處理生活上和其它方面的問題，這里關(guān)心的是效率，因此此條款也 不適合普通項目開發(fā)。8、采用敏捷開發(fā)模式。這是輕量級程序的開發(fā)模式，項目經(jīng)理的都應該具 備這些知識了吧。9、項目培訓應提早進行：在合同簽署之后的件事就是項目中的技能培訓， 比如行業(yè)、前沿技術(shù)等等。這個直接關(guān)系到項目進度、用戶需求與穩(wěn)定性的指 標。10、讓管理層遠離團隊：如果是有經(jīng)驗的團隊都有這樣的經(jīng)歷，管理層的 很多意見不適合壓力下的技術(shù)開發(fā)，讓他們離開團隊才是團隊正常運轉(zhuǎn)的保 證。很多情況下他們都愿意做你潛在的客戶，他們會這么說，然后來參與到你 的團隊中，然后他們有很多意見，然后他們會以領(lǐng)導的身份告訴團隊應該如何 改進，而不是客戶的身份。相信我，讓他們離開你的團隊，他們一般不會做好 這樣的角色互換，因為他們不知道客戶要干什么，不是所有，是大部分。上面