摘要：針對國內IT企業(yè)百人左右的大中型產品或團隊在項目管理上存在的問題，文章提出了在企業(yè)研發(fā)流程中引入MSF（Microsoft Solutions Framework）軟件開發(fā)模型，并結合企業(yè)的具體情況進行裁減，其能夠極大的提高軟件工程過程管理能力，從而提高整個軟件產品的質量。

關鍵詞：項目管理；MSF；軟件過程管理

中國絕大多數(shù)的軟件、互聯(lián)網企業(yè)在100人規(guī)模以下，開發(fā)團隊幾十人左右，工作經驗3年～9年，基本處于原始手工作坊式的刀耕火種階段，工業(yè)化的軟件研發(fā)流程和方法往往不執(zhí)行，或執(zhí)行不得力。本文引入微軟公司的MSF（Microsoft Solutions Framework）軟件開發(fā)模型，通過A企業(yè)的實踐證明，運用MSF框架的軟件工程過程管理能大大提高小型軟件開發(fā)公司的軟件研發(fā)能力，軟件的交付期也得到了基本保證。

一、 MSF基本模型

1. 組隊模型。MSF把軟件開發(fā)分成了六個小組，分別是：程序管理組、產品管理組、開發(fā)組、用戶培訓組、測試組、安裝管理組。組隊的原則是小隊（一般3人～8人）、多側面；角色交叉、目標一致；人員技術、業(yè)務精；關注能力和交貨期；對項目的前景認識一致；人人參與設計；善于總結經驗；共同管理、共同決策，項目人員同地工作等。

2. 過程模型。MSF過程模型主要確立了四個重要的里程碑：前景范圍確認、項目規(guī)劃確認、開發(fā)完成、對外發(fā)布，通過控制這四個里程碑來分解管理項目過程。

3. 應用模型。MSF應用模型是分層次的應用模型，大體可分為三層，用戶層、業(yè)務層和數(shù)據層，各層次通過標準組件進行封裝，互相通訊調用來完成系統(tǒng)任務。

4. 風險模型。MSF風險管理過程主要包括：風險識別、風險表述，通過分析、計劃、跟蹤和控制過程，最終解除風險。

二、 MSF在A企業(yè)呼叫中心項目中的具體應用

本文以A企業(yè)呼叫中心項目為例（合計開發(fā)人員50人），結合該項目中的數(shù)據資料，對此項目中服務商的選擇進行具體的分析和研究。

1. 組隊模型裁減。首先，確立項目經理角色，符合一般企業(yè)的管理模式，比較容易被接受。如果有多人同時負責的話，容易產生責權理不清楚，互相扯皮的現(xiàn)象。有一個項目經理對項目完全負責，遇到問題容易很快得到解決；他作為項目組代表，負責向上級匯報工作，能使其他人全力投入到項目中，而不至于在日常的事務中耽誤太多時間，從而在某種程度上也提高了工作效率。

產品管理經理（以下簡稱產品經理）是項目中非常重要的角色，他可以對技術不是很精通，但是必須對產品所服務的領域非常熟悉，最好是領域專家，在他的帶領下，項目才不至于偏離預先設定的前景范圍。他必須對產品的需求能做出很好的把握，在適當?shù)臅r候能進行流程重組，對產品的可用性和易用性有最終決定權。通過設定產品經理，主要的感覺是產品受用戶的歡迎程度增加了，無用的特性少了，因而也更容易成功。

2. 開發(fā)過程管理。在過程模型上，主要包括四個重要里程碑：①前景/范圍確認；②項目規(guī)劃確認；③開發(fā)完成；④對外發(fā)布。

A企業(yè)把MSF的各個階段對應到傳統(tǒng)的項目開發(fā)各階段，目的是使企業(yè)所有人員便于理解和使用。其中“前景范圍確認”對應傳統(tǒng)的“可行性分析”；“項目規(guī)劃確認”對應“需求分析”和“項目計劃”；“首次運行”對應“開發(fā)完成”，“發(fā)布”的意思和傳統(tǒng)基本相同。同時，A企業(yè)根據企業(yè)的具體情況對流程進行了相應調整，把整個流程分為可行性分析、需求分析、開發(fā)計劃、開發(fā)過程和結項總結五個階段，下面分別進行說明。

（1）可行性分析。在做可行性分析的時候，要充分考慮企業(yè)以前的各種技術和市場積累，還有目前的資源可用性情況，特別是要做好風險分析。通常企業(yè)在項目立項前沒有充分考慮各種情況，認為這個項目比較簡單，應該沒什么問題，結果是沒有做得很成功，進度上也拖了一段時間。在后來結項分析的時候，認為主要的問題就是領域的區(qū)別造成了企業(yè)內部沒有人對該領域特別熟悉，缺乏領域專家，并對上述風險估計不足，也沒有對風險進行較好的管理，所以造成了項目的不成功。

