產(chǎn)品經(jīng)理在日常工作的過程中，經(jīng)常會面對突如其來的需求，如果不能在短時間內(nèi)記錄需求、處理需求，會對后期的產(chǎn)品開發(fā)排期產(chǎn)生一定的影響。因此，本文討論在面對新的需求場景下，產(chǎn)品經(jīng)理應該如何有效地處理突發(fā)需求。

一、問題的來源

在日常的工作中，各種突發(fā)需求經(jīng)常來源于客戶、老板、其他部門，這些人提出的需求經(jīng)常與原有計劃產(chǎn)生沖突，使本來就擁擠的需求隊列更雪上加霜。

二、問題原因

對于經(jīng)驗不夠的產(chǎn)品新人通常會直接答應下去，以證明自己的工作能力優(yōu)秀，能夠完成多種需求，但這種想法對于成熟的產(chǎn)品經(jīng)理來說，是片面的、缺乏思考的。

當時的需求源為領導或客戶，自己因?qū)Ψ铰毤?身份重要性，在緊張的情況下，直接不經(jīng)思考許諾了對方，由此對正常排期造成一定的影響。

下面我舉例說明一下具體的偽需求：

• 這個需求很新穎，但不能助力業(yè)務增長。
• 這個需求聽起來對業(yè)務增長很可觀，但沒有經(jīng)過驗證。
• 這個需求很容易完成，但是不值得做。
• 這個需求可是領導提的，但這不是真實需求。

三、問題的影響

沒有經(jīng)過深度思考后答應需求方，會帶來以下后果：

• 重新調(diào)整需求開發(fā)的優(yōu)先級。 比如：按照排期，前端開發(fā)工程師正在開發(fā)【權(quán)限配置頁面】，但你已經(jīng)答應別人修改【審批流程頁面UI】為最高優(yōu)先級，現(xiàn)在你只能讓前端優(yōu)先修改【審批流程頁面UI】，這就可能導致了前端開發(fā)工程師逾期完成【權(quán)限配置頁面】，如果【權(quán)限配置頁面】需要前后端聯(lián)調(diào)，可能還會影響后端的開發(fā)進程，帶來連鎖進度影響。
• 重新調(diào)整開發(fā)資源配置。 比如：現(xiàn)在有兩個前端工程師和兩個后端工程師正在聯(lián)調(diào)【表單功能模塊】，當你答應別人的緊急需求以后，需要一個前端和一個后端去處理你的新需求，因此，拖延了【表單功能模塊】的上線日期，導致排在【表單功能模塊】后的【審批功能模塊】的開發(fā)人力資源缺失。
• 重新安排相關(guān)日程。 對于以開發(fā)為中心點，輻射其他工作的影響，可根據(jù)團隊任務輕重來評估。當今的互聯(lián)網(wǎng)公司，已經(jīng)摒棄了軟件時代瀑布式開發(fā)流程，采用了敏捷開發(fā)模式，敏捷開發(fā)模式的優(yōu)點是可以根據(jù)實際需求，帶領團隊快速做需求變更。當你的團隊被臨時任務壓滿，其靈動性會大幅降低，導致面對意外的能力大幅降低。

四、解決問題

4.1 面對不斷涌起的突發(fā)需求

一個有減肥需求的人士去健身房，如果沒有提前規(guī)劃好健身方案、沒有系統(tǒng)地學習健身姿勢，那么最后的結(jié)果很可能是沒有減肥，反而因為不正確的姿勢傷了身體。

所有的需求終將轉(zhuǎn)化為功能或者服務，而服務和功能是助力業(yè)務為公司創(chuàng)造價值的源泉，如果將不經(jīng)過深度思考的需求投入開發(fā)或者修改，將會浪費人力成本，甚至會影響公司收益。

4.2 留給自己思考空間

在突然接到用戶的需求時，不要立刻給出答案，一定要留給自己空間去評估需求的真?zhèn)?、需求的緊急程度、需求的實現(xiàn)難度等一系列因素。那么在突發(fā)需求場景中，如何為自己創(chuàng)造思考的空間呢？

需要用到這個方法：

肯定需求方/感謝需求方的支持+翻譯/確認需求方的具體需求+請需求方給時間思考如何幫其更有效地解決問題。

其在場景中應用的示例如下：

