編輯導(dǎo)語：產(chǎn)品經(jīng)理在日常工作中經(jīng)常會接收到各方來的需求，對于這些需求需要進(jìn)行評估和取舍，選擇性的實(shí)現(xiàn)需求，而后期對于需求的更新迭代也有著一定的邏輯；本文作者分享了關(guān)于To B需求頻繁變更應(yīng)該怎么控制的方法，我們一起來看一下。

作為產(chǎn)品經(jīng)理，最常打交道的一個(gè)詞就是“需求”，從需求調(diào)研、需求池、需求優(yōu)先級、需求文檔（PRD）、需求排期、需求迭代、需求分析，“需求”貫穿整個(gè)產(chǎn)品設(shè)計(jì)的過程。

不同產(chǎn)品經(jīng)理的PRD風(fēng)格多樣，但是必有一個(gè)共通點(diǎn)，就是《版本/需求變更記錄》，可見需求變更是一個(gè)十分常見的場景。

下文將根據(jù)筆者的工作經(jīng)驗(yàn)，從需求變更的原因、類型、應(yīng)對方法以及如何控制變更來做一下總結(jié)，拋磚引玉。

一、為什么需求會頻繁變更？

1. 業(yè)務(wù)不穩(wěn)定，需求跟隨業(yè)務(wù)發(fā)展變動(dòng)

這種情況多發(fā)生在創(chuàng)業(yè)型企業(yè)，或者信息化程度比較初級的傳統(tǒng)型企業(yè)中。

創(chuàng)業(yè)型企業(yè)，自身的業(yè)務(wù)模式?jīng)]有穩(wěn)定下來，溫飽存亡是日日奮斗的目標(biāo)；管理流程也沒有標(biāo)準(zhǔn)化，這種情況下，軟件需求的設(shè)計(jì)，必定要隨著業(yè)務(wù)的變動(dòng)，同步進(jìn)行調(diào)整。

現(xiàn)在中國企業(yè)的發(fā)展逐漸正規(guī)化，很多民營企業(yè)發(fā)展的也不錯(cuò)；于是很多在企業(yè)內(nèi)部推行信息數(shù)據(jù)化，這對企業(yè)的作業(yè)流程、管理方式產(chǎn)生了較大的影響。

在企業(yè)傳統(tǒng)管理方式轉(zhuǎn)變?yōu)樾畔⒒芾淼倪^程中，線下業(yè)務(wù)與線上操作的沖突摩擦，導(dǎo)致需求不斷變更，甚至有可能出現(xiàn)相互矛盾的情況。

2. 需求預(yù)測出現(xiàn)偏差，需求設(shè)計(jì)的結(jié)果不正確

對需求進(jìn)行調(diào)研與設(shè)計(jì)，十分考驗(yàn)產(chǎn)品經(jīng)理對于行業(yè)的理解程度，業(yè)務(wù)的了解深度，當(dāng)前信息化系統(tǒng)的業(yè)務(wù)覆蓋范圍。

在需求變動(dòng)的相同現(xiàn)實(shí)下，優(yōu)秀的產(chǎn)品經(jīng)理對需求方向和范圍變動(dòng)預(yù)測的準(zhǔn)確性更高。如果能準(zhǔn)確預(yù)測需求將往哪個(gè)迭代，那么在設(shè)計(jì)需求的環(huán)節(jié)，就可以合理規(guī)避一些變更。

3. 需求調(diào)研偏差，業(yè)務(wù)場景覆蓋不全面

筆者在之前的一篇文章中《B端需求調(diào)研，牢記“人、場、文”三字訣》提過，需求調(diào)研需要了解業(yè)務(wù)中的角色、業(yè)務(wù)場景、輸出文檔。

如果對其中環(huán)節(jié)有遺漏或者考慮不全面，上線的需求要么就是使用率低無法解決業(yè)務(wù)問題；要么就是需求方向偏差，緊急下線，改版重新上線。

二、需求變更的類型有哪些？

需求變更的類型，可以歸納為以下幾種：

1. 功能性需求變動(dòng)

即解決這個(gè)業(yè)務(wù)問題，需要上線什么功能。比如合同簽約系統(tǒng)中，為了保證線上簽約人員的真實(shí)性，需要上線人臉識別功能。

2. 體驗(yàn)型需求變動(dòng)