上面提到，可行性分析一般是由未來的項目經理和產品經理完成，必要時還需要市場人員的參與，項目經理主要考慮技術可行性，包括項目最初估計的進度表和資源需求情況；產品經理主要考慮市場和經濟上的可行性（主要是針對軟件產品而言）。只有預先對各種問題進行完備的分析后，才能得出正確的決策。不要到后來因為那些事先沒考慮到的，但應該想到的各種原因造成項目失敗；或者雖然完成了，但是沒有取得預期的效果，不能給企業(yè)帶來較好的收益。

只有在可行性分析通過評審，企業(yè)高層領導者認可的情況下才能付諸實施。通過可行性分析，揭示了即將面臨的各種問題及風險，使得企業(yè)內部對該項目有了一致的認識，在后來的資源申請上也更容易得到高層支持，更易于導致項目成功。

（2）需求分析。需求管理是軟件開發(fā)中非常重要的部分，在一般的MIS型項目中，準確的把握需求往往是項目成功的關鍵。但需求管理也是個困難的過程，太多項目的需求都沒有良好的管理過程，往往導致項目后期的大量修改或者直接使項目失敗。

需求的管理主要由產品經理負責，其中最終用戶的實時參與是一個非常重要的因素。在需求采集階段，A企業(yè)主要采用了原型法，使用ViualStudio.Net建立最終產品的界面，然后把功能實現(xiàn)和界面一一對應起來，和用戶進行討論，并不斷的修改界面。最終在基本達成一致后，對應原型寫出需求規(guī)格說明書，在評審后納入基線管理。

在需求的制定過程中，產品經理必須和項目經理、開發(fā)人員、測試人員進行良好的溝通，使項目組全體都參與到需求分析中來，并共同確定需求的關鍵特性：①項目的范圍：在需求分析中，首先必須明確項目的范圍，去掉那些看似屬于該項目其實不該在項目中的需求特性。特別是在一些MIS項目中，客戶往往把一些屬于他們的日常工作但不屬于該項目的需求提交給項目組，這時就必須分清項目的范圍，不要在項目中加入太多不應該做的東西，否則往往會導致項目范圍無限擴大，最終只能是使項目失敗。②需求的優(yōu)先級：需求的優(yōu)先級是非常重要的特性，只有在準確把握的需求優(yōu)先級的基礎上才可能規(guī)劃外部里程碑（產品版本）和內部里程碑（開發(fā)的階段性，后面會講到）。通常是用戶最關心，使用最頻繁的功能應該屬于高優(yōu)先級，而那些不怎么重要或很少用到的功能應該屬于低優(yōu)先級。A企業(yè)必須在產品的開始版本和項目的開始就把重點放在高優(yōu)先級的需求上，而對于低優(yōu)先級的功能可以在項目后期根據需要進行裁減或納入下一個版本規(guī)劃。③產品的易用性：產品的易用性反映在原型中，是原型法的一個非常重要的作用。很多產品的失敗其一個重要原因就是易用性比較差，雖然它在功能上滿足了用戶需求，甚至可以說功能很強大。通過原型法，能讓用戶看到并模擬使用最終的產品界面，能在需求階段通過修正軟件界面來適應用戶的偏好，從而在很大程度上提高了產品的易用性，使項目更容易成功。④其他需求特性：如性能要求、健壯性等。這些特性是產品的非功能性需求，也是項目成功的關鍵因素，特別是在一些大型的涉及重要領域的管理信息系統(tǒng)中。

需求分析完成后，項目組需要對項目的初步計劃進行重新審定，一般都需要變更項目時間表和資源需求。需求分析的完成也意味著項目其他部分可以齊頭并進，如概要設計、測試計劃、用戶說明書，這也在某個方面證明了需求分析的重要性——它是下面所有活動的基礎和準繩。

（3）開發(fā)計劃。軟件開發(fā)中的計劃性是非常重要的，一個沒有良好計劃的開發(fā)項目能夠成功的機會非常小，除非有天才的程序員再加上好運氣。開發(fā)計劃的主要內容包括：項目進度安排、人力資源安排，風險管理策略等。

