1、Microsoft 解決方案框架 MSF 項目管理準則 v. 1.1發(fā)布日期： 點擊這里下載本白皮書的副本Microsoft 解決方案框架白皮書摘要Microsoft 解決方案框架 (MSF) 具有一種分布式的、能夠提高責任性的項目管理小組方法，這個框架還具備很大范圍的靈活性，既適用于小型項目，也適用于非常巨大和復雜的項目。本白皮書描述了這種分布式小組方法的原理，并解釋了項目經(jīng)理與 MSF 小組模型之間的關系。盡管項目管理對于小型項目也很重要，但是本白皮書把重點放在具有擴展小組的大型項目上。雖然本文沒有涉及到項目管理領域的所有方面，但是給出了用于規(guī)劃和評估的推薦做法。本頁內(nèi)容框架概述介紹MSF

2、 基礎原理關鍵概念MSF 項目管理的特征用于 MSF 小組的精選建議計劃安排建議結(jié)論尾注框架概述為了使信息技術 (IT) 項目的成功最大化，Microsoft 提供了一個打包的指南，用于有效地設計、開發(fā)、部署、操作和支持建立在 Microsoft 技術之上的解決方案。這一知識來自于 Microsoft 在大規(guī)模軟件開發(fā)和服務操作項目上的經(jīng)驗，來自于 Microsoft 顧問在為企業(yè)客戶實施項目時所獲得的經(jīng)驗，以及來自于全球 IT 行業(yè)的最佳知識。本指南安排成相互補充、緊密集成在一起的兩個知識體系，或者叫做框架。它們分別是 Microsoft 解決方案框架 (MSF) 和 Microsoft 操

3、作框架 (MOF)。在預算范圍內(nèi)按期創(chuàng)建一個業(yè)務解決方案需要一種經(jīng)過檢驗的方法。MSF 為成功地規(guī)劃、設計、開發(fā)和部署 IT 解決方案提供了經(jīng)過檢驗的做法。與規(guī)定的方法相反，MSF 提供了一個可以伸縮的靈活框架，以滿足任何規(guī)模的組織或者項目小組的需要。MSF 指南由原理、模型和用來管理人員、項目和技術元素的準則，以及它們的折衷（大多數(shù)項目都會碰到）組成。Microsoft 操作框架 (MOF) 提供了技術指導，從而讓組織能夠在使用 Microsoft 產(chǎn)品和技術創(chuàng)建的 IT 解決方案上取得任務關鍵系統(tǒng)的可靠性、可用性、可支持性，以及可管理性。MOF 的指導致力于解決人員、過程、技術和管理等問題

4、，這些問題都與操作復雜的、分布式的、差異巨大的 IT 環(huán)境有關。MOF 基于一套行業(yè)最佳做法，稱為 IT 基礎結(jié)構(gòu)庫 (ITIL)，由英國政府的政府商務辦公室 (OGC) 頒布。返回頁首介紹MSF 最引人注目的一個特性是其缺乏一個稱為項目經(jīng)理的角色或者職位頭銜。這對于一個用來解決 IT 項目成功完成相關問題的框架來說是很令人意外的。但是 MSF 非常強調(diào)與項目管理有關的準則和能力。本白皮書總結(jié)了項目管理準則的關鍵方面，并描述了 MSF 如何來處理它們。本文闡述了 MSF 的基礎原則如何在實施項目管理中衍生一些與眾不同的概念和做法。本白皮書還描述了為了支持整個小組，MSF 程序管理角色如何提供專

5、門的項目管理技能，并描述了典型的項目管理活動如何分布到 MSF 小組的各個領導身上。本白皮書并非旨在提供項目管理的指南，它也不會試圖解釋有經(jīng)驗的項目經(jīng)理所使用的很多技巧。它的目的在于說明 MSF 的原理如何產(chǎn)生出項目管理方法，其中項目管理的職責被分布到了小組領導的身上。項目管理的專家提供一種以促進和指導為基礎的方法，而不是強行去控制小組里的其他成員。在閱讀本白皮書之前，請先閱讀 MSF 小組模型白皮書。返回頁首MSF 基礎原理盡管沒有在本文里討論，但是 MSF 項目管理準則會以某種方式應用 MSF 所有的原理，這一準則與下面的幾點直接相關。清晰的責任共擔職責MSF 小組模型基于這樣一個前提，即

6、小組里的每個角色都代表了對項目的一種獨一無二的觀點，沒有哪一個人能夠成功地代表所有角色的所有質(zhì)量目標。但是客戶需要一個對項目狀態(tài)、行動和當前問題等信息的權威來源。為了解決這一兩難的境地，同級的小組必須把對客戶的清晰責任與對整體成功的共同職責結(jié)合起來。在小組內(nèi)部，每個角色都對實現(xiàn)自己質(zhì)量目標所需要的活動負有責任。小組的每個成員都對項目的整體成功和解決方案的質(zhì)量都負有職責，并希望根據(jù)他們自己的知識提供自己的想法和觀察，即使是在那些他們并不負責的領域里。具體來說，MSF 小組角色共同擔當著項目管理很多方面的職責，例如風險管理、時間管理、質(zhì)量管理、規(guī)劃、日程安排、小組招聘，以及人力資源管理等。被賦予權

