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

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

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

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

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

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

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

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

小張做錯(cuò)了么？

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

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

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

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

二、確認(rèn)——容易被忽略的過程

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

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

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

1. 確認(rèn)

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

正確的做法麻煩一些，增加一個(gè)確認(rèn)的步驟：

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

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

2. 執(zhí)行

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

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

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

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

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

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

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

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

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

1. 新增

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

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

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

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

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

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

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

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

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

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

2. 替換

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

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

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

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

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

這里的識別主要指的是針對影響需求和期望的風(fēng)險(xiǎn)進(jìn)行識別；

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

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

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

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

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

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

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

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