作為一個產(chǎn)品人，你需要讓自己保持饑渴的狀態(tài)，運營、數(shù)據(jù)分析、項目管理等，都需要涉及。最新迷戀上項目管理的學(xué)習(xí)，我會把我自己目前在學(xué)的項目管理整個技能體系，都給大家做一個簡單的分享。

項目管理鐵三角

學(xué)習(xí)項目管理前先認識項目管理著名的鐵三角概念，項目鐵三角在項目管理中是屬于比較靠前，需要先思考。鐵三角有三個非常關(guān)鍵的要素：范圍、時間、成本。三個基本元素相互影響且關(guān)聯(lián)性強。

舉個例子：

1. 范圍增加，要么時間增加，要么成本增加；
2. 時間縮短，要么范圍縮小，要么成本增加；
3. 成本縮小，要么時間增加，要么范圍減少；
4. 等等…

這些都是我們在現(xiàn)實場景中會出現(xiàn)的，比如領(lǐng)導(dǎo)要求范圍不許動，時間、成本三項都要減少，就會產(chǎn)生產(chǎn)品質(zhì)量降低的情況。所以在項目管理過程中，會決定著不同的選擇，可能需要調(diào)整時間或者調(diào)整成本等。那么如何調(diào)質(zhì)量？就要看客戶滿意度，在客戶滿意度的情況下，保證把項目質(zhì)量盡力做到最好。

范圍管理

范圍管理是我們十大知識領(lǐng)域中靠前需要先思考先管起來。

為什么要管范圍？

項目范圍不好控制，項目的范圍會經(jīng)常變化，所以很多人經(jīng)常會抱怨“計劃趕不上變化”。在實際工作中常會見到公司的產(chǎn)品還處于研發(fā)中，但是市場、用戶、資源等各個因素都時時發(fā)生變化，甚至?xí)霈F(xiàn)產(chǎn)品上市后，產(chǎn)品現(xiàn)用戶與當初設(shè)立的目標用戶不同，這些因素的變化都會導(dǎo)致項目定位、需求、方向等要素變化。當然項目管理不只是單純告訴你“計劃趕不上變化”這回事。

那么是不是不做計劃，就不會出邊“計劃趕不上變化”的局面。

明白的人都清楚越是計劃趕不上變化的情況下，越是要加強計劃的制定，應(yīng)當認清楚不做計劃風(fēng)險越大。那么做計劃的前提基礎(chǔ)，要先提明確項目范圍，項目過程中哪些活該干，哪些不該干。如果從一開始連項目中什么該做什么不該做都搞不清楚，那么這個項目做成功的概率是非常小的。

所以項目范圍管理的重要性，是在于我們在給我們的工作內(nèi)容圈定范圍，以保證我們的工作人員與項目相關(guān)的人，都在做這個范圍內(nèi)的事情，保證相關(guān)人員都在做范圍內(nèi)的事情，避免干了半天都在做不關(guān)項目的活，既浪費大家時間、還浪費公司資源。

項目管理的特點是目標導(dǎo)向非常強的一種管理模式，它本來就是臨時性，就是為了短期臨時去完成一個目標，只有當我們把所有的關(guān)注和資源全新投入到這個目標相關(guān)事情上面才能最快最好完成這個目標，不要去做與目標無關(guān)的其他事情。

一、收集需求

那么需求是從哪里來的？

常見的需求來源：

1. 公司內(nèi)部（老板/其他部門）
2. 產(chǎn)品經(jīng)理（策劃/挖掘）
3. 外部（用戶/客戶）

在實際工作中，根據(jù)項目章程和項目干系人的分析，我們會發(fā)現(xiàn)老板、相關(guān)監(jiān)管部門，不同的職能部門的需求占大部分。

所以在收集需求過程中我們需要去收集所有干系人的需求，然后從這些需求里面其分析哪些需求是可行的哪些需求是不可行的，這是圈定項目范圍的第一步。

常用的收集需求方式，定性到定量的一個過程：