• 肯定需求方/感謝需求方的支持： 感謝您提出的建議、您這個建議確實對產(chǎn)品價值提升起到了一定的幫助、您講的這個方向挺新穎的、這個確實是個可以深入的點。
• 翻譯/確認需求方的具體需求： 您的意思是想優(yōu)化一下頁面、您覺得系統(tǒng)的流暢度還能得到改善、您對于系統(tǒng)操作順序可能有點異議。
• 請需求方給時間思考如何幫需求方更有效地解決問題：請您給我點時間看下還能不能有更多的改進空間、麻煩您稍等下我現(xiàn)在去找開發(fā)確認下情況。

接下來我舉兩個實際場景中發(fā)生的例子：

客戶： 我覺得你們的產(chǎn)品近來一段時間頁面都沒有什么大的變化，請你們立刻改一下頁面UI，下午有個領導要來視察，你現(xiàn)在告訴我下大概什么時間可以改好。
產(chǎn)品經(jīng)理： 您提的這個需求很重要，我也很重視，對于領導檢查確實得認真準備一下，您剛提的要求能不能給我10分鐘思考的時間，我主要想一下怎么配合您的建議改善下系統(tǒng)的現(xiàn)狀，以便能更好地支撐領導檢查。

客戶： 這個【權(quán)限功能】你們不是剛開始嗎，要不先別做了，我覺得沒什么實際用處，咱們系統(tǒng)又不涉及權(quán)限分發(fā)這一塊的內(nèi)容。
產(chǎn)品經(jīng)理： 您一直以來對產(chǎn)品的要求都比較務實，對開發(fā)團隊的工作量也很照顧，【權(quán)限功能】目前已經(jīng)開展了一定的研發(fā)進度，您能不能給我一點時間，我先去評估下現(xiàn)在開發(fā)的具體進展，我馬上給您回復。

4.3 需求處理方法論

接下來要面對的問題是：如何在短時間內(nèi)高效評估需求的有效性。

產(chǎn)品經(jīng)理必須要有一套需求處理的方法論，一般稱呼為產(chǎn)品路線圖/產(chǎn)品流程圖/產(chǎn)品象限圖等。無論那種方法，其核心都是管理需求的優(yōu)先級。

筆者在管理需求優(yōu)先級實際應用的過程中，一般先通過【優(yōu)先級估算】的方式，快速定位需求優(yōu)先級的大概位置，排除偽需求。然后通過【需求優(yōu)先級模型】得到需求在需求池中的排名。

4.3.1 需求優(yōu)先級估算

優(yōu)先級估算主要通過兩方面去考量：

1. 業(yè)務價值考量。
2. 相關(guān)資源考量。

業(yè)務價值考量： 主要通過衡量需求和公司主線業(yè)務的相關(guān)性做出預估，在這個粗評估階段主要考慮使用者對該需求的接觸頻率、該需求所輻射的使用者數(shù)量，此需求對于業(yè)務增長產(chǎn)生的效益和實現(xiàn)此需求所花費成本之間的權(quán)衡。

舉例來講：對于To C領域，此需求能不能為公司主線產(chǎn)品獲取新用戶、提高留存率、提升用戶轉(zhuǎn)換率、增加私域流量等——以公司主線業(yè)務指標去衡量需求的效益。

相關(guān)資源考量： 相關(guān)資源主要考慮包含人力、物力。人力是指：投入開發(fā)、設計所花費的人力成本，和需求落地帶來效益的對比。物力是指：滿足此需求的過程，是否需要采購其他產(chǎn)品；是否需要花費額外的龐大資源助力需求落地。（例：Openai公司訓練chatgpt4一次所耗費的電能約為美國120個家庭一年的耗電量，開發(fā)這種量級的系統(tǒng)應把物力消耗考慮其中）

通過兩個估算過程，大概能夠排除掉一般的偽需求，那么有些需求涉及的方面比較多，對業(yè)務的影響比較大，無法通過估算排期，那么接下來需要引入【需求優(yōu)先級模型】進行處理。

4.3.2 需求優(yōu)先級模型

需求優(yōu)先級模型的引入的目的是：通過成熟的方法論，根據(jù)不同場景需求，使用不同的判斷模型，將突發(fā)的需求和正在開發(fā)的需求進行對比，通過判斷突發(fā)需求的優(yōu)先級，來保證正在開發(fā)的需求邊際收益最大化。

