項目管理中的三大難點，分別是需求管理、風(fēng)險管理和干系人管理。其中就提到，需求管理，是項目管理過程中的一大難點。作為項目經(jīng)理，能做好這三個方面的管理，項目管理的水平也就達(dá)到了一定的高度。

那為什么需求管理是項目管理中的一大難點呢？我先看看這些場景是不是都很熟悉：

1）產(chǎn)品提的期望是A ，結(jié)果做出來演示的是B，實際出現(xiàn)很大的偏差，從期望到真正可落地的需求千差萬別；

2）比如老板和產(chǎn)品負(fù)責(zé)人對需求的理解不一致，經(jīng)常出現(xiàn)已經(jīng)定好的目標(biāo)，產(chǎn)品負(fù)責(zé)人要變更，但老板覺得沒必要，項目經(jīng)理受夾板氣；

3）老板經(jīng)常性的插入需求，導(dǎo)致變更率居高不下，需求變更流程形同虛設(shè)；

4）需求落地執(zhí)行的過程中，一切都看上去挺順利的，都在按計劃執(zhí)行，結(jié)果到驗收階段，各種問題頻出：不是功能的缺失，就是進(jìn)度的延遲，功能看著像是做完了，但各種小問題一堆；

5）多方不斷地插入需求，但時間又不允許增加，還要求按原計劃完成，導(dǎo)致團(tuán)隊怨聲載道，滿意度很低。

以上這些場景，是不是都不陌生。事實上，可能遠(yuǎn)不止這些問題。

那么就我們項目管理日常的一些場景來分析，需求管理的難點在于：

1）需求管理本身，因為項目的特點是漸進(jìn)明晰，不確定性是貫穿整個周期，而需求是源頭，一旦源頭有問題，對整個項目全流程都有很大的影響；

2）需求管理“背后”，需求輸出、實現(xiàn)、交付、完成，都是由人來參與的，有人參與的地方，人的復(fù)雜性，就使得整個鏈路都不會太簡單。比如對需求方期望的真正理解、對老板變更預(yù)期的理解、對團(tuán)隊執(zhí)行過程中的跟進(jìn)與監(jiān)控、還有團(tuán)隊執(zhí)行的滿意度。

但作為一名項目經(jīng)理，我們?nèi)粘ｍ椖抗芾碇?，非常重要的一項工作，就是需求管理。如何做好需求管理，非?？简烅椖拷?jīng)理能力。

今天，來系統(tǒng)地談一下，我是怎么做需求管理的。

1、了解背景

一位合格的項目經(jīng)理，在負(fù)責(zé)一個項目之初時，需要花大量的時間了解清楚項目的背景。我認(rèn)為這是非常重要的前提。換句話說，如果項目經(jīng)理對自己所負(fù)責(zé)的項目背景都不了解，就別提對業(yè)務(wù)有所了解和理解了。

何謂項目的背景，簡單來說，就是這是一款什么樣的項目？是什么類型的項目？市場上是否已經(jīng)有類似的競品？和競品相比，項目的優(yōu)勢和亮點體現(xiàn)在哪里？項目的主要干系人有哪些？項目發(fā)起人，項目核心管理層的預(yù)期是什么？

除了這些以外，還有必要了解清楚，我們?yōu)槭裁匆鲞@個項目？做這個項目能帶來的價值是什么？

再更深入一點的，這個項目主要要針對的是哪些用戶？這些目標(biāo)用戶，我們的項目是否可以滿足他們的期望和訴求？我們項目將圍繞怎樣的目標(biāo)來展開，以便滿足這些用戶的期望和訴求。

為什么要了解項目的背景，其實目的很簡單：當(dāng)了解項目的背景之后，會有助于真正理解業(yè)務(wù)。也就是說，項目經(jīng)理是要真正理解業(yè)務(wù)的。

2、明確目標(biāo)

當(dāng)了解了項目背景之后，接著就要進(jìn)一步明確項目的目標(biāo)，從項目階段來說可分為：短期目標(biāo)、中期目標(biāo)和遠(yuǎn)期目標(biāo)。從產(chǎn)品本身來說，項目目標(biāo)分為：最直接的目標(biāo)、業(yè)務(wù)目標(biāo)和戰(zhàn)略目標(biāo)。