一般產(chǎn)品介紹C端產(chǎn)品和B端產(chǎn)品的區(qū)別時(shí)，一般會提及C端注重交互體驗(yàn)，而B端注重企業(yè)降本增效；這里的交互體驗(yàn)，也屬于體驗(yàn)型需求的一種，為非功能性需求。

體驗(yàn)型需求一般涉及界面的變動(dòng)，需要的功能支撐較少。

比如B端的后臺收到用戶抱怨，說信息錄入過于混亂，希望技術(shù)部門予以解決；UE/UI設(shè)計(jì)師在界面上做了步驟條拆解錄入流程、對于相似信息進(jìn)行分層、復(fù)雜名詞給予詳細(xì)說明協(xié)助用戶快速理解，上線后得到用戶好評。

3. 數(shù)據(jù)類需求變動(dòng)

例如根據(jù)角色做數(shù)據(jù)隔離；例如報(bào)表系統(tǒng)上線，協(xié)助業(yè)務(wù)部門分析決策；例如系統(tǒng)遷移、對接，接口字段的定義、互傳等。

4. 規(guī)則類需求變動(dòng)

規(guī)則類需求變動(dòng)，可大可小，一般會和數(shù)據(jù)類需求、功能類需求一同出現(xiàn)；例如優(yōu)惠券的規(guī)則是一個(gè)用戶僅可領(lǐng)取一張變?yōu)橐粋€(gè)用戶最多領(lǐng)取5張。

大的規(guī)則類需求的變動(dòng)，可能會導(dǎo)致產(chǎn)品架構(gòu)大規(guī)模的調(diào)整，甚至推到重來，此類不在本文討論。

三、需求變更如何應(yīng)對？

上文講述了需求變更的可能原因以及變更的類型，那么對于頻繁變更的需求，我們除了做好心理建設(shè)，在實(shí)際工作中，應(yīng)該如何處理呢？

1. 需求優(yōu)先級劃分，保證需求迭代緊跟核心業(yè)務(wù)指標(biāo)，解決用戶痛點(diǎn)

相信產(chǎn)品經(jīng)理們都有做需求池的習(xí)慣，不管是通過Excel表格、World文檔、記事清單等。只要業(yè)務(wù)在穩(wěn)定運(yùn)轉(zhuǎn)，需求就不會有枯竭的那天，否則技術(shù)部門就要集體失業(yè)了；需求池中的需求，都是按照一定的準(zhǔn)則，做了優(yōu)先級的劃分。

常見需求優(yōu)先級劃分規(guī)則有：四象限法則/矩陣分析法、KANO模型、成本效益核算模型、二八原則、誰的權(quán)力大聽誰的模型…做需求迭代；筆者認(rèn)為需要關(guān)注兩點(diǎn)，一個(gè)是用戶，一個(gè)是核心指標(biāo)。

企業(yè)是盈利性的組織，必定要考慮商業(yè)利潤最大化的問題。比如你的產(chǎn)品的核心指標(biāo)是用戶留存，對比之下用戶注冊率是一個(gè)不那么重要的指標(biāo)；根據(jù)這個(gè)指標(biāo)，你推算出在注冊環(huán)節(jié)，應(yīng)該要求用戶填寫詳細(xì)的信息過濾掉非意向客戶，而非通過第三方快速登錄，無法有效的后續(xù)跟進(jìn)客戶。

領(lǐng)導(dǎo)認(rèn)為這種注冊方式用戶體驗(yàn)不好，但是你很明白核心指標(biāo)是什么，產(chǎn)品應(yīng)該為核心指標(biāo)服務(wù)。關(guān)于核心指標(biāo)的確認(rèn)，《精益創(chuàng)業(yè)》一書有很精彩的講解，建議有興趣的人了解一下。

用戶，更加不用說，產(chǎn)品的核心就是在解決用戶痛點(diǎn)；產(chǎn)品需要同理心，時(shí)刻站在用戶的角度去發(fā)現(xiàn)問題，設(shè)定解決方案。

2. 拆解目標(biāo)，做好版本規(guī)劃，控制研發(fā)成本

確認(rèn)要做需求變更之后，評估變更對需求池中、研發(fā)中的需求的影響；預(yù)測對現(xiàn)有軟件架構(gòu)的影響；以及技術(shù)實(shí)現(xiàn)的難度。

權(quán)衡利弊，做好版本控制，MVP簡化上線，快速驗(yàn)證調(diào)整，再次迭代。

好的需求，解決的問題多于制造的麻煩。

3. 建立統(tǒng)一需求渠道，減少需求變更對工作的影響

