產(chǎn)品經(jīng)理在項目進(jìn)行過程中，常常會面臨一個重大考驗：改需求！這也是產(chǎn)品經(jīng)理經(jīng)常被攻擊的地方。為什么要改？不同階段的問題是什么？這些都是擺在產(chǎn)品經(jīng)理面前的一道道難題，本文作者就這些難題分享了自己的看法，供大家參考。

產(chǎn)品從需求出發(fā)，經(jīng)過了原型設(shè)計、開發(fā)排期到測試驗收、灰度后上線的過程，可以說經(jīng)過了較長的一段時間。根據(jù)需求的復(fù)雜程度，產(chǎn)品開發(fā)時間可能需要1天、1周甚至1個月的情況。在游戲行業(yè)，產(chǎn)品開發(fā)周期則更長，多達(dá)幾個月。

我們可以把產(chǎn)品經(jīng)理完成的PRD原型，作為需求的集合。UI設(shè)計、開發(fā)、測試等部門的同事會根據(jù)原型所呈現(xiàn)的效果進(jìn)行落實。

可以說，產(chǎn)品經(jīng)理把原型做出來并在評審?fù)ㄟ^后，就成為了一份“綱領(lǐng)性”文件。每個人都會圍繞它為中心進(jìn)行工作。

一旦涉及到需求原型的變更，往往是牽一發(fā)而動全身。例如：在原型評審后，增加了一個列表排序的工作。這部分的需求變更（增加）會造成怎樣的后果呢？

• 首先：UI要根據(jù)功能進(jìn)行重新設(shè)計UI圖；
• 技術(shù)經(jīng)理要評估該功能所要開發(fā)的時間、難度、成本、可行情況；
• 測試要根據(jù)原型進(jìn)行測試用例的寫作和測試的準(zhǔn)備工作；
• 如果功能聯(lián)動到其他業(yè)務(wù)情況，牽扯出來的情況就更多了。

毫不夸張的是，需求變更更像是一種“原罪”。

每次產(chǎn)品經(jīng)理在進(jìn)行需求變更后，往往開發(fā)同事是一臉懵逼的，表現(xiàn)出“一開始，我是拒絕的”的態(tài)度，除非你能說服利益相關(guān)方。

原型的變更往往不都是產(chǎn)品經(jīng)理背的鍋。雖然需求變更可能導(dǎo)致開發(fā)效率的落后、產(chǎn)品的延期、工作氣氛的負(fù)面影響、團(tuán)隊和諧程度下降等等，這不意味著需求變更就是錯誤的。

有某些情況下，需求變更意味著產(chǎn)品通過接受市場環(huán)境變化的不確定性，所采取的有效措施，讓產(chǎn)品跟得上市場的變化，這是一種“利”，而不是“害”。

一、需求變更的原因

明確了這點，我們再來討論：需求變更是什么原因?qū)е碌模?/p>

需求變更的原因，主要有幾個方面：

1. 產(chǎn)品經(jīng)理原因
2. 開發(fā)或其他部門的原因
3. 公司的原因
4. 市場/用戶的原因
5. 客觀原因（或者不可抗拒原因）

下面逐一解釋：

1. 產(chǎn)品經(jīng)理原因

這部分的原因往往是因為產(chǎn)品經(jīng)理本身想不清楚需求、定義不清楚需求，導(dǎo)致了需求在開發(fā)過程中出現(xiàn)許多問題。

例如：比如，筆者所做過的一個項目中，涉及到針對某些渠道的掃碼關(guān)注情況的統(tǒng)計，需使用一個概念把所有相關(guān)渠道進(jìn)行概括。當(dāng)時我會把所有的相關(guān)的渠道都一一列出來。

如果我在產(chǎn)品原型里，對需求的定義模糊其詞，僅定義為“把涉及到這部分的相關(guān)掃碼渠道都進(jìn)行統(tǒng)計”，但并不列舉是哪些渠道。開發(fā)自然會懵逼。如果開發(fā)工程師把你的表述理解為了其中一個渠道，那么造成的后果是統(tǒng)計有缺漏，反應(yīng)的數(shù)據(jù)情況自然是不準(zhǔn)確的。

