起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品項目管理體系之范圍管理
作為一個產品人，你需要讓自己保持饑渴的狀態，運營、數據分析、項目管理等，都需要涉及。最新迷戀上項目管理的學習，我會把我自己目前在學的項目管理整個技能體系，都給大家做一個簡單的分享。
?項目管理鐵三角
學習項目管理前先認識項目管理著名的鐵三角概念，項目鐵三角在項目管理中是屬于比較靠前，需要先思考。鐵三角有三個非常關鍵的要素：范圍、時間、成本。三個基本元素相互影響且關聯性強。
舉個例子：
- 范圍增加，要么時間增加，要么成本增加；
- 時間縮短，要么范圍縮小，要么成本增加；
- 成本縮小，要么時間增加，要么范圍減少；
- 等等…
這些都是我們在現實場景中會出現的，比如領導要求范圍不許動，時間、成本三項都要減少，就會產生產品質量降低的情況。所以在項目管理過程中，會決定著不同的選擇，可能需要調整時間或者調整成本等。那么如何調質量？就要看客戶滿意度，在客戶滿意度的情況下，保證把項目質量盡力做到最好。
范圍管理
范圍管理是我們十大知識領域中靠前需要先思考先管起來。
為什么要管范圍？
項目范圍不好控制，項目的范圍會經常變化，所以很多人經常會抱怨“計劃趕不上變化”。在實際工作中常會見到公司的產品還處于研發中，但是市場、用戶、資源等各個因素都時時發生變化，甚至會出現產品上市后，產品現用戶與當初設立的目標用戶不同，這些因素的變化都會導致項目定位、需求、方向等要素變化。當然項目管理不只是單純告訴你“計劃趕不上變化”這回事。
那么是不是不做計劃，就不會出邊“計劃趕不上變化”的局面。
明白的人都清楚越是計劃趕不上變化的情況下，越是要加強計劃的制定，應當認清楚不做計劃風險越大。那么做計劃的前提基礎，要先提明確項目范圍，項目過程中哪些活該干，哪些不該干。如果從一開始連項目中什么該做什么不該做都搞不清楚，那么這個項目做成功的概率是非常小的。
所以項目范圍管理的重要性，是在于我們在給我們的工作內容圈定范圍，以保證我們的工作人員與項目相關的人，都在做這個范圍內的事情，保證相關人員都在做范圍內的事情，避免干了半天都在做不關項目的活，既浪費大家時間、還浪費公司資源。
項目管理的特點是目標導向非常強的一種管理模式，它本來就是臨時性，就是為了短期臨時去完成一個目標，只有當我們把所有的關注和資源全新投入到這個目標相關事情上面才能最快最好完成這個目標，不要去做與目標無關的其他事情。
一、收集需求
那么需求是從哪里來的？
常見的需求來源：
- 公司內部（老板/其他部門）
- 產品經理（策劃/挖掘）
- 外部（用戶/客戶）
在實際工作中，根據項目章程和項目干系人的分析，我們會發現老板、相關監管部門，不同的職能部門的需求占大部分。
所以在收集需求過程中我們需要去收集所有干系人的需求，然后從這些需求里面其分析哪些需求是可行的哪些需求是不可行的，這是圈定項目范圍的第一步。
常用的收集需求方式，定性到定量的一個過程：
最常見的四種數據分析方法有用戶訪談、問卷調查、數據分析、可用性測試，本文主要講解項目管理體系，暫不詳細分析每種收集需求方法。
二、定義范圍
當我們把需求收集工作做好后，接下來就要去定義項目范圍，定義項目范圍是為了保證什么該做什么不該做。
定義范圍的時候，我們需要對前一步收集來的需求進行分析，哪些需求是我們現在該做、能做、哪些不能做或者后期在做，白紙黑字的記錄下來，我們知道需求并不能證明我們最后工作量，其實需求解決的問題是我們最后要交付哪些東西。跟所有干系人確定需求列表后，就能很好的定義項目范圍哪些工作我們該做，哪些工作我們不該做。
在定義項目范圍過程中，我們要先把我們要交付的產品弄清楚。
產品結構-產品分解
要把整個產品拆分成子產品，每個子產品要完成哪些工作。定義產品的話相對于定義每個子產品，所以要列出產品清單。通常產品清單會由不同模塊組成，產品清單并沒有唯一的模板。如下圖，對汽車的分解。
對于一個IT類的項目，更要定義清楚范圍，講清楚產品產出與交付是什么。
產出一個系統具體是指什么？如CRM系統，那什么叫CRM系統，系統背后是一個集合。
當把CRM系統交付進行分解，可能會有軟件、硬件、用戶說明書、培訓課件教程。不同企業的CRM系統還會出現不一樣，有的里面有銷售運營報表、有的有用戶清單、等。所以每個點都能逐層進行分解，才不會落東西。實際中，我曾經遇到過，運營活動快上線了，才說沒有預熱；產品上線了才發現缺少產品日志等等。
所以前期的產品分解，分解的越清晰越不會落下東西。因此一開始如果不能定義好要交付的產品，后期會造成很大麻煩。
有了項目分解后，要與定義一份項目范圍說明書：
- 項目范圍描述（我們要交付哪些產品）
- 產品驗收標準（驗收標準與驗收人）
- 項目可交付成果
- 項目的除外責任（有哪些情況下，某些東西做錯不負責任，如有些假設條件出現不可控的情況，負責人不擔責）
- 項目制約因素
制約因素是受制于既定行為或不行為的狀態、特性或感覺?？梢允莵碜皂椖績炔炕蛲獠康?，會影響項目或過程績效的限制因素。制約因素是已經客觀存在的，往往對項目的范圍、成本、進度、時間、資源等方面起限制與約束作用。
例如，施加于項目進度的、會影響進度活動時間安排的任何限制或約束，都屬于進度制約因素，一般表現為固定的強制日期。如果項目是根據合同實施的，那么合同條款通常也是制約因素。
就像我國汽車售后市場規模已接近9676億元，但是與整車市場的快速成長不相配，還在一定程度上制約了中國汽車行業的發展，制約因素如下：市場整體質量不高、市場集中度不高、服務水平較低、行業統計數據不到位，同時外資企業擴張較快。這就是項目制約因素。
項目假設條件
是一個將來概念，就是事情還沒有發生，到底會出現什么情況誰都不知道。但是在項目管理中，你要對你現在的項目作出假設，假設會出現什么事情影響你的項目，然后提前作出準備，減低不必要的損失。就比如一個戶外活動定在周六，結果周六出現暴風雨天氣，那么其實在項目開展前就要準備好頂棚之類的東西。
三、創建WBS（核心）
1.創建工作分解結構–WBS。
我們在定義范圍的時候，前期理清要交付的東西，然后明白我們需要干什么活，通過工作分解方式去了解我們要干什么活。
分解結構WBS，不止是項目管理，在其他領域都可以使用，當大家發現一件事非常難干不知道怎么做的時候，往往是因為大家將雜亂無章并且把無關的事情與核心工作揉在一起而導致事情難做。當大家沒有理清工作順序、思路時候，它把原來叫一個活進行分開分開，越分解對工作內容越清楚，當把工作分解到一定大小時候，就能將工作落實到負責這工作的人身上。通過拆分成不同層面、不同顆粒度，我們就能更好的把工作關起來。所以不用分解結構工作，是很難將項目管理起來的。
2.什么是WBS？
- 面向可交付成果的對項目工作的層次化分解。
- 定義項目整個范圍，范圍內的顆粒度越細越好，這樣的話不會再產生超出范圍外的需求。
- 將項目工作分解為較小的，易于管理的多項工作。管理的難度通常取決于要管理這個工作的復雜程度，拆成越小，越好管理。好比一個人管理一大堆事和一個人管理一兩件事，后者肯定是比較好管理。
- 每分解下一層代表對項目更詳細的定義。
分解得越細，對項目越了解。就像對某個需求，進行逐層分析，才能想到很多涉及到該需求的其他功能沒有想到。所以分解得越細能幫我們再次去分析用戶需求對實現需求的理解。
3.常見分解維度
按階段分解：先把項目工作按照生命周期劃分成不同的階段，再分解每個階段要做的事情。
如打算迭代一款社交產品V4.0版本的開發工作，收集需求階段>詳細設計階段>構建開發階段>整合措施階段。每個階段下，都有需要完成的工作。好處：可以看到哪些交付物是屬于這個階段該完成的，有利于階段性的管控。
按成果分解：他的第一層不是以階段維度，而是不同類型的交付物。然后為了完成某類交付物，我需要去完成哪些分解后的交付物。如我們去分解產品兼容設備，我們可以劃分基礎兼容設備、特殊兼容設備，細化層次的兼容設備。好處：保證了我們不會落下交付物，應為我們第一層分解的就是交付物類型。
4.工作包
當進行WBS時候，我們把所有東西都分解到最底層的時候，會形成一種概念——工作包，也叫工作細目。
定義工作包的目的，是為了找到合適的人去承擔完成這個工作包這一部分的職責。
什么時候稱為分到底了，我們可以監控進度、估算成本和資源，那就可以打包成為一個工作包。并找到一個合適的人與承擔的時候，那么這個東西就可以稱為一個工作包。
5.WBS分解
WBS分解-最基本遠側
- 100%劃分原則，項目中所有工作都要進行WBS劃分，所有項目工作都在WBS中提現，如后期發現有遺漏，那就沒有100%劃分了，就算超出項目范圍外。
- 分解到工作包水平的時候，必須要有人去承擔職責，由責任人來自己決定完成工作所需要的資源等。
- 每一層的分解不能只有一個，常見一個分解成多個才算分解，一個分解一個并不算分解。
- 要描述合格交付物的狀態，特別是產品工作包后，要清楚描述工作包的狀態，讓責任人能清晰理解工作包的狀態。
WBS-最佳實踐性質的原則
- 基于可交付物和期望的狀態（期望的狀態指：開發階段的狀態、測試階段的狀態…）來進行分解。
- 重點描述產出而不是動作。產出指WBS分解出來的每一要素最好是名詞，不是動作。當我們進行WBS分解時候，每一層分解出來的要素都要是名詞，如合同、說明書，合同的上傳功能，合同審批的功能；動作：創建合同上傳功能，創建合同審批的功能，創建一個業務流程的兒描述。為什么要重視產出，應為我們做項目重點要的是輸出物，而不是動作，動作是輸出物的過程，如打印照片，照片是輸出物，打印是動作。有些項目經理分解出來大量的動作，如分析XX需求，開發XX軟件等等，所有動作都在，但是把交付物都落下了。我們做項目重要的是動作后能得出產出。所以對于WBS分解也是一樣，WBS我們定義的是一個范圍，如果我們定義的是一個個產出物，那么其實我們定義的目標是當我們得到某個產出才算完成。
- 每層分解不要超過9個，超過9個難以控制，建議3-7個。
- 每個要素只能指定一個負責人，尤其是在我們國家，指定給多個人那基本就是沒制定人。由負責人去分配給一些配合人員。一擔落到幾個人身上，幾個人都會覺得不是自己的事情。
- 每層級別盡量做到100%分解完，再分解下一層，常見的錯誤分解完一層后，抓住一個點深入分解下去，接著再分解其它層，這樣容易出現，一條線分解完后，再分解另一條線同層級的維度會出現不同。
6.WBS表達形式-層次結構圖和鋸齒列表
- 圖形式表達：非常直觀，讓大家一下就能看出層次之間關系，但是占地大。
- 鋸齒形列表方式：通常不直觀，但是能在一張紙里面顯示出來。
7.WBS詞典
當我們通過WBS把我們主要的交付和工作都理清時候，我們還需要建立WBS詞典，WBS詞典是對每一個工作分解結構要素的工作和技術文件做詳細說明，文檔表格根據自己所需制定。
通常WBS詞典里需要有11個內容：
- 分解代碼：一個項目的WBS可能分解出成千上百的項不同任務，這時候如果不編碼會造成混亂。同時編碼也能幫助我們標識每個分解出來的任務關系。
- 工作描述：分解出來的工作描述，如做某個功能的開發，這個開發主要實現什么功能，包括開發語言是什么？負不負責測試？等
- 負責組織：每個分解出來的任務指派給相關負責人與負責部門。
- 里程碑清單：標識幾個關鍵的里程碑，這樣我們才能知道任務進行到什么階段，進展是快還是慢。
- 進度活動：進度需要有一個描述。
- 所需資源：所需要有哪些資源。
- 成本估算：時間成本、開發成本、金錢成本等
- 質量要求：什么程度算完成，測試到什么程度算通過等
- 驗收標準：每個工作完成后，誰去驗收、用什么方式去驗收。
- 參考文獻：有些活動需要參考不同文檔，需要寫出參考哪些文檔。
- 合同信息：有些項目需要外包，還需要簽署相關合同。
通過WBS分解后的任務活動，如果沒有這些注解和解釋，很容易產生各種注解和誤會，不同的人對活動的注解理解是不一樣的，所以產出WBS詞典，保證每個人對注解的理解是一致的。
四、核實范圍
需求說明書+范圍說明書+WBS+WBS詞典=項目范圍基準（基線）
- 通常項目正式實施之前，需要把基線定義出來，這個基線定義項目需要完成哪些工作才算完成。將來進行項目評價與績效考核時候，會將產出項目與定義的基線、WBS詞典做對比得出偏差有多大。偏差越大則代表項目已經偏離范圍。
- 核實產品是否在范圍內，首先要通過【需求跟蹤矩陣】去保持客戶聯系，確定產品范圍有沒變，確?！拘枨笪臋n】最新后，用它去核實“確認過質量的產品”【確認的可交付成果】的范圍，核實沒有問題就可以驗收這個產品；如果有問題就要提交一個變更請求。注意在核實和控制過程還是用需求文件，而沒有用范圍說明書，因為相對需求文件，范圍說明書比較粗略。
- 實際企業中，前期工作沒搞這么復雜，只是把項目過程中關鍵任務關鍵活動列出來，做個計劃，但是這樣的計劃是不準確的。因為通常意義上，我們做計劃前需要把WBS分解到最底層并且找到合適的責任人。最怕的是沒將項目WBS分解清楚并且任務責任人也沒找著，就開始做計劃，這樣會導致計劃執行不下去，且過程中會一直調整，造成這樣的情況就是因為一開始計劃就沒做清楚。
計劃沒做清楚還會導致部門/成員合作之間容易產生誤會，比如，銷售部門的理解和運營部門的理解都是不一樣的，我們常說“一千個人眼里就有一千個哈姆雷特”就是在這個道理。
所以為了避免過程中需求一直被調整，計劃不斷被調整，項目一開始WBS就要分解到最底層，分解清楚，而且每一個分解出來的工作包或者元素能有一個準確的定義，并且整個團隊能對此達成共識，這個項目范圍就不會容易被改變。 - 當項目進行實施階段，項目經理需要檢查實際工作范圍與實際產出的結果是否與范圍基準一致。這時候需要進行范圍核實，范圍核實是正式驗收項目已完成的可交付成果的過程。這個過程中項目經理要做的是組織合適的人去驗收，通常項目經理去驗收會比較存在風險，比如不懂代碼的項目經理如何去驗收代碼？
五、控制范圍
偏差分析
偏差分析是一種確定實際績效與基準的差異程度及原因的技術，可用于項目績效測量結果來評估偏離范圍基準的程度。用于控制項目偏離范圍基準的原因和程度、決定是否需要采取糾正和預防措施。
范圍控制是監督性工作，在干活的過程中，該干的活沒干，不該干的活卻做了，做著做著就跑偏了，所以這個階段需要進行偏差分析。不斷的去比對，現在實際做的工作是不是范圍基準以內的工作，如果說與范圍基準有誤差，那么我們就該停下重新做調整。常見的IT類項目，范圍不斷地被改變，特別是業務部門對項目的交付物不是特別的想清楚，他們會對交付物不斷的調整。如果業務部門提出的交付物與原交付物差別較大，那就需要重新去定義基準，并且重新計劃，避免實際交付物與后期調整交付物存在結果、成本、資源等誤差。
所以范圍控制與范圍核實并不完全一樣，它們是互補狀態，
- 參與人：核實客戶必須參加，控制客戶不必參與
- 時間點：核實在關鍵的階段完成點，控制在項目執行全過程
- 內容：核實只關注最終交付成果，控制關注所有執行過程中輸出
范圍核實和控制范圍是互補的，范圍核實關注的是結果，控制范圍關注的是過程。
本文由 @阿信 ?原創發布于人人都是產品經理。未經許可，禁止轉載。
項目范圍通俗易懂，不錯
內容寫的很好，很有收益，非常感謝分享。為什么停止分享了呢？