7、力的小組會更加有效在一個高效的小組里，成員被賦予權力來交付他們自己的承諾，他們相信只要是他們所依賴的、由別人來承擔的承諾，別人就能夠交付承諾。類似的，客戶有權認為，小組會兌現(xiàn)其承諾，并就此進行規(guī)劃。任何延遲或者改變都應該被盡快報告。MSF 小組向其成員賦予了完成他們的承諾所需要的權力。這對于項目管理這一角色監(jiān)視過程的能力具有深遠的影響。如果沒有被賦予的權力和承諾，小組管理者就必須不斷檢查，看小組成員是否偏離了方向。一旦他們確信任何延遲都會在發(fā)現(xiàn)的時候被立即報告，小組領導就會變成一個具有更大促進作用的角色，幫助小組成員評估他們的真實位置，同時為他們提供指導和幫助。對過程的監(jiān)視分布在小組的各處，并

8、成為一個支持性的角色，而不是一個控制性的角色。返回頁首關鍵概念要理解 MSF 的項目管理方法，理解 MSF 定義下列概念和術語的方法就顯得尤為重要了：MSF 中的準則MSF 認為，多個非技術領域里的專長是 MSF 小組模型里所有角色需要具備的重要能力。這就叫做準則。要獲得更多的信息，請參閱 MSF 小組模型白皮書。當前，MSF 有三個準則，分別是風險管理、就緒管理和項目管理。MSF 認為，這些準則已經(jīng)發(fā)展出了建立在多個行業(yè)基礎上的最佳做法，而不僅僅只在信息技術 (IT) 行業(yè)里。這些做法常常能夠被應用到 IT 操作和其他業(yè)務過程以及 IT 項目里。MSF 沒有重新發(fā)明這些做法，而是總結(jié)了項目小

9、組需要知道的、關于這些準則的一些內(nèi)容，并加入了 Microsoft 小組在過去幾年里所領悟到的東西。為了有效地實施這些準則，MSF 所有的小組角色都必須在每個領域里具有足夠高的能力。什么是項目管理？在描述 IT 項目里的項目管理之前，不論什么類型的項目，首先理解項目管理的定義是很有好處的：一個項目就是一次臨時的投機，它具有確定的開始和結(jié)束，其目標是創(chuàng)造一項獨特的產(chǎn)品或者服務。 項目管理是用來實現(xiàn)項目目標的一套知識、技能、工具和技術，而項目目標就是一致認同的質(zhì)量、成本、日程安排和約束等的參數(shù)。(I)在一些公司和國家里，程序這個術語用來描述被放在一起的項目組。為了與叫做程序管理的 MSF 小組角色

10、群區(qū)分開來，一組項目被叫做項目組合。MSF 對項目管理職責、技能和活動的領域進行了下列分類。(ii).項目管理領域描述項目規(guī)劃跟蹤改變控制集成和同步項目計劃；設置用于管理和跟蹤變化的步驟和系統(tǒng)范圍管理定義、分解工作范圍（項目范圍）；管理項目折衷日程安排管理利用小組估計生成日程安排，任務排序、將資源與任務進行匹配、應用統(tǒng)計學的技術、日程安排維護成本管理根據(jù)小組時間估計來準備成本估計；過程報告和分析；成本風險和價值分析人員資源管理規(guī)劃資源、構(gòu)建小組、解決沖突、（為項目而）規(guī)劃技能就緒交流管理交流規(guī)劃（小組、客戶贊助商、用戶、利益相關人），項目狀態(tài)報告風險管理促進和推動小組風險管理過程；維護風險文檔

11、采購邀請承包商參與服務和或硬件軟件的投標；準備要求建議 (RFP)，管理供應商或者分包商；合同和協(xié)議的管理和談判；開放采購訂單和批準發(fā)票質(zhì)量管理質(zhì)量規(guī)劃，即確定要使用哪些標準，提供質(zhì)量標準和質(zhì)量測量過程的文檔盡管本白皮書無法給出關于上述領域的完整指導，但是本文檔后面會提供經(jīng)過挑選的 MSF 推薦做法。項目管理不是由項目經(jīng)理一個人完成的在日常的言談中，項目管理這個術語可以被用描述一個角色以及在某個領域里的技能和專長。例如，想想“項目管理層說他們現(xiàn)在應該已經(jīng)完成了它”這樣的說法，以及“太空機構(gòu)一般都會有優(yōu)秀的項目管理能力”這樣的說法。這種差別很重要，因為項目管理作為一種活動是由很多人（共同）完成的

