B端產品經理,你會做需求分析嗎?

山河奇力廣告管理
陳文中小站
 1.01w
2019-10-08

隨著雲計算、AI、教育、智能製造和產業互聯網的興起,這些新技術、新方案首先從B端企業開始滲透,因此市場上對B端產品經理的崗位需求大增。

但目前行業內對產品需求的方法論,大部分是針對C端產品的,所以本篇文章的主題來談談如何對B端產品進行需求分析和設計。

既然要談“B端產品”的需求分析,那麼首先我們要搞清楚一個問題,B端產品和C端產品在產品設計的本質差異性在哪裏?

C端產品設計的邏輯在於“輕流程、重體驗”,以抖音這種短視頻工具為例,隻有2個簡單的流程:發布視頻和觀看視頻。並且把觀看視頻的流程簡化到了極致—沒有流程,在強大的推薦算法機製下,用戶無需思考要觀看什麼,隻需要向下滑屏,就可以實現不中斷的沉浸式觀看體驗。

所以C端產品側重的是用戶的感受和體驗,在產品設計時,精心對頁麵和交互進行打磨,大到優化版麵結構,小到改變一個按鈕的大小、顏色及位置,都可能會極大影響用戶的行為,對產品的運營數據產生深刻的影響。

而B端產品呢? 其產品設計的邏輯是“重流程規則、輕體驗”,一個母嬰電商公司的老板,購買一套電商ERP係統的目的是什麼呢?

是讓員工操作的體驗更舒服、更放鬆?一定不是!

他在意的是怎麼把手忙腳亂、錯誤百出的客服從20個人降到2個人,從而降低緊張的資金壓力;他在意的是怎麼把揀貨流流程由人拿著單子滿倉庫跑,改為流水線式自動化作業,從而降低出錯率;他在意的是把財務從每個月末抱著一堆單據通宵做賬解脫出來,改為係統自動對賬,從而讓企業的財務數據清晰、透明,為經營決策提供準確、可信的依據。

所以,B端產品最終的目的是通過互聯網IT技術對企業業務流程進行重構、優化、從而降低成本、提高效率。

從上麵可以看出,C端產品經理像是一個感性的匠人,在產品設計時,帶入同理心、想象力、簡化用戶心智,在產品設計時精心打磨用戶感受和體驗。

而B端產品經理更像是一個理性而嚴謹的“業務專家”,他們具備強大的係統性邏輯思維,富有理性的對企業業務進行全麵梳理和診斷,並給出合理有效的解決方案。

由於B端產品業務流程複雜、功能龐大、用戶角色眾多,所以對B端產品經理的需求分析能力,提出了很高的要求。

但我在實際工作中發現,目前互聯網公司對複雜B端產品具有完整駕馭能力的並不多見,甚至包括工作5年10年以上的產品經理,輸出的產品規劃文檔,常常給人以“隻見樹木,不見森林”的印象。

真正具有複雜B端產品需求分析能力的是資深的程序員、架構師、但他們寫出來的東西、技術術語過多、複雜、晦澀難懂。

既然B端產品業務流程複雜、功能龐大、用戶角色眾多,那麼它一定是一個“係統性的工作”,必然得有一套“係統性的方法論”來去支撐B端產品的業務需求分析。

以肯尼迪發起的“阿波羅”登月工程為例,耗資數百億美金,曆時11年,動員了整個的國家力量。這種“係統性的工程”,你不能上來就討論登月艙結構,火箭推力設計的細節問題。

你得有“工程性思想”去支撐,把問題分解3大步驟,1“雙子座計劃”,2.繞月 3.登月 ,再層層分解,逐步細化,論證,才有可能完成這種係統性任務。

那麼B端產品需求分析和設計,有哪些“係統性思想”來支撐呢?


一、確保理解背景


這是很多新手產品會犯的一個致命錯誤。例如和客戶交流完後,客戶需要一個ERP產品,結果發現,客戶需要的隻是一個訂單打印小工具。

