起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識To B | 需求頻繁變更，怎么辦？
編輯導語：產品經理在日常工作中經常會接收到各方來的需求，對于這些需求需要進行評估和取舍，選擇性的實現需求，而后期對于需求的更新迭代也有著一定的邏輯；本文作者分享了關于To B需求頻繁變更應該怎么控制的方法，我們一起來看一下。
作為產品經理，最常打交道的一個詞就是“需求”，從需求調研、需求池、需求優(yōu)先級、需求文檔（PRD）、需求排期、需求迭代、需求分析，“需求”貫穿整個產品設計的過程。
不同產品經理的PRD風格多樣，但是必有一個共通點，就是《版本/需求變更記錄》，可見需求變更是一個十分常見的場景。
下文將根據筆者的工作經驗，從需求變更的原因、類型、應對方法以及如何控制變更來做一下總結，拋磚引玉。
一、為什么需求會頻繁變更？
1. 業(yè)務不穩(wěn)定，需求跟隨業(yè)務發(fā)展變動
這種情況多發(fā)生在創(chuàng)業(yè)型企業(yè)，或者信息化程度比較初級的傳統(tǒng)型企業(yè)中。
創(chuàng)業(yè)型企業(yè)，自身的業(yè)務模式沒有穩(wěn)定下來，溫飽存亡是日日奮斗的目標；管理流程也沒有標準化，這種情況下，軟件需求的設計，必定要隨著業(yè)務的變動，同步進行調整。
現在中國企業(yè)的發(fā)展逐漸正規(guī)化，很多民營企業(yè)發(fā)展的也不錯；于是很多在企業(yè)內部推行信息數據化，這對企業(yè)的作業(yè)流程、管理方式產生了較大的影響。
在企業(yè)傳統(tǒng)管理方式轉變?yōu)樾畔⒒芾淼倪^程中，線下業(yè)務與線上操作的沖突摩擦，導致需求不斷變更，甚至有可能出現相互矛盾的情況。
2. 需求預測出現偏差，需求設計的結果不正確
對需求進行調研與設計，十分考驗產品經理對于行業(yè)的理解程度，業(yè)務的了解深度，當前信息化系統(tǒng)的業(yè)務覆蓋范圍。
在需求變動的相同現實下，優(yōu)秀的產品經理對需求方向和范圍變動預測的準確性更高。如果能準確預測需求將往哪個迭代，那么在設計需求的環(huán)節(jié)，就可以合理規(guī)避一些變更。
3. 需求調研偏差，業(yè)務場景覆蓋不全面
筆者在之前的一篇文章中《B端需求調研，牢記“人、場、文”三字訣》提過，需求調研需要了解業(yè)務中的角色、業(yè)務場景、輸出文檔。
如果對其中環(huán)節(jié)有遺漏或者考慮不全面，上線的需求要么就是使用率低無法解決業(yè)務問題；要么就是需求方向偏差，緊急下線，改版重新上線。
二、需求變更的類型有哪些？
需求變更的類型，可以歸納為以下幾種：
1. 功能性需求變動
即解決這個業(yè)務問題，需要上線什么功能。比如合同簽約系統(tǒng)中，為了保證線上簽約人員的真實性，需要上線人臉識別功能。
2. 體驗型需求變動
一般產品介紹C端產品和B端產品的區(qū)別時，一般會提及C端注重交互體驗，而B端注重企業(yè)降本增效；這里的交互體驗，也屬于體驗型需求的一種，為非功能性需求。
體驗型需求一般涉及界面的變動，需要的功能支撐較少。
比如B端的后臺收到用戶抱怨，說信息錄入過于混亂，希望技術部門予以解決；UE/UI設計師在界面上做了步驟條拆解錄入流程、對于相似信息進行分層、復雜名詞給予詳細說明協(xié)助用戶快速理解，上線后得到用戶好評。
3. 數據類需求變動
例如根據角色做數據隔離；例如報表系統(tǒng)上線，協(xié)助業(yè)務部門分析決策；例如系統(tǒng)遷移、對接，接口字段的定義、互傳等。
4. 規(guī)則類需求變動
規(guī)則類需求變動，可大可小，一般會和數據類需求、功能類需求一同出現；例如優(yōu)惠券的規(guī)則是一個用戶僅可領取一張變?yōu)橐粋€用戶最多領取5張。
大的規(guī)則類需求的變動，可能會導致產品架構大規(guī)模的調整，甚至推到重來，此類不在本文討論。
三、需求變更如何應對？
上文講述了需求變更的可能原因以及變更的類型，那么對于頻繁變更的需求，我們除了做好心理建設，在實際工作中，應該如何處理呢？
1. 需求優(yōu)先級劃分，保證需求迭代緊跟核心業(yè)務指標，解決用戶痛點
相信產品經理們都有做需求池的習慣，不管是通過Excel表格、World文檔、記事清單等。只要業(yè)務在穩(wěn)定運轉，需求就不會有枯竭的那天，否則技術部門就要集體失業(yè)了；需求池中的需求，都是按照一定的準則，做了優(yōu)先級的劃分。
常見需求優(yōu)先級劃分規(guī)則有：四象限法則/矩陣分析法、KANO模型、成本效益核算模型、二八原則、誰的權力大聽誰的模型…做需求迭代；筆者認為需要關注兩點，一個是用戶，一個是核心指標。
企業(yè)是盈利性的組織，必定要考慮商業(yè)利潤最大化的問題。比如你的產品的核心指標是用戶留存，對比之下用戶注冊率是一個不那么重要的指標；根據這個指標，你推算出在注冊環(huán)節(jié)，應該要求用戶填寫詳細的信息過濾掉非意向客戶，而非通過第三方快速登錄，無法有效的后續(xù)跟進客戶。
領導認為這種注冊方式用戶體驗不好，但是你很明白核心指標是什么，產品應該為核心指標服務。關于核心指標的確認，《精益創(chuàng)業(yè)》一書有很精彩的講解，建議有興趣的人了解一下。
用戶，更加不用說，產品的核心就是在解決用戶痛點；產品需要同理心，時刻站在用戶的角度去發(fā)現問題，設定解決方案。
2. 拆解目標，做好版本規(guī)劃，控制研發(fā)成本
確認要做需求變更之后，評估變更對需求池中、研發(fā)中的需求的影響；預測對現有軟件架構的影響；以及技術實現的難度。
權衡利弊，做好版本控制，MVP簡化上線，快速驗證調整，再次迭代。
好的需求，解決的問題多于制造的麻煩。
3. 建立統(tǒng)一需求渠道，減少需求變更對工作的影響
需求的變更，參與方包括需求提出方、產品經理、研發(fā)部門、需求上線使用者。
為了減少需求變更對多方工作的影響，最好是在需求設計階段，邀請各方深度參與產品方案的評估，一來可以確認變更方向無誤差；另外可以讓研發(fā)部門了解需求的方向，做好應對措施；對于不現實的需求，也可以盡早暴露出來；畢竟產品的實際效果，是業(yè)務、產品、研發(fā)多方共同努力的成果。
另外可以建立統(tǒng)一的需求變更渠道，盡量將需求變更的傳達者、上線后的反饋者固定在指定的人員之間，減小溝通的成本；設定公開透明的平臺，和各方分享需求即將進行的方向，保持信息的透明度和傳達的效率。
筆者最近在嘗試做一個公共的需求看板，將當前研發(fā)的需求，未來規(guī)劃的需求，臨時插入的需求，變更的需求標記出來，分享給各業(yè)務部門；需驗證一段時間之后，再來總結實際效果。
4. 脫離軟件設計，提供其他途徑的解決方案
不給自己設限，也不給產品方案設限。需求變更的本質原因在于業(yè)務遇到了難點，解決的方式可以有多種，不一定是在軟件系統(tǒng)上做需求迭代；或許可以通過需求調研，頭腦風暴發(fā)現業(yè)務中不合理的地方，協(xié)助業(yè)務解決。
5. 需求變更，事后評估及時復盤，升級認知
上文有說到，需求的變更，有可能是產品經理對行業(yè)的預測、業(yè)務的了解深度、系統(tǒng)的業(yè)務覆蓋范圍不夠而引起；產品經理除了需要加深自身的認知，還需要對需求的變更及時進行復盤，實踐出真知。
6. 合理拒絕需求，控制需求的范圍
筆者在面試過程中會問應聘者如何設定需求的優(yōu)先級，有人講述了領導要求緊急上線需求，最后拼命壓縮時間，按時上線的案例，這實際上是一個比較失敗的答題方式。
雖然前文有戲謔領導可以決定需求的優(yōu)先級，但這句話隱含的是，領導在自己的領域內是專業(yè)的，可以確定自己負責的業(yè)務內需求的優(yōu)先級。
但是需求的具體實施，是需要結合軟件系統(tǒng)的實際情況、研發(fā)團隊的資源配置情況、需求在產品設計中的合理性、需求的ROI，多方平衡之后再做取舍。
筆者認為，有理有據的拒絕需求的時候，是一個小白產品成長的里程碑。
四、總結
需求可能因為業(yè)務不穩(wěn)定、需求調研不準確、需求預測出現偏差，導致變更。
作為需求實施人，產品經理可以嘗試這樣應對：
- 劃分需求優(yōu)先級，確認需求為核心指標服務；
- 拆解目標，做好版本規(guī)劃，控制研發(fā)成本；
- 建立統(tǒng)一需求渠道，減少需求變更對工作的影響；
- 脫離軟件設計，提供其他途徑的解決方案；
- 需求變更，事后評估及時復盤，升級認知；
- 合理拒絕需求，控制需求的范圍。
本文由 @RaRa 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 unsplash，基于 CC0 協(xié)議
其實最大的問題在于，如何能把規(guī)范的需求變更流程按規(guī)范走完，同時如何拉通業(yè)務干系人完成評審，有的人怪你沒拉通到位有的人當時不吱聲，事后出問題才說…我覺得最大的不確定性因素都是人，但人是最難管的
需求評審會確實很必要，不能因為合同時間節(jié)點比較緊而忽略，后期會出現開發(fā)與需求理解不一致等一系列問題。降低團隊的整體開發(fā)效率。得不償失。