12、，而這些人并不都是項目經(jīng)理。在 MSF 里， 項目管理總是用來指上面所列領域里的特定知識和技能，而不是一個角色或者職位頭銜。而項目經(jīng)理這個術語將會被用來描述擅長進行項目管理的人。項目管理和 IT 特定過程總的來說，項目管理由一些知識和技術組成，這些知識和技術可以廣泛應用到實施這些項目的任何行業(yè)領域里。每個行業(yè)領域（例如太空行業(yè)、建筑行業(yè)、IT 行業(yè)等等）都有最適合該行業(yè)的特定過程、階段、角色和做法。為了成功地實施項目，這些針對行業(yè)的過程就必須與一般的項目管理做法形成互補。MSF 為 IT 項目提供了過程和推薦的做法。它與項目管理準則的關系見圖 1。圖 1：MSF 與項目管理準則的關系查看完整的

13、圖像。在這上面的圖里，針對行業(yè)的領域是 MSF 過程的五個階段。針對行業(yè)的項目管理活動的一個例子是用于跟蹤錯誤的推薦做法。項目管理的一般知識領域在左邊。一個例子是用于管理合同或者跟蹤預算的推薦做法。交叉代表了特定的項目管理做法，后者是 MSF 的特征。這些都會在后文進行描述。返回頁首MSF 項目管理的特征MSF 方法的這些與眾不同的特征將在這里描述，并在后面進行更加詳細的討論：項目經(jīng)理角色的大多數(shù)職責都包含在 MSF 程序管理角色群里。在需要 MSF 擴大小組的大型項目里，項目管理活動在多個層次發(fā)生。某些大型的或者復雜的項目需要專門的項目經(jīng)理或者項目管理小組。項目管理角色包含在程序管理里MSF

14、 程序管理角色群包括了下面所示的職能職責領域。在小型項目里，所有的職能職責一般都是由一個程序經(jīng)理來處理的。隨著項目規(guī)模和復雜性的提高，這一角色群分解成了兩個專門的分支：一個處理解決方案體系結(jié)構(gòu)和規(guī)范，另一個處理項目管理。程序管理如何與小組領導一起工作要理解項目管理如何在 MSF 里工作，就有必要理解小組模型如何擴大規(guī)模、進行規(guī)劃、通訊，以及決策。關于這一點的更多信息，請參閱 MSF 小組模型白皮書。如何去分布小組管理，在很大程度上要取決于項目的規(guī)模和復雜性。MSF 是一個高度可伸縮的框架，它能夠被用在只需要兩個或者三個人的小型項目里，也可以用在非常大型的項目里。Microsoft 內(nèi)部的產(chǎn)品小

15、組就涉及成百甚至上千個小組成員。MSF 已經(jīng)把從 Microsoft 小組組織里學到知識進行了歸納，供更大范圍的 IT 項目使用。MSF 的可伸縮性在很大程度上來自于小組模型。小組模型可以以兩種方式擴大規(guī)模：1.通過將小組角色抽象成為一套職能職責，而不是特定的職位描述。通過這種方式，每個角色的職能就不會被限定到個人身上。一個角色可以被擴展成為多個角色群，每個都專注于一系列目標更加明確的職責。一個或者多個個人可以擔當這些更加專業(yè)的角色。2.使用功能小組和職能小組的各種組合，以創(chuàng)建任意數(shù)量的可能的大型小組結(jié)構(gòu)。對功能小組和職能小組的描述見下面。職能小組職能小組是存在于一個角色內(nèi)部的子小組，當一個角

16、色里的任務達到要求使用專門資源的時候它才會被組建。職能小組的一個關鍵方面并不簡單的就是角色需要一個以上的人來擔當，而是在其成員中有一個對任務的陳述。圖 2 是其中一個例子。小組領導是大型小組其他成員的集成點。小組領導在其子小組這一層次負有一些項目管理的職責。圖 2：負責用戶體驗的職能小組示例查看完整的圖像。功能小組功能小組是跨學科的子小組，它們被安排在解決方案的特定功能周圍。功能小組由組成小組模型的六個角色構(gòu)成。圖 3 顯示了一個功能小組。程序管理角色也是為大型小組提供集成點的小組領導。功能小組的結(jié)構(gòu)是遠程或者“離岸”子小組（用于為解決方案構(gòu)建相當分散的組件）的有力候選對象。圖 3：功能小組示

17、例查看完整的圖像。擴大程序管理職能的規(guī)模圖 4 顯示了如何在三個項目規(guī)模層次處理項目管理活動。在項目 A 里，所有的角色都由大約六個或者更少的人來擔當，所有的項目管理活動都由程序管理來處理。這并不意味著其它的角色就不會為項目管理作出貢獻。事實上，這意味著他們在負責規(guī)劃、時間估計和識別他們各自領域里的風險。圖 4：項目管理的可伸縮方法查看完整的圖像。在項目 B 里，大多數(shù)或者所有的角色都由子小組來擔當，每個角色都有一個小組領導。小組領導對其各自的子小組進行項目管理。程序管理角色群擁有負責整個項目的項目管理活動。要注意的是，功能小組沒有在圖上顯示出來，但是它們也是子小組。由于每個子小組都是跨學科的

