專案（Explore）總結之專案範圍管理

§1.3  專案範圍管理

專案範圍管理是確保專案成功完成專案所需的全部工作，但又只包括必須完成的工作的各個過程。

在該專案中，範圍是指為提供具有規定特徵與功能的產品、服務或成果而需要完成的工作。

§1.3.1                  範圍規劃

範圍規劃是確定範圍管理決策的過程，以專案範圍管理計劃作為決策的載體，包括如何確定專案範圍、制定詳細的專案範圍說明書、確定與製作工作分解結構、核實專案範圍以及控制專案範圍。

Explorer專案沒有正式的專案範圍管理計劃，但有一些不成文的做法：

1.      確定專案範圍：產品範圍以三方簽字蓋章確認的需求說明書確定，包括業務需求說明書和系統規格說明書（主要是介面和功能確認）；

2.      制定詳細的專案範圍說明書：專案範圍說明書的載體為業務需求說明書和系統規格需求說明書。對於每一子系統，製作的過程包括業務需求調研、調研問題討論和確認，需求說明書編寫，需求說明書討論和確認，往往需要多輪的討論和確認；

3.      確定與製作WBS：沒有專門的文件記載WBS，粗略的把業務需求說明書的每一個功能對應WBS的一個條目；

4.      核實專案範圍：沒有核實的概念和過程，客戶測試透過，系統上線，視為核實的過程；

5.      專案範圍控制：以簽字確認後的需求說明書作為基線，如需變更，需書面提出，三方簽字確認後才予以實施。

§1.3.2                  範圍定義

範圍定義是根據在專案啟動階段所收集的資訊基礎上形成專案範圍說明書。

Explorer專案沒有正式的專案範圍說明書，專案範圍的主要依據仍然是招標檔案，不過，在客戶專案組之間都有一個不成文的範圍約定，那就是X1-X6等6個子系統，可惜的是一直沒有以書面的形式予以明確。除此之外，綱要性的資訊，如專案目標，專案要求說明書（根據干係人分析而得）、專案邊界、產品驗收原則沒有說明，專案的初步組織結構（如甲乙雙方的PM、專案組成員）沒有明確，專案進度和費用上的要求和影響因素如進度里程碑、資金要求、專案的假設和制約因素、初步確定的風險等亦沒有說明。

§1.3.3                  製作工作分解結構

工作分解結構以可交付成果為物件，將應由專案組為實現專案目標並創造必要的可交付成果而執行的工作分解之後的一種層次結構。

你沒猜錯，Explorer專案亦沒有正式工作分解結構文件，正如之前所述，專案以業務需求說明書作為專案的WBS。由於X1-X6系統在開始時客戶沒有提出相關的需求，範圍不太清晰，每一子系統的業務需求說明書是在啟動該子系統開發時才開始編寫的，理論上來說是使用“滾動式”的規劃方式。WBS的粒度控制在“選單”級，亦即，業務需求說明書的每一個功能模組基本都可以對應到系統中的某個選單上。另外，業務需求說明書中的對每一功能模組的說明可以“牽強”的對應到工作分解結構的詞彙表上。

業務需求說明書經簽字確認後即納入基線管理。

§1.3.4                  範圍核實

範圍核實是專案利害關係者對已完成的專案範圍與可交付成果正式驗收的過程。

每一個子系統試執行上線前，都有一個客戶驗收測試的過程，可以視為對可交付成果—子系統—的驗收過程。客戶驗收測試分為兩個階段，第一個階段是客戶測試階段，由專案組配合客戶對可交付成果進行測試，核實是否滿足業務要求和效能要求，這個階段一般需反覆迴歸進行幾次；第一階段結束後，即可進入第二個階段，即驗收評審階段，這時候一般由PM與客戶初步確定上線時間和三方驗收測試評審，由客戶資訊部門負責知會客戶代表、監理，同時組織正式的驗收測試評審會議。評審會議上，主要由專案組負責演示系統操作，由客戶代表和監理對照需求說明書，核實系統的功能完備性，確定是否可以透過驗收測試。

在系統演示的同時，客戶代表和監理可能會提出意見和建議，屬於系統Bug的，進入bug跟蹤系統；屬於系統變更的，則要求書面提出變更申請，經三方簽字確認後予以實施。

驗收測試透過，由三方簽署系統驗收測試報告，以此說明系統已具備條件，可上線試執行。

§1.3.5                  範圍控制

範圍控制是對造成專案範圍變更的因素施加影響並控制這些變更造成的後果。

之前也提到過，以簽字確認的業務需求說明書作為基線，在範圍出現變更時，需書面提出申請，經三方簽字確認後才予以實施。範圍變更提出後，專案組和客戶資訊部門會對變更作評估和影響分析，一般有以下幾種結果和處理方法：

1.      接納建議：三方簽字確認予以實施；

2.      接納建議，但採用替代的方案：與業務部門溝通，如不能達成一致，雙方意見無法統一，提交到上層處理；

3.      需求不清，需進一步分析：要求業務部門完善需求，直至可評估為止；

4.      不接納建議：給出不採納的理由，反饋給業務部門；如不能達成一致，雙方意見無法統一，提交到上層處理。

以上各項處理的結果均歸檔到專案的SVN中，如涉及需求變更的，更新需求基線。正常來說，範圍的變更很可能會影響到專案進度計劃，但可惜計劃自制定後就扔在一邊了。

-------------------------- 本文可任意轉載，但請註明作者和出處 ----------------------------