我是如何來進行項目管理-範圍管理的

　　項目在客戶的眼中，需求常常是含糊不清的，他們也常常道不清述不明，客戶內部也經常衆口不一。客戶沒有責任把需求整理好來告訴你，就算告訴你的也不必定就是他們最終想要的，因此做爲項目經理，「範圍管理」是很是重要的活動。這裏主要講述一下我做爲項目經理的職能時，在項目範圍管理中，進行的收集需求、定義範圍、建立WBS、確認範圍、控制範圍的過程。   

　　 項目管理-時間管理-甘特圖 （ http://www.cnblogs.com/wgp13x/p/4385475.html ）是個人項目管理專輯的第一篇，他們都很重要。

 

　　

1、收集需求、定義範圍

　　項目範圍管理是重中之重，矣是不少項目作失敗的關鍵所在。如何正確的掌握客戶的需求是範圍管理的目標，而需求每每隱藏太深以致於看不到。收集需求有多種工具與技術，在瀑布或迭代式開發過程當中，肯定需求一般要花費較大的時間與精力來作，好比以前咱們使用的UML大象技術（詳情見：http://www.cnblogs.com/wgp13x/p/3824964.html）中的業務需求分析技術，由於此種項目的規模較大，需求一旦發生變動形成的影響是巨大的，要慎重對待。

　　

　　下面是項目管理中十大知識領域之一的項目範圍管理的框架圖。

 

 

 

2、建立WBS，確認範圍

　　項目範圍通常不可能在項目進行過程當中一成不變，但這不是在動手開發前不進行範圍肯定的藉口。若是沒有建立通過多方共同確認的範圍文檔，那簡直是一個惡夢。你確定也遇到過，想一下，當你接近完成某功能時，一個領導說這個跟我想要的不同麼，我想象中的應該能完成那樣的功能啊，另外一個領導說也不對，應該是另外一種效果，你是否是很抓狂。說到底，業務確定是業務單位最瞭解，溝通重要，方法更重要。咱們要在動手作以前「肯定」好，要作什麼，作出來的產品應該是什麼樣的。注意這裏的「肯定」不是項目經理說的算的，也不是某一領導說的算的，有爭議的要及時溝通，儘早解決。

 

 

　　上面是我用「億圖」工具繪製的咱們上個項目的WBS圖，內容不全，這裏只用做說明。

 

　　下面是我製做的《項目需求規格說明書》的一部分，它是使用EXCEL繪製，TFS管理。

 

 

 

 

 

　　上圖中畫紅框的部分是會常常用到的，它們能夠與TFS集成使用，所以很是易用，項目團隊中的成員能夠隨時查看咱們的項目範圍。

 

 

3、控制範圍

　　項目範圍通常不可能在項目進行過程當中一成不變，就像接口確定不能徹底一路到底同樣。雙方開發前「敲定」的接口真的能「敲定」嗎？總有技術細節在真正實施前沒有被考慮到。項目範圍也同樣，尤爲是對經驗欠缺的項目更是如此。項目開始前指定的項目範圍須要隨着業務分析與系統分析的過程，進行細化與補充，甚至詳細分析完成了都會有「個別」的項目範圍不能肯定，但這只是不多數的。溝通是最重要的，不管在什麼時候進行範圍確認與更新時，必定要保持與干係人的及時溝通。畢竟咱們是服務提供者，沒有什麼事情是不能商量的。會出現這麼一種狀況，在開發後期出現了「莫名遺漏」的需求，產生的緣由不少，只能避免，沒法杜絕。這裏可能會產生一個「變動」，這時咱們就要考量此「變動」會帶來的影響，進度上的、成本上的等等，再做決定如何處理，關於這些就要在「變動管理」一節中詳述了。

 

 

總結

　　項目範圍是「三權分立」中的最基本、極重要的一權，它是後續開發的依據，更是系統測試的依據。沒有它不少扯皮的事情就要發生，沒有它系統測試都無所適從。項目範圍管理很是重要，這也是我在管理上個項目中所取得的極其amazing的經驗與技能。

 

　　家裏有一整套1995年豬年郵票，距今整整20年了，不知道價值如今幾何。豬郵票還挺可愛的，給你們貼兩張欣賞一下。

 

 

來自王安琪