軟件項目的“管理之癢”

軟件項目的“管理之癢”

在國內(nèi)，不少做過幾年程序員，被同事、圈內(nèi)的朋友公認為技術(shù)水平不錯的人，在考慮自身職業(yè)發(fā)展的時候，可能會想當然的認為：“我可以做項目經(jīng)理了，感覺做個項目經(jīng)理也沒啥特別難的”。

但如果你真的有機會，去嘗試帶一個團隊，哪怕是只有幾個人的一個小TEAM的時候，你就會發(fā)現(xiàn)，你必須面對一系列的問題和麻煩，而這些事情的處理結(jié)果，基本上和個人技術(shù)水平無關(guān)。

舉一些例子：

“自己每天被領(lǐng)導施壓，忙忙碌碌，累得吐血，可手下的幾個人，卻讓人覺得他們閑的發(fā)慌”。

“給他們布置的任務，好像怎么也做不完，一拖再拖，個人感覺是很簡單的事情”。

“好容易分工做完了幾個模塊，整合起來卻怎么都不對，老是出現(xiàn)錯誤，還得我自己親自動手修改處理”。

“交給了客戶一個測試的版本做展示，客戶第一句話就是：這個不是我們想要的”。

“眼瞅產(chǎn)品交付的最后期限逼近，可軟件的問題層出不窮，錯誤百出，這怎么能讓客戶滿意并且驗收簽字呢？”。

“天天加班，把人搞得生理時鐘失調(diào)，晝夜顛倒，做這個項目的人怨聲載道，整天怒氣沖沖，威脅辭職、罷工”。

……

在具體的軟件項目運轉(zhuǎn)中，這些令人頭痛的問題接連不斷，常常把人搞得焦頭爛額，心煩意亂，任你技術(shù)水平再高，都沒用。俗話說的好：“你渾身是鐵，能碾幾顆釘”。事必躬親，大包大攬的結(jié)果只能是把自己累垮，工作還沒做好。在軟件越來越復雜，需求多變的情況下，個人英雄主義、單打獨斗是行不通的，干活還得靠大家。

痛定思痛，你也會很聰明的想到：我必須使用軟件工程方法、開發(fā)流程來管理我的團隊。但你真的要在團隊中套用上鼎鼎大名的CMM，更令人沮喪的事情還在后面：CMM中光是那一堆名詞和文檔，就夠大家理解好久的了。而且，這些標準、指南更像是評分手冊，可操作性不足。項目組好像整天在忙，老是開會，煩不勝煩，搞出一大摞文檔，真正的軟件卻總是出不來。

還有不少其它的項目管理方法、指南，也是難以在實際環(huán)境中操作應用。

你必須找到適合自己公司團隊的開發(fā)流程、框架，不僅要完整，而且必須有良好的可操作性，比較靈活，適應范圍廣泛。所以，向在軟件項目管理上成熟、完善的公司學習，是個很有效的辦法，能讓你迅速掌握在項目管理上的各種方法和技巧，并且上升到理論水平。

在軟件行業(yè)，微軟公司的軟件產(chǎn)品眾多，產(chǎn)品線齊全。這個軟件巨人在各個市場上取得的成功也是有目共睹，其軟件項目的開發(fā)、管理過程也一直是大家很感興趣的焦點。

筆者有幸參加了一次軟件項目管理的培訓，由微軟中國顧問咨詢部門的講師主講，為期三天，大有斬獲。好多困擾已久的問題和疑惑得到了解答，有種豁然開朗的感覺。

課程內(nèi)容是MSF－MicrosoftSolutionsFramework，微軟解決方案框架，所謂MSF，就是微軟公司定義的用于軟件項目管理的一套完整的流程、方法。講義是從英文教材翻譯過來的，MSF的版本是3.0。你可能會覺得奇怪，怎么這個框架還有版本。嗯，沒錯，微軟公司的講師聲稱，當VisualStudio.net2005發(fā)布的時候，會整合、攜帶MSF4.0一起面市。

因為MSF自身也是根據(jù)軟件產(chǎn)業(yè)環(huán)境，根據(jù)新的思想、新的理念、新的實際項目經(jīng)驗不斷調(diào)整，不斷演進的，并不是教條。如3.0版本的過程模型中，就比2.0版本多了一個稱為部署階段的過程。

MSF是由微軟公司的全球產(chǎn)品組、咨詢服務部門、信息技術(shù)部、微軟的合作伙伴共同協(xié)作，分析、總結(jié)經(jīng)過實踐檢驗的正確經(jīng)驗，對比業(yè)界的方法，匯總而成，是關(guān)于“人和過程”的指南。它的特點就是實戰(zhàn)性很強，對項目整個過程的指導很完整。而且，它是通用的體系，不管你用什么技術(shù)，做什么項目，都有可以參照的準則。

MSF主要包含了兩套模型、三個準則。模型正好涵蓋了“人和過程”：團隊模型、過程模型。三個準則：項目管理準則、風險管理準則、就緒管理準則。

