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

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

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

可以說，產品經理把原型做出來并在評審通過后，就成為了一份“綱領性”文件。每個人都會圍繞它為中心進行工作。

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

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

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

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

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

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

一、需求變更的原因

明確了這點，我們再來討論：需求變更是什么原因導致的？

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

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

下面逐一解釋：

1. 產品經理原因

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

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

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

再舉個反面例子：

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

最后的結果就是：用戶關注了你的公眾號，但實際上最后一步的漏斗轉化就缺失了，白白流失了這部分用戶的進一步轉化。

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

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

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

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

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

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

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

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

3. 財務部門的原因

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

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

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

4. 公司的原因

這可能是公司策略的改變，所以需要對產品進行修正、甚至重構的過程，也可能是上級領導根據其意愿所安排的需求變更。

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

5. 市場/用戶的原因

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

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

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

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

這里往往是因為底層技術的限制、服務器、開發(fā)成本、資源限制等方面的原因導致需求變更（比如砍需求、對需求進行成本分析，找成本少的先實現(xiàn)）

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

二、產生需求變更的時間階段

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

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

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

前2個時間階段是由產品經理定奪，算不上需求的變更，但涉及到其他角色的參與，也算在內。

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

也就是說，如果需求變更是科學的、合理的，產品經理以解決問題為己任，因此，推動變更成為了產品經理所必須背負的一個“鍋”。

如果需求變更后，產品經理如何進行推動和落實呢？這里有一份筆者總結的“需求變更落實難度”的模型，僅供參考。

需求變更落實難度模型

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

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

三、建議

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

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

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

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

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

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