中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：做B端產品的時候，重要而且不能忽略的一個步驟就是收集和分析客戶的需求，并且根據需求來設計和改進產品。如果不了解客戶需求，產品可能就會脫離客戶，從而難以達成目標。由于To B 和 To C 有很大的不同，那么在ToB領域，應該如何收集和分析客戶需求呢？

目前，C端產品的需求分析方法已經非常成熟，各位大佬已經提出了自己非常專業的視角。前文有提到，B端產品主要是面向企業的“組織欲望”，為企業“降本增效”（具體可見《To B 產品與 To C 產品的區別》）。

那么，B端產品需求，多數情況下不會像C端產品那樣具有普遍性（saas類除外），更多的B端產品需求更加偏重個性化和定制化。

今天，貓爸就結合自己的個人經歷，總結和分享一下，面對個性化、定制化的產品從0~1該如何進行用戶的需求收集和分析。以供大家共同學習交流；由于專業及領域限制，難免存在認知限制，還請各位前輩指點一二，在下感激不盡。

在分析之前，我們先理解一下，什么是“用戶需求”？

套用李叫獸《需求三角模型》模型，概括成一句話：用戶需求，就是理想與現實之差。而對于企業客戶來說，就是企業的理想與現實之差；即企業期望達到“降本增效”的理想，與現實工作中“高成本、低效率”的差別。

所以，當我們要做B端產品時，就必須要面向企業進行需求的收集和分析，了解清楚他們的理想與現實之間的差距究竟有哪些表現層面，落實到具體的工作中，又會有哪些流程需要梳理。

一、收集需求

1. 需求來源

無論是對內的產品還是對外的產品，在落地設計之前，都需要進行需求收集和整理，B端產品的需求的來源一般分為如下：

1）客戶調研

B端產品的需求，最直接的來源即為企業客戶；前文也提到B端產品的本質是滿足企業的“組織欲望”，所以B端產品的需求，一般都會根據企業客戶調研進行需求的收集分析。

針對企業的B端產品，可以大致分為內部產品和對外服務的產品，但無論是哪種，都需要找到對應的企業需求發出人，然后進行采集分析。

2）競品分析

對于SaaS級產品或標準化服務的產品，我們也可以根據市場上已有的競品情況，進行收集分析，具體的分析方法本文不做贅述，大家可以參考之前的文章《B端產品如何做競品分析》。

當然，在做競品分析之前，我們也會時刻關注市場的變化情況，進而自主判斷需要增加哪方面的產品需求，這種方式一般會與競品分析進行合并梳理。

3）其他渠道

其他的渠道包括不限于銷售業務反饋、售前售后咨詢、公司老板提需求等等；此處不過多贅述，我們根據實際情況來酌情判斷即可。

2. 客戶需求收集

記得曾經遇到過一個面試題：當我們接到任務，要對某一家客戶進行需求收集，或者對公司的某一項內部流程進行產品化；這個時候，我們一般會怎么做呢？當然，那個時候的我，有點懵逼。

首先分析我們在實際工作中面臨的問題：

其實我們做產品，最本質的是“如何系統的梳理復雜的業務流程”，只有復雜的業務流程搞透徹了，我們才知道該如何將其線上化，產品化。

而這個“復雜”不僅僅是純業務流程的復雜，還有可能是客戶之間的內部關系的復雜，利益鏈條的復雜等等。所以，我們需要有自己的節奏和標準，做到“心中有桿秤，遇事不慌張”。

1）建立調研標準

在開展調研之前，我們自己要要有一個評判標準，主要有兩個目的：梳理可以產品化的業務形態、判斷需求的優先級。

B端產品的建立，都是基于目前目標客戶的業務形態來進行的，所以必要的了解目標客戶的業務形態，是非常重要的，常見的客戶業務形態分類如下：

在需求調研之前，另一件非常重要的事情就是有自己的優先級判斷，對于優先級比較低的業務邏輯，不要花費過多的精力去研究。

優先級的判斷方式有很多，例如C端經常用的KANO模型等等。對于B端定制化方面的需求，常見區分優先級的方式比較簡單粗暴：

需求優先級比較難定義；所以按照職能級別，老板級別最高，中高層就低一些。

因為老板會去看這個系統，然后中高層會去點頭，然后才能付款。有些公司可能老板是甩手掌柜，但是最終還是老板拍板付款，所以有時候如何抓住老板的認可也要一定的技巧。

