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

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

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

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

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

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

回頭想想，為什么我們在做這個項目——不就是領(lǐng)導們冒出了個想法，想讓我們實現(xiàn)嘛。

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

小張做錯了么？

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

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

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

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

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

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

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

確認環(huán)節(jié)分為兩個重要的點——確認和執(zhí)行

1. 確認

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

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

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

再比如，如果你是軟件交付的項目經(jīng)理，客戶說“我希望在這里加一個XXX功能”，你需要做的同樣不是直接找產(chǎn)品經(jīng)理和工程師們?nèi)?zhí)行，而是跟客戶溝通好需求的細節(jié)后，出一份寫明功能點的確認單據(jù)，讓客戶簽字。

2. 執(zhí)行

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

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

這里給初級項目經(jīng)理或者是產(chǎn)品管理者一個建議——強硬一些！

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

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

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

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

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

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

1. 新增

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

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

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

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

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

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

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

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

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

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

2. 替換

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

Tips：需求控制是在生產(chǎn)環(huán)節(jié)最重要的一環(huán)，項目經(jīng)理與產(chǎn)品經(jīng)理都需要有足夠的控制力，來掌控生產(chǎn)工作的范圍；

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

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

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

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

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

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

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

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

這邊建議初級產(chǎn)品經(jīng)理也經(jīng)常關(guān)注一下市場動態(tài)，了解了解當前的市場環(huán)境與經(jīng)濟環(huán)境，帶入自己的產(chǎn)品思考一下：這個熱點會不會對我的產(chǎn)品有影響等等。

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

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

題圖來自Unsplash，基于CC0協(xié)議