所以客戶眼中的"ERP",一定不是你眼中的"ERP"。

任何一個B端產品和解決方案,一定是在某個特定的階段滿足企業的某種價值,這種價值可以很小,也可以放的很大,這是一種平衡和取舍,所以產品經理一定要搞清楚這個產品需求產生的背景是什麼?

你的客戶目前是什麼現狀?組織的複雜度?使用你的產品是為了解決什麼問題?是業務轉型的問題,還是流程改革和優化的問題?

另外從某種程度上來講,企業經營也是管理者個人意誌的體現,boss對產品或解決方案的訴求是為了達成什麼樣的目的?你確保了你理解他的訴求?

對背景的理解和解讀,一定是你產品文檔的開篇部分。


二、搞清經營模式


在理解背景的基礎上,我們需要搞清楚企業的經營模式,經營模式決定了產品分析和設計的框架。

很多產品沒有把業務理解清楚的根本點在於,沒有充分理解企業的經營模式,經營模式理解不清楚,會出現嚴重的係統設計偏差。

特別是一些複雜的平台級產品,例如鋼鐵B2B交易平台,涉及到行業生態上下遊廠商、大大小小的貿易商、終端客戶、倉儲公司、物流公司、金融企業等眾多的參與方,每個參與方又有不同的職能部門需要在平台作業。

很難想象沒有搞清楚經營模式,產品需求分析和設計如何進行。

但搞清楚經營模式,也不是非常困難。任何再複雜的業態,一定有一條主幹經營流程,這條主幹流程簡單的來說,就是以下幾個問題?

賣什麼?怎麼賣?掙什麼錢?

買什麼:這個企業經營什麼產品或服務?有多少種?差異性在哪裏?...

怎麼賣:產品或服務的銷售流程是什麼樣的?是通過互聯網,還是通過線下渠道?如果是,這些渠道怎麼管理?當前存在哪些問題....

掙什麼錢:企業是如何盈利的?是靠銷售產品或服務嗎?還是羊毛出在豬身上,狗來買單?...

一旦你把這條主線梳理清楚,就可以清晰的知道企業的經營模型,有哪些供應商、客戶、合作夥伴等各種參與方,為接下來的需求分析,打下堅實的基礎。

經營模式可以用一張圖表來說明,它是你產品設計的藍圖。通常需要用不同的線條把信息流、物流、資金流標識清楚,來搞清楚企業是如何運作的。

下圖說明了一個家電售後平台的經營模式運作圖。


三、析出業務角色


到這裏,才真正從商業分析部分進入到產品分析和設計部分。

如何把需求從商業概念轉化為產品分析和設計概念,我目前看到最具有係統性的是UML,其設計思想,貫穿了從需求分析到係統設計的整個過程。

但UML本身是軟件工程的產物,概念繁多:圖、依賴、泛化等各種概念。本身太過於龐大、複雜、笨重,並且難以學習。

不過其“係統性工程”思想可以值得我們借鑒學習。

為什麼,產品分析和設計的第一步是分析出業務角色?而不是畫流程圖(這是很多人的做法)

因為業務角色是產品需求的源頭,所有的產品需求一定來自於全部業務角色需求的集合,B端產品的複雜度決定了必須從業務角色分析著手,才不會出現遺漏和偏差。

並且B端產品越複雜、業務參與方越多、你會發現這種分析越有價值。

在上一步搞清楚經營模式的基礎上,會會對該經營模式涉及到的所有業務角色有了個完整的了解,接下來的工作,就是把業務角色分離出來。

下圖說明了一個B2B平台的業務角色圖。


四、推導出業務用例


有了業務角色後,我們可以推導出業務用例(也即業務角色需求)。

UML的業務用例圖,最大的好處是用一張圖可以把整個係統的需求以全局的方式,生動、完整、清晰的表達出來。

有了這種圖,我們可以很方便的和業務、開發、測試方便的去溝通需求,對係統需求有個整體的認識。

