起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品經理，你會做需求分析嗎？
筆者從B端產品和C端產品在產品設計上的差異性出發，結合案例，對B端產品如何進行需求分析和設計進行了探討。
隨著云計算、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大步驟:“雙子座計劃”、繞月、登月，再層層分解，逐步細化，論證，才有可能完成這種系統性任務。
那么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.明確業務規則
#專欄作家#
陳文中，微信公眾號：秀肌肉的碼蟻，人人都是產品經理專欄作家。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
哇，寫的太好了吧～非常好看??
挺好
剛好接手一個課程管理系統，在沒有需求文檔的情況下，硬啃著操作手冊來熟悉后臺，好痛苦，學習了需求分析真的很重要
看完文章，有點開闊了
開導思維，幫助很大！
之前負責迭代一個B端產品，因為產品初期的需求分析沒做好，導致后來的產品構架出來很大問題，基本做不了新需求，給老板提出重構產品架構，也沒同意。最坑的是公司之前的產品經理都沒有工作交接，產品初期的很多文檔都沒有。后面因為來來回回天天就在幫忙處理bug就離職了，很多自以為懂產品的人其實都對需求分析非常不重視
非常清晰的思路，學習了