再舉個反面例子：

例如：當(dāng)用戶購買了某電商產(chǎn)品并支付完成后跳轉(zhuǎn)頁面，彈出了二維碼。用戶掃碼進(jìn)入該電商平臺公眾號-點擊關(guān)注，產(chǎn)品經(jīng)理在用戶關(guān)注后并不做任何的公眾號彈出的提示操作。這就是定義不清晰、想不全面。

最后的結(jié)果就是：用戶關(guān)注了你的公眾號，但實際上最后一步的漏斗轉(zhuǎn)化就缺失了，白白流失了這部分用戶的進(jìn)一步轉(zhuǎn)化。

2. 開發(fā)或其他部門的原因

這里更偏向于開發(fā)部門，其他部門則指客服、運營、銷售、財務(wù)等部門。開發(fā)部門導(dǎo)致的需求變更一般會比其他部門的多，但這塊也要根據(jù)公司業(yè)務(wù)重點情況，不能一概而論。

產(chǎn)品制定了原型并進(jìn)行了評審后，進(jìn)入了開發(fā)階段。有些情況下，需求的變更不是在評審時發(fā)現(xiàn)的問題，而是在開發(fā)時。

例如：不斷數(shù)據(jù)表之間的多層嵌套、異步特征導(dǎo)致數(shù)據(jù)加載延遲等情況，這些在產(chǎn)品體驗層面是致命傷。當(dāng)然也不可能進(jìn)行開發(fā)落實。

例如：某個數(shù)據(jù)頁面加載的時間，按照原型的不同數(shù)據(jù)方案（同步或異步讀取混合），導(dǎo)致用戶能在頁面上看到的時間為15s，雖然可以進(jìn)行前端的提示，實際上會嚇跑用戶。我們在使用各種不同app，在等待頁面過程中大概10s左右就會不會有不耐煩的表現(xiàn)呢？15s？20s呢？

因此，開發(fā)上能實現(xiàn)但造成產(chǎn)品體驗的問題，也會導(dǎo)致需求的變更。上述案例中，變更后的需求，對異步的數(shù)據(jù)分開統(tǒng)計，并加強(qiáng)產(chǎn)品提示，弱化數(shù)據(jù)入口等方式，從而減少用戶等待的期待。這樣的變更就是可以接受的。

除了開發(fā)部門之外，諸如運營部在準(zhǔn)備活動、臨時通知、運營功能臨時增加等情況下，就會造成需求變更。

測試部的變更情況，在筆者的實踐看來，更多的是從測試難易程度的角度給出的產(chǎn)品優(yōu)化建議。注意：測試本身是懂技術(shù)的，這部分的變更實際上如果測試能提供較好的方案，產(chǎn)品的需求變更也在考慮的范圍了。

3. 財務(wù)部門的原因

這個筆者也跟財務(wù)打過交道，財務(wù)部門所提出的優(yōu)化建議往往涉及到有效的對資金進(jìn)行處理的效率，這部分也需要進(jìn)行特別的考慮和評估。有時候你所做的優(yōu)化往往是財務(wù)比價迫切的，對需求進(jìn)行變更，其實帶來的是財務(wù)、財務(wù)對客戶等方面更高的效率。

由于財務(wù)并非專業(yè)于產(chǎn)品的設(shè)計，在開發(fā)成本和需求之間，產(chǎn)品經(jīng)理仍然要做好需求的把控。

當(dāng)然，還有其他情況，例如客服部門、新媒體部門等，這些都有可能會給產(chǎn)品提出一些優(yōu)化建議，導(dǎo)致需求變更的情況。

4. 公司的原因

這可能是公司策略的改變，所以需要對產(chǎn)品進(jìn)行修正、甚至重構(gòu)的過程，也可能是上級領(lǐng)導(dǎo)根據(jù)其意愿所安排的需求變更。

總而言之，這往往意味著命令的特性。我們需要對此進(jìn)行充分的了解和溝通。

5. 市場/用戶的原因