最常見的四種數(shù)據(jù)分析方法有用戶訪談、問卷調(diào)查、數(shù)據(jù)分析、可用性測試，本文主要講解項目管理體系，暫不詳細分析每種收集需求方法。

二、定義范圍

當我們把需求收集工作做好后，接下來就要去定義項目范圍，定義項目范圍是為了保證什么該做什么不該做。

定義范圍的時候，我們需要對前一步收集來的需求進行分析，哪些需求是我們現(xiàn)在該做、能做、哪些不能做或者后期在做，白紙黑字的記錄下來，我們知道需求并不能證明我們最后工作量，其實需求解決的問題是我們最后要交付哪些東西。跟所有干系人確定需求列表后，就能很好的定義項目范圍哪些工作我們該做，哪些工作我們不該做。

在定義項目范圍過程中，我們要先把我們要交付的產(chǎn)品弄清楚。

產(chǎn)品結(jié)構(gòu)-產(chǎn)品分解

要把整個產(chǎn)品拆分成子產(chǎn)品，每個子產(chǎn)品要完成哪些工作。定義產(chǎn)品的話相對于定義每個子產(chǎn)品，所以要列出產(chǎn)品清單。通常產(chǎn)品清單會由不同模塊組成，產(chǎn)品清單并沒有唯一的模板。如下圖，對汽車的分解。

對于一個IT類的項目，更要定義清楚范圍，講清楚產(chǎn)品產(chǎn)出與交付是什么。

產(chǎn)出一個系統(tǒng)具體是指什么？如CRM系統(tǒng)，那什么叫CRM系統(tǒng)，系統(tǒng)背后是一個集合。

當把CRM系統(tǒng)交付進行分解，可能會有軟件、硬件、用戶說明書、培訓(xùn)課件教程。不同企業(yè)的CRM系統(tǒng)還會出現(xiàn)不一樣，有的里面有銷售運營報表、有的有用戶清單、等。所以每個點都能逐層進行分解，才不會落東西。實際中，我曾經(jīng)遇到過，運營活動快上線了，才說沒有預(yù)熱；產(chǎn)品上線了才發(fā)現(xiàn)缺少產(chǎn)品日志等等。

所以前期的產(chǎn)品分解，分解的越清晰越不會落下東西。因此一開始如果不能定義好要交付的產(chǎn)品，后期會造成很大麻煩。

有了項目分解后，要與定義一份項目范圍說明書：

1. 項目范圍描述（我們要交付哪些產(chǎn)品）
2. 產(chǎn)品驗收標準（驗收標準與驗收人）
3. 項目可交付成果
4. 項目的除外責任（有哪些情況下，某些東西做錯不負責任，如有些假設(shè)條件出現(xiàn)不可控的情況，負責人不擔責）
5. 項目制約因素

制約因素是受制于既定行為或不行為的狀態(tài)、特性或感覺。可以是來自項目內(nèi)部或外部的，會影響項目或過程績效的限制因素。制約因素是已經(jīng)客觀存在的，往往對項目的范圍、成本、進度、時間、資源等方面起限制與約束作用。

例如，施加于項目進度的、會影響進度活動時間安排的任何限制或約束，都屬于進度制約因素，一般表現(xiàn)為固定的強制日期。如果項目是根據(jù)合同實施的，那么合同條款通常也是制約因素。

就像我國汽車售后市場規(guī)模已接近9676億元，但是與整車市場的快速成長不相配，還在一定程度上制約了中國汽車行業(yè)的發(fā)展，制約因素如下：市場整體質(zhì)量不高、市場集中度不高、服務(wù)水平較低、行業(yè)統(tǒng)計數(shù)據(jù)不到位，同時外資企業(yè)擴張較快。這就是項目制約因素。

項目假設(shè)條件

是一個將來概念，就是事情還沒有發(fā)生，到底會出現(xiàn)什么情況誰都不知道。但是在項目管理中，你要對你現(xiàn)在的項目作出假設(shè)，假設(shè)會出現(xiàn)什么事情影響你的項目，然后提前作出準備，減低不必要的損失。就比如一個戶外活動定在周六，結(jié)果周六出現(xiàn)暴風(fēng)雨天氣，那么其實在項目開展前就要準備好頂棚之類的東西。

