需求分析能力是產(chǎn)品經(jīng)理基礎(chǔ)技能之一，而B端與C端的要求又有所不同。這篇文章，作者帶我們重新認(rèn)識B端的需求分析，看看和你理解的是否一樣。

如果選一項能力作為產(chǎn)品基礎(chǔ)能力中最重要的一項，那我會毫不猶豫的選擇“需求分析”。

可隨著工作的推進,我相信大部分產(chǎn)品經(jīng)理會變得麻木，不再去分析需求的真實性，不再去考慮技術(shù)的可行性。會變成需求的翻譯器，業(yè)務(wù)提什么就是什么，畫個原型直接開發(fā)應(yīng)付了事就好了。

說實話很長時間我也陷入到這種狀態(tài)之中，甚至喪失了思考的能力。但需求分析作為產(chǎn)品經(jīng)理最最重要的能力之一，一旦丟棄也就相當(dāng)于放棄了產(chǎn)品生涯。

今天我將總結(jié)通用的需求分析產(chǎn)品方法論并結(jié)合實際工作場景與大家重新認(rèn)識B端需求分析！

一、什么是需求分析？

如果說一句話概括需求分析，那么我的回答是：挖掘用戶需求背后最真實的想法并轉(zhuǎn)化為性價比最高的產(chǎn)品需求。

這句話中涉及到的關(guān)鍵詞有：

• 挖掘：用戶不是已經(jīng)說了他想要什么了嗎？為什么還要挖掘？用什么方式挖掘？
• 最真實的想法：用戶想要的到底是什么？
• 性價比最高：解決問題的方式有很多，哪種才是當(dāng)下最應(yīng)該選擇的也是投入回報最大的呢？

二、B端需求分析有哪些類型？

B端需求分析可大可小，通?？煞譃橛脩粜枨螅ㄓ脩粼诠ぷ髦谢虍a(chǎn)品使用中產(chǎn)生的功能性需求），業(yè)務(wù)需求（滿足業(yè)務(wù)在某一場景下的系統(tǒng)支撐需求），產(chǎn)品需求（根據(jù)產(chǎn)品經(jīng)驗或行業(yè)標(biāo)準(zhǔn)提出的規(guī)劃性需求）

寫到這里我突然發(fā)現(xiàn)好像沒辦法有一套通用的需求分析模板去應(yīng)對不同類型的B端需求。且C端常用的KANO模型、Y模型、馬斯洛需求層級理論等好像都不是特別適用。因為B端的側(cè)重點更在于業(yè)務(wù)的高效運作，用戶的體驗往往不是決定作用。所以我將對不同的B端需求類型提出自己的思考。    

三、如何針對不同類型的需求進行分析？

1. 業(yè)務(wù)需求

（往往涉及多角色、多場景、多模塊）

在B端工作中業(yè)務(wù)場景的支撐是很常見的一類需求，比如供應(yīng)鏈金融產(chǎn)品方案的資方對接，業(yè)務(wù)數(shù)據(jù)四流合一校驗。

這類需求往往包含了多個具體場景以及需要多系統(tǒng)，多模塊之間的配合才能支撐業(yè)務(wù)流程的運作。

清晰的梳理出不同場景下，不同角色的訴求至關(guān)重要。            

此處以供應(yīng)鏈金融經(jīng)理最常接觸的金融產(chǎn)品資方對接為例。所謂的金融產(chǎn)品資方對接就是將銀行提供的支撐公司供應(yīng)鏈場景下的某一類金融產(chǎn)品方案，形成內(nèi)部系統(tǒng)與資方系統(tǒng)的全流程對接，支撐客戶在該場景下的授信、支用、還款等主要操作。

那么在接手這樣一個龐大的業(yè)務(wù)需求后如何開展呢？我認(rèn)為可以抽象成以下幾步：

1.1 了解項目背景

在了解項目背景這一步往往需要具備一定的領(lǐng)域知識，在本例中就需要了解金融產(chǎn)品方案要素，業(yè)務(wù)模式，以及與需求的各個參與方溝通，明各方在本需求中期望實現(xiàn)的結(jié)果。

