項目在客戶的眼中，需求經常是含糊不清的，他們也經常道不清述不明，客戶內部也常常眾口不一。客戶沒有責任把需求整理好來告訴你，就算告訴你的也不一定就是他們最終想要的，所以作為項目經理，“范圍管理”是非常重要的活動。這里主要講述一下我作為項目經理的職能時，在項目范圍管理中，進行的收集需求、定義范圍、創建WBS、確認范圍、控制范圍的過程。
一、收集需求、定義范圍
項目范圍管理是重中之重，矣是很多項目做失敗的關鍵所在。如何正確的掌握客戶的需求是范圍管理的目標，而需求往往隱藏太深以至於看不到。收集需求有多種工具與技術，在瀑布或迭代式開發過程中，確定需求通常要花費較大的時間與精力來做，比如之前我們使用的UML大象技術（詳情見：http://www.cnblogs.com/wgp13x/p/3824964.html）中的業務需求分析技術，因為此種項目的規模較大，需求一旦發生變更造成的影響是巨大的，要慎重對待。
下面是項目管理中十大知識領域之一的項目范圍管理的框架圖。
二、創建WBS，確認范圍
項目范圍一般不可能在項目進行過程中一成不變，但這不是在動手開發前不進行范圍確定的借口。如果沒有創建經過多方共同確認的范圍文檔，那簡直是一個惡夢。你肯定也遇到過，想一下，當你接近完成某功能時，一個領導說這個跟我想要的不一樣么，我想象中的應該能完成那樣的功能啊，另一個領導說也不對，應該是另一種效果，你是不是很抓狂。說到底，業務肯定是業務單位最了解，溝通重要，方法更重要。我們要在動手做之前“確定”好，要做什么，做出來的產品應該是什么樣的。注意這里的“確定”不是項目經理說的算的，也不是某一領導說的算的，有爭議的要及時溝通，盡早解決。
上面是我用“億圖”工具繪制的我們上個項目的WBS圖，內容不全，這里只用作說明。
下面是我制作的《項目需求規格說明書》的一部分，它是使用EXCEL繪制，TFS管理。
上圖中畫紅框的部分是會經常用到的，它們可以與TFS集成使用，因此非常易用，項目團隊中的成員可以隨時查看我們的項目范圍。
三、控制范圍
項目范圍一般不可能在項目進行過程中一成不變，就像接口肯定不能完全一路到底一樣。雙方開發前“敲定”的接口真的能“敲定”嗎？總有技術細節在真正實施前沒有被考慮到。項目范圍也一樣，尤其是對經驗欠缺的項目更是如此。項目開始前指定的項目范圍需要隨着業務分析與系統分析的過程，進行細化與補充，甚至詳細分析完成了都會有“個別”的項目范圍不能確定，但這只是很少數的。溝通是最重要的，無論在何時進行范圍確認與更新時，一定要保持與干系人的及時溝通。畢竟我們是服務提供者，沒有什么事情是不能商量的。會出現這么一種情況，在開發后期出現了“莫名遺漏”的需求，產生的原因很多，只能避免，無法杜絕。這里可能會產生一個“變更”，這時我們就要考量此“變更”會帶來的影響，進度上的、成本上的等等，再作決定如何處理，關於這些就要在“變更管理”一節中詳述了。
總結
項目范圍是“三權分立”中的最基本、極重要的一權，它是后續開發的依據，更是系統測試的依據。沒有它很多扯皮的事情就要發生，沒有它系統測試都無所適從。項目范圍管理非常重要，這也是我在管理上個項目中所取得的極其amazing的經驗與技能。
家里有一整套1995年豬年郵票，距今整整20年了，不知道價值現在幾何。豬郵票還挺可愛的
，給大家貼兩張欣賞一下。
，給大家貼兩張欣賞一下。