18、，所以每一個都有一個程序管理領導。項目 C 和項目 B 類似，盡管它有與其規(guī)?；蛘邚碗s性相關的特殊風險。復雜的項目，就像用在 MSF 里的一樣，意味著項目具有與下列因素相關的高風險：大規(guī)模或者高成本。地理上分散的小組。小組成員隸屬于多個公司、組織或者分包商。固定的或者高度受限的預算或者日程安排。需要技能和時間來管理的合同或者法律問題。為了降低這些風險，程序管理角色群有一個職能小組，它包括專門的項目經(jīng)理和解決方案架構(gòu)師。要注意的是，風險的限度對于所有的組織和項目來說都是不同的。對于某個組織來對成本非常高的東西對于其他組織來說可能未必。這完全取決于項目早期進行的風險評估。項目管理職責上面一個章節(jié)討

19、論了如何把不同規(guī)模和復雜性層次的項目管理活動分布給各個小組成員。本章就將描述這些活動。圖 5 描述了每個角色和程序管理的小組領導所具有的項目管理職責。在復雜項目（例如圖 4 里的 項目 C）里，專門的項目經(jīng)理所關注里的領域與程序管理的相同，只不過是在一個獨有的基礎上。要注意的是，相同的職責領域常常會由項目層和子小組層來負責。圖 5：小組領導的項目管理職責查看完整的圖像。小組領導小組領導要為其子小組準備計劃，以描述工作要如何完成，如何根據(jù)計劃跟蹤實際的工作，如何管理范圍和變化，如何給子小組里的特定任務分配資源，以及如何協(xié)調(diào)子小組的內(nèi)部溝通。小組領導所進行這些活動都需要子小組各個成員的參與和輸入。

20、在參與全部風險識別的時候，小組領導要專門負責識別其角色專長領域里的風險。圖 5 里有三個地方可以將小組領導的職責與其他成員的職責模式區(qū)分開來：1.項目的成本管理一般都被作為程序管理職責集中到一起了。把這些職能分布到領導身上將會分散大家的注意力，并可能引起混亂。2.采購職責由程序和或發(fā)布管理來處理，而不是由其他的小組領導來處理。程序管理會處理項目以及多種采購服務的大多數(shù)合同事宜。（把項目的一部分）分包一個 Web 設計公司，讓其加入小組就是這樣的一個例子。發(fā)布管理作為小組 IT 操作的代表，會處理構(gòu)建解決方案所需的以及小組開發(fā)和測試實驗室環(huán)境所需的硬件、軟件和設備等的采購工作。3.在整個項目層的

21、溝通管理由程序管理和產(chǎn)品管理來共同承擔。產(chǎn)品管理會為客戶、利益相關人，以及任何外部人員創(chuàng)建和交付溝通計劃。程序管理會規(guī)劃和負責項目溝通，例如報告狀態(tài)、主持小組會議，以及類似的事情。溝通管理還包括小組以外的溝通規(guī)劃、合同指定點的分配和過程的報告。程序管理除了負責高層的解決方案體系結(jié)構(gòu)和編寫職能規(guī)范（就如在小組模型里描述的那樣），程序管理還擁有把項目作為一個整體的所有項目管理領域。程序管理會把小組計劃集成到主要計劃里，同步日程安排，并管理跨小組的依賴性。把解決方案設計的職責和職能規(guī)范放到同一個角色里作為日程安排和成本職責有一個巨大的好處：它會打破相對于成本而言的設計過度的傾向與日程安排所暗示的之間

22、的平衡。大型、復雜項目里的項目管理隨著項目變得更大或者更復雜，它可能會取代管理職能規(guī)范、更新日程安排、發(fā)出小組溝通、報告過程和進行其他的項目管理活動。要應付這個，把程序管理角色群的職責分割成解決方案體系結(jié)構(gòu)和專門的項目管理角色常常是有道理的。項目監(jiān)督服務在某些方面，一個大型的項目必須要做的事情和小型業(yè)務必須要做的相同：跟蹤財務、采購供給和服務、管理員工的業(yè)務、提供入門培訓、安裝小組工作設施等等。在大型項目里，對狀態(tài)、成本和日程安排的例行跟蹤變得非常耗時。為了讓項目經(jīng)理把精力放在最緊迫的問題上，更多日常的項目管理活動被委派給了項目監(jiān)督（或者項目支持）角色。項目監(jiān)督服務還為小組領導提供了支持，幫助

23、其維護小組日程安排和其他的管理活動。客戶的責任客戶常常想要一個實現(xiàn)整個項目成功的責任點。有些組織希望項目經(jīng)理來扮演這個角色。有時候這在大型或者復雜的項目里會有保證，但是這種方法會使得小組角色責任失衡，從而導致項目表現(xiàn)不佳。MSF 滿足了客戶為確保滿意度而產(chǎn)生的對監(jiān)督點的需要，同時在同級小組里保留職責。在 MSF 同級小組里，小組的每個角色都在內(nèi)部負責自己的活動。此外，擔當每個角色的個人通常也都要在項目小組之外的一些管理結(jié)構(gòu)里負責。由于 MSF 認為，并不是所有的小組成員都工作在同一個公司或者組織里，所以這些責任路徑會通往這些個人所屬的組織、團隊或者部門。這里的關鍵點是：在這個主題上沒有絕對的事

