起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識重新認識B端需求分析
“產品需求”是產品經理基礎能力中最重要的一項，貫穿了整個行業生涯。下面這篇文章是筆者分享總結通用的需求分析產品方法論并結合實際工作場景的內容，令大家再重新認識B端需求分析。為了不辜負筆者的好意大家一起來看看吧！
如果選一項能力作為產品基礎能力中最重要的一項，那我會毫不猶豫的選擇“需求分析”?？呻S著工作的推進,我相信大部分產品經理會變得麻木，不再去分析需求的真實性，不再去考慮技術的可行性。
會變成需求的翻譯器，業務提什么就是什么，畫個原型直接開發應付了事就好了。說實話很長時間我也陷入到這種狀態之中，甚至喪失了思考的能力。但需求分析作為產品經理最最重要的能力之一，一旦丟棄也就相當于放棄了產品生涯。
今天我將總結通用的需求分析產品方法論并結合實際工作場景與大家重新認識B端需求分析！
一、什么是需求分析？
如果說一句話概括需求分析，那么我的回答是：挖掘用戶需求背后最真實的想法并轉化為性價比最高的產品需求。
這句話中涉及到的關鍵詞有：
- 挖掘：用戶不是已經說了他想要什么了嗎？為什么還要挖掘？用什么方式挖掘？
- 最真實的想法：用戶想要的到底是什么？
- 性價比最高：解決問題的方式有很多，哪種才是當下最應該選擇的也是投入回報最大的呢？
二、B端需求分析有哪些類型？
B端需求分析可大可小，通?？煞譃橛脩粜枨螅ㄓ脩粼诠ぷ髦谢虍a品使用中產生的功能性需求），業務需求（滿足業務在某一場景下的系統支撐需求），產品需求（根據產品經驗或行業標準提出的規劃性需求）。
寫到這里我突然發現好像沒辦法有一套通用的需求分析模板去應對不同類型的B端需求。且C端常用的KANO模型、Y模型、馬斯洛需求層級理論等好像都不是特別適用。因為B端的側重點更在于業務的高效運作，用戶的體驗往往不是決定作用。所以我將對不同的B端需求類型提出自己的思考。
三、如何針對不同類型的需求進行分析？
1. 業務需求
（往往涉及多角色、多場景、多模塊）在B端工作中業務場景的支撐是很常見的一類需求，比如供應鏈金融產品方案的資方對接，業務數據四流合一校驗。這類需求往往包含了多個具體場景以及需要多系統，多模塊之間的配合才能支撐業務流程的運作。清晰的梳理出不同場景下，不同角色的訴求至關重要。
此處以供應鏈金融經理最常接觸的金融產品資方對接為例。所謂的金融產品資方對接就是將銀行提供的支撐公司供應鏈場景下的某一類金融產品方案，形成內部系統與資方系統的全流程對接，支撐客戶在該場景下的授信、支用、還款等主要操作。
那么在接手這樣一個龐大的業務需求后如何開展呢？我認為可以抽象成以下幾步：
1）了解項目背景
在了解項目背景這一步往往需要具備一定的領域知識，在本例中就需要了解金融產品方案要素，業務模式，以及與需求的各個參與方溝通，明各方在本需求中期望實現的結果。
2）業務場景分析
在進行業務場景分析時需要明確在該需求中存在的核心場景有哪些，可以是通過線下用戶調研了解，也可以是通過行業標準化的東西去制定，這也需要產品經理具備一定的行業知識。
就本案例來說如果不了解供應鏈金融的運作流程，是無法從關鍵節點切入進行分析的。當了解到關鍵的運作節點有客戶授信，客戶支用，客戶還款以后就可以從這三大主流程切入進行需求分析了。
以客戶授信舉例，需要梳理出在這一關鍵場景下，各參與角色的背景、誘因及期望。可采取5W1H的方法進行細致拆分。
3） 核心業務流程梳理
在完成了核心業務場景分析后，我們就需要進行核心業務流程的串聯，這一步至關重要。在這一步通常需要進行泳道圖的繪制。
將核心場景中的參與角色進行串聯形成完整的作業流。這里的流程可能不是由產品決定的，其實往往是由業務決定的。所以產品需要反復與運營、資方進行溝通以確保流程能夠滿足各方的需要。
這一步的分析將很大程度的影響后續在產品設計中能否滿足用戶的核心需求。因此在分析過程中對于各方的側重點需要深入挖掘。對于資方來說它在意的是客戶的詳細數據獲取以最大程度的支持授信風險判斷；對于運營來說更在意的是在推廣業務時流程和客戶操作的便捷性最大程度的提升授信額度。
4）產品需求
在了解了項目背景，業務場景及業務流程后，我們終于可以開始進行產品需求的轉換。我們需要著重考慮在業務流程中各系統應該提供什么樣的功能來支撐業務流程的高效運作，并完美的與現有系統融合，以及后續產品迭代的拓展性。以及設計的功能能否滿足每個用戶最核心的訴求。
下圖為我在本案例中涉及的工作任務：
2. 用戶需求
用戶需求的提出往往是針對非常具體的一個業務場景，它也可能包含在業務需求之中，在業務需求中定義好每一個模塊后可能仍需對具體模塊進行需求分析。那如何進行這類需求的分析呢？可參照C端需求分析方法。
1）需求澄清
用戶在提出需求的時候往往不會的特別具體，甚至他自己也不知道自己的核心訴求是什么。他可能只說了一句話，但如果不進行澄清的話，直接按照個人主觀判斷去做很可能得到的并不是用戶想要的。這里仍可以采取5W1H方法。
那么對于上面業務需求的客戶授信場景下，會存在這樣一個需求，客戶基礎數據的收集并推送資方。采取5W1H可拆分進行分析。
- who:準入客戶(多為紡織業學歷水平較低的土老板)，潛在用戶有運營同學（可能在推廣現場幫助用戶操作）。
- what:高效便捷提交客戶基礎數據并推送資方。
- where:授信資料提交場景，線下客戶辦公室使用地點。
- when:客戶授信前？客戶授信后？
- why:資方對客戶數據的維護。
- how:提供客戶基礎數據收集界面。
經過以上的分析可以得出哪些產品設計的關注點呢？
使用客戶多對PC端操作不熟悉，更多使用移動端，信息收集盡量簡便、多采取下拉選擇方式。收集節點在授信審核前，因為在授信前會有運營同學在現場可指導客戶操作，為滿足資方對客戶數據的維護也需要與資方溝通確認采集字段，并盡量與資方爭取簡化滿足客戶高效填寫的問題避免損失客戶耐心。
這樣一來毫無頭緒的一句話的簡單需求在腦海中就更加清晰了，也能夠指導我們下一步的工作以及產品設計的側重點。
2）需求甄別
在日常需求工作中，產品經理會接收到大量的需求，如果全盤接收，那么開發的招聘將永無止境。因此在進行產品設計前還需要確定需求是否值不值得，應不應該做?？梢詮囊韵聨讉€方面考慮：
前面幾點都很好理解，但對于是否為硬性要求來說需要考慮的是業務場景中合規要求、合作方硬性要求等等。
3）需求優先級
- 這里有兩個常用方法論：四象限法則、P序列。兩者可結合使用。
- 四象限法則：根據重要和緊急程度劃分為四個維度。
如下圖所示：
緊急與不緊急的判斷在B端可以根據影響業務運行的程度來判斷，重要不重要可以根據提升業務的價值程度來判斷。
P序列：按照優先級劃分P0>P1>P2>P3>…>Pn，如下圖所示：在工作中產品經理經常會碰到多個需求，沒辦法絕對判斷出哪個需求是P1、哪個需求是P2的順序。這種情況下，建議按照經驗執行就好，不要那么糾結，反而浪費時間。
4）確定產品需求方案
確認需求方案，其實就是根據前面在需求分析的過程中，所提煉出的目的及流程，針對性的去設計出滿足需求的產品方案。包括但不限于：系統流程設計，頁面流程設計，原型設計，交互設計等等。
當然對于一個問題的解決方案有很多，作為B端產品可能還需要由業務決定，可將你認為合理的方案全部提供出來由業務拍板，當然也要有自己的思考和立場。
3. 產品需求
在日常產品工作中，產品經理可能會根據自己或行業的經驗提出對現有功能的迭代或新的功能點，更有可能是領導的一句話需求。對于這類需求需要注意的是避免陷入自嗨，覺得自己想到個新功能直接原地起飛，在一年半的工作里沒少干這些事。還是要將需求放在業務場景之中，多做競品分析及用戶調研，結合業務發展現狀及價值綜合分析。
四、總結
在B端產品分析中可能沒有C端那樣側重用戶體驗的分析，更多的分析重點是業務運作本身。對于業務需求及用戶需求兩者經常會結合在一起。通過分析業務需求得出產品整體架構，再通過用戶需求分析對具體的功能模塊或功能點最大程度的滿足各方需要。
當然還有一些其它的需求分析方法論，比如用戶體驗地圖、KANO模型、Y模型等等，更多的會偏向C端一點。在B端這里UML統一建模也是邁向更高級產品分析的一門好課程，有興趣的可以深入了解一下。最后歡迎大家交流自己的思考和批評指正！
本文由 @愛健身的產品小白 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
有夢想。。。
哈哈哈哈