不論項目內(nèi)部自己怎么劃分，這個不是重點，重點是項目經(jīng)理需要明確項目目標(biāo)?？偛荒芤唤拥巾椖浚椭苯訋е鴪F(tuán)隊開干吧。

之所以要特別強(qiáng)調(diào)明確目標(biāo)，是因為在實際落地執(zhí)行過程中，我們很多項目經(jīng)理往往會忽略這個目標(biāo)的確定。

我們項目經(jīng)理的首要事項就是帶領(lǐng)團(tuán)隊去實現(xiàn)項目目標(biāo)，如果目標(biāo)都不清晰，怎么做好項目管理，更別提具體到需求管理的細(xì)節(jié)了。

以最直接的目標(biāo)為例，其實就是弄清楚時間、成本（人力）、范圍和質(zhì)量這四要素。要做這個項目，預(yù)計是在什么時間，投入多少人力資源，做多少需求，達(dá)到怎樣的質(zhì)量標(biāo)準(zhǔn)，這是必須項，也是項目確定目標(biāo)非常具象化的。比如我們常常會去界定，項目在某個時間節(jié)點上線。這就是最直接的目標(biāo)。

而業(yè)務(wù)目標(biāo)是更深一層次的目標(biāo)，也就是投資項目的價值是什么，或者說做這個項目的價值是什么？

項目經(jīng)理在了解項目背景的時候，通常都需要清楚地知道業(yè)務(wù)目標(biāo)。執(zhí)行過程中是以最直接的目標(biāo)為依托，但真正是以業(yè)務(wù)目標(biāo)為導(dǎo)向。因為要達(dá)成業(yè)務(wù)目標(biāo)，是需要通過一個個已經(jīng)規(guī)劃的版本來達(dá)成的。

3、界定范圍

在目標(biāo)明確之后，要落地每一個版本，就必然要界定清楚每個版本的范圍。這個范圍通常可以按照敏捷的MoSCoW法則來定：must（一定有） 、should（應(yīng)該有）、could or would not（可有可沒有）。

MoSCoW法則只是確定范圍的一個方法。在確定范圍之前，還有一個步驟，就是對目標(biāo)進(jìn)行分解。目標(biāo)分解之后，再針對每個小目標(biāo)進(jìn)行范圍的界定，這樣執(zhí)行才可以比較有效地落到。

以一個為期一年的項目為例：

1）項目最直接的目標(biāo)是，一年后要上線測試；

2）為期一年的項目，說長不長，說短也不短。界定范圍時，得先有一個整體的需求框架，這個是整個項目的大范圍。梳理需求框架的目的不言而喻，就是我們要做一款產(chǎn)品，會涉及到哪些系統(tǒng)功能。這和scrum里面提的梳理產(chǎn)品待辦事項列表是一個意思來的。比如下圖表格所呈現(xiàn)的模式，把整個一年要做的需求都界定清楚。

這個梳理出來之后，可以讓團(tuán)隊對整體的功能需求有一個全貌。當(dāng)然最重要的目的之一還是為了對整體版本進(jìn)行規(guī)劃來的。

3）有了整體的需求框架之后，就可以開始進(jìn)行版本的整體規(guī)劃。在做整體規(guī)劃的時候，項目經(jīng)理不能完全的去拍個腦袋做一份規(guī)劃，應(yīng)該需要和產(chǎn)品負(fù)責(zé)人進(jìn)行深入的溝通和交流，確保彼此的理解一致。比如我們最初始的節(jié)奏是以兩個月為一個版本周期和節(jié)奏進(jìn)行規(guī)劃。

4）有了版本規(guī)劃之后，就可以進(jìn)一步地進(jìn)行范圍的界定了。以beta1為例，要做11個功能系統(tǒng)。這11個功能系統(tǒng)，也會進(jìn)一步明確，哪些是必須要保證的，哪些是應(yīng)該有的，哪些是可有可不有的。

可能會有朋友疑惑，為什么進(jìn)行了版本的規(guī)劃，還需要去進(jìn)行需求優(yōu)先級的劃分。這里面主要的原因在于團(tuán)隊的資源有限，進(jìn)行需求優(yōu)先級的劃分是更有利于需求的落地執(zhí)行。同時，項目在研發(fā)過程中，是一定要預(yù)留buff的，以便可以應(yīng)對各種突發(fā)情況。