24、。在直接的項目小組之外，組織的報告結(jié)構(gòu)和服務關系之間存在很多可能的不同之處。識別項目的責任路徑。闡明在小組自身之外，誰要為項目的什么方面負責。MSF 小組模型以下列方式提供了客戶責任：產(chǎn)品管理會維持與客戶之間的關系，并扮演客戶支持者的角色。這一角色的目標就是客戶的滿意度。程序管理表現(xiàn)的目標是在項目約束內(nèi)成功地交付項目。產(chǎn)品和程序管理會共同工作以便在項目約束之內(nèi)滿足客戶需要。這兩者共同分擔項目的整體成功，盡管它們的角色都在為不同的目標而努力。如果發(fā)生了產(chǎn)品和程序管理都無法解決的問題，那么這些問題都會逐步升級成為整個項目的責任路徑。返回頁首用于 MSF 小組的精選建議下面推薦的項目管理做法是用于

25、MSF 小組領導和程序管理的。這些與出現(xiàn)在圖 5 里的某些，但不是全部的項目管理職責相對應。范圍管理范圍管理的目的是確保項目能夠識別完成解決方案所需要的所有工作，而不會在沒有先期的調(diào)查和同意的情況下就偏離目標去進行范圍以外的活動。構(gòu)想階段的范圍在項目的早期階段，項目的寬范圍必須被識別和列入文檔。在 MSF 構(gòu)想階段，小組會為解決方案生成一個沒有邊界的前景。然后范圍就會被識別，成為第一個版本。這在前景范圍文檔里有描述，而且在項目繼續(xù)之前經(jīng)過了小組、客戶和利益相關人的認可。在這個階段過程中，范圍只能在描述特性這一層次被廣義地理解。解決方案范圍和項目范圍范圍可以指解決方案范圍和項目范圍。解決方案范圍

26、是要被構(gòu)建的特性和交付內(nèi)容的總和。項目范圍是交付解決方案所必須完成的所有工作的總和。這個術語用 MSF 設計過程來定義解決方案范圍。范圍定義在規(guī)劃階段，整個項目范圍必須被細分成為更小的、可管理性更強的部分。這個過程會闡明項目之外的特殊領域。通常，這些都是會產(chǎn)生誤解的具有特殊風險的領域。在定義范圍的過程中，小組會識別構(gòu)建每個特性和交付內(nèi)容所需的任務和技能類型。這會被歸檔放到一個工作分解結(jié)構(gòu) (WBS) 里，本白皮書下文即將討論這一結(jié)構(gòu)。范圍改變控制一旦定義了范圍并為其制定了基準，小組就會將其置于改變控制之內(nèi)。對范圍的改變必須同時由小組和客戶來檢查及認可。好的改變控制在一定程度上涉及好的折衷決策。

27、MSF 折衷三角形和折衷矩陣是以可控方式推動改變的有用工具。要獲得更多信息，請參閱 MSF 過程模型白皮書。準備計劃規(guī)劃作為一項活動會發(fā)生在項目的始終。在構(gòu)想階段，小組會安排創(chuàng)建項目交付內(nèi)容所需要的高層方法。例如，測試方法會描述測試的類型、工具以及所需的技能。根據(jù)項目的規(guī)模不同，這可能只有一頁或者兩頁紙，甚至只是一段文字。盡管計劃會在每個階段改進和更新，但是大多數(shù)的規(guī)劃工作都會在 MSF 規(guī)劃階段進行。在這個階段里規(guī)劃過程的一般順序是：設計過程（你要構(gòu)建什么？）規(guī)劃過程（你要怎么來構(gòu)建？）對開發(fā)進行日程安排（什么時候構(gòu)建它？）這些可能會在某些方面相互重疊，但是在下一個過程能夠取得豐碩的成果之前

28、，必須為先前的過程制定一個基準。本章就將集中討論規(guī)劃過程。重新使用文檔項目小組一直都會因為要把規(guī)劃的時間和花費壓到最小而倍感壓力。在壓縮規(guī)劃花費的同時怎么才能夠獲得好的規(guī)劃所帶來的好處呢？答案就是巧妙地搜集和重復使用項目計劃文檔。意識到項目計劃文檔是有價值的知識產(chǎn)權的組織會投資把它們組織和維護起來，放到一個能夠輕易訪問得到的儲備庫里。在創(chuàng)建新的計劃之前，小組應該總是搜尋任何已經(jīng)被完成的東西。一旦一個項目完成了，項目文檔就應該被歸檔，放到一個未來的小組能夠重復使用的地點。項目計劃在 MSF 里，項目計劃指的是一套描述如何完成項目交付內(nèi)容的文檔。職能規(guī)范用來描述將要構(gòu)建的內(nèi)容。主項目計劃是每個角色

