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

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

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

2）比如老板和產品負責人對需求的理解不一致，經常出現已經定好的目標，產品負責人要變更，但老板覺得沒必要，項目經理受夾板氣；

3）老板經常性的插入需求，導致變更率居高不下，需求變更流程形同虛設；

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

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

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

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

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

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

但作為一名項目經理，我們日常項目管理中，非常重要的一項工作，就是需求管理。如何做好需求管理，非?？简烅椖拷浝砟芰Α?/span>

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

1、了解背景

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

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

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

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

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

2、明確目標

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

不論項目內部自己怎么劃分，這個不是重點，重點是項目經理需要明確項目目標。總不能一接到項目，就直接帶著團隊開干吧。

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

我們項目經理的首要事項就是帶領團隊去實現項目目標，如果目標都不清晰，怎么做好項目管理，更別提具體到需求管理的細節(jié)了。

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

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

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

3、界定范圍

在目標明確之后，要落地每一個版本，就必然要界定清楚每個版本的范圍。這個范圍通?？梢园凑彰艚莸腗oSCoW法則來定：must（一定有） 、should（應該有）、could or would not（可有可沒有）。

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

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

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

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

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

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

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

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

4、確認需求

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

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

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

1）每個需求的輸出，是需要在產品內部（游戲的產品叫做策劃）經過層層把關的，具體的流程是這樣的：

需求模塊撰寫人->領域負責人審核->領域群評審->主策劃評審->制作人和策劃團隊一起評審->輸出需求提交項目經理安排。

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

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

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

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

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

5、需求開發(fā)

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

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

需求的源頭確認了，那么在需求進入開發(fā)階段的源頭，也需要多次核對并確認。正所謂磨刀不誤砍柴工，千萬不要認為這個時間花了，還不如提前接入寫幾行代碼。一旦出現被催進度，盡快啟動開發(fā)的時候，項目經理一定要頂得住壓力，把前面的準備工作做足。

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

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

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

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

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

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

6、搭建可視化

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

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

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

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

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

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

7、應對變更

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

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

不否認的是，很多項目經理怕項目過程中出現變更，甚至想方設法制定各種流程，試圖來控制變更。

從我自身的角度來說，我認為這都是不成熟項目經理做的事情，或者是初級項目經理會做的事情。

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

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

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

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

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

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

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

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

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

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

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

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

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

如果是時間可以調整，那新增的需求，在當前的人力資源情況下，整體評估完成時間，更新計劃，同步老板和團隊，按新的計劃進行。

如果范圍和時間不變，新增的需求可以協調其他人力支持，項目經理也需要更新項目的情況，同步老板和團隊。

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

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

4）項目目標出現變化

項目目標出現變化，必然會導致項目的范圍出現變化。

項目經理要對目標有清晰的理解和認知，要能夠根據日常的溝通，尤其是管理層的溝通中，獲取有用的信息，以便判斷是否對目標有影響。

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

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

事實上，本身也不復雜，當目標出現變化時，就又回到了前面第二、三大要點，重新明確目標，界定范圍。

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

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

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

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

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

8、產品能力

最后一個要點，產品能力，是說項目經理需要具備一定的產品能力。以互聯網項目或游戲項目為例，在負責這一類項目時，可以不懂技術，但我認為是需要具備一定的產品能力，需要真正的懂業(yè)務。

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

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

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

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

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

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