4、確認(rèn)需求

范圍確定之后，接下來就是確定需求。確定需求這一步，往往是決定需求管理做好與不好的關(guān)鍵步驟。而確定需求，恰恰也是項目經(jīng)理最容易忽略的地方。

需求管理，最根本在于對需求源頭的管理，只有源頭抓好了，后面的每個環(huán)節(jié)才會更順。所以，具體到每個需求在正式開始落地之前，一定要經(jīng)過確認(rèn)。怎么來確認(rèn)？

敏捷提倡我們小步快跑，快速迭代，但并不代表著對需求的質(zhì)量輸出沒有要求。確認(rèn)需求，提高需求的輸出質(zhì)量，可以借鑒如下：

1）每個需求的輸出，是需要在產(chǎn)品內(nèi)部（游戲的產(chǎn)品叫做策劃）經(jīng)過層層把關(guān)的，具體的流程是這樣的：

需求模塊撰寫人->領(lǐng)域負(fù)責(zé)人審核->領(lǐng)域群評審->主策劃評審->制作人和策劃團(tuán)隊一起評審->輸出需求提交項目經(jīng)理安排。

2）需求輸出之后，需要進(jìn)行交互的設(shè)計，交互是產(chǎn)品需求和開發(fā)的一個橋梁。在需求確認(rèn)之后，還需要進(jìn)一步明確交互設(shè)計。交互的用途在于，把需求以可視化的方式呈現(xiàn)出來，也有利于開發(fā)人員進(jìn)行詳細(xì)的評估。

互聯(lián)網(wǎng)或游戲項目，需求的產(chǎn)出都是來自于內(nèi)部產(chǎn)品經(jīng)理，項目經(jīng)理只需制定好相應(yīng)的流程和規(guī)則，處理起來也都還好。

但對于一些甲方和乙方類的項目，很多時候客戶提出的不一定是需求，可能是某一個期望。這種情況下，從期望到真正落地的需求，項目經(jīng)理是需要花費(fèi)更多的時間來對齊確認(rèn)的。

這一類的項目，項目經(jīng)理更加需要了解項目的背景和目標(biāo)，有了信息的基礎(chǔ)，當(dāng)客戶講他們的訴求時，往往也能更容易抓住核心觀點，逐步進(jìn)行拆解和分解，最終輸出可落地的需求。

所以，需求是一定需要經(jīng)過確認(rèn)的，而且對于我們項目來說，只有經(jīng)過產(chǎn)品團(tuán)隊內(nèi)部確認(rèn)過的需求，包括項目總監(jiān)，leader等一并確認(rèn)過的需求，才會被提到需求管理工具中來。這也是我們項目制定的最基本的原則之一。

5、需求開發(fā)

需求確認(rèn)之后，進(jìn)入開發(fā)階段。從需求評審到最后驗收，是一個閉環(huán)流程。詳見下圖：

需要特別說明的是，需求在開發(fā)階段，需求評審、需求可行性論證、需求的方案設(shè)計、技術(shù)方案評估，都需要開發(fā)和美術(shù)的leader一起參與評審，并對結(jié)果負(fù)責(zé)。在需求評審的時候，產(chǎn)品、開發(fā)、美術(shù)和測試相關(guān)的人員都需要參加。

需求的源頭確認(rèn)了，那么在需求進(jìn)入開發(fā)階段的源頭，也需要多次核對并確認(rèn)。正所謂磨刀不誤砍柴工，千萬不要認(rèn)為這個時間花了，還不如提前接入寫幾行代碼。一旦出現(xiàn)被催進(jìn)度，盡快啟動開發(fā)的時候，項目經(jīng)理一定要頂?shù)米毫?，把前面的?zhǔn)備工作做足。

以一個需求為例來說，我們看的是整個需求的完整開發(fā)周期，也就是從需求評審->需求開發(fā)->需求驗收->需求測試->需求完結(jié)。

需求開發(fā)的源頭就是需求方案的設(shè)計，詳細(xì)工作量的評估，需要層層把關(guān)，對結(jié)果負(fù)責(zé)。試想，如果為了省這個幾天的時間，結(jié)果導(dǎo)致需求開發(fā)完成之后，出現(xiàn)一堆bug，最后驗收效果不好，測試過程坎坷，看著前面省了一點時間，但其實整個需求的開發(fā)周期都拉長了。