在同一級別里面，也要區分子級別，例如都是中層管理者，哪個人的需求該優先，哪個該延后，這些也是需要評估的。

一般情況下，會根據需求實現難易程度，需求發出者對業務的幫助貢獻度、多名同級人員在公司的重要程度等等來進行區分（此處有點“勢利眼”的成分哈）。

2）把控調研的節奏

有了自己的調研標準，那么接下來就是實際的業務調研了，在調研的過程中，我們必須有一定的章法節奏。一般通過下面四個方法，可以有條不紊的開展工作。

方法一：提前了解行業知識

B端產品經理，大多面向的對象都是各行各業，在做需求收集之前，我們必須要提前了解行業概況，了解這個行業的一些常見的專業知識和專業術語，這樣我們在收集需求時，才能夠跟需求方有共同話題，對方說一些專業的流程，我們不至于發懵。

一般的，行業知識的了解渠道如下：

方法二：私下溝通調研

找到對應業務的業務接口人，私下了解業務的方向，涉及到的部門人員，關鍵節點等等；重點是對客戶的項目進行一個全貌的了解。

其實是伴隨著會議溝通同步進展的；甚至前期應該先進行一輪私下溝通。會議溝通，一般是了解對方的戰略方向，期望等；而私下溝通，有些會議中不能提及的問題，消耗時間的業務細節，會更容易了解。私下溝通重點關注以下內容：

方法三：召開調研會議

熟悉了一些行業知識后，首要任務就是開始調研了解對方的訴求。

可能前期商務關系的介入，大概的客戶訴求是明確的，但是為了保障后續方案落地順利，產品經理需要再進行詳細的調研和挖掘，深入分析和了解對方的業務流程和業務方式，此時召開會議是非常有效的手段之一。

方法四：排除調研干擾

有時候，我們在調研客戶需求經常不是那么一帆風順的，拋去客觀因素，我們還會遇到例如業務流程遭遇非業務部門干預、兩個部門對于流程的意見不相符、調研對象拒絕溝通等情況。

此時，我們要可以嘗試通過以下方法來解決：

二、分析需求

業務流程了解清楚，需求收集完成后，我們就要開始進行業務需求的分析和梳理了。在分析梳理之前，我們需要了解到，關注這個產品的目標人群，他們的關注點有哪些：

想要滿足這些，我們需要把用戶需求進行梳理，形成可具象的落地方案。在梳理的時候，面對復雜多變的需求點，我們該如何做呢？

分析需求，本質上就是分析企業實際的業務場景，而任何的場景，都是由“人+事”組成，不同于C端產品的場景化思考，B端產品的場景化更加直接，我們可以直接面向目標對象來進行分析。

1. 需求分析方法

1）對人的分析

首先，我們分析需求時，需要了解到，這個需求到底是給誰用的？這個人在企業中扮演什么角色？他的這個角色是什么樣的群體？這個群體在企業里面的組織架構是處于什么層級？這樣我們可以獲取到一個角色的圖譜。

基于上述的角色圖譜，這個角色有什么樣的使用權限， 日常業務中能夠訪問哪些內容等等。

2）對事的分析

接下來，我們需要了解的是，假如我們完成了某個產品，那么這個產品能夠幫助“人”做成什么事兒？“人”用這個產品可以做什么事情，角色的日程工作流程是什么樣的？有些事兒的審批流程是如何的？每一個流程可能會涉及到的功能有哪些？哪些功能可以合并成一個大的功能模塊？這些問題都需要分析了解。

2. 復雜流程梳理

無論是無論是對內的產品，還是為客戶定制化的B端產品，一般的業務流程都相對復雜，該如何進行復雜業務流程的梳理呢？

1）step1：單一化業務流程

企業的復雜業務，一般都是由眾多的角色一起參與完成的；但是常規情況下，都會有一個任務需求方發起任務，此時我們可以根據之前收集到的需求，通過初步的分析篩選，將業務流程單一化。

在單一化流程中，重點可以通過以下維度進行關注：

公司的產品線有哪些？這些產品線中，哪些是主流程？通過梳理，把眾多主流程明確下來。

例如：虛擬物品下單流程中，瀏覽——下單——支付——發貨——收貨。這是一個主流程，我們可以基于這個主流程進行業務分析。

