很多産品同學在創業公司，可能因為話語權不夠，是以導緻可能開發直接對接需求。但需要明确的是，産品一定是對接需求的。産品經理這個崗位存在的意義就是因為需求的存在。使用者需求不等同于系統需求，相信自己介入需求到開發中的價值。
一、好需求的定義
1.1 好需求的摸樣
調研需求之前，我們需要在内心有一個好需求的摸樣，可以遵循GPSPAC原則。
- Goal目标：為什麼要去做這個事情？
- Process流程：達成目标所需要的組織協調方式；
- Scene場景：流程中所有可能出現的狀況（正常、異常）；
- Person人員：特定場景中涉及到的人/部門；
- Action行動：特定場景下的人進行的判斷和動作；
- Check檢查：對于人員所需要采取行動的檢查（非必選）；
有了一個“标準”的答案在心裡了，那麼你在紛繁複雜的業務中調研需求的時候，就不會被業務牽着鼻子走，你會順着你的标準來引導業務向你娓娓道來你想要的，去抓住GPSPAC。
二、擷取B端需求
擷取需求之前先明确需求的背景，明确需求的價值和厘清目前現在業務的現狀。更重要的是識别需求的真僞性，不要被使用者牽着鼻子走。不要隻聽一面之詞，兼聽則明。
2.1 擷取需求
明确需求背景
需求背景是整個産品設計的前提，隻有深刻了解背景裡所存在的問題、及對應的使用者痛點，才能把握好産品的設計方向。同時隻有大家都認可這個背景的真實、有效和價值，才能夠更好推進産品方案的落地。
完整需求背景的一般包含三個部分：使用者、場景和需求。即使用者在什麼樣的場景下，遇到什麼樣的問題/或者對于目前的産品産生了怎樣的需要或者訴求。或者更深入一點，何人在何地，因為什麼原因，用什麼方法做了什麼事情，做到什麼程度/取得了什麼結果。
5W1H具體指的是：
- 何因（Why）：原因
- 何事（What）：對象或什麼事情
- 何地（Where）：地點
- 何時（When）：時間
- 何人（Who）：人員或責任人
- 何法（How）：方法或程式
此外，有的時候也會加入”多少”（How Many），用以進一步明确數量級和規模。這種方法鼓勵從原因、對象、地點、時間、人員和方法這六個方面對標明的項目、工序或操作提出問題進行深入思考。例如，公司生産什麼産品？這個産品在哪裡生産？為什麼要生産這個産品？這些産品是什麼時候生産的？這些産品是由誰來生産的？以及這些産品是如何生産的？等等。這種多角度的思考方式可以幫助我們更全面地了解一個問題或者情況，進而做出更加明智的決策。
在産品設計的時候，應該就用“使用者+場景+需求”的句式來反複确認，産品背景是否把握準确未偏離方向；向開發介紹的時候也應利用這種句式，邏輯清晰地向他們傳達出功能背後的價值。
厘清現狀
- 不解決誰會難受？
- 有多難受（最好有量化名額，比如：不做就要有多少人線下花費多少時間成本去做？錯誤率，風險等等）
- 多久難受一次（頻次)
- 目前的方案是怎麼做的
明确需求價值
- 這個需求從哪産生的？
- 解決了什麼問題？
- 我們目前的資源足以完成這個嗎？
- 這一塊業務中最痛的痛點是什麼？
- 為什麼過去沒做，未來不做，而是現在做？
注意：對于使用者我們隻挖掘問題，不挖掘方案；
2.2 需求的價值
生産效率的思考角度
- 整體協同鍊路的效率提升 。(如報帳到放款時間降低，退款時間降低等，管理痛點）
- 機關生産資料的産出提升或機關産出的成本降低 。(如銷售訪客數的上升，一個客服接電話數的上升，操作痛點）
- 規模化下決策難度降低或準确率提升。(如資料報表，業務診斷，智能化工具等，決策痛點）
不同解決方案的不同價值定義
- 數字化：定性為主（定性如跑通流程，全鍊路可視）, 定量為捕（如回報時效提升等）。
- 自動化：定性+定量，以定量為主。
- 智能化：必須定量。
定性：以完成特定的任務或動作為考核方式，如流程跑通，能夠看到資料等，主觀性強。
定量：以達成特定的數值為考核方式，如100萬gm,獲得100個新客等，客觀性強。
2.3 識破僞需求
真需求還是僞需求，want or need？
用英文就可以清晰地區分：僞需求叫 Want，真需求叫 Need。Want的東西使用者不一定會掏錢，Need 的東西使用者一定願意掏錢。是以識别出 Need 的需求是需要優先實作和滿足的，減少或者不做What需求。
要想獲得真需求，就要搞清楚使用者要通過産品達到什麼樣的目的，産品經理需要跳脫既有的思維和主觀的判定，同時也不能輕信使用者直接回報的解決方案，要不斷地問為什麼，去挖掘背後真正的原因。對單個需求通常可以問以下問題，識别出需求的不同，進而進行優先級排序：
- 需求強度：使用者是否痛？有多痛？
- 需求頻次：多久痛一次？
- 持續時間：是否持續地痛？
- 廣度：有多少使用者有類似的痛點？
- 付費意願：使用者為此痛點付費的意願如何。
挖掘真需求的理論方法
- 挖掘需求的理論方法有很多，比如使用者調研、資料分析、競品分析等等。其中使用者調研包含核心使用者回報、問卷法、訪談法、實地調研。
- 在分析客戶的需求的時候，要懂得無視他們想要的東西，去探究其内心真正的渴望，如此才能給出更好的解決方案，或者說是使用者真正需要的東西。
總結：
什麼是“僞需求”？
- 缺乏充分的使用場景，看似有用實則沒有相應的适應場景；
- 可有可無，并不解決核心痛點的“增量需求”；
如何識别僞需求？
- 需求收集階段，不光聽使用者的說辭，要找到真實的使用場景、說辭背後的動機；
- 從動機入手設計解決方案，而不是拿使用者提出的“設計”直接作為解決方案；
- 原型階段，做使用者測試，傾聽使用者的使用感受；
- 重要功能，灰階上線/試點上線，避免集體翻車；
三、如何管理B端需求
3.1 需求優先級的判斷
1.如何判斷項目的緊急程度？ 短期不做會不會死？
2.如何判斷項目的重要程度？”長期不做會不會死？
3.優先級=(重要程度+緊急程度)/研發成本
4.是否影響到主流程的繼續運轉？如果沒有，那就可以有相對充裕的時間進行調研；
5.是否必須修複功能才能滿足業務需求？例如頁面的資料導出功能出問題，使用者無法導出資料，那麼可以直接從資料庫中導出資料并提供給使用者，在這種情況下，主流程不受影響。
3.2 優先級準則
1.高優高價值：需求價值為先，即高價值的需求優先做;
2.上司很關注：高層級及”大噪門”酌情考慮,即老闆需求和高壓力的需求适度提高優先級;
3.配置設定要合理：小中大需求合理調配，即保證資源充分利用的基礎下小中大需求齊頭并進（建議235或226的比例配置設定）；通常需求的價值與需求大小成正比；
4.各方要對齊：充分溝通，配置設定透明，即優先級的安排需要與各方充分溝通，盡量達成一緻，并且及時将進度與優先級同步所有關聯方；
總之，需求優先級的排布是一門藝術而不僅僅是技術。
3.3 需求池的管理
需求四象限時間管理法
P0重要緊急；
a.處理方法：立即去做；
b.飽和後果：壓力無限增大、危機；
c.原則：越少越好，很多第一象限的事情是因為他們在第二象限時沒有被很好的利用；
P1重要不緊急；
a.處理方法：有計劃去做；
b.飽和後果：忙碌但不盲目；
c.原則：集中精力處理，投資于第二象限，做好計劃，先緊後松；
P2不重要緊急；
a.處理方法：交給别人去做；
b.飽和後果：忙碌且盲目；
c.原則：放權給别人去做；
P3不重要不緊急;
a.處理方法：盡量不做；
b.飽和後果：浪費生命；
c原則：可當做調節身心，但是不能沉溺于這個象限；
P0需求量控制在不超過25%；
P1保持長期投入，每個疊代預留一定的資源（建議小于20%）；
注意：需求的優先級不是一成不變的，每當有新需求的加入，或者業務的變化，同時伴随着需求池的更新，更是對業務的再思考。
需求池需求的類型
1.功能改進類需求
2.體驗提升類需求
3.BUG修複類需求
4.新增功能類需求
5.其他需求
秉持寬進嚴出的準則
四、如何分析B端需求
第一步：業務部門、崗位及職責梳理。
第二步：業務流程梳理。
第三步：業務流程确認。
第四步：3W1H法則，系統功能點拆解。
第五步：系統流程圖的出具。
五、需求的傳遞和落地
理清邏輯并将邏輯準确無誤地同步到開發，是産品的基本工作,越複雜的需求越需要這樣。如果因為産品自身的局限性，擔心産品邏輯不是最理想方案或者可行性問題，那可以在方案完成前提前與開發leader/核心開發溝通。否則，讓開發對産品邏輯自由發揮，就是在為後面疊代或者後人埋坑。
本文由 @逸軒 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。