在軟件質(zhì)量里面有一句話：質(zhì)量是設(shè)計出來的。測試人員是質(zhì)量最后的“守門員”，不要把所有的質(zhì)量問題都留在最后測試環(huán)節(jié)。

所以技術(shù)方案，詳細(xì)工作量評估（WBS）這些準(zhǔn)備的越充足，一方面是有利于跟進(jìn)執(zhí)行；更重要的是有利于保證驗收環(huán)節(jié)和測試環(huán)節(jié)的順利。

為了確保驗收的效率和測試的順利，在整個需求開發(fā)流程里面，我們還額外新增了自測用例的評審，開發(fā)某個需求自測聯(lián)調(diào)結(jié)束之后，開發(fā)人員需要跑10%-20%的自測用例，通過率需要達(dá)到90%及以上，才能正式轉(zhuǎn)產(chǎn)品驗收。

當(dāng)產(chǎn)品驗收的體驗問題輸出之后，需要快速拉起開發(fā)、產(chǎn)品、測試一起對齊，落實體驗優(yōu)化，在體驗單解決完90%及以上之后，才會正式轉(zhuǎn)測試。

6、搭建可視化

需求管理的過程需要透明化，可視化。市面上已經(jīng)有很多好的工具。項目經(jīng)理需要善于借助工具來搭建搭建可視化，建立需求自動化運(yùn)轉(zhuǎn)流程。

一個好的工具，可以讓我們在對需求管理時事半功倍。我們用的TAPD工具非常的強(qiáng)大。

因為每個公司的項目管理工具可能不一樣，所以這里不做細(xì)述。但用工具需要是為了更好地去提升效率。

通過工具，讓整個項目管理過程更加的可視化，透明化。項目經(jīng)理要詳盡一切辦法，讓能夠可視化的都盡量可視化。這也是項目經(jīng)理的核心價值之一。

至于工具的使用，需求單狀態(tài)的流轉(zhuǎn)，從宣講開始，逐步的培養(yǎng)團(tuán)隊養(yǎng)成這樣的習(xí)慣，這些并不是難事。

同時，建立相應(yīng)的規(guī)則，加以約束，避免部分成員不遵守。對于還有部分經(jīng)常性不遵守的成員，則在項目管理過程中重點關(guān)注，以引導(dǎo)和教育為主。

7、應(yīng)對變更

世界著名作家、大思想家斯賓塞.約翰遜曾經(jīng)說過“世界上唯一不變的，是變化本身”。

作為項目經(jīng)理，我們在帶項目的過程中，需要有一個認(rèn)知：市場驅(qū)動型的項目，變是永恒。面對變化，項目經(jīng)理需要擁抱變化，宜疏不宜堵。

不否認(rèn)的是，很多項目經(jīng)理怕項目過程中出現(xiàn)變更，甚至想方設(shè)法制定各種流程，試圖來控制變更。

從我自身的角度來說，我認(rèn)為這都是不成熟項目經(jīng)理做的事情，或者是初級項目經(jīng)理會做的事情。

而一位合格的項目經(jīng)理，成熟的項目經(jīng)理，是需要懂得怎么去擁抱變化，有效地引導(dǎo)和控制變更，做好預(yù)期管理。

怎么來更好地應(yīng)對變化呢？這里要分幾種情況來看：

1）項目的范圍蔓延和鍍金

這是項目經(jīng)理需要重點關(guān)注的，范圍蔓延和鍍金也是項目推進(jìn)過程中變化的一種情況。當(dāng)出現(xiàn)范圍蔓延或鍍金的時候，會慢慢蠶食項目的資源，或者原本產(chǎn)品需求沒有的，額外新增了一些功能，使得原本的計劃不斷地偏移，團(tuán)隊各種加班趕進(jìn)度，抱怨聲音不斷。

這種情況我認(rèn)為是需要控制的。項目經(jīng)理需要高度的敏感，一旦識別項目范圍蔓延或出現(xiàn)鍍金的情況，要及時地進(jìn)行管控，確保項目在正常的框架內(nèi)運(yùn)行。因為資源是一點點被蠶食，可能會不知不覺中進(jìn)行，當(dāng)量積累到一定程度的時候，可能會對原有計劃有很大的影響。