29、的小組計劃的集成和累積。每個小組角色都擁有描述自己要如何完成交付內(nèi)容的計劃。MSF 沒有規(guī)定所有項目都必須具有一個適用于所有情況計劃列表。下面的默認列表涵蓋了軟件開發(fā)和基礎結(jié)構(gòu)部署項目里常見的規(guī)劃領域。在小型項目里，這些計劃中的某一些可能會被組合在一起。有些項目可能需要額外的計劃。計劃類型驅(qū)動角色溝通計劃產(chǎn)品管理開發(fā)計劃開發(fā)培訓計劃用戶體驗安全計劃開發(fā)、發(fā)布管理測試計劃測試預算計劃程序管理用戶教育計劃用戶體驗部署計劃發(fā)布管理采購和設備計劃發(fā)布管理、程序管理試驗計劃發(fā)布管理工作分解結(jié)構(gòu)工作分解結(jié)構(gòu) (WBS) 是一個面向交付內(nèi)容的、經(jīng)過分組的項目工作元素，用來組織和定義項目的總范圍 (iii)。

30、它是要被完成的工作的大綱。沒有納入 WBS 結(jié)構(gòu)里的工作就不在項目的范圍之內(nèi)。小組領導和項目管理將 WBS 用作項目管理工具，來構(gòu)建計劃和日程安排。在 MSF 里，創(chuàng)建 WBS 是一項需要所有小組角色參與的集體工作。每個角色都主要負責定義其各自領域里的工作細節(jié)。在大型項目里，子小組（職能和或功能小組）可能需要單獨地集體討論所需要進行的工作。小組領導會把集體討論的結(jié)構(gòu)歸檔，并把結(jié)果呈交給核心（領導）小組。項目管理然后就會把這些結(jié)果同步成為一個共同的 WBS。優(yōu)點如果被當作一套數(shù)據(jù)而不是特定的文檔的話，那么WBS 的價值會得到最全面的理解。這一數(shù)據(jù)在和其他項目數(shù)據(jù)結(jié)合到一起的時候，可以用來創(chuàng)建計劃

31、、日程安排、預算，以及其他項目交付內(nèi)容。WBS 能夠用縮進式列表或者塊關系圖來顯示，并能夠用各種工具來創(chuàng)建，比如電子數(shù)據(jù)表、文字處理程序，或者項目管理軟件。WBS 具有下列優(yōu)點：估計 。為要被估計的任務提供一個基準。所提供估計結(jié)果用來確定成本和日常安排。提供資源。通過明確要被完成的工作項目，員工和技能資源就會成為可知的。如果項目的利益相關人要詢問理由，這還會有助于說明所需要的資源。排序。提供一個能夠用來分析依賴性和資源約束的任務基準列表，以便將其發(fā)展成為日程安排。風險識別。幫助小組在識別風險的時候考慮每項任務。職責。可以被用來生成職責矩陣。WBS 和職能規(guī)范以及主項目計劃之間的可跟蹤性職能規(guī)范

32、、主項目計劃和 WBS 之間存在一個可跟蹤的關系。它反映了交付內(nèi)容和構(gòu)建交付內(nèi)容所需任務之間的關系。對于職能規(guī)范里的每個特性或者組件，WBS 列出了與完成該交付內(nèi)容相關的任務。在職能規(guī)范里，特性或者組件被分組的方式同與它們相關的任務出現(xiàn)在 WBS 里的方式不同。如果一個特性在 WBS 里沒有與之相對應的任務項目，那么它可能會在后來的估計過程中“掉入裂縫”，而這可能會導致不切實際的日程安排或者預算。主項目計劃和 WBS 以一種互補的方式工作。WBS 會簡要地列出每個任務。任務如何進行、質(zhì)量標準和詳細的子任務或者清單等的詳細信息都被歸檔進了計劃。圖 6 是 WBS 能夠如何成為維護規(guī)范、計劃和日程

33、安排之間可跟蹤性的強大工具。圖 6：WBS 提供了規(guī)范、計劃和日程安排之間的可跟蹤性查看完整的圖像。構(gòu)建工作分解結(jié)構(gòu)每個小組都會識別生產(chǎn)項目交付內(nèi)容所需要的特定活動?；顒拥木唧w細節(jié)都由各種角色或者子小組以清單和項目的形式所有和跟蹤。在 MSF 里，層次最低的活動出現(xiàn)在主項目計劃里，而不在 WBS 里。這些會合成為值得在整個項目層進行跟蹤和報告的大型任務，這就是 WBS。小組領導與其他角色小組碰面，以分解工作要求。通過與職能規(guī)范和其他交付內(nèi)容的規(guī)范一起工作，所需要的工作就要被識別和分解成微小的活動和任務。這一過程就叫做工作分解。MSF 風險管理過程的結(jié)果之一就是其它響應風險（有時候也叫做“威脅”