三、創(chuàng)建WBS（核心）

1.創(chuàng)建工作分解結(jié)構(gòu)–WBS。

我們在定義范圍的時候，前期理清要交付的東西，然后明白我們需要干什么活，通過工作分解方式去了解我們要干什么活。

分解結(jié)構(gòu)WBS，不止是項目管理，在其他領(lǐng)域都可以使用，當大家發(fā)現(xiàn)一件事非常難干不知道怎么做的時候，往往是因為大家將雜亂無章并且把無關(guān)的事情與核心工作揉在一起而導(dǎo)致事情難做。當大家沒有理清工作順序、思路時候，它把原來叫一個活進行分開分開，越分解對工作內(nèi)容越清楚，當把工作分解到一定大小時候，就能將工作落實到負責這工作的人身上。通過拆分成不同層面、不同顆粒度，我們就能更好的把工作關(guān)起來。所以不用分解結(jié)構(gòu)工作，是很難將項目管理起來的。

2.什么是WBS？

1. 面向可交付成果的對項目工作的層次化分解。
2. 定義項目整個范圍，范圍內(nèi)的顆粒度越細越好，這樣的話不會再產(chǎn)生超出范圍外的需求。
3. 將項目工作分解為較小的，易于管理的多項工作。管理的難度通常取決于要管理這個工作的復(fù)雜程度，拆成越小，越好管理。好比一個人管理一大堆事和一個人管理一兩件事，后者肯定是比較好管理。
4. 每分解下一層代表對項目更詳細的定義。
   分解得越細，對項目越了解。就像對某個需求，進行逐層分析，才能想到很多涉及到該需求的其他功能沒有想到。所以分解得越細能幫我們再次去分析用戶需求對實現(xiàn)需求的理解。

3.常見分解維度

按階段分解：先把項目工作按照生命周期劃分成不同的階段，再分解每個階段要做的事情。

如打算迭代一款社交產(chǎn)品V4.0版本的開發(fā)工作，收集需求階段>詳細設(shè)計階段>構(gòu)建開發(fā)階段>整合措施階段。每個階段下，都有需要完成的工作。好處：可以看到哪些交付物是屬于這個階段該完成的，有利于階段性的管控。

按成果分解：他的第一層不是以階段維度，而是不同類型的交付物。然后為了完成某類交付物，我需要去完成哪些分解后的交付物。如我們?nèi)シ纸猱a(chǎn)品兼容設(shè)備，我們可以劃分基礎(chǔ)兼容設(shè)備、特殊兼容設(shè)備，細化層次的兼容設(shè)備。好處：保證了我們不會落下交付物，應(yīng)為我們第一層分解的就是交付物類型。

4.工作包

當進行WBS時候，我們把所有東西都分解到最底層的時候，會形成一種概念——工作包，也叫工作細目。

定義工作包的目的，是為了找到合適的人去承擔完成這個工作包這一部分的職責。

什么時候稱為分到底了，我們可以監(jiān)控進度、估算成本和資源，那就可以打包成為一個工作包。并找到一個合適的人與承擔的時候，那么這個東西就可以稱為一個工作包。

5.WBS分解

WBS分解-最基本遠側(cè)

1. 100%劃分原則，項目中所有工作都要進行WBS劃分，所有項目工作都在WBS中提現(xiàn)，如后期發(fā)現(xiàn)有遺漏，那就沒有100%劃分了，就算超出項目范圍外。
2. 分解到工作包水平的時候，必須要有人去承擔職責，由責任人來自己決定完成工作所需要的資源等。
3. 每一層的分解不能只有一個，常見一個分解成多個才算分解，一個分解一個并不算分解。
4. 要描述合格交付物的狀態(tài)，特別是產(chǎn)品工作包后，要清楚描述工作包的狀態(tài)，讓責任人能清晰理解工作包的狀態(tài)。

WBS-最佳實踐性質(zhì)的原則

