確認與控制范圍

在范圍管理中，我們已經講完了 4 個管理過程，剩下的兩個過程就是對范圍的確認以及在整個項目執(zhí)行過程中進行范圍的監(jiān)控管理。這兩個過程的內容都不多，所以今天的內容還是非常輕松的，在正式學習之前，我們先來看看 甘特圖 是長什么樣子的。

先睹為快 甘特圖

這是我之前做一個小官網開發(fā)時畫的一張 甘特圖 ，從這張圖中可以看出，左邊的那個列表其實就是一個 列表式 的 WBS 。而右邊的內容其實是我們的開發(fā)周期也就是加上了進度時間所形成的一種橫向的柱狀圖。也就是說，我們把 范圍 和 進度 結合起來，就可以畫出 甘特圖 。當然，成本、資源等也可以在 甘特圖 中體現出來。不過這些都是后話了。

大家可以看看，這個分解出來的工作結構有什么問題嗎？其實問題還是挺多的，比如說有點太粗了，沒有正式的功能范圍的劃分，因為粗所以很難監(jiān)控，而且很明顯，這是我一個人畫出來的，真正的 WBS 應該是各重要相關干系人一起制定的。在學習了上節(jié)課的內容之后，大家可不要像我一樣再畫出這樣的甘特圖來了。

關于甘特圖的內容，后面我們還會再說到，這里就是簡單的先看一下。

確認范圍

確認范圍其實也是 貫穿項目始終 的一個過程，它也可以叫做是范圍核實或者核實范圍。它包括與客戶或發(fā)起人一起審查可交付成果，確?？山桓冻晒褕A滿完成，并獲得客戶或發(fā)起人的正式驗收。

在信息系統(tǒng)集成項目中，確認范圍并不是容易的事情，這個不容易主要體現在與用戶的溝通上。項目團隊傾向于讓用戶確認范圍以盡快開始后續(xù)的工作，而用戶則可能認為自己什么也沒有看到，怎么可以確認呢？因此，項目團隊的溝通能力在確認項目范圍這里具有非常重要的作用。

項目干系人進行范圍確認時，一般要檢查以下幾個方面的問題：

• 可交付成果是否是確定的、可確認的。

• 每個可交付成果是否有明確的里程碑，里程碑是否有明確的、可辨別的事件。

• 是否有明確的質量標準。

• 審核和承諾是否有清晰的表達。

• 項目范圍是否覆蓋了需要完成的產品或服務進行的所有活動，有沒有遺漏或者錯誤。

• 項目的風險是否太高，管理層是否能夠降低可預見的風險發(fā)生時對項目的沖擊。

確認范圍中最主要的是項目的干系人（例如客戶、發(fā)起人）對項目的范圍進行確認和接受的工作，每個人對項目范圍所關注的方面也是不同的，這也就是我們的所有干系人需要關注的不同點，主要包括：

• 管理層所關注的是項目范圍，是指范圍對項目的進度、資金和資源的影響。

• 客戶主要關心的是產品的范圍，關心項目的可交付成果是否足夠滿足產品或服務。

• 項目管理人員主要關注可交付成果是否滿足需求和必須完成，時間、資金和資源是否足夠。

• 項目團隊成員主要關心項目范圍中自己參與的元素和負責的元素，檢查自己的工作時間是否足夠。

如果在確認范圍工作中發(fā)現項目范圍說明書、WBS 中有遺漏或者錯誤，需要向項目團隊明確指出錯誤的內容，并給出修正的意見。項目團隊需要根據修改意見重新修改項目范圍說明書和 WBS 。在確認范圍工作過程中也可能會出現范圍變更請求，如果這些范圍變更請求得到了批準，那么也要重新修改項目范圍說明書和 WBS 。

確認項目過程中有個工具叫做檢查，是指開展測量、審查與確認等活動，來判斷工作和可交付成果是否符合需求和產品驗收標準。檢查有時也被稱為審查、產品審查和巡檢等。而確認范圍的輸出則是 驗收的可交付成果 ，說白了，就是我們要正式交付的產品、服務等，它是所有結束項目階段或過程的重要輸入。如果項目在早期被終止，確認范圍過程也要記錄它的完成情況。記住，項目只要有開始，就一定要有結束，在整體管理中講過的結束項目或階段工作是必不可少的，即使是失敗和提前結束的項目，它們的資料也會成為組織過程資產。