需求的變更，參與方包括需求提出方、產(chǎn)品經(jīng)理、研發(fā)部門、需求上線使用者。

為了減少需求變更對多方工作的影響，最好是在需求設(shè)計(jì)階段，邀請各方深度參與產(chǎn)品方案的評估，一來可以確認(rèn)變更方向無誤差；另外可以讓研發(fā)部門了解需求的方向，做好應(yīng)對措施；對于不現(xiàn)實(shí)的需求，也可以盡早暴露出來；畢竟產(chǎn)品的實(shí)際效果，是業(yè)務(wù)、產(chǎn)品、研發(fā)多方共同努力的成果。

另外可以建立統(tǒng)一的需求變更渠道，盡量將需求變更的傳達(dá)者、上線后的反饋者固定在指定的人員之間，減小溝通的成本；設(shè)定公開透明的平臺，和各方分享需求即將進(jìn)行的方向，保持信息的透明度和傳達(dá)的效率。

筆者最近在嘗試做一個(gè)公共的需求看板，將當(dāng)前研發(fā)的需求，未來規(guī)劃的需求，臨時(shí)插入的需求，變更的需求標(biāo)記出來，分享給各業(yè)務(wù)部門；需驗(yàn)證一段時(shí)間之后，再來總結(jié)實(shí)際效果。

4. 脫離軟件設(shè)計(jì)，提供其他途徑的解決方案

不給自己設(shè)限，也不給產(chǎn)品方案設(shè)限。需求變更的本質(zhì)原因在于業(yè)務(wù)遇到了難點(diǎn)，解決的方式可以有多種，不一定是在軟件系統(tǒng)上做需求迭代；或許可以通過需求調(diào)研，頭腦風(fēng)暴發(fā)現(xiàn)業(yè)務(wù)中不合理的地方，協(xié)助業(yè)務(wù)解決。

5. 需求變更，事后評估及時(shí)復(fù)盤，升級認(rèn)知

上文有說到，需求的變更，有可能是產(chǎn)品經(jīng)理對行業(yè)的預(yù)測、業(yè)務(wù)的了解深度、系統(tǒng)的業(yè)務(wù)覆蓋范圍不夠而引起；產(chǎn)品經(jīng)理除了需要加深自身的認(rèn)知，還需要對需求的變更及時(shí)進(jìn)行復(fù)盤，實(shí)踐出真知。

6. 合理拒絕需求，控制需求的范圍

筆者在面試過程中會問應(yīng)聘者如何設(shè)定需求的優(yōu)先級，有人講述了領(lǐng)導(dǎo)要求緊急上線需求，最后拼命壓縮時(shí)間，按時(shí)上線的案例，這實(shí)際上是一個(gè)比較失敗的答題方式。

雖然前文有戲謔領(lǐng)導(dǎo)可以決定需求的優(yōu)先級，但這句話隱含的是，領(lǐng)導(dǎo)在自己的領(lǐng)域內(nèi)是專業(yè)的，可以確定自己負(fù)責(zé)的業(yè)務(wù)內(nèi)需求的優(yōu)先級。

但是需求的具體實(shí)施，是需要結(jié)合軟件系統(tǒng)的實(shí)際情況、研發(fā)團(tuán)隊(duì)的資源配置情況、需求在產(chǎn)品設(shè)計(jì)中的合理性、需求的ROI，多方平衡之后再做取舍。

筆者認(rèn)為，有理有據(jù)的拒絕需求的時(shí)候，是一個(gè)小白產(chǎn)品成長的里程碑。

四、總結(jié)

需求可能因?yàn)闃I(yè)務(wù)不穩(wěn)定、需求調(diào)研不準(zhǔn)確、需求預(yù)測出現(xiàn)偏差，導(dǎo)致變更。

作為需求實(shí)施人，產(chǎn)品經(jīng)理可以嘗試這樣應(yīng)對：

1. 劃分需求優(yōu)先級，確認(rèn)需求為核心指標(biāo)服務(wù)；
2. 拆解目標(biāo)，做好版本規(guī)劃，控制研發(fā)成本；
3. 建立統(tǒng)一需求渠道，減少需求變更對工作的影響；
4. 脫離軟件設(shè)計(jì)，提供其他途徑的解決方案；
5. 需求變更，事后評估及時(shí)復(fù)盤，升級認(rèn)知；
6. 合理拒絕需求，控制需求的范圍。

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

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