推導出業務用例的過程,我們可以通過以核心業務角色為重點,交叉驗證思維來快速構建整個業務用例。

例如下圖的B2B交易平台,我們隻需要以該平台最重要的業務角色采購商為切入點,再來交叉驗證:采購商需要采購下單,必然需要供應商發布商品、供應商發布商品必然需要平台監管人員去審核和管理...,這樣基本可以搞清楚各種業務角色80%的需求。


五、細化出業務流程


再接下來,我們需要把重要的業務需求,細化為業務流程。

業務流程可以用UML的活動圖來展示,在to B複雜的業務場景中,我們往往使用的是跨泳道流程圖,例如一個取消訂單的業務流程,涉及到ERP、客服、財務不同的業務角色。

這樣在構建業務流程的過程中,我們對係統設計如何實現,也有了一個完整的概念。

另外,業務流程圖的最最要的一個原則是線條不能交叉,無論流程如何複雜,保證線條不要交叉,很多新手犯的錯誤,就是把流程圖畫的縱橫交織像一個蜘蛛網,非常難以看懂。


六、繪製可視化頁麵原型


至此,我們通過對業務角色分析、不同角色的業務需求分析,核心業務需求的業務流程確認,我們實現了從商業概念到業務概念的建立。

接下來,我們需要把上述業務需求轉化為產品係統的設計,這是一個更加細致的工作,我們最熟悉的Axure工具就正式上場了。

當然從“抽象的業務需求”到“具象的係統需求”,也存在一個巨大的鴻溝,這個需要參考同類產品的設計思想,從中吸取精華,並結合互聯網設計,做一定程度的創新。

例如,采購商反饋說,通過購物車下單太麻煩了,需要一個“批量下單”功能,你單憑想象是難理解這個需求的。

最好的辦法是到用戶的工作現場,觀察和感受下他平時工作是如何處理訂單的。

等你到了現場,你會發現和2C用戶的下單場景截然不同:用戶的桌麵是堆積如山的文檔、忙碌的電話接入,長達幾頁的訂單要等待錄入...

你會發現B端產品設計的首要目的是快速、準確、無誤的幫助用戶提高工作效率,節約用戶的時間,其他都是耍流氓。

所以你需要去大量觀摩和學習一些B端成熟軟件的設計邏輯,再結合一些移動端的特性,例如GPS定位、拍照識別、語音,去構思一些創新的設計,可以幫助用戶大大提高工作效率。


七、其他補充


產品設計過程中,非常重要的一點是,明確業務規則。

在一個項目團隊中,由於背景、工作經驗、領悟能力各不相同,如果業務規則不明確,同一個概念,每個人的理解不同,會造成雞同鴨講,爭執不下,浪費大量時間。

所以一些核心、重點、複雜的業務規則,產品經理需要舉出詳實的例子來,把各種情況一一枚舉出來,並進行闡述。

例如在互聯網交易平台,涉及到商品、SPU、SKU這3個概念,產品經理可能對這些概念很熟,但業務方、開發人員不一定對這些概念很清楚。

如果在頁麵上隻是簡單的描述為“點擊此按鈕,將此SKU加入購物車”,會引發大量的困惑和爭議,我看到過一個產品經理的需求會,為此爭執和討論了半個小時。

理想的做法,把這些重要的概念和規則,用數據實例呈現出來,並指出他們之間的結構關係,這樣在講解業務時,確保所有人的理解是一致的。

再例如互聯網交易平台的交易流程,包括各種正向流程、逆向退換貨流程所有的單據狀態,這些單據狀態互相交叉,互相影響。他們是係統設計的骨架和脈絡,如果不定義清楚他們之間的互動關係,會造成嚴重的混亂和缺陷。


總結


整體上來說,分為三個過程,商業分析—業務分析—係統設計。

商業分析:1.確保理解背景 2.搞清經營模式

業務分析:3.析出業務角色 4.推導出業務用例 5.細化業務流程

係統設計:6.繪製頁麵原型 7.明確業務規則

參與討論