34、）或者意外計劃和活動的任務。這些任務必須像其他所有的任務一樣被加到 WBS 里，被估計、規(guī)劃和列入如日程安排。要考慮連續(xù)開設小組工作分解講座和風險集體討論講座。WBS 的第一層應該包括項目生命周期的一個階段。MSF 過程模型在這一點上做得很好。MSF 所建議的中間里程碑與交付內(nèi)容的完成以及基準的制定是密不可分的。中間里程碑還會構(gòu)成一個自然的第二層。在這一層次之下，可以識別所有的交付內(nèi)容并針對每一個都分解任務。這一過程也叫做工作分解或者任務分解。任務分解指南在進行任務分解的時候，建議采用下列指南：能夠被實際地估計。被認為不會少于一天，不會多于 40 天（對于 IT 項目而言）。有成果豐碩的結(jié)果和

35、交付內(nèi)容。能夠被完成，而不會有較大的中斷?？梢员环峙浣o一個人負責其完成。要比其他的更能夠分解為特定的層次。能夠把高風險的活動分解為其他低風險的活動。除了最上面的一個或者兩個層次，要使用一個動賓短語來描述任務。例如，使用“設計數(shù)據(jù)庫架構(gòu)”，而不是簡單地用“數(shù)據(jù)庫架構(gòu)”。以大綱的形式包括三到五個層次。WBS 會在項目過程中反復發(fā)展，但是會在規(guī)劃階段中定型。從下到上的估計IT 項目的估計應該由那些日程安排里規(guī)定的人員來進行。從下到上的估計是對來自多個小組成員的估計進行開發(fā)和集成的過程。它帶來了下列好處：更高的準確性。 由那些專門人員作出的估計要更加準確，因為進行估計的人員具有從事類似工作的經(jīng)驗。責任

36、。 開發(fā)自己工作估計的人會感到他們對自己工作的責任更大。他們也會對成功達到自己作出的估計感到更大的責任。賦予小組權力。 擁有由小組開發(fā)的日期而不是由管理指定的日期會賦予小組權力，因為日程安排建立在小組成員能夠接受的實際估計之上。集成小組估計每個小組領導及其子小組，對準備完成其角色領域里的交付內(nèi)容所需的時間估計負有職責。例如，開發(fā)領導會為開發(fā)人員準備估計；用戶體驗領導會利用來自小組的信息為用戶體驗 (UE) 交付內(nèi)容準備估計等等。程序管理角色會推動小組估計過程，并把所有的估計集成（“累積”）成為一個主日程安排和預算。軟件項目的估計IT 項目的成本在很多程度上由勞動成本構(gòu)成，所以對工作努力的估計是

37、獲得成本和日程安排估計所必需的數(shù)據(jù)輸入信息。設置正確的預期估計會為未來的某種結(jié)果設置一些預期。由于這個原因，設定一些關于估計準確性的正確預期與生成預期所需要的技術一樣重要。程序和產(chǎn)品管理角色群必須努力工作以確保下面這些內(nèi)容的共同預期：估計要依靠規(guī)范。 開發(fā) IT 解決方案和自定義建造一個房屋很相象。在特性被仔細定義之前就了解其成本是很重要的。這不是說規(guī)范就是項目估計所需要的所有東西。其它的工作項目，例如客戶溝通、項目會議、狀態(tài)報告等，都需要花時間，而且必須在估計里予以考慮。為折衷做好準備。 利用折衷矩陣來討論折衷三角形和設置默認的優(yōu)先權有助于小組和客戶設置共同的預期。某些不精確是無法避免的。

38、由于解決方案的開發(fā)是一個不斷改進的過程，所以估計包含有一定的變動空間。在每個里程碑處重新估計。小組應該隨著項目的進展而提供一系列經(jīng)過更多改進的估計。不確定性和估計的準確性軟件估計是一個漸進的改進過程。圖 7 說明了所謂的軟件估計的“不確定性圓錐”（估計會聚）。在項目早期，對真正成本的估計的變動范圍還非常廣。這個范圍會隨著項目的推進而逐漸變小。要注意的是，在前景范圍認可里程碑處，估計可以低兩個數(shù)量級，或者高 0.5 個數(shù)量級。所顯示的特定數(shù)據(jù)值取自于 20 世紀 90 年代中期的調(diào)查數(shù)據(jù)，它們不應該被過于生搬硬套地使用。重要的是理解在每個階段數(shù)量級的變化。這里所要學習到的知識是，在構(gòu)想階段，小組

39、會制定出時間和成本的估計范圍（有時候也叫做“球場估計”）。一定不要在這一階段提供一個固定的成本估計或者固定的日程安排估計。需要弄清楚的是，這些估計在構(gòu)想范圍認可里程碑處可能會因為某個重大的因素而發(fā)生變化。圖 7：不確定性圓錐查看完整的圖像。來源： 摘自 Boehm 及其他作者的 Cost Models for Future Lifecycle Processes: COCOMO 2.0， 1995 (iv)。位于任務分解最底層的估計在任務層次準備工作估計的方式有多種。所有的方式都會從把 WBS 里的每個任務分解成為更小的活動開始。這在子小組層進行，并由每個小組領導來協(xié)調(diào)。然后，會生成一個針對每