項目的進度安排和人力資源安排可能是開發(fā)計劃中最重要的部分，也是最難以估計的部分。一般國內的中小軟件企業(yè)對項目工作量和開發(fā)人員能力的量化程度不高，所以導致進度和資源安排不確切，有時候甚至是相差很遠。目前一個最實際的辦法就是根據以往項目的積累，但必須要求是同一領域的類似項目，這樣才有較強的可比性。由于這些計劃安排是預估粗略的，所以還必須在以后的項目各階段完成后進行合理的變更，反應項目的實際需求。微軟的辦法是把進度估計的權限交給開發(fā)人員，由開發(fā)人員根據自己的經驗進行估計，由于一般開發(fā)人員往往會高估自己的能力，估計的進度也會相應偏短，最后再做適當?shù)难娱L。這種辦法有它合理的地方，在中國還需進行實踐摸索。

對于進度的估計業(yè)界有個經驗公式，即最初預估的時間再乘以2.5，可能是最后的完成時間。因為許多人在估計進度的時候，往往忽略了很多非開發(fā)時間，如與客戶溝通的時間、項目組溝通時間、企業(yè)培訓時間、假期等，所以在估計進度的時候，一定要全方位周全考慮，在盡可能的情況下寧愿把進度估計的長一點，免得在項目后期導致非常被動的局面。后面將具體講到采取的階段性的開發(fā)方法，這種方法的運用反映在進度估計時必須在各階段間預留緩沖時間，以解決那些事先沒有預料到的活動。如果進度表和要求的出貨時間有沖突，寧愿砍掉一些不重要的功能，也不要盲目增加人手，這種做法可能會導致產品質量下降，最終得不償失。

（4）開發(fā)過程。在項目的開發(fā)過程中，A企業(yè)采用了階段式的開發(fā)過程，這也是微軟企業(yè)所推薦的開發(fā)過程。在開發(fā)過程的初期，首要的活動是概要設計。概要設計的目標是簡單、適用、能夠覆蓋所有的需求并能支持后面的階段式開發(fā)。微軟的應用方案解決模型是基于服務的三層（多層）架構，包括用戶層，業(yè)務層和數(shù)據層，各層之間采用標準的接口進行通訊。

階段開發(fā)過程不是傳統(tǒng)的根據模塊劃分來依次完成各模塊，最后再進行項目的整合，而是在每個階段完成后，項目都可以推出產品，只不過該產品的功能比最終產品的功能弱一些。階段性完成項目比傳統(tǒng)的開發(fā)方法最明顯的優(yōu)點是不必到項目的末期才開始整合產品，使產品模塊之間協(xié)作產生的問題及早產生，也及早修正，從而項目的風險也大大減小。當然采用階段性開發(fā)方法也有相應的代價，最大的代價可能是反復的整合、測試已經完成的模塊，但采用相應的一些自動化工具可以減小這個代價。

一般在開始的階段進行的是系統(tǒng)架構和最重要的功能，后面的階段是相對不怎么重要的功能。這樣的分配有利于最終用戶在早期就能看到系統(tǒng)的大致模樣，便于他們及早的對產品提出意見，并對相應的錯誤進行修改；也有利于項目組在項目后期時間很緊的情況下，去掉一些不重要的功能，把它們納入下一個版本處理，確保產品的推出時間。迭代的順利進行依賴于良好的架構設計，前面階段的設計應該給后面要加入的功能預留出各種接口，并能使后面的工作在前面的基礎上繼續(xù)進行下去。

這種在開發(fā)階段的迭代方式不同于整個項目的完全迭代開發(fā)，后者是項目的需求、概要設計、開發(fā)等全部是迭代進行，一次迭代要進行所有的項目活動。至于誰優(yōu)誰劣可能在不同的情況下有不同的說法，需要根據項目和自身的情況合理采用。還有就是迭代的次數(shù)也要根據項目的具體情況而定。不能太多，導致重復的工作量過大；也不能太少，使得該方法退化到傳統(tǒng)方法。通常把項目分了四個階段：架構完成、主要功能完成、其他功能完成、整合發(fā)行。實踐證明，這樣的實施比傳統(tǒng)方法確實在很大程度上減小了項目失敗的風險，再沒有產生那種“似乎永遠也做不完的感覺”。

（5）結項總結。很多企業(yè)在項目完成后往往忽視了最后的總結，沒有把在上個項目中得到的經驗教訓進行分析，轉化成企業(yè)的巨大財富。項目的總結是整個項目的不可缺少的重要組成部分，只有通過詳盡的充分的項目總結，才能使項目組的所有成員對項目的歷程有一個清楚的了解，提高他們對軟件項目的認識。

A企業(yè)的做法是在項目完成后首先由各個項目成員寫出各自的總結報告，包括所從事的工作、任務的完成情況、遇到的問題及解決方案、對項目過程的意見和自己的想法等內容。項目負責人需要把整個的項目歷程整理成一份文件，其中包括項目的介紹、項目進行的具體資料（如實際花費時間、源代碼數(shù)、功能模塊數(shù)量等）、項目計劃與實際的比較等。