最后，我們再看看一下確認范圍與幾個術語之間的比較。

• 確認范圍與核實產品：核實產品是針對產品是否完成，強調產品是否完整；確認范圍則是針對項目可交付成果，由客戶或發(fā)起人在階段末確認驗收的過程。

• 確認范圍與質量控制：確認范圍是有關工作結果的接受問題，而質量控制是關注交付成果的正確性；質量控制一般在確認范圍前進行，當然同時進行也是可以的；確認范圍體現在 “多少” ，也就是范圍的大小，多是由外部來驗收，而質量控制更多的地體現 “好壞” ，多屬于內部檢查。

• 確認范圍與項目收尾：確認范圍強調的是核實與接受，而項目收尾強調的是結束項目（或階段）所要做的流程性工作。

控制范圍

控制范圍是監(jiān)督項目和產品的范圍狀態(tài)、管理范圍基準變更的過程。在這個過程中，我們要確保所有請求的變更、推薦的糾正措施或預防措施都經過實施整體變更控制過程的處理。

在控制范圍的過程中，我們要重點關注的焦點問題包括：對造成范圍變更的因素施加影響，以確保這些變更得到一致的認可；確定范圍變更是否已經發(fā)生；當范圍變更發(fā)生時，對實際的變更進行管理。既然我們要關注這么多問題，那么項目的范圍一般會在什么情況下發(fā)生變更呢？

• 政府政策的問題。同時也可以看成是項目外部 "環(huán)境" 發(fā)生了變化。

• 項目的范圍計劃編制不周密詳細，有一定的錯誤或遺漏。這一點大多數可以歸結為 "人" 的原因。

• 市場上出現了或是設計人員提出了新 “技術” 、新手段或新方案。

• 項目執(zhí)行組織本身發(fā)生了變化。這是內部 “環(huán)境” 發(fā)生了變化。

• 客戶對項目、項目產品或服務的要求發(fā)生變化。這還是 “人” 的問題。

還記得我們在 項目整體管理 的 實施整體變更控制 的原因中講過的 “人財物法環(huán)” 嗎，這里其實也是類似的。可以說，大部分的變更，不管是范圍、成本、進度還是什么，基本都和這五個元素相關?？刂品秶_保所有的變更請求、推薦的糾正措施或預防措施，都會通過 實施整體變更控制 過程進行處理。

未經控制的產品或項目范圍的擴大（未對時間、成本和資源做相應調整）被稱為 范圍蔓延 。除了 范圍蔓延 外，還有一個名詞叫做 “鍍金” 。它的意思是團隊成員內部主動發(fā)起的范圍擴大的問題，沒有經過正式的變更流程處理，從而導致整體項目范圍的擴大。比如說，程序員主動為一個功能添加了一些額外的輔助功能，這叫 鍍金 。而客戶直接找到程序員并且要求馬上添加的額外功能就是 需求蔓延 。它們都是失控的變更，都沒有經歷正規(guī)的變更過程，都應該是在項目過程中極力避免的。

最后，我們再一起看一下在整個項目周期內，范圍變更控制的主要工作，包括但不限于：

• 影響導致范圍變更的因素，并盡量使這些因素向有利的方面發(fā)展。

• 判斷范圍變更是否已經發(fā)生。

• 范圍變更發(fā)生時管理實際的變更，確保所有被請求的變更按照項目整體變更控制過程處理。

總結

今天的內容不多吧，很輕松吧。雖說內容少，但確認范圍的概念、與質量控制的區(qū)別，控制范圍產生的原因，以及 范圍蔓延 和 鍍金 的概念這些內容都是需要我們去深入理解及記憶的。

到此為止，項目范圍管理的內容我們就學習完了。項目管理十大知識領域我們已經學習完了兩個，不知道大家有沒有感覺到貌似項目管理部分的內容還是比較輕松的。確實，相比不是計算機相關專業(yè)的人員去學習網絡和系統(tǒng)知識來說，項目管理方面的知識其實更通用一些，而且也更加的好理解一些。既然如此的話，大家就多多加油吧。當然，難點也還是有的，比如說我們馬上要進入的 項目進度管理 的學習，以及后面的 項目成本管理 都會比范圍管理的難度要高一些。

參考資料：

《信息系統(tǒng)項目管理師教程》

《某機構培訓資料》

《項目管理知識體系指南 PMBOK》第六版