4.3.2.1 MoSCoW模型（莫斯科模型）

• M – Must（必須）: 對系統(tǒng)成功實施至關(guān)重要的需求——這些需求是客戶對產(chǎn)品的基本要求，是主力推動業(yè)務增長的功能或服務。 例如：微信的最重要的功能是通訊，而不是朋友圈。
• S – Should（應該）: 對系統(tǒng)的成功實施非常重要，但不像Must那樣急迫——這種功能通常會滿足客戶的“爽點”和“癢點”提高用戶體驗、增強用戶粘度。 例如：Iphone6，豈止于大，這種能夠滿足用戶情感訴求的解決方案。
• C – Could（可以）: 這些需求在Must和Should滿足之后會被考慮，但它們不是緊急的。 例如：對于一個軟件產(chǎn)品，【多語言支持】功能不是項目成功的關(guān)鍵因素，但可以為更廣泛的用戶群體帶來價值。當基本功能和核心特性已經(jīng)實現(xiàn)并投入使用后，團隊可以考慮增加【多語言支持】功能作為下一步的改進。
• W – Won’t（不做）: 這些需求在當前版本中不會被實現(xiàn)，但可以作為后續(xù)版本的候選。

優(yōu)點總結(jié)： MoSCoW模型優(yōu)先級層次分明，節(jié)省排期時間，易于相關(guān)方理解；在Must欄目中，涵蓋了主要的發(fā)展目標，可作為OKR工作法中的北極星指標，使整個團隊專注于最重要的真實需求，避免了過多的資源浪費。

缺點總結(jié)： MoSCoW模型分類不夠細化，只有四種優(yōu)先級；在判斷需求的重要性時，決策者主觀介入較多，沒有各需求檔次之間的劃分標準，導致需求優(yōu)先級排列不準確。

4.3.2.2 RICE模型

RICE 是一個縮寫，代表著四個指標：Reach（受眾規(guī)模）、Impact（影響力）、Confidence（信心度）和Effort（工作量）。這些指標以加權(quán)的方式用于計算每個項目的優(yōu)先級分數(shù)。

公式：優(yōu)先級得分 = ( R * I * C ) / E

• Reach（受眾規(guī)模）：指項目對受眾的影響范圍，即有多少用戶會受益于該項目，通常使用百分比表示。例：假設你是一家【在線教育平臺】的產(chǎn)品經(jīng)理，你正在考慮開發(fā)一個新功能，該功能將允許用戶通過平臺與導師進行一對一的在線輔導。在這種情況下，”Reach” 將評估該功能能夠影響的用戶數(shù)量。如果你的用戶總數(shù)為100人，你預估影響90人，那么“Reach”值為90%。
• Impact（影響力）：表示該項目對用戶或業(yè)務的影響程度，通常在指標化程度上進行評估。評分使用1到10之間的數(shù)，10分表示影響力最大。例：假設你是一家電子商務公司的產(chǎn)品經(jīng)理，你正在考慮一個新功能，該功能將改變用戶結(jié)賬流程，使其更加簡化和便捷。在這種情況下，”Impact” 將涉及到該功能對用戶體驗和轉(zhuǎn)化率的影響。如果該功能被實施后，用戶結(jié)賬的流程變得更加快速和直觀，會顯著提高購買轉(zhuǎn)化率，并且?guī)砀嗟匿N售收入。這樣的影響將被認為是高的，因為它直接關(guān)系到業(yè)務的核心目標，一般打9-10分。
• Confidence（信心度）：指評估該項目所需工作實施的信心度，考慮到資源、技術(shù)和市場等方面的風險。信心度也是用1-10的分數(shù)來評分。例：假設你是一家新創(chuàng)公司的產(chǎn)品經(jīng)理，你考慮實施一個新的社交媒體功能，該功能將增加用戶之間的互動和分享。在這種情況下，”Confidence” 將涉及到你對該項目成功實施的信心程度。 如果你有充分的數(shù)據(jù)支持，可以證明類似的功能在其他平臺上取得了成功，并且你的團隊也具備開發(fā)和推出這一功能所需的技術(shù)和資源，那么你可能會對該項目的成功有很高的信心，一般打8-10分。 如果這個功能需要依賴尚未成熟的技術(shù)，或者缺乏可靠的數(shù)據(jù)來支持其潛在的成功，你可能會對項目的成功實施有較低的信心，一般打2-5分。
• Effort（工作量）：表示實現(xiàn)該項目所需的時間和資源投入。使用時間（例如，人天）來表示，例如，需要5個人天的工作量。