40、個最底層活動的估計。這些估計會被集中到一起，在 WBS 里創(chuàng)建一個任務估計。檢查先前項目里的真實數(shù)據(jù)是為估計設定基準的最好方法之一。聰明的組織會收集和分析這些數(shù)據(jù)。很多項目活動都有行業(yè)標尺，能夠提供好的衡量基準。一項更加準確且值得推薦的技術是對每個低級別的活動都生成三點估計。三點估計包括對應于每個任務的一個樂觀估計值、一個不利估計值和一個最有可能的估計值。應該有一個標準來明確這些值都意味著什么。不利估計值不應該意味著它是所有可能方案的最差的。樂觀和不利估計應該要基于合理的和可能的風險。一旦低層次的活動匯總成為了 WBE 層次的任務，每個任務就有了三個層次的估計值。小組領導會把這些信息轉(zhuǎn)交給程序

41、管理用于成本分析，然后使用估計數(shù)據(jù)來準備日程安排。PERT 分析一旦所有任務的估計被集中成為了 WBS，程序管理（或者專門的項目經(jīng)理）會用統(tǒng)計分析來調(diào)整整個時間估計。完成這一個目標的技術有多種，但是最常用的一種是 PERT（程序評估檢查技術）。PERT 會用到三點估計，并計算分布的平均值。這會被用來規(guī)劃最有可能的結(jié)束日期，而不是最有可能的估計值。它還會根據(jù)關鍵路徑上所有任務的變化提供多種估計結(jié)果。對 PERT 的完整描述不在本文的討論范圍之內(nèi)。但是項目管理工具，例如 Microsoft Project，提供了進行 PERT 分析的能力。返回頁首計劃安排建議計劃安排管理包括確保項目按期完成所需的

42、過程。任務排序一旦項目的任務和活動被歸檔進入了 WBS 并進行了估計，它們之間的依賴性就會被識別。例如，如果描述某個特性的職能規(guī)范沒有完成，那么該特性的用戶文檔草案也無法完成。應該在任務的最小級別來識別依賴性。時間搏擊使用內(nèi)部時間限制來保持項目小組在指定特性和活動優(yōu)先順序上的壓力 叫做“時間搏擊”。這不應該被隨意用來減少小組的時間估計。正確的“時間搏擊”要從合理的時間估計和對某些特性可能需要被裁減掉以滿足時間限制的理解開始。任務驅(qū)動的日程安排風險最大的高優(yōu)先權特性或者組件應該被計劃安排在項目的早期。這可以把響應問題的可用時間最大化。管理緩沖時間要增加緩沖（額外）時間來制定項目日程安排，從而允許

43、小組能夠應付無法預料的問題和變化。所要應用的緩沖時間量取決于風險的量。通過在項目早期進行風險評估，就可以估計最有可能發(fā)生的風險對日程安排的影響，并使用緩沖時間來補償?？紤]緩沖時間的一種方式是將其作為對未知任務和事件的估計。無論小組的經(jīng)驗有多豐富，不是所有的項目任務都是可知的，都是可以事先進行估計的。但是，可以肯定的是，有些項目風險將會發(fā)生，并對項目產(chǎn)生影響，響應風險所需要的修正行動將需要額外的時間。推薦對緩沖時間使用下面的指南。不應該通過填充個人任務的估計來增加緩沖時間。由于工作會按照日程安排來擴展并填充完成它的時間（一種叫做帕金森氏法則的效應），緩沖會被計劃內(nèi)的任務所吸收，而不是計劃外的任務

44、。緩沖時間也應該納入日程安排，就像任何任務一樣。一般來說，緩沖時間會在主要的里程碑，尤其是后來的一些里程碑之前立即就被分配。它總是應該被放在項目的關鍵路徑上。關鍵路徑是項目里相互依賴的任務的最長鏈，并直接決定著項目的持續(xù)時間。隨著緩沖時間在項目過程中不斷擴展，剩下的時間量應該由程序管理仔細地跟蹤和保存。由于緩沖是共享的，所以它只能夠根據(jù)請求來分配。如果加入了資源，或者從項目里取消了一些資源，不要用緩沖時間來補償。如果這樣做了，那么補償風險的能力也會相應地降低。要使用折衷三角形來協(xié)調(diào)特性、資源和日程安排。如果整個緩沖時間已經(jīng)被使用了，那么就要確保整個小組都知道任何中斷或者延遲都有可能帶來”級聯(lián)“效應，并危及結(jié)束日期。返回頁首結(jié)論MSF 提供了一種可伸縮的方式，確保從非常小的項目到極其龐大和復雜項目中的項目管理職能都能夠得到滿足。這種方法避免了小型