在講師講述團隊模型的時候，很有趣，讓我們5個人一組，分組做了一個讓人印象深刻的實驗。這也是這套課程的獨到之處，講師上課，并非照本宣科的講，而是在學習過程中，穿插了多個實驗和具體的項目實例，讓大家在一個臨時組織的團隊中，體會理論的含義，加深消化理解。

這個實驗并不復雜，就是模仿大家日常工作中最常見的、項目小組的結(jié)構(gòu)化組織形式，小組包含一個“老板”，一個項目經(jīng)理，多個團隊成員。由“老大”發(fā)號施令，讓項目經(jīng)理指揮自己團隊的人執(zhí)行，然后看結(jié)果。等15分鐘的時限過去，“老板”揭示“成果”，小組成員要當眾發(fā)表感想。難以想象，平時我們認為那么自然的組織結(jié)構(gòu)，竟然有這么多缺陷！

老板感言：我以為大家知道的事情，原來他們根本不了解，不知道，信息完全不對稱。

項目經(jīng)理：太累，不懂領(lǐng)導到底要啥。

團隊成員：閑得無聊，不知道要干什么。對工作沒有積極性，不主動。

這樣的結(jié)果就是：領(lǐng)導和項目經(jīng)理的個人能力，基本決定了項目成功的可能性。

然后大家開始分析為什么會這樣，原因在哪里，于是就引入了MSF的團隊模型。

當然這個實驗模型為了突出問題，做了很多簡化，但在實際環(huán)境中，這些缺陷是確確實實存在的。

MSF的團隊模型中，分成了6個角色，這6個角色是：程序管理、開發(fā)、測試、發(fā)布管理、用戶體驗、產(chǎn)品管理。每個角色之間是平等的關(guān)系，沒有上下級的行政差別。

這幾個角色并非一定要和人一一對應，當你沒有足夠的人手時候，一些角色可以重疊，由一個人兼任，但開發(fā)不推薦和其它角色兼任，這是因為要保持開發(fā)的封閉性。

當你的團隊人數(shù)眾多，規(guī)模比較大的時候，可以把大團隊劃分成小團隊，再由核心團隊總攬。既可以按照軟件功能、特性來分成功能團隊，也可以根據(jù)職能劃分，例如，程序管理角色有多個人擔任。這充分體現(xiàn)了MSF非常靈活、務實的一面，適應性很強?？梢杂糜趲讉€人的小TEAM，也可以適用于規(guī)模很大的團隊。

敏捷軟件開發(fā)理論適應性就弱些，大家公認不太適合超過10人的團隊組織，而且，對成員的要求更高。

在另外一個模型－過程模型里面，MSF敏捷的一面又顯露了出來。通過把復雜的項目分成多個版本進行迭代開發(fā)，來充分的簡化項目難度。每個版本都有自己要完成的功能范圍，可以看成一個“小項目”，項目小了，復雜度、難度自然大大下降，當然成功的概率就高的多。而且，和項目相關(guān)的人能很快的評估項目成果，來決定項目的“下一版本”方向。

在每個項目過程中，都包含一個很完整的階段，項目構(gòu)思、項目計劃、項目開發(fā)、項目穩(wěn)定、項目部署。從項目構(gòu)思到項目部署結(jié)束，每個環(huán)節(jié)都有很多的所謂“里程碑”成果。就是每個階段都有很明確的要求，到底要拿出什么成果。而這些成果，是需要團隊成員共同努力來取得的，正好和團隊模型相互結(jié)合。

在項目的任何一個階段，每一個團隊成員都要有成果，大家是并行工作的。這樣一來，就避免了傳統(tǒng)組織方法的很多弊病，如開發(fā)沒結(jié)束，測試難以進行。在這樣的模型中，不再是一個上司發(fā)號施令，下面的人去被動執(zhí)行，已經(jīng)演變成了大家都能積極主動的參與進來，每個人都有事情可以做。不同的角色在不同的項目階段，分別起到主導作用。

課程中還有一個很重要的MSF原則貫穿其中，那就是風險。所謂風險，簡單的說就是事件有可能發(fā)生，但是不確定何時何地。

團隊最早開始做的事情之一就是管理風險，我們通過分組，在課堂上模擬了一遍，很有意思。每個人根據(jù)實驗要求，挖空心思，冥思苦想，想象在項目過程中到底會發(fā)生什么事情，判斷可能性和后果。連團隊成員懷孕，無法繼續(xù)工作這種事情也被找了出來，戲劇性的是，一個學員就承認，自己的團隊就遇見了這樣的麻煩，而且還不知道到底應該怎么辦。

管理風險的目的就是把握主動權(quán)，在風險發(fā)生的時候能迅速處理，從而保證項目能順利進行下去。這樣一來，客戶會對我們更有信心，更信任我們，項目成功的可能性會進一步提高。