項目范圍管理是一項全局性而又基礎的工作，產品經理在做項目管理時要通過需求范圍來開展。

在做項目管理整體規劃時，需要引入我們的項目范圍，可以說項目范圍是構成項目鐵三角很重要的一個因素。還記得我曾提及的項目管理的質量，范圍，時間，成本構成的鐵三角嗎？可以說項目范圍管理的好壞直接影響我們項目的成敗。

項目管理鐵三角

為什么要做范圍管理

場景1

老板通知產品經理小Y馬上到辦公室，因為昨天老板參加一個互聯網的聚會看到同行產品有個全新的功能，于是需要小Y在本次迭代周期內將這個新功能列入到開發進度上去，因為是老板下達的任務小Y馬上對自己的原型進行了修改，同時將工作任務交給了開發經理，開發經理看了心里不知道該說什么……

場景2

在項目開發工程中，客戶方因為人事變動新入職了一位VP，而這位VP對這個項目非?？粗?，并結合自己的經驗需要在項目中加入一些認為非常好的功能，并告知項目經理這個功能對我們的項目非常重要，務必要增加這項新功能，項目經理將這個需求告知給開發負責人，開發負責人默默的從抽屜拿出來菜刀…….

場景3

項目實施過程中，項目成員漫無天日的進行開發著，項目因為干系人的原因已經做了多次變更，這時項目經理走過來對開發負責人說，前一個版本上變更的一個功能客戶反饋沒有之前的好用這個版本需要改回來…..

以上幾個場景做過項目的小伙伴是不是很熟悉啊，因為項目范圍沒有約定好很容易導致項目無限期的延續，最終導致管理學上的沙漠綜合癥，項目經理和項目團隊成員像在沙漠里面行走沒有方向，也不知道什么時候這個項目是個頭，整個項目團隊士氣低落，項目開發效率嚴重低下，人員流動性增加，最終導致項目的失敗。

由此可以看出來，項目范圍管理是一項全局性而又基礎的工作，而我們產品經理在做項目管理時要通過需求范圍來開展。

1、項目的范圍是一項全局性和基礎性的工作

全局性是需要我們產品經理或者項目經理能夠對開發的產品有全局意識，心中知道我們產品的需要達成的目的是什么，圍繞我們要達成的目標建立一系列需要素材，哪些開發的項目是需要做的，哪些是不需要做的，哪些是不能夠做的。

基礎性是意味著我們團隊所有的項目活動都是圍繞著這一目的進行的，沒有一個既定的范圍所有的項目活動都是盲目的，比如我之前做的汽車類APP項目，在開發前期相關項目干系人不知道做這個APP目的是為何，產品一而再再而三的變更范圍，這樣投入了大量的人力物力最終沒有任何結果。

2、KANO需求模型

項目范圍的原則是綜合考慮用戶各方面的需求完成讓用戶滿意工程，這里可以提一下KANO模型，在收集需求的時候可以將需求進行劃分成為：

基本需求，用戶使用該產品必須有的功能，當這個需求得到滿足的時候用戶不會感到滿意，沒有得到滿足用戶會非常反感，比如我們電商功能中的支付環節，能夠支付時用戶感覺理所當然，不能實現線上支付時用戶覺得非常不專業。

期望需求，是指用戶的滿意情況與需求的滿足程度成正比例關系的需求，此類需求得到滿足或表現良好的話，客戶滿意度會顯著增加，該需求提供的越多，顧客的滿意狀況越好。同時此類需求得不到滿足的情況下，客戶的不滿也會顯著增加。比如產品好的用戶體驗。

魅力需求，指不會被顧客過分期望的需求。隨著滿足顧客期望程度的增加，顧客滿意也急劇上升但興一旦得到滿足，即使該需求表現并不盡善盡美，顧客表現出的滿意狀況則也是非常高的。相反，如果該需求沒有被滿足，用戶也不會表現出來明細的不滿意。比如海里撈提供擦眼鏡片，等候時提供的美甲等服務。

無差異需求，不論是否滿足該需求，對用戶體驗無影響。比如餓了么上面提供的天氣服務。

反向需求，增加該需求會引起大多數的用戶不滿的需求。比如之前文章提到過高層領導需要獲取汽車用戶車輛完善的信息，而增加繁瑣的錄入功能，從導致現場操作人員工作量劇增的功能。

產品經理在編制項目范圍時，需要以用戶滿意做為前提，通過KANO模型對需求進行有效的劃分，從而根據產品生命階段來逐步構建產品的功能需求。那作為產品經理或者項目經理怎么具體做好我們項目范圍管理功能呢？

收集需求

范圍管理也就是明晰需要做什么，在項目管理中收集需求需要引入范圍管理計劃，需求管理計劃，項目章程，這三項管理計劃告訴我們產品經理我們項目大體需要做什么？很多做互聯網項目的是沒有這個計劃的，所以我們產品經理值得關注的是干系人管理計劃和干系人登記冊。什么是干系人呢？很多產品經理會說我們的產品面向的是C端消費者，怎么去做干系人？后面的章節會進行說明，這里需要明確的是與我們項目相關的人都可以納入干系人行列。所以我們需要對項目相關的干系人進行管理。