例如：產(chǎn)品經(jīng)理要針對某個社區(qū)功能進(jìn)行排行榜的設(shè)計，用戶要增加積分功能、要發(fā)放獎品、要每日的打卡行為特征…要知道，排行榜所能承載的功能非常多，不可能把所有的功能都進(jìn)行設(shè)計。

而用戶的建議則是根據(jù)其本身需求進(jìn)行的判斷，更有誘惑性。人是需求的集合體，而我們所做的產(chǎn)品是為了滿足用戶的需要一旦用戶提出了這個需求，我們恨不得馬上幫他們解決，滿足了這部分用戶的需求，就能滿足了用戶，提升滿意度。這里也是產(chǎn)生需求變更的地方。

其他的：競品、市場動態(tài)、政策趨勢等方面，都有可能造成需求變更

6. 客觀原因（或者不可抗拒原因）

這里往往是因為底層技術(shù)的限制、服務(wù)器、開發(fā)成本、資源限制等方面的原因?qū)е滦枨笞兏ū热缈承枨?、對需求進(jìn)行成本分析，找成本少的先實現(xiàn)）

以上列舉的6個方面產(chǎn)品需求變更的原因，但是秉持這“ 先內(nèi)因后外因”的處理角度，筆者建議在需求變更的原因產(chǎn)生時，要經(jīng)常從內(nèi)因、從自我本身的角度，對產(chǎn)生需求變更進(jìn)行反思和分析。

二、產(chǎn)生需求變更的時間階段

我們進(jìn)行對需求變更的原因的分析，其實還可以從需求的不同時間階段角度進(jìn)行分析。

我把產(chǎn)生需求變更的時間階段分為以下幾個：

1. 產(chǎn)品規(guī)劃階段
2. 原型階段
3. 評審階段
4. 開發(fā)前階段
5. 開發(fā)階段（初期）
6. 開發(fā)階段（中期）
7. 開發(fā)階段（后期）
8. 測試階段
9. 灰度階段
10. 上線后

前2個時間階段是由產(chǎn)品經(jīng)理定奪，算不上需求的變更，但涉及到其他角色的參與，也算在內(nèi)。

根據(jù)不同階段所產(chǎn)生的需求變更，其應(yīng)對的行動自然也會不同。產(chǎn)品經(jīng)理要推動需求變更后的落實，往往由于開發(fā)、測試、UI或者利益相關(guān)方的反對而失敗。

也就是說，如果需求變更是科學(xué)的、合理的，產(chǎn)品經(jīng)理以解決問題為己任，因此，推動變更成為了產(chǎn)品經(jīng)理所必須背負(fù)的一個“鍋”。

如果需求變更后，產(chǎn)品經(jīng)理如何進(jìn)行推動和落實呢？這里有一份筆者總結(jié)的“需求變更落實難度”的模型，僅供參考。

需求變更落實難度模型

從圖中可以看出，星級越少，則變更后的需求的落實難度越小，而星級越少的大部分是在產(chǎn)品還沒有開始開發(fā)之前。

因此，產(chǎn)品經(jīng)理如何把需求變更的可控范圍縮小到開發(fā)前，自然會減少了需求的落實壓力。

三、建議

事情往往不是我們所想象的那么順暢。無論是在哪里階段進(jìn)行的需求變更，筆者有以下的一些建議：

1. 提升產(chǎn)品能力。要把產(chǎn)品想清楚，邏輯、產(chǎn)品設(shè)計、需求定義等能力；
2. 提升項目把控能力。把產(chǎn)品當(dāng)做項目，那么，就需要你對項目進(jìn)行有效的把控；
3. 提高眼界。充分吸收外界優(yōu)秀的需求管理思想，提升對需求的處理能力、提高自己對產(chǎn)品的構(gòu)造力，站得高才能看得遠(yuǎn)。在良好的產(chǎn)品架構(gòu)下，會減少很多的無用功。

注意，我們要做的不是避免變更，而是科學(xué)的變更；把“原罪”減低到最小，充分理解并踐行需求變更后的優(yōu)勢，提高需求變更后的落地能力。

需求變更是無止境的，但只有充分保存自我的”定力“，才能在工作中游刃有余，立于不敗之地。

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

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