優(yōu)點總結(jié)： RICE方法從產(chǎn)品開發(fā)的各種方面進行評估，考慮周全，不僅考慮到了產(chǎn)品資源，也考慮到了開發(fā)能力；同時，這種方法在實際應用中評估過程較為簡單，通過將需求數(shù)據(jù)化評估，使得需求優(yōu)先級排列更為精準。

缺點總結(jié)： 受眾人群和信心評價較為主觀，由于環(huán)境和場景對決策人的影響，可能會和實際情況產(chǎn)生一定的誤差；整體評估流程只是評估了關(guān)鍵因素，還有很多影響較大因素，未被納入評估，如：技術(shù)可行性等。

4.3.2.3 馬斯洛需求模型

馬斯洛的需求層次結(jié)構(gòu)是心理學中的激勵理論，包括人類需求的五級模型，通常被描繪成金字塔內(nèi)的等級。從層次結(jié)構(gòu)的底部向上。需求分別為：

1. 生理（食物和衣服)： 例如：當一個人很饑餓時，那么他極需要食物。假設人需要工作的薪酬來生存，其具體表現(xiàn)形式為：領導以生理需求來激勵下屬。
2. 安全（工作保障）： 例如：一個工作者居無定所，四處漂泊，沒有相關(guān)的職業(yè)保障，缺乏相應醫(yī)療保險、失業(yè)險和退休福利等。
3. 社交需要（友誼）： 例：一個人要求與其他人建立感情的聯(lián)系或關(guān)系。
4. 尊重： 例：自尊的需要使人相信自己的力量和價值，使得自己更有能力，更有創(chuàng)造力。缺乏自尊，使人自卑，沒有足夠信心去處理問題。
5. 自我實現(xiàn)：例：運動員把自己的體能練到極致，讓自己成為世界第一，只是單純?yōu)榱顺阶约骸?/li>

這種五階段模式可分為不足需求和增長需求。其優(yōu)先級對應1（最高）-5（最?。?/p>

優(yōu)點總結(jié)： 馬斯洛的理論為人們的需求提供了一個清晰的結(jié)構(gòu)，幫助人們快速定位需求層級，同時可以判斷出需求方的主要訴求，以便更好地采用方法論幫其解決問題。

缺點總結(jié)： 馬斯洛需求理論并未考慮到不同文化下的需求差異，可能不能完全適用于所有人群，其次，該理論是建立在所有人的需求層級結(jié)構(gòu)的相似性，但每個人的需求順序和重要性都是存在差異的。

五、反饋問題

在確認完需求的合理性以后，需要對需求方做需求評定反饋，在對需求方反饋問題的時候，大致分成兩種情況，第一：對方的需求經(jīng)過評估，不是一個有效的需求。第二：對方的需求是一個有效的需求。

1. 如果對方的需求無效：首先，要感謝需求方對開發(fā)流程的幫助與指導，其次，闡明開發(fā)流程中與需求的相關(guān)性、需求對開發(fā)的影響，以及對需求實現(xiàn)以后的判斷。最后，給需求方一個結(jié)論。例：您提的這個需求很好，有助于對用戶體驗的改進，是這樣的：我們現(xiàn)在開發(fā)正在主要做權(quán)限結(jié)構(gòu)相關(guān)功能落地，這個需要前后端協(xié)同開發(fā)，而且快到了上線交付日期了。我們會將您提的需求安排在下個階段，在整體產(chǎn)品升級的時候，我們會重點考慮您提的建議，感謝您的指導。
2. 如果對方的需求合理： 直接向?qū)Ψ奖磉_謝意，同時告知需求方開發(fā)排期，大概多久這個變更可以投入上線使用。

以上是筆者根據(jù)自身的真實經(jīng)歷總結(jié)的一些技巧，希望可以幫助到剛?cè)肼毜漠a(chǎn)品朋友。