解析不同種類的軟件項目團隊模型
軟件開發(fā)是智力型團隊，如何發(fā)揮每個人的作用，并將所有人的力量扭成一股強大的項目團隊戰(zhàn)斗力，這是項目團隊模型要重點解決的問題。
大綱：
1.傳統(tǒng)項目團隊模型
2.實際項目團隊模型
3.MSF的項目團隊模型
4.實用團隊模型
5.什么才是合適的項目團隊模型？
正文：
傳統(tǒng)項目團隊模型
什么是項目團隊模型？簡單地說就是項目以怎樣的方式組建團隊，軟件開發(fā)項目團隊的傳統(tǒng)團隊模型如下：
項目組在項目經(jīng)理的帶領(lǐng)下，各角色協(xié)調(diào)工作，為項目成功而努力！
各角色的具體職責如下：
項目經(jīng)理：整體協(xié)調(diào)項目，編制計劃及保證計劃執(zhí)行，推動項目成功。
系統(tǒng)分析員：分析系統(tǒng)需求，保證系統(tǒng)需求既滿足客戶要求，同時保證技術(shù)可行性；指導項目技術(shù)方案及系統(tǒng)架構(gòu)設計。
軟件設計師：細化系統(tǒng)設計。
程序員：編碼實現(xiàn)設計。
測試工程師：測試系統(tǒng)，保證系統(tǒng)滿足需求。
實施工程師：部署、調(diào)試系統(tǒng)，培訓客戶，協(xié)助客戶推動系統(tǒng)上線運行。
配置管理員：對整個項目周期中的工作產(chǎn)品實施配置管理。
QA：質(zhì)量保證工程師，保證開發(fā)過程按照既定的要求進行，保證工作產(chǎn)品符合既定的規(guī)范。
這個傳統(tǒng)團隊模型有兩大特點：
1.一個團隊總有一個頭（這也是我們的慣性思維），這個頭就是項目經(jīng)理。
2.假設各種專業(yè)的角色能協(xié)調(diào)工作，并能各自發(fā)揮所長。
我們希望項目團隊能有一個強大的頭領(lǐng)，加上一班專業(yè)人才，共同為項目成功而努力。
但實際情況有這么理想嗎？
項目經(jīng)理會埋怨手下能力不夠、不主動報告工作、不主動承擔責任......
而項目組成員會埋怨項目經(jīng)理不夠強，只會叫他干活，不授權(quán)，更加不會傳授知識......
實際項目團隊模型
我們實際項目的團隊結(jié)構(gòu)，往往是這樣的：
實際情況與理想的傳統(tǒng)模型比較，有以下重大差異：
1.項目經(jīng)理身兼多職。
很多項目往往沒有專職的系統(tǒng)分析員和軟件設計師，項目經(jīng)理兼任需求分析與軟件設計的工作，甚至還需要負責編碼的工作。
圖中系統(tǒng)分析員、軟件設計師這兩個角色都是虛線框，意思就是表示這兩個角色往往只是虛位，難以落實具體的專職的人員。
項目經(jīng)理要做的事情太多了，往往沒有辦法專注項目管理，項目計劃相關(guān)的文檔能免則免，項目設計文檔能少則少。
2.測試工程師、實施工程師低人一等。
很多公司公司的測試工程師、實施工程師會“低人一等”，開發(fā)人員有天生的優(yōu)越感，而項目經(jīng)理往往是由開發(fā)人員升任的，項目經(jīng)理會有意無意地將測試工程師、實施工程師擺低一級。各角色如果不能平等的工作，項目團隊戰(zhàn)斗力自然大受影響。
造成這種不平等的原因主要有兩個：一就是開發(fā)人員的天生優(yōu)越感，二就是整體來說我們的測試工程師、實施工程師水平確實還不夠
在我們公司其實也有這樣的“不平等”情況，我花了很多時間營造“平等”的氛圍，我的主要辦法有：
1）通過各種途徑不斷強調(diào)項目團隊各專業(yè)人才的重要性。
2）想盡辦法提高測試工程師與實施工程師的水平。
3.配置管理員、QA再低人一等，甚至可有可無。
圖中這兩種角色是灰色的，這兩者可能是整個項目團隊中最“慘淡”的角色了！
好一點的公司都會有配置管理員，但往往被當作文員來看待，而有些公司甚至沒有專職的配置管理員，項目經(jīng)理甚至沒有想到要配置管理這回事。QA是一個四面不討好，到處惹人非議的角色，可以說是項目組中最“差”的職位了。
造成這局面原因也主要有兩個：一就是大家的習慣性思維認為這兩個職位就是最不重要的，二就是我們的配置管理員、QA的水平還不夠的問題。
對于配置管理工作，其實實質(zhì)就是項目生命周期中各種工作產(chǎn)品的管理工作，我認為項目經(jīng)理應該發(fā)揮更大的作用，而我們的配置管理員應該嵌入到項目的具體中去完成工作，而不要只抱著配置管理的大道理來工作。
QA確實是最痛苦的職位，優(yōu)秀的QA需要有資深的項目經(jīng)驗，但有資深項目經(jīng)驗的人大都不愿意做QA，這是多么矛盾和痛苦??！
簡單地說，實際的項目團隊結(jié)構(gòu)有以下嚴重問題：
1.團隊的頭不能專職項目管理。
2.項目團隊中各專業(yè)人才要么缺失、要么嚴重不平等。
MSF的項目團隊模型
MSF，全稱是Microsoft Solution Framework，微軟解決方案框架，是微軟進行研發(fā)活動的方法論。
MSF的團隊模型非常特別，它沒有團隊的頭領(lǐng)：
此圖來自MSF的官方資料
微軟的團隊是沒有項目經(jīng)理的，由6類角色組成，分別是產(chǎn)品經(jīng)理(Product Management)、程序經(jīng)理(Program Management)、開發(fā)(Development)、測試(Test)、發(fā)布管理(Release Management)、用戶體驗(User Experience)。
各類角色負責的職責如下：
該模型的幾個重要特點：
1.沒有所謂的項目經(jīng)理。
程序經(jīng)理這個角色可以說是最接近項目經(jīng)理的了，他需要編制計劃及跟蹤計劃執(zhí)行，但在行政級別上，他不是大家的頭，大家都是平等的，大家只是處在不同專業(yè)的角度來負責工作。
2.強調(diào)項目團隊是由各專家組成的。
軟件開發(fā)活動是高強度高挑戰(zhàn)的智力活動，我們需要由各類專家共同負責協(xié)調(diào)工作，每位專家都是同等重要的。
3.用戶體驗是我們常常忽略的部分。
用戶體驗簡單地說就是用戶使用軟件時的感覺，軟件的顏色、布局、文字、行為等等會直接影響用戶使用軟件的滿意度。目前我們國內(nèi)的項目組，往往沒有用戶體驗設計環(huán)節(jié)，也沒有專職的用戶體驗設計師。
我第一次學習MSF團隊模型時讓我很震動，該模型體現(xiàn)了以人為本的開發(fā)模式，讓團隊中的每個人都極受鼓舞，但該模型在實際工作中很難完全應用，主要原因如下：
1.各專業(yè)人才水平參差不齊。
我的個人感覺國內(nèi)以上六類角色的水平由高到低排列，大致這樣：開發(fā)、程序經(jīng)理、產(chǎn)品管理、測試、發(fā)布管理、用戶體驗，而用戶體驗基本是空白。各專業(yè)人才能力不相當，就無法組成“無頭領(lǐng)”的團隊，充分發(fā)揮各種角色的作用。
2.各專業(yè)人才水平全部沒達到要求。
哪怕是水平最高的開發(fā)角色，我們的平均水平跟微軟的相比還是相差太遠，那就更加不需要提其他角色了。
3.團隊協(xié)助能力差。
我們的團隊基本不會“team work”，我們從小到大的教育就基本沒有“team work”的教育。
MSF常常也被人以“太理想化”質(zhì)疑，MSF所描述的世界只是軟件開發(fā)的烏托邦而已。難道我們的現(xiàn)實情況就決定了我們的項目團隊水平嗎？我們沒有辦法建立一種實用的項目團隊模型，讓我們的項目團隊能持續(xù)進步嗎？
實用團隊模型
我?guī)ьI(lǐng)過很多團隊，其中不少是帶領(lǐng)應屆生或者是工作經(jīng)驗還不多的工程師，團隊中每個人的能力如果還不能塑造好，確實無法讓團隊高效運作。而項目初期我做的很多事情，都是通過項目具體工作來訓練大家、提高每個人水平的事情。
我們的計算機相關(guān)教育并沒有訓練出合格的各類專業(yè)人才，但我們這般計算機從業(yè)者都是充滿激情和追求進步的，基于這樣的現(xiàn)狀，我覺得應該有合適的團隊模型能讓我們的項目團隊自學習，然后逐步發(fā)揮各專業(yè)人才的作用。
我們光抱怨我們的教育制度是沒有用的，我們需要實用的團隊模型來解決當前的實際問題。我在實際項目中的項目團隊模型，通常是這樣的：
角色和人并一定是一一對應的，一個人可以戴多個角色的帽子，一種角色也可能由多個人擔當。
上述模型有8種角色：項目經(jīng)理、產(chǎn)品經(jīng)理、軟件設計師、用戶體驗設計師、測試工程師、實施工程師、配置管理員、QA。
前面六種角色分別與MSF的程序經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)、用戶體驗、測試、發(fā)布管理角色類似。
我基本上是很認可MSF的項目管理思想的，但為了適應實際情況，我做了一些必要的調(diào)整。
1.讓綜合能力比較強的人擔當項目經(jīng)理。
這個人不一定非常強，但只要他是項目組所有人中綜合能力最強的人就可以了。項目經(jīng)理除了領(lǐng)導項目團隊，他需要更關(guān)注項目成員的成長。項目經(jīng)理進行相關(guān)決策的時候，應該充分發(fā)揮大家的參與性。
2.各角色是同等重要的。
無論是測試工程師、實施工程師、配置管理還是QA，他們都和開發(fā)人員是平等的。哪怕是項目經(jīng)理也不是高高在上的，項目經(jīng)理只是比大家稍微高級別一點，之所以這樣也是因為各角色的水平還不是很夠，我們需要一個項目帶領(lǐng)人。
3.持續(xù)總結(jié)與進步。
犯錯不可怕，只需要能不斷學習不斷總結(jié)不斷進步就可以了。整個項目小組是學習型成長型的團隊，要人人勇于承擔責任，不怕犯錯，遇到問題一起來總結(jié)進步！
4.強調(diào)用戶體驗的重要性。
用戶體驗其實是很重要的工作，但往往被我們忽視，而現(xiàn)實情況是我們基本沒有用戶體驗方面的高校教育，各公司在這方面的基礎(chǔ)也比較薄弱。我在實際工作中，會把用戶體驗的責任落實到實施工程師與測試工程師頭上，要求他們多從客戶的角度來思考軟件應該如何設計。另一方面，我會要求項目組成員或者我自己親自編寫出用戶體驗設計文檔，讓整個項目小組來評審。希望通過這系列的工作，培養(yǎng)出公司自己的用戶體驗設計師。
什么才是合適的項目團隊模型？
其實沒有固定的標準，各種項目管理理論都會有它自己的見解。無論是傳統(tǒng)的團隊模型，還是MSF的團隊模型，各種理論都會基于某些假設，我們實際工作中應用這些知識時，應充分認識當前我們的水平和存在的問題，針對性地調(diào)整模型將其轉(zhuǎn)化為合適的情況，并在實際工作中持續(xù)改善它。
從我的經(jīng)驗看來，以下幾點是很重要的：
1.項目中的每個人盡管水平和能力不一致，但應該都被平等的對待，所有人對項目同等重要。
2.水平和能力較高的人，應該承擔更多責任，并且有責任推動項目組人員提高水平。
3.“學習、總結(jié)、進步”，是每個項目團隊應該具備的基本特點。
4.項目各角色的劃分其實是靈活的，但項目所有人員的整體能力和水平，應該能覆蓋實用項目團隊模型的8種角色。如果缺失某種角色，或者某種角色的水平較低，項目組則應該有計劃地去增強這部分的水平。
5.項目組中所有人承擔的工作負荷和責任應該大致均等。
通過本文，希望能為各位打造高效的項目團隊帶來有益的啟發(fā)。
原文鏈接：http://www.cnblogs.com/umlonline/archive/2011/07/19/2110300.html
【編輯推薦】