1. 基于可交付物和期望的狀態(tài)（期望的狀態(tài)指：開發(fā)階段的狀態(tài)、測試階段的狀態(tài)…）來進行分解。
2. 重點描述產(chǎn)出而不是動作。產(chǎn)出指WBS分解出來的每一要素最好是名詞，不是動作。當我們進行WBS分解時候，每一層分解出來的要素都要是名詞，如合同、說明書，合同的上傳功能，合同審批的功能；動作：創(chuàng)建合同上傳功能，創(chuàng)建合同審批的功能，創(chuàng)建一個業(yè)務(wù)流程的兒描述。為什么要重視產(chǎn)出，應(yīng)為我們做項目重點要的是輸出物，而不是動作，動作是輸出物的過程，如打印照片，照片是輸出物，打印是動作。有些項目經(jīng)理分解出來大量的動作，如分析XX需求，開發(fā)XX軟件等等，所有動作都在，但是把交付物都落下了。我們做項目重要的是動作后能得出產(chǎn)出。所以對于WBS分解也是一樣，WBS我們定義的是一個范圍，如果我們定義的是一個個產(chǎn)出物，那么其實我們定義的目標是當我們得到某個產(chǎn)出才算完成。
3. 每層分解不要超過9個，超過9個難以控制，建議3-7個。
4. 每個要素只能指定一個負責人，尤其是在我們國家，指定給多個人那基本就是沒制定人。由負責人去分配給一些配合人員。一擔落到幾個人身上，幾個人都會覺得不是自己的事情。
5. 每層級別盡量做到100%分解完，再分解下一層，常見的錯誤分解完一層后，抓住一個點深入分解下去，接著再分解其它層，這樣容易出現(xiàn)，一條線分解完后，再分解另一條線同層級的維度會出現(xiàn)不同。

6.WBS表達形式-層次結(jié)構(gòu)圖和鋸齒列表

1. 圖形式表達：非常直觀，讓大家一下就能看出層次之間關(guān)系，但是占地大。
2. 鋸齒形列表方式：通常不直觀，但是能在一張紙里面顯示出來。

7.WBS詞典

當我們通過WBS把我們主要的交付和工作都理清時候，我們還需要建立WBS詞典，WBS詞典是對每一個工作分解結(jié)構(gòu)要素的工作和技術(shù)文件做詳細說明，文檔表格根據(jù)自己所需制定。

通常WBS詞典里需要有11個內(nèi)容：

1. 分解代碼：一個項目的WBS可能分解出成千上百的項不同任務(wù)，這時候如果不編碼會造成混亂。同時編碼也能幫助我們標識每個分解出來的任務(wù)關(guān)系。
2. 工作描述：分解出來的工作描述，如做某個功能的開發(fā)，這個開發(fā)主要實現(xiàn)什么功能，包括開發(fā)語言是什么？負不負責測試？等
3. 負責組織：每個分解出來的任務(wù)指派給相關(guān)負責人與負責部門。
4. 里程碑清單：標識幾個關(guān)鍵的里程碑，這樣我們才能知道任務(wù)進行到什么階段，進展是快還是慢。
5. 進度活動：進度需要有一個描述。
6. 所需資源：所需要有哪些資源。
7. 成本估算：時間成本、開發(fā)成本、金錢成本等
8. 質(zhì)量要求：什么程度算完成，測試到什么程度算通過等
9. 驗收標準：每個工作完成后，誰去驗收、用什么方式去驗收。
10. 參考文獻：有些活動需要參考不同文檔，需要寫出參考哪些文檔。
11. 合同信息：有些項目需要外包，還需要簽署相關(guān)合同。

通過WBS分解后的任務(wù)活動，如果沒有這些注解和解釋，很容易產(chǎn)生各種注解和誤會，不同的人對活動的注解理解是不一樣的，所以產(chǎn)出WBS詞典，保證每個人對注解的理解是一致的。

四、核實范圍

需求說明書 范圍說明書 WBS WBS詞典=項目范圍基準（基線）