首先需要對我們干系人進行造冊，哪些人會對這個項目產生影響？這些人職位是什么？是不是有所遺漏？在前在做建站的項目時候，因為沒有這塊的意思，經常設計把設計稿和對接人通過后，因為又有其他領導介入導致設計搞需要重新修改，現在回想起來簽訂合同的商務人員可以把需求板上釘釘確定后，后期功能上面沒有變更這個也就是充分的管理好了干系人。所以在收集需求的伊始不要漏下任何相關的干系人。

其次需要了解這些干系人對項目的訴求點是什么？怎么樣權衡各個干系人之間的利益？這個說起來可能很簡單但是也是最復雜的。經常在一些資料上教育產品經理發現用戶的本質需求也就是這個道理（例子就不多舉福特造車，打井啊大家可以百度一下）。

最后需要選用合適的方法和干系人進行采集，這個也需要心里有數，對外和對內由于時間和成本的差異選擇的方式也就不同。常用的方法包括訪談，問卷，觀察，原型法，標桿分析，文件分析，德爾菲法，引導式研討會，群體決策等。

工具不是目的，工具是為了很好的為我們的目標服務的。我們通過收集需求需求為了是充分了解我們干系人對我們產品的需求是哪些。收集完需求后我們需要輸出需求文件，產品經理習慣叫做需求池，里面包括需求類型，需求描述，需求的來源，解決方案，時間等。除了需求的記錄另外需要建立需求的跟蹤矩陣，這個文件可以包含需求收集文件內，主要記錄需求跟蹤情況。不要管殺不管埋，對需求要有始有終。這也是對干系人6有個交代，也是小米提及的參與感。

定義范圍

我們通過上一步過程廣泛的將用戶需求進行了收集。這個時候還不能擼起袖子干起來，需要結合我們綱領性文件項目章程，明確我們系統到底要做什么。同時這樣可以把一些偽需求給PASS掉或者做優先級較低的排期。范圍的定義我們需要對產品進行分析，將我們產品怎么進行劃分模塊，這個也是將我們收集的需求匯總的過程，這樣可以更好確定我們產品的范圍同時也方便制定驗收標準。系統分析和價值分析從產品未成形和成形來分析我們產品的價值，那個功能價值點會更高，更高的價值點我們需要賦予他怎么樣的目標。

定義范圍的好處在于讓系統更加明確需要實現什么，不需要實現什么。需要實現的是高價值的功能，比如KANO模型里面的基本需求，期望需求和魅力需求，而需要摒棄的是一些低價值的需求，之前做酒店管理系統時與客戶溝通過程中，發現產品里面80%的功能是客戶沒有用過的，這些功能的產生可能來自個別用戶，也可能是需求人員拍腦袋，從而導致系統功能很“強大”，需要專業的人員培訓之后才會使用。

創建WBS

當我們把前面的工作完成后，領導就會過來問產品什么時候可以出來了，這個時候你可能還是兩眼一抹黑，有經驗的項目經理可能大致評估一個時間。為什么不能評估出來，因為我們沒有把工作進行分解，我們的系統還是停留在構思上，沒有落實到人。怎么樣落實到人呢？我們需要將我們的工作做WBS分解。

WBS就是將我們的產品或者交付物分解到更小的單元，方便我們做時間進度和成本上的評估。WBS分解的方式可以是樹狀或者表格形式進行分解，并且需要確保我們分解到最小的單元，最小的單元遵循8/80法則，也就是說工作包最低不能低于8H也就是1天，最高不能超出80H小時，另外分解 過程需要逐漸明晰，近期工作要分配詳細，拆分到最小單元，而遠期的工作做個規劃表，這樣不至于我們將手上的工作進行遺漏，這也是說的迭代的一個過程。做WBS時層級在3-6層比較適合，顆粒過粗不易于管理風險較大，顆粒過細效率會降低同時資源會造成浪費。

WBS好處：

1. 讓干系人放心，清晰明了的知道每一步需要做哪些工作；
2. 不容易遺漏工作，做到每一項工作心里有數，什么時間節點做什么工作；
3. 便于落實工作責任，哪些人員要什么時間點做什么工作；
4. 成本和進度的基礎，只有制定完善WBS后才能對，項目進度和成本進行估算；
5. 項目溝通管理的依據，在溝通和管理管理中，對于匯報對象清晰明了知道每個的工作內容和實施情況，同時也是做計劃和控制的依據；
6. WBS有效的防止范圍的蔓延。

范圍確認和監控

范圍確認是產品或交付物正式提交后，對產品或交付物的范圍進行核實，是否按量完成了該工作，范圍確認和質量控制工作可以并行，質量控制是需要確認產品內容是否達到要求的質量標準，而范圍核實是確認產品是否按照既定的范圍進程開發。

范圍監控主要確認范圍是否按照既定范圍相關文檔進行，分析哪些因素會導致范圍的變更，范圍有變更是否按照約定的流程進行，已批準的變更是否做了組織過程資產的更新和項目文件的更新，高層是否知曉變更。做好范圍監控要對外要有效控制范圍蔓延，對內要控制鍍金的現象。

以上就是關于范圍管理知識的說明，一個產品成功與否和范圍管理有直接的關系，所以在做產品的時候要非常重視范圍和需求的問題。

相關閱讀

產品經理需知的項目知識：整體管理

本文由 @產品_空?原創發布于人人都是產品經理?，未經許可，禁止轉載。

題圖來自 unsplash，基于 CC0 協議