編輯導讀：對于每個項目經理來說，需求管理都是一件很重要的事情，它決定著項目是否能成功。一個好的項目管理流程不僅可以推動項目的進行，還可以提高項目的成功率。那么我們應該如何進行需求和期望管理呢？我們來看看本文作者的分析。

今天看到小伙伴一臉痛苦，出于對小伙伴的關懷上前問了下情況，小伙伴跟我說他很痛苦，項目的需求控制不住了；詳細了解之后才知道：小伙伴只對接了信息部門的文員，接到的需求也都是從業務部門調研到的，也沒有經過簽字確認；在對小伙伴表示慰問和同情后我陷入了沉思。

軟件交付行業近年來業務增長很快，對人員的需求量也大，導致大量非項目管理專業的互聯網軟件人才進入到軟件項目管理崗位，雖然他們的基礎能力很強，但是缺乏項目管理的基礎導致前期瘋狂踩坑，不得不說，確實很難受。

針對小伙伴這種情況，來聊聊軟件交付中的需求和期望管理。

一、期望——沒有寫下來的高層級客戶需求

被互聯網行業大潮影響，現在從業人員總會把“需求”和“痛點”掛在嘴邊，項目管理從業人員也開始這么叫了；當然這么叫也沒錯，只不過是把范圍這個概念換了個稱呼而已，但是換完稱呼后少了一部分內容就不對了，沒有人關注客戶期望了。

回頭想想，為什么我們在做這個項目——不就是領導們冒出了個想法，想讓我們實現嘛。

舉個例子，領導有一天突然把小張叫過去說：“我們要做個電商功能，滿足商家可以上傳商品，用戶可以查看和購買，跟淘寶差不多就行”這個時候小張馬上列出需求功能清單，找到產品經理開始研究淘寶，兩個月之后項目還沒上線，小張被領導一頓罵：“就一個上傳商品和購買功能做這么久，你們團隊平常在干嘛，發呆么！”小張抱著抄了一個多星期淘寶的PRD躲在角落里哭泣。

小張做錯了么？

錯了，從一開始就錯了，他錯誤的理解了領導的期望，本以為領導想要個淘寶的功能，但實際上領導只想要個淘寶的UI，滿足上傳商品和購買就行了。

這種情況就會導致項目延期以及出現功能冗余。

當然，錯誤理解客戶或領導期望的情況不只這一種，但無論是哪一種，如果出現了，就會對項目造成傷害。

Tips：各個層級的客戶或領導溝通，了解清楚他們真實的期望，是想早點上線，還是想界面美觀、還是功能完善，了解清楚再動手，畢竟有了方向后，不管走哪條路都一定是對的路。

二、確認——容易被忽略的過程

需求的確認簡直是一件太常見的事了，無論是純做互聯網產品的公司還是做軟件交付的公司中，每天都能聽到幾次需求確認的信息，但是能把需求確認這件事做好的不超過一半。

在互聯網公司中，由于需求太多，提出方也太多，可能是老板提的、用戶提的、運營提的、商務提的，這種確認就很難做；一些做的比較好的公司，會定期發布版本更新計劃，但會不會按照更新計劃來執行就又另說了。

確認環節分為兩個重要的點——確認和執行

1. 確認

小的互聯網公司或者多數軟件公司都存在的一個現象就是：接到客戶/用戶的需求之后馬上行動，最后導致客戶不滿意，并且反悔說類似“我沒說過這個”“這不是我想要的”云云。

正確的做法麻煩一些，增加一個確認的步驟：

比如，如果你是產品經理，接到了大量的用戶反饋，說“我希望食堂的門可以換個更鮮亮一些的顏色”；這時候你需要做的不是去調研哪些顏色是鮮亮的，而是準備好你的方案后找用戶溝通“為什么你希望換鮮亮的顏色呢？”“如果換成這個顏色是不是可以呢？”在得到大部分抽樣用戶的肯定后再執行；

再比如，如果你是軟件交付的項目經理，客戶說“我希望在這里加一個XXX功能”，你需要做的同樣不是直接找產品經理和工程師們去執行，而是跟客戶溝通好需求的細節后，出一份寫明功能點的確認單據，讓客戶簽字。

2. 執行

其實需求確認不是一件難事，難得是確認后的執行——完完整整地按照已確認的需求執行任務。

中國社會是一個人情社會，很多事情有時候按照規章制度執行會被人情往來給阻斷，這是很正常的一件事，但往往就因為XXX的項目特別緊急、XX總的需求優先級比較高，就把已經確認的計劃打亂。

這里給初級項目經理或者是產品管理者一個建議——強硬一些！

從規章制度確立到執行，是要有一個適應的過程的，如果項目管理者或者產品管理者都沒有執行規章制度，只會讓同事們更加肆無忌憚的無視這些制度；但這些制度卻是保護我們的，所以拒絕他們你沒有做錯。

Tips：需求確認過程是比較麻煩且沒什么技術含量的一個過程，但是卻是實實在在保護項目/產品管理者在管理進度工作的重要法寶；多數項目經理和產品經理沒有意識到它是在保護自己，所以才不去執行；如果你是項目經理或者產品經理，謹記你有這個隱形法寶傍身，一定要好好使用！

三、控制——保證雙方利益的方法