1.2 業(yè)務(wù)場景分析

在進行業(yè)務(wù)場景分析時需要明確在該需求中存在的核心場景有哪些，可以是通過線下用戶調(diào)研了解，也可以是通過行業(yè)標(biāo)準(zhǔn)化的東西去制定，這也需要產(chǎn)品經(jīng)理具備一定的行業(yè)知識。就本案例來說如果不了解供應(yīng)鏈金融的運作流程，是無法從關(guān)鍵節(jié)點切入進行分析的。當(dāng)了解到關(guān)鍵的運作節(jié)點有客戶授信，客戶支用，客戶還款以后就可以從這三大主流程切入進行需求分析了。

以客戶授信舉例，需要梳理出在這一關(guān)鍵場景下，各參與角色的背景、誘因及期望?？刹扇?W1H的方法進行細致拆分。    

1.3 核心業(yè)務(wù)流程梳理

在完成了核心業(yè)務(wù)場景分析后，我們就需要進行核心業(yè)務(wù)流程的串聯(lián)，這一步至關(guān)重要。在這一步通常需要進行泳道圖的繪制。將核心場景中的參與角色進行串聯(lián)形成完整的作業(yè)流。這里的流程可能不是由產(chǎn)品決定的，其實往往是由業(yè)務(wù)決定的。所以產(chǎn)品需要反復(fù)與運營、資方進行溝通以確保流程能夠滿足各方的需要。

這一步的分析將很大程度的影響后續(xù)在產(chǎn)品設(shè)計中能否滿足用戶的核心需求。因此在分析過程中對于各方的側(cè)重點需要深入挖掘。對于資方來說它在意的是客戶的詳細數(shù)據(jù)獲取以最大程度的支持授信風(fēng)險判斷；對于運營來說更在意的是在推廣業(yè)務(wù)時流程和客戶操作的便捷性最大程度的提升授信額度。    

1.4 產(chǎn)品需求

在了解了項目背景，業(yè)務(wù)場景及業(yè)務(wù)流程后，我們終于可以開始進行產(chǎn)品需求的轉(zhuǎn)換。我們需要著重考慮在業(yè)務(wù)流程中各系統(tǒng)應(yīng)該提供什么樣的功能來支撐業(yè)務(wù)流程的高效運作，并完美的與現(xiàn)有系統(tǒng)融合，以及后續(xù)產(chǎn)品迭代的拓展性。以及設(shè)計的功能能否滿足每個用戶最核心的訴求。

下圖為我在本案例中涉及的工作任務(wù)：    

2. 用戶需求

用戶需求的提出往往是針對非常具體的一個業(yè)務(wù)場景，它也可能包含在業(yè)務(wù)需求之中，在業(yè)務(wù)需求中定義好每一個模塊后可能仍需對具體模塊進行需求分析。那如何進行這類需求的分析呢？可參照C端需求分析方法。

2.1 需求澄清

用戶在提出需求的時候往往不會的特別具體，甚至他自己也不知道自己的核心訴求是什么。他可能只說了一句

一句話，但如果不進行澄清的話，直接按照個人主觀判斷去做很可能得到的并不是用戶想要的。這里仍可以采取5W1H方法。

那么對于上面業(yè)務(wù)需求的客戶授信場景下，會存在這樣一個需求，客戶基礎(chǔ)數(shù)據(jù)的收集并推送資方。采取5W1H可拆分進行分析。

• who:準(zhǔn)入客戶(多為紡織業(yè)學(xué)歷水平較低的土老板)，潛在用戶有運營同學(xué)（可能在推廣現(xiàn)場幫助用戶操作）
• what:高效便捷提交客戶基礎(chǔ)數(shù)據(jù)并推送資方
• where:授信資料提交場景，線下客戶辦公室使用地點
• when:客戶授信前？客戶授信后？
• why:資方對客戶數(shù)據(jù)的維護
• how:提供客戶基礎(chǔ)數(shù)據(jù)收集界面

經(jīng)過以上的分析可以得出哪些產(chǎn)品設(shè)計的關(guān)注點呢？