但是這個主流程里面，充滿了多個分支流程；比如支付流程，就會衍生出第三方支付、銀聯支付等等，但是在進行業務分析下單流程時，將“支付”模塊當做“黑盒”進行分析。如果是分析支付流程，那么就需要將對應的分支流程畫出來，從而進行分析。

2）step2：定位關鍵角色

完成主流程的梳理后，每一條主流程，都會有一個需求角色，而其他角色均屬于參與者。

例如：合同審批流程，需求方可能是業務方（銷售、售前等），而參與的角色可能會有部門經理、分管副總、法務、財務、總經理等等，所以把這幾個關鍵的角色找到，然后理清楚前后順序，將他們的主流向圖畫出來。

需要注意的是，有時候，關鍵角色不一定是人，也有可能是系統，比如第一步的例子中，發放虛擬幣可能就是系統自動發放，而不是某個人來發放。

3）step3：異常流程補充

主流程梳理完畢后，我們需要了解，對于單一化的業務中，有沒有可能會出現異常的情況，如果是簡單的異常邏輯，我們可以畫在主流程中。

如果一個異常流程，需要處理和涉及的角色會更多，就會產生分支流程。此時我們把這條分支流程作為另外的一條單一的業務流程，重新進行step1、step2進行梳理。

在梳理流程的過程中，可以采用一個“臺階模型”的方式進行梳理（名字是我自己取的，勿噴），如下圖：

把梳理的單一業務流程，按照上述圖進行繪制，這樣就可以清晰的明確一條流程中，有哪些節點，會有哪些參與角色。

3. 產出《需求分析文檔》

通過以上的分析，我們最終能夠將收集到的需求進行分析、匯總、歸類。文檔不需要非常詳細，但是要給大家知道能夠評估這個項目能不能做，具體怎么做，都有哪些東西需要做。

需求分析的文檔一般包括以下部分：

1）項目背景

主要介紹當前項目的情況，包括的問題有客戶的業務背景、產品背景情況：

• 客戶業務背景：主要體現當前客戶所處行業、目前的業務情況，市場情況等簡要做出概況；
• 產品背景：主要介紹客戶為什么要做這個產品。這個產品可以解決客戶什么問題。解決的問題對于客戶來說是否有足夠的影響力（這一點可以判斷客戶是否重視這個項目）。

2）目標

產品的目標是什么，產品能夠為自己的公司，為客戶的公司帶來什么樣的價值。

3）期望

對于客戶來說，有哪些期望，包括不限于上線時間，投入產出比等等。對于公司來說，又有哪些期望，也一并列舉出來。

4）詳細需求列表

一份詳細的需求列表，主要記錄的客戶關注的重點需求的所有細節，包括類別、提出部門、提出人、提出時間、需求描述、需求背景、需求的目標、提出需求的期望、涉及到的角色、權限、業務流程。

5）產品架構圖

如果是一個完整的業務架構，還應該根據業務流程繪制出對應的產品架構圖，方便大家一眼能夠了解整體的產品架構及相互之間的耦合關系（注：架構圖不是結構圖，兩者不是一個東西）。

4. 需求分析評估的維度

我們最后產出的《需求分析文檔》重點不是為了產出文檔，而是為了各方在一起初步進行需求評估，從而為接下來需求是否能落地來進行準備。

所以在進入初期的評估階段，公司的技術人員就必須介入進來參與評估。

三、總結

通過整體的文檔介紹我們也能夠了解到需求工作是非常龐雜的，所以我們在前期的收集、分析階段，一定要把控好節奏，根據項目情況進行靈活的應變及應對。

對于一個復雜的項目，要做好長期進行需求收集確認的準備。

需求收集是一個不斷變化的過程，我們有可能面臨著，不同人員對于需求的理解不同導致需求多次變更情況；也有可能面臨需求提出者睡一覺就會改變主意的情況；也有可能是我們需求在評估過程中，研發說技術上無法完成的情況，更有可能是在設計階段發現需求不合理的情況……

這些都會導致需要進行變更，我們需要時刻跟進項目情況，不斷做出調整和協調，最終將項目落地。

作者：兩只貓爸；公眾號：PMGrow ，我會持續分享更多自己的心得，與大家一起交流成長~

本文由 @兩只貓爸 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。