“需求越做越多，做不完了”“客戶又要新增加功能”“銷售又承諾客戶倆功能，這項目沒法做了”

做項目管理這幾年，類似的話從產品、項目、研發同事口中聽到了太多次了，最開始還老好人一般的上前安慰兩句，溝通一下出現這種問題的原因及解決方案；現在已經不管了，一個是沒有人聽，一個是自己已經習慣了這種被迫加班的情況，改變太麻煩（說實話這個理由我真心接受不了）。

無論是做項目管理還是產品管理，需求的控制一定是重中之重，常見的需求控制場景主要分為三種：減少、新增和替換，其中需求減少的情況太過少見，而且屬于比較良性的變更，不做討論，主要聊聊新增和替換：

1. 新增

需求的新增是幾乎所有項目經理和產品經理在工作過程中一定會遇到的場景，我們針對敏捷開發方式和瀑布式開發方式分別聊一聊新增需求的處理方法：

在敏捷開發方式中，工程師們按照產品負責人寫好的故事點進行有穩定的迭代，在突然接到新增的需求后，產品負責人需要去判斷這個新增的需求對于產品架構的影響——是否影響已完成的迭代，或者對后續的迭代計劃有很大的沖突；

如果沒有很大的影響，那么直接更新到后面的迭代中就好；

如果是對當前故事點有影響，最好能拒絕就拒絕，拒絕不了嘗試在本故事點后插入一個新的故事點來滿足這個新增需求，最壞的辦法才是加班滿足，畢竟這樣對測試的壓力還是很大的；

如果是對整體很大的影響或者沖突，那么建議產品負責人反思一下產品架構的設計，并跟高層商量一下重構；

在敏捷開發環境中，需求的控制方法并不是直接控制需求，而是是否遵守“敏捷”規則，如果不完全使用“敏捷”規則，而是敏捷與瀑布式集合，那么就比較容易出現很多問題，其中無法控制需求就是一個比較嚴重的問題。

在瀑布式開發方式中，需求的提出方大多數是由客戶來扮演的，所以控制需求相對比較容易一些，比如可以嘗試這些方法：

①談錢：商業行為中最合適的就是談錢了，如果客戶提出新需求，作為項目經理分析之后給出報價，雙方開開心心地簽合同執行，這是最好的結果；

②談影響：多數情況下遇到的麻煩事就是客戶突然找到你，說必須在這個月上線XXX功能，否則不給簽驗收；初級項目經理很容易就被客戶嚇到連夜組織工程師趕工，拼命把新需求上線，最后因為嚴重壓縮開發和測試時間，質量一塌糊涂；

其實遇到這種情況的時候，安心跟客戶談影響就好了（你嚇我，我也嚇你），首先你需要掌握客戶的角色以及想要新增需求的原因，然后跟客戶一起坐下來討論一下強行新增的影響：質量無法保證、進度無法保證、成本嚴重超支；而你和客戶都是無法承擔這些后果的，討論之后的事情多數就會對你有利了，比如客戶被嚇倒了，收回了新需求，再比如客戶確實急，然后去協調你的領導給你增派資源解決當前問題。

2. 替換

需求的替換，其實就是先減掉某個需求，再新增某個需求，控制好成本和資源就好了。

Tips：需求控制是在生產環節最重要的一環，項目經理與產品經理都需要有足夠的控制力，來掌控生產工作的范圍；

而提升自己控制力的最好方法就是嚴格執行制度，公司有相關制度就要帶領伙伴們一起執行；公司沒有相關制度就自己制定一個制度，來約束伙伴們的行為；

另外，如果你能自己制定制度，那么這個制度就可以成為你的方法論，甚至可以升級成為公司級別的方法論，大家加油！

四、識別——影響需求的因素早知道

這里的識別主要指的是針對影響需求和期望的風險進行識別；

其實針對需求的管理，講完識別需求和期望、確認需求和控制需求后基本就結束了，但是作為一個經常被客戶折磨的項目經理，還是想多嘮叨點關于識別風險的事情；

對項目經理群體來說，識別風險這件事就是日常工作；這邊想要提醒的是初級項目經理，因為多數初級項目經理是不會習慣于去主動識別風險的，而是風險已經發生，甚至風險已經升級到問題的時候，才去著手處理問題，這是很不好的習慣；

針對需求和期望的管理，建議多與客戶溝通，及時識別能夠影響客戶需求和期望的因素；舉個相對應景的例子，如果你做的是一個社區管理軟件，當疫情剛剛爆發的時候，是不是就會有健康情況上報的隱形需求存在，而疫情爆發這件事就一定會影響社區的管理者，這就是一個對于項目有影響的風險，其他同理，需要多交流，多識別，多想；

對于產品經理群體來說，多數產品在識別風險這個方面做的并不多；建議產品經理們也培養一下識別風險的習慣；高階的產品經理其實已經在做這件事了，而他們把識別風險稱作“掌握市場動態”；

這邊建議初級產品經理也經常關注一下市場動態，了解了解當前的市場環境與經濟環境，帶入自己的產品思考一下：這個熱點會不會對我的產品有影響等等。

Tips：識別風險，對于控制客戶的需求和期望是有很大幫助的，比如識別到某些風險后主動跟客戶提出解決方案，那么這件事的主動權就在你的手上了。

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

題圖來自Unsplash，基于CC0協議