msf項目管理準則白皮書(編輯修改稿)

　

【文章內容簡介】 溝通管理由程序管理和產品管理來共同承擔。產品管理會為客戶、利益相關人，以及任何外部人員創建和交付溝通計劃。程序管理會規劃和負責項目溝通，例如報告狀態、主持小組會議，以及類似的事情。溝通管理還包括小組以外的溝通規劃、合同指定點的分配和過程的報告。程序管理除了負責高層的解決方案體系結構和編寫職能規范（就如在小組模型里描述的那樣），程序管理還擁有把項目作為一個整體的所有項目管理領域。程序管理會把小組計劃集成到主要計劃里，同步日程安排，并管理跨小組的依賴性。把解決方案設計的職責和職能規范放到同一個角色里作為日程安排和成本職責有一個巨大的好處：它會打破相對于成本而言的設計過度的傾向與日程安排所暗示的之間的平衡。大型、復雜項目里的項目管理隨著項目變得更大或者更復雜，它可能會取代管理職能規范、更新日程安排、發出小組溝通、報告過程和進行其他的項目管理活動。要應付這個，把程序管理角色群的職責分割成解決方案體系結構和專門的項目管理角色常常是有道理的。項目監督服務在某些方面，一個大型的項目必須要做的事情和小型業務必須要做的相同：跟蹤財務、采購供給和服務、管理員工的業務、提供入門培訓、安裝小組工作設施等等。在大型項目里，對狀態、成本和日程安排的例行跟蹤變得非常耗時。為了讓項目經理把精力放在最緊迫的問題上，更多日常的項目管理活動被委派給了項目監督（或者項目支持）角色。項目監督服務還為小組領導提供了支持，幫助其維護小組日程安排和其他的管理活動。客戶的責任客戶常常想要一個實現整個項目成功的責任點。有些組織希望項目經理來扮演這個角色。有時候這在大型或者復雜的項目里會有保證，但是這種方法會使得小組角色責任失衡，從而導致項目表現不佳。MSF 滿足了客戶為確保滿意度而產生的對監督點的需要，同時在同級小組里保留職責。在 MSF 同級小組里，小組的每個角色都在內部負責自己的活動。此外，擔當每個角色的個人通常也都要在項目小組之外的一些管理結構里負責。由于 MSF 認為，并不是所有的小組成員都工作在同一個公司或者組織里，所以這些責任路徑會通往這些個人所屬的組織、團隊或者部門。這里的關鍵點是：?在這個主題上沒有絕對的事。在直接的項目小組之外，組織的報告結構和服務關系之間存在很多可能的不同之處。?識別項目的責任路徑。闡明在小組自身之外，誰要為項目的什么方面負責。MSF 小組模型以下列方式提供了客戶責任：?產品管理會維持與客戶之間的關系，并扮演客戶支持者的角色。這一角色的目標就是客戶的滿意度。?程序管理表現的目標是在項目約束內成功地交付項目。?產品和程序管理會共同工作以便在項目約束之內滿足客戶需要。這兩者共同分擔項目的整體成功，盡管它們的角色都在為不同的目標而努力。?如果發生了產品和程序管理都無法解決的問題，那么這些問題都會逐步升級成為整個項目的責任路徑。 用于 MSF 小組的精選建議下面推薦的項目管理做法是用于 MSF 小組領導和程序管理的。這些與出現在圖 5 里的某些，但不是全部的項目管理職責相對應。范圍管理范圍管理的目的是確保項目能夠識別完成解決方案所需要的所有工作，而不會在沒有先期的調查和同意的情況下就偏離目標去進行范圍以外的活動。構想階段的范圍在項目的早期階段，項目的寬范圍必須被識別和列入文檔。在 MSF 構想階段，小組會為解決方案生成一個沒有邊界的前景。然后范圍就會被識別，成為第一個版本。這在前景／范圍文檔里有描述，而且在項目繼續之前經過了小組、客戶和利益相關人的認可。在這個階段過程中，范圍只能在描述特性這一層次被廣義地理解。解決方案范圍和項目范圍范圍可以指解決方案范圍和項目范圍。解決方案范圍是要被構建的特性和交付內容的總和。項目范圍是交付解決方案所必須完成的所有工作的總和。這個術語用 MSF 設計過程來定義解決方案范圍。范圍定義在規劃階段，整個項目范圍必須被細分成為更小的、可管理性更強的部分。這個過程會闡明項目之外的特殊領域。通常，這些都是會產生誤解的具有特殊風險的領域。在定義范圍的過程中，小組會識別構建每個特性和交付內容所需的任務和技能類型。這會被歸檔放到一個工作分解結構 (WBS) 里，本白皮書下文即將討論這一結構。范圍改變控制一旦定義了范圍并為其制定了基準，小組就會將其置于改變控制之內。對范圍的改變必須同時由小組和客戶來檢查及認可。好的改變控制在一定程度上涉及好的折衷決策。MSF 折衷三角形和折衷矩陣是以可控方式推動改變的有用工具。要獲得更多信息，請參閱 MSF 過程模型白皮書。準備計劃規劃作為一項活動會發生在項目的始終。在構想階段，小組會安排創建項目交付內容所需要的高層方法。例如，測試方法會描述測試的類型、工具以及所需的技能。根據項目的規模不同，這可能只有一頁或者兩頁紙，甚至只是一段文字。盡管計劃會在每個階段改進和更新，但是大多數的規劃工作都會在 MSF 規劃階段進行。在這個階段里規劃過程的一般順序是：?設計過程（你要構建什么？）?規劃過程（你要怎么來構建？）?對開發進行日程安排（什么時候構建它？）這些可能會在某些方面相互重疊，但是在下一個過程能夠取得豐碩的成果之前，必須為先前的過程制定一個基準。本章就將集中討論規劃過程。重新使用文檔項目小組一直都會因為要把規劃的時間和花費壓到最小而倍感壓力。在壓縮規劃花費的同時怎么才能夠獲得好的規劃所帶來的好處呢？答案就是巧妙地搜集和重復使用項目計劃文檔。意識到項目計劃文檔是有價值的知識產權的組織會投資把它們組織和維護起來，放到一個能夠輕易訪問得到的儲備庫里。在創建新的計劃之前，小組應該總是搜尋任何已經被完成的東西。一旦一個項目完成了，項目文檔就應該被歸檔，放到一個未來的小組能夠重復使用的地點。項目計劃在 MSF 里，項目計劃指的是一套描述如何完成項目交付內容的文檔。職能規范用來描述將要構建的內容。主項目計劃是每個角色的小組計劃的集成和累積。每個小組角色都擁有描述自己要如何完成交付內容的計劃。MSF 沒有規定所有項目都必須具有一個適用于所有情況計劃列表。下面的默認列表涵蓋了軟件開發和基礎結構部署項目里常見的規劃領域。在小型項目里，這些計劃中的某一些可能會被組合在一起。有些項目可能需要額外的計劃。計劃類型驅動角色溝通計劃產品管理開發計劃開發培訓計劃用戶體驗安全計劃開發、發布管理測試計劃測試預算計劃程序管理用戶教育計劃用戶體驗部署計劃發布管理采購和設備計劃發布管理、程序管理試驗計劃發布管理工作分解結構工作分解結構 (WBS) 是一個面向交付內容的、經過分組的項目工作元素，用來組織和定義項目的總范圍 (iii)。它是要被完成的工作的大綱。沒有納入 WBS 結構里的工作就不在項目的范圍之內。小組領導和項目管理將 WBS 用作項目管理工具，來構建計劃和日程安排。在 MSF 里，創建 WBS 是一項需要所有小組角色參與的集體工作。每個角色都主要負責定義其各自領域里的工作細節。在大型項目里，子小組（職能和／或功能小組）可能需要單獨地集體討論所需要進行的工作。小組領導會把集體討論的結構