使用客戶多對PC端操作不熟悉，更多使用移動端，信息收集盡量簡便、多采取下拉選擇方式。收集節(jié)點在授信審核前，因為在授信前會有運營同學(xué)在現(xiàn)場可指導(dǎo)客戶操作，為滿足資方對客戶數(shù)據(jù)的維護也需要與資方溝通確認(rèn)采集字段，并盡量與資方爭取簡化滿足客戶高效填寫的問題避免損失客戶耐心。

這樣一來毫無頭緒的一句話的簡單需求在腦海中就更加清晰了，也能夠指導(dǎo)我們下一步的工作以及產(chǎn)品設(shè)計的側(cè)重點。

2.2 需求甄別    

在日常需求工作中，產(chǎn)品經(jīng)理會接收到大量的需求，如果全盤接收，那么開發(fā)的招聘將永無止境。因此在進行產(chǎn)品設(shè)計前還需要確定需求是否值不值得，應(yīng)不應(yīng)該做?？梢詮囊韵聨讉€方面考慮：

前面幾點都很好理解，但對于是否為硬性要求來說需要考慮的是業(yè)務(wù)場景中合規(guī)要求、合作方硬性要求等等。

2.3 需求優(yōu)先級

這里有兩個常用方法論：四象限法則、P序列。兩者可結(jié)合使用。

四象限法則：根據(jù)重要和緊急程度劃分為四個維度，如下圖所示：

緊急與不緊急的判斷在B端可以根據(jù)影響業(yè)務(wù)運行的程度來判斷，重要不重要可以根據(jù)提升業(yè)務(wù)的價值程度來判斷

P序列：按照優(yōu)先級劃分P0>P1>P2>P3>…>Pn，如下圖所示：在工作中產(chǎn)品經(jīng)理經(jīng)常會碰到多個需求，沒辦法絕對判斷出哪個需求是P1、哪個需求是P2的順序。這種情況下，建議按照經(jīng)驗執(zhí)行就好，不要那么糾結(jié)，反而浪費時間。    

2.4 確定產(chǎn)品需求方案

確認(rèn)需求方案，其實就是根據(jù)前面在需求分析的過程中，所提煉出的目的及流程，針對性的去設(shè)計出滿足需求的產(chǎn)品方案。包括但不限于：系統(tǒng)流程設(shè)計，頁面流程設(shè)計，原型設(shè)計，交互設(shè)計等等。當(dāng)然對于一個問題的解決方案有很多，作為B端產(chǎn)品可能還需要由業(yè)務(wù)決定，可將你認(rèn)為合理的方案全部提供出來由業(yè)務(wù)拍板，當(dāng)然也要有自己的思考和立場。

3. 產(chǎn)品需求

在日常產(chǎn)品工作中，產(chǎn)品經(jīng)理可能會根據(jù)自己或行業(yè)的經(jīng)驗提出對現(xiàn)有功能的迭代或新的功能點，更有可能是領(lǐng)導(dǎo)的一句話需求。對于這類需求需要注意的是避免陷入自嗨，覺得自己想到個新功能直接原地起飛，在一年半的工作里沒少干這些事。還是要將需求放在業(yè)務(wù)場景之中，多做競品分析及用戶調(diào)研，結(jié)合業(yè)務(wù)發(fā)展現(xiàn)狀及價值綜合分析。

四、總結(jié)

在B端產(chǎn)品分析中可能沒有C端那樣側(cè)重用戶體驗的分析，更多的分析重點是業(yè)務(wù)運作本身。對于業(yè)務(wù)需求及用戶需求兩者經(jīng)常會結(jié)合在一起。

通過分析業(yè)務(wù)需求得出產(chǎn)品整體架構(gòu)，再通過用戶需求分析對具體的功能模塊或功能點最大程度的滿足各方需要。

當(dāng)然還有一些其它的需求分析方法論，比如用戶體驗地圖、KANO模型、Y模型等等，更多的會偏向C端一點。

在B端這里UML統(tǒng)一建模也是邁向更高級產(chǎn)品分析的一門好課程，有興趣的可以深入了解一下。

最后歡迎大家交流自己的思考和批評指正！