1. 通常項目正式實施之前，需要把基線定義出來，這個基線定義項目需要完成哪些工作才算完成。將來進行項目評價與績效考核時候，會將產(chǎn)出項目與定義的基線、WBS詞典做對比得出偏差有多大。偏差越大則代表項目已經(jīng)偏離范圍。
2. 核實產(chǎn)品是否在范圍內(nèi)，首先要通過【需求跟蹤矩陣】去保持客戶聯(lián)系，確定產(chǎn)品范圍有沒變，確?！拘枨笪臋n】最新后，用它去核實“確認過質(zhì)量的產(chǎn)品”【確認的可交付成果】的范圍，核實沒有問題就可以驗收這個產(chǎn)品；如果有問題就要提交一個變更請求。注意在核實和控制過程還是用需求文件，而沒有用范圍說明書，因為相對需求文件，范圍說明書比較粗略。
3. 實際企業(yè)中，前期工作沒搞這么復(fù)雜，只是把項目過程中關(guān)鍵任務(wù)關(guān)鍵活動列出來，做個計劃，但是這樣的計劃是不準確的。因為通常意義上，我們做計劃前需要把WBS分解到最底層并且找到合適的責任人。最怕的是沒將項目WBS分解清楚并且任務(wù)責任人也沒找著，就開始做計劃，這樣會導(dǎo)致計劃執(zhí)行不下去，且過程中會一直調(diào)整，造成這樣的情況就是因為一開始計劃就沒做清楚。
   計劃沒做清楚還會導(dǎo)致部門/成員合作之間容易產(chǎn)生誤會，比如，銷售部門的理解和運營部門的理解都是不一樣的，我們常說“一千個人眼里就有一千個哈姆雷特”就是在這個道理。
   所以為了避免過程中需求一直被調(diào)整，計劃不斷被調(diào)整，項目一開始WBS就要分解到最底層，分解清楚，而且每一個分解出來的工作包或者元素能有一個準確的定義，并且整個團隊能對此達成共識，這個項目范圍就不會容易被改變。
4. 當項目進行實施階段，項目經(jīng)理需要檢查實際工作范圍與實際產(chǎn)出的結(jié)果是否與范圍基準一致。這時候需要進行范圍核實，范圍核實是正式驗收項目已完成的可交付成果的過程。這個過程中項目經(jīng)理要做的是組織合適的人去驗收，通常項目經(jīng)理去驗收會比較存在風(fēng)險，比如不懂代碼的項目經(jīng)理如何去驗收代碼？

五、控制范圍

偏差分析

偏差分析是一種確定實際績效與基準的差異程度及原因的技術(shù)，可用于項目績效測量結(jié)果來評估偏離范圍基準的程度。用于控制項目偏離范圍基準的原因和程度、決定是否需要采取糾正和預(yù)防措施。

范圍控制是監(jiān)督性工作，在干活的過程中，該干的活沒干，不該干的活卻做了，做著做著就跑偏了，所以這個階段需要進行偏差分析。不斷的去比對，現(xiàn)在實際做的工作是不是范圍基準以內(nèi)的工作，如果說與范圍基準有誤差，那么我們就該停下重新做調(diào)整。常見的IT類項目，范圍不斷地被改變，特別是業(yè)務(wù)部門對項目的交付物不是特別的想清楚，他們會對交付物不斷的調(diào)整。如果業(yè)務(wù)部門提出的交付物與原交付物差別較大，那就需要重新去定義基準，并且重新計劃，避免實際交付物與后期調(diào)整交付物存在結(jié)果、成本、資源等誤差。

所以范圍控制與范圍核實并不完全一樣，它們是互補狀態(tài)，

• 參與人：核實客戶必須參加，控制客戶不必參與
• 時間點：核實在關(guān)鍵的階段完成點，控制在項目執(zhí)行全過程
• 內(nèi)容：核實只關(guān)注最終交付成果，控制關(guān)注所有執(zhí)行過程中輸出

范圍核實和控制范圍是互補的，范圍核實關(guān)注的是結(jié)果，控制范圍關(guān)注的是過程。

本文由 @阿信 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。