2）項目執(zhí)行過程中出現(xiàn)的需求變更

一個項目計劃已經(jīng)按照既定的要求制定好了，并在有序的進(jìn)行執(zhí)行中。在做著做著的過程中，發(fā)現(xiàn)一些需求的細(xì)節(jié)需要補(bǔ)充，或者在自測用例評審的時候，發(fā)現(xiàn)需要增補(bǔ)一些功能點。

這種情況在實際執(zhí)行過程中是非常常見的，項目經(jīng)理不要急著去阻止這些需求，成熟的做法是和團(tuán)隊一起溝通對齊這些新增需求需要花費(fèi)的時間，然后評估需求的影響面和必要性（或者敏捷談到的價值）。有了這些數(shù)據(jù)之后，再去和管理層溝通，給出相應(yīng)的方案，最終讓管理層和團(tuán)隊一起來決策是否需要走變更流程。

如果走變更流程，就重新刷新計劃，更新好之后同步全員，按新的計劃執(zhí)行；如果溝通的結(jié)論是可以放到后面再安排，則按原計劃進(jìn)行。這里我個人會傾向于開發(fā)過程中出現(xiàn)的這類需求細(xì)節(jié)的調(diào)整，盡可能的一次性到位的安排處理。

3）項目執(zhí)行過程中，有插入新的需求情況

這在很多項目中是非常常見的，插入的需求可能大多來自于老板，領(lǐng)導(dǎo)。老板們的需求自然是要重視的，但如果放任這種情況持續(xù)的發(fā)生，需求的管理會逐步失控，而且團(tuán)隊的滿意度會直線下降，對項目經(jīng)理的認(rèn)可度也會大打折扣。

根據(jù)我自己的經(jīng)驗，遇到這種情況，偶爾出現(xiàn)一次，管控好預(yù)期，應(yīng)該問題不大。插入的需求或許是業(yè)務(wù)側(cè)本身的需要，但需求的增加，表明范圍的擴(kuò)大，鐵三角中，人和時間都不變的情況下，這個插入的需求必然是會影響已經(jīng)制定的計劃的。這種情況下怎么應(yīng)對呢？

如果時間和人都不變的情況下，對于插入的需求，可以重新把之前的需求拿出來一起溝通對齊優(yōu)先級，重新排優(yōu)先級就好，千萬別給老板拍胸脯保證，可以內(nèi)部消化掉，因為很有可能趕時間完成的需求和預(yù)期有很大的偏差，而且團(tuán)隊成員也加班加點，不買賬。

如果是時間可以調(diào)整，那新增的需求，在當(dāng)前的人力資源情況下，整體評估完成時間，更新計劃，同步老板和團(tuán)隊，按新的計劃進(jìn)行。

如果范圍和時間不變，新增的需求可以協(xié)調(diào)其他人力支持，項目經(jīng)理也需要更新項目的情況，同步老板和團(tuán)隊。

如果項目經(jīng)理可以做決策的情況下，以上都可以，但為凸顯項目經(jīng)理的更加專業(yè)和穩(wěn)重，可以將各種方案呈現(xiàn)出來，最終由老板去做選擇題，拍板決定使用哪個方案。

對于偶然的情況，以上的策略都是可行的。但如果作為項目經(jīng)理，你發(fā)現(xiàn)已經(jīng)出現(xiàn)2-3次這種插入需求的情況，甚至未來還會持續(xù)的時候。項目經(jīng)理需要和管理層“約法三章”了，要從源頭梳理并重新建立相應(yīng)的規(guī)則，制定插入需求的處理方式。不要認(rèn)為老板提的需求，項目經(jīng)理就無條件地去執(zhí)行。老板也是怕欠人情的，多次提需求，使得項目推進(jìn)過程出現(xiàn)變化，甚至延期，那就有必要從管理層入手來解決這個頻發(fā)插入需求的情況。

4）項目目標(biāo)出現(xiàn)變化

項目目標(biāo)出現(xiàn)變化，必然會導(dǎo)致項目的范圍出現(xiàn)變化。

項目經(jīng)理要對目標(biāo)有清晰的理解和認(rèn)知，要能夠根據(jù)日常的溝通，尤其是管理層的溝通中，獲取有用的信息，以便判斷是否對目標(biāo)有影響。