在上述完成后，全體項目參與人員舉行項目結項工作會議，對各人所列舉的問題及想法進行討論，目的是得出好的經驗教訓，從而指導后面項目過程。會議可由分別針對的問題分為幾個部分，如項目過程方面的、質量管理方面的、技術方面的等，整合后形成結項會議報告。

項目負責人最后把項目歷程、資料、在結項會議中總結的經驗教訓等整理成一份總的項目過程文件，歸檔并分發(fā)到各成員和上層領導，并由項目經理向上層領導匯報，這時，一個完整的項目才真正告一段落。這些項目資料給以后的項目提供很好的模板和借鑒意義，并可以作為以后項目預估的依據。

3. 風險管理。微軟企業(yè)認為，軟件開發(fā)是一個風險驅動的過程，由此可看出風險管理在軟件項目中的重要性。一個項目的風險有許多來源，如客戶、進度、開發(fā)過程、人力資源等，忽視風險的后果可能是成本超支、進度推后，最嚴重導致項目失敗。

MSF的風險管理原則是：①風險應該在整個項目的進程中一直被估計，并且作為項目決策的依據之一。②有效的風險管理過程覆蓋了所有關鍵的人力、過程、商務及技術領域。③風險在納入管理前必須被清晰的表述。④重要的風險必須優(yōu)先被處理。

MSF風險管理過程包括以下階段：風險識別、風險陳述、風險分析、處理計劃、風險跟蹤、風險控制、風險解除。

在中小企業(yè)的風險管理過程中，一般項目經理擔任風險管理員的角色，但同時需要另外的資深開發(fā)人員輔助，一起完成風險管理的任務。他們負責維護十大風險清單（不一定非要列出十個），并在項目進程中隨時對風險清單進行更新。對風險的評級MSF采用的方式是：風險影響程度=風險的可能性×風險發(fā)生造成的損失，根據風險影響程度的大小對風險進行評級。

在項目實施中，A企業(yè)總結的一些高風險事件主要有：需求的不準確、項目時間表過于短促、開發(fā)一個從前沒進入的領域軟件、開發(fā)人員對工具的不熟悉、人員流動頻繁、使用了外部軟件中間件等。如果對這些風險不提前做出計劃，可能會對項目的順利進行造成極大的破壞，甚至直接導致項目失敗。針對每一個風險，A企業(yè)需要列出who， when， how， how much等事項，并對風險處理的結果進行追蹤，最后決定是否已經解除風險或再進入風險處理循環(huán)。

三、 總結

引入MSF管理思想后，項目的成功率比原來增大了很多。企業(yè)研發(fā)流程必須盡可能MSF模型化，工具化，沒有銀彈。所有的這一切都是在一個公共的工具平臺上，至少需要需求管理工具、版本控制工具、日志構建工具、Bug管理工具等。德魯克認為，管理既不是科學，也不是藝術，管理是實踐，正如軟件工程的世界級大師Ivar Jacobson所說，“我相信沒有一種技術、沒有一種流程能夠解決所有的問題，我更相信基于實踐的方式。你需要用不同來源的實踐，結合自己的流程，改進自己的流程和工作方式，這樣才能立于不敗之地?！?/p>

參考文獻：

1. （美）邁克爾·科索馬羅，理查德·賽爾比 著.程化 譯. 微軟的秘密. 北京：北京大學出版社， 西蒙與舒斯特國際出版公司，1996.

2. （美）史蒂夫·麥克康奈爾 著，余孟學 譯. 微軟項目求生法則. 北京：機械工業(yè)出版社，2000.

3. （美）Karl E. Wiegers 著.陸麗娜，王忠民，王志敏 譯. 軟件需求. 北京：機械工業(yè)出版社，2000.

4. （美）卡耐基梅隆大學軟件工程研究所著.劉孟仁 譯. 能力成熟度模型（CMM）：軟件過程改進指南. 北京：電子工業(yè)出版社，2001.

5. （美）Frederick P. Brooks Jr. 著. 人月神話（影印版） The Mythical Man-Month. 北京：中國電力出版社，2003.

6. 匡曉紅. 基于MSF的風險管理模型. 中國科技信息， 2007，（17）.

基金項目：福建省社會科學規(guī)劃一般項目（項目號：2011B223）。

作者簡介：劉震宇，廈門大學管理學院教授、博士生導師；陳思恩，廈門大學管理學院博士生，高級工程師；張耕，廈門大學國際經濟與貿易系副教授。

收稿日期：2012-10-26。