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

一、問題的來源

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

二、問題原因

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

當時的需求源為領導或客戶，自己因對方職級/身份重要性，在緊張的情況下，直接不經思考許諾了對方，由此對正常排期造成一定的影響。

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

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

三、問題的影響

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

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

四、解決問題

4.1 面對不斷涌起的突發需求

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

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

4.2 留給自己思考空間

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

需要用到這個方法：

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

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

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

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

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

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

4.3 需求處理方法論

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

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

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

4.3.1 需求優先級估算

優先級估算主要通過兩方面去考量：

1. 業務價值考量。
2. 相關資源考量。

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

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

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

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

4.3.2 需求優先級模型

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

4.3.2.1 MoSCoW模型（莫斯科模型）

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

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

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

4.3.2.2 RICE模型

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

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

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

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

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

4.3.2.3 馬斯洛需求模型

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

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

這種五階段模式可分為不足需求和增長需求。其優先級對應1（最高）-5（最?。?。

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

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

五、反饋問題

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

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

以上是筆者根據自身的真實經歷總結的一些技巧，希望可以幫助到剛入職的產品朋友。