當(dāng)然，通常情況下，如果是因為市場的變化，因為政策的變化，使得項目目標(biāo)要進(jìn)行調(diào)整，這個時候管理層也會主動發(fā)起相關(guān)的會議，和項目的核心干系人進(jìn)行溝通對齊。

但切記，管理層的信息對齊只是一個信息的傳達(dá)，作為項目經(jīng)理，需要果敢的應(yīng)對這種突發(fā)的變化，要清楚的知道該如何開展下一步的工作。

事實上，本身也不復(fù)雜，當(dāng)目標(biāo)出現(xiàn)變化時，就又回到了前面第二、三大要點，重新明確目標(biāo)，界定范圍。

因為目標(biāo)已經(jīng)變了，再按原來的計劃執(zhí)行下去，做得越多，可能錯的也就越多，所以，需要即刻展開范圍的梳理和界定，然后重新制定計劃。

學(xué)習(xí)ACP的朋友，這個時候也需要靈活地進(jìn)行變通，理論知識是說一個迭代內(nèi)是不允許變更的，但實際項目執(zhí)行的過程，當(dāng)出現(xiàn)目標(biāo)變化，需要果斷的叫停一些已經(jīng)做的需求，哪怕是這個需求即將做完。

在應(yīng)對變更時，項目經(jīng)理需要根據(jù)實際情況，發(fā)揮自己的專業(yè)性，對項目重新梳理，尤其是范圍，在重新制定計劃之后，還需要特別的和管理層對齊預(yù)期。

項目的特點是漸進(jìn)明晰，實際推進(jìn)項目的過程中，哪怕是風(fēng)險管理做得再好，也還是會出現(xiàn)一些突發(fā)的情況。因此，變更的情況在這里也不能一一枚舉。

一位成熟的項目經(jīng)理，就是當(dāng)項目出現(xiàn)突發(fā)情況時，能夠在團(tuán)隊面前處變不驚，并且有思路、有邏輯的展開和推進(jìn)各項工作。所以，變化是永恒的。擁抱變化，管理好預(yù)期，是應(yīng)對變更的重要原則。

8、產(chǎn)品能力

最后一個要點，產(chǎn)品能力，是說項目經(jīng)理需要具備一定的產(chǎn)品能力。以互聯(lián)網(wǎng)項目或游戲項目為例，在負(fù)責(zé)這一類項目時，可以不懂技術(shù)，但我認(rèn)為是需要具備一定的產(chǎn)品能力，需要真正的懂業(yè)務(wù)。

當(dāng)項目經(jīng)理具備一定的產(chǎn)品能力，能夠更充分地理解需求，把握產(chǎn)品意圖。因此，項目經(jīng)理要能夠或者多培養(yǎng)自己從產(chǎn)品層面思考，讓項目的推進(jìn)能夠更加貼合產(chǎn)品的最終形態(tài)，這樣更有利于對項目的把控。

在我的認(rèn)知里面，項目經(jīng)理絕不僅僅只是排排計劃，管管風(fēng)險，和管理層溝通溝通。項目管理中，需求管理要真正的做得好，項目經(jīng)理是需要理解業(yè)務(wù)的，需要花一定的精力下沉到業(yè)務(wù)線中，要對產(chǎn)品有自己的理解和認(rèn)知。

具體的產(chǎn)品能力包括但不限于需求的理解和分析能力、產(chǎn)品意識（產(chǎn)品體驗和競品分析）、運(yùn)營數(shù)據(jù)分析能力、用戶思維等。

當(dāng)項目經(jīng)理具備一定的產(chǎn)品能力，真正的懂業(yè)務(wù)，對業(yè)務(wù)有自己的理解，在實際推進(jìn)項目的過程中，也會更加有底氣。

在和團(tuán)隊成員溝通對齊目標(biāo)時，不用擔(dān)心自己不懂技術(shù)而沒有共同溝通的頻道，一切以目標(biāo)為出發(fā)，就是最好的手段之一。

作者：zhouxu，騰訊IEG研發(fā)項目管理，PMP，PRINCE2，專注于分享日常項目管理過程中的點滴，輔以分享職業(yè)成長的思考與感悟。著有《誰說菜鳥不能成為項目經(jīng)理》一書。