5個方法，幫助產品經理做好業務分析

業務需求來源於業務，業務梳理的主要思路是去理清業務中的要素，以及業務方在業務過程中的問題和所關注的核心點、需求。文章分享了5種梳理業務的方法，希望通過此文能夠加深你對業務的認識。

在產品經理教學市場中，充斥着大量的課程、書籍，向我們灌輸用户需求分析，用户研究等等概念，但少有人提及“業務”，即使提及了，也講述得非常籠統，在進行“業務分析”關鍵詞的搜索時，甚至很難看到有人對“業務”進行了定義。

相比於國外，B端的業務分析體系已經較為成熟，形成了健壯的知識共同體，有認證機構、配套的教學體系等等。而C端業務，由於面向羣體的混沌性、隨機性，國內國外都未呈現出系統性的知識體系。

在本文中，筆者嘗試通過對“業務”進行定義，並對業務進行建模，得到描述業務的主要維度，並定義“業務需求”是什麼。接着我會聊聊為什麼重視業務以及業務建模很重要。

最後講講關於闡述業務的可視化方式，也就是業務分析完後需要輸出的內容是什麼。但具體的瞭解業務的方式由於篇幅有限就暫且不展開了。

我們在研究一樣東西的時候，首先需要對這件事情做一個定義。業務這個詞對於產品經理來説並不陌生，但讓你回答一下“業務”是什麼的時候，這個事情似乎又沒那麼容易。

寫這篇文章前，我就因為這個問題卡住了不少時間，司空見慣的東西卻是最難以解釋的。

後來我從他的英文單詞中，明白了它的定義 — Business。

*Business* is the activity of making one’s living or making money by producing or buying and selling products (such as goods and services).業務(商業)是通過生產和買賣產品(如商品和服務)來謀生和賺錢的活動。業務一詞最早來源於日本的翻譯。

那我們可以明白，業務的本質其實就是商業，那我們在研究業務過程，本質上是在理解商業過程，及這個過程中供需關係與其中信息流、物流、資金流的傳遞。

從我過去所讀過的一些經濟學、進化論社科類書籍中，我明白了一個道理，人類的社會的經濟發展來自於個體自下而上的信息、物質互換，在這過程中，比較優勢凸顯出來，個體的分工也越就更加明確。

在這個分佈式的信息、物質傳遞過程中，一個複雜適應系統演化出來（複雜適應系統是我最近比較感興趣的內容，不知不覺就會扯到它，以後找機會寫寫），在「理性樂觀派」中，將這個系統稱之為“集體大腦”，他是個體分工合作的集合。

業務，就是分工合作的小集合。社會中不同的業務共同構成我們的集體大腦。

「理性樂觀派」中有一段話：經濟進步的一項衡量標準：超過一半的人口脱離了自給自足，去探索以集體大腦為基礎的生活所充滿的無窮可能性。

啥意思呢？集體大腦是人類分工合作的結果，是社會中所有崗位的集合，我們工作就是參與了集體大腦的構建，從而有了更安全、更乾淨、更便捷的生存空間。但我們工作之餘，也有精神需求，有學習、閲讀、追求個性等等需求，他們則是集體大腦為基礎的更多可能。

所以，我個人將產品分為兩類，一種是為了構造集體大腦的，及業務型的產品，需要研究業務本身，研究促成社會發展的分工合作；另一種是有足夠生活基礎後，是對美好生活的探索，需要研究個體需求，這類產品俗稱C端產品。

業務是分工合作，通俗的説，就是一羣人在一起合作，以完成業務，達到各方的期許。通過業務，供需雙方各取所需，各方消耗邊際成本，獲得邊際收益，B端產品則是服務於這一過程的信息系統或服務。

那麼完整地描述一個業務，需要有哪幾個維度？這關乎到每一個產品經理在面對一個或陌生或熟悉的業務時，是否能準確分辨研究對象。

通過用户？場景？需求？似乎這種方式太過於簡單粗暴，不太嚴謹。通過流程圖？還是不夠全面，業務中涉及到的信息沒法很好的體現。

最後我在這本書中找到答案 –「七步掌握業務分析」

10年出版的書，評價僅有五十來人，頁數也不算很多，但內容牛批。

這本書中，將業務分為四個部分：人、信息、流程、規則。從一個信息系統的角度來看，也就是外部實體、數據、過程及業務規則。

以打車這個分工場景為例：參與的人員有司機和乘客，司機需要的信息是是否有乘客是否需要打車，他在哪裏，他要去哪裏，乘客需要的信息是哪裏有車可以打，哪輛車可以提供服務等等。整個流程便是，乘客發佈乘車需求這一信息，司機接受後，前往乘客所在地，獲知乘客目的地，提供價格，乘客獲取價格，選擇坐與不坐，最後到目的地，乘客花費了金錢，滿足了迅速到達目的地的需求，司機花費了時間成本、燃油費等，獲得了酬勞。這一過程，還需要一定的規則，比如行車價格規則、安全規範等等，假若規則不明確，供需雙方就可能無法達成平衡，以至於業務無法開展。

用一張圖來表示這其中涉及到的人員和信息及規則，可以是這樣：

加上流程描述，那就是這樣，在書中，被稱為核心需求組件。

第一張圖，在書中稱之為高階數據流圖，而我更傾向於業務全景圖，因為他描述的是一個業務大致全貌，有助於我們在一開始確認研究的範圍。

在這四個維度的基礎上，我又加上了兩個維度：業務目的、業務風險。因為業務的完成總是有所目的的，打車的目的是車主賺到錢，乘客安全快速地到達目的地，是業務參與人“想要”的驅動力。

而一個業務參與人也同樣是有“不想要”的驅動力，那就是業務風險，完不成業務可能會發生的後果。比方説

再舉幾個例子：

產品開發業務，在這個業務當中有多個角色，簡單地來看的話，主要是產品經理和程序員，程序員需要產品需求、BUG、數據需求等等，產品經理需要產品成果、開發，流程上可能會有企業的立項流程、產品開發流程等等。大家都基於公司的規章制度來行事，最終是想通過這個業務，這個分工合作來達到企業、員工、客户各方的利益，完不成業務的風險則是錯失客户、市值下跌、員工可能被炒魷魚…

PM與RD之間，存在信息不對稱、不及時的話，就會耽誤開發週期，間接影響業務的完成質量，而這些在排除人員個人問題之外，主要就是由流程不明確、規則不明確、角色分工不明確導致的。

案件發生後，警察要抓賊，也就是情報偵查業務，這個業務中，賊與警察是兩個主要角色，賊與警察存在着信息的不對稱。賊知道是自己犯的事，而警察不知道，業務的目的就是彌合這種信息的不對稱，使賊被抓住，維護被害人的權益，維持社會的穩定。那麼啊sir就會通過各種手段來彌合這種信息差，通過監控、人臉識別等方式，而啊sir的信息則需要故意不讓賊知道，啊sir需要基於一些規則辦事，比方説調用監控的權限規則、依據法律辦案。倘若破壞了規則，則可能造成一系列的公關問題，信息泄露問題等等。

前文我們定義了業務是什麼，也就是理清我們的研究對象，但是至於他們想解決什麼問題還沒有解決。

業務需求的含義指的是他們在分工合作中遇到了一些問題，所以主導這個業務的、能夠從這個業務中獲利的人希望能夠解決掉他們。或者是這個人看到了業務能夠提升的空間，也就是業務機會，希望能夠抓住這個機會來實現業務的提升。

業務需求來源於業務，那麼就是四要素中出現了某些問題，導致成本損耗、營收達不到目標要求、風險失控。不同的業務需求，決定了我們接下來要解決的用户需求是不同的，

為什麼我認為在做產品之前，應當先理解業務，再考慮方案？可能有些人會説因為沒考慮清楚業務，做出來的產品肯定是不符合需求的。但個人認為還有一個更重要的原因，這個原因困惑了我許久時間。

做產品經常會被要求要有框架性思維，我也一直試圖再學習練習在面對一個陌生事物，不管是生活中的還是工作上的，都能夠帶入這套思維去思考，後來發現，不管我怎麼做，我最後都還是會回到起點，沒有辦法在一時間構想整個框架。後來，我發現這個框架太龐大了，從最初的需求到後期的運營，啪一下全構想出來是不可能的，因為工作記憶只能容納7個數字，人類的大腦特性決定了這件事情是不可能。

但是為什麼有些人能夠一次性記憶數百個數字，那是因為他將一連串的數字拆分成3-4個數字的組合，並且通過已有知識將這些無邏輯的數字構想成邏輯，組合起來就能記憶上百個數字。比如説記憶100252037989，就可以拆分為1002（是我的出生日期倒過來，Justkidding），5203（我愛你撒），7989，學習更多的數字抽象化方式有助於記憶。

那產品思維的方式也是這樣的，需要將多個複雜步驟拆分成幾個模塊，並且通過已有的知識將這些模塊拆解、構成自己的邏輯，就可以有效記憶和理解。同樣，學習和練習更多的需求理解方法論，也有助於理解。

那麼首先要思考的就是業務的四要素和業務目的、業務風險，通過對業務的瞭解。

由於篇幅問題，本文就直接講解業務梳理後輸出的內容，也可以説是業務要素的呈現方式。

業務梳理的主要思路是去理清業務中的要素，以及業務方在業務過程中的問題和所關注的核心點、需求。

我們定義了業務是什麼，那我們如何梳理業務，讓業務信息儘可能全面和清晰呢？

這裏介紹幾種方法，幫助我們能夠梳理清楚並清晰展示業務的過程邏輯。

他們分別是：

這幾個方法的層級關係是這樣的：業務範圍圖描述最粗粒度的業務，只描述關鍵信息與所涉及的人員。而核心需求組件進一步，描述業務的人（外部主體）、信息（數據）、流程、規則，但也是粗粒度的整體描述。再通過流程圖、用例圖展開描述所涉及到的人與流程之間的關係，業務規則表展開描述規則，數據模型則描述人與信息之間的關係。

在前文中也介紹過，業務範圍圖描述業務中所涉及的所有角色，以及每個角色在業務過程中所供給和需要的重點信息。業務範圍圖，有助於在項目初期理清業務範圍、業務干係人，和其中比較重要的信息，無需技術背景，也可以讓各方干係人理解溝通。

外部的方塊表示外部實體，角色、機構、依賴的系統等。箭頭表示信息進出的方向，中心的圓圈表示研究的領域，及業務。

核心需求組件提煉業務的核心要素。依次來描述：

信息（數據）：可以指的是一個實體，比如説一個訂單，也可以是實體的屬性，訂單價格。對於數據的分析待會會再提及。這裏的只需要將這些數據進行羅列，個人建議羅列實體，屬性在實體，理清業務中的信息對象。

外部主體（角色）：指的是與業務領域內有交互的人、組織或系統。體現的是業務過程中，哪些角色進行了分工合作，有時候分工對象還有硬件設備或外部軟件，它們也是其中的外部主體。

流程：流程是所有產品經理最熟悉的東西了，指的是業務所完成的活動工作。流程就會涉及外部主體與信息的傳遞。這裏只需要概述有哪幾個業務流程。比方説項目管理業務，包括立項流程，月總結流程，結項流程。

規則：業務規則是分工合作過程中的條件，是業務演化的結果，它使得業務在一些情況下，能夠有決策依據，使業務保持一致，順利開展。現在很流行的策略型產品經理，我認為本質上就是在寫業務規則，即推理規則、計算規則。

業務流程是大家熟知的方法，不管是C端B端都會繪製業務流程，後期運營也通常是通過它來找問題。

業務流程圖展示的是一個業務分工合作、信息互傳的過程，描述的是沒有我們的設計方案之前是如何完成業務的，流程通常用動詞進行描述，表述角色的任務、動作。關於業務流程圖的資料已經較多，就不做展開。

描述角色動作（任務）與信息傳遞的方式還有用例圖。用例圖即可以是描述系統功能、產品需求的方式，也是我們做業務分析時，可以使用到的工具。

用例圖有四個元素：參與者、用例、邊界、箭頭（關係）。參與者表示與軟件（項目）接口的人、組織、系統；邊界在軟件需求中指的是系統的操作邊界，而對於我們進行業務分析而言，它就意味着業務的邊界範圍；用例是角色在業務範圍內的動作；箭頭在複雜的用例圖中有多種畫法，我們可以儘量保持簡潔以便溝通。

用例的使用，可以讓我們清晰看到在業務範圍內，不同角色有哪些職責、任務，也可以理解為不同角色的用户需求，但用例圖隱藏了用例過程中的一些細節，有時候還需要更詳盡的用例説明來輔助表達。

除了流程圖和用例之外，也可以用用户-場景-需求的方式去梳理用户需求。

在「軟件需求：第3版」中，業務規則分為這麼幾類：事實、約束、觸發條件、推理規則、計算規則。它們都有相應的需求表述的方式。值得一説的是權限也是業務規則的一種説明。

比如：項目管理業務中，公司規定了PM每個月必須上報項目進度。這是一條業務規則，但後期，設計一款項目管理工具時，它就成為一個需求，每個月未上報，會進行郵件通知或者績效考核扣分之類的後置條件。

業務規則的類型較多，表達方式也比較多，如權限設計有RBAC模型，策略算法可能用的決策樹、決策表等等。本文介紹一種簡單、通用的方法來記錄這些規則，來自於「軟件需求：第3版」，業務規則表。每條業務規則用一句話去描述，

來源：軟件需求第三版

數據模型處理的是人和信息之間的關係。

我們在業務的過程中，我們經常會虛構出一些詞彙，來定義某一類東西，以便於業務各方能夠快速溝通，同步信息。就像金錢是我們生活中虛構出來的概念，以便於在市場中，能夠進行快捷有效的交易，又比方説“訂單”，它的作用在於讓購買者和出售者用同一載體溝通購買的結果。又比如説“課程”，它是為了讓教師和學生方便溝通的統一介質，他們都是某種人為定義的非物理性質（也可能被制定成某種物理材料）的概念。

數據模型的梳理是為了讓我們知道業務過程中，有多少種人為抽象出來的概念，以便於信息的傳遞和溝通。在業務調研過程中，就需要發現和記錄這些虛構出來的概念。那如何記錄與分析呢，就需要用到我們的實體關係圖。

同樣，實體關係圖也是來自於信息系統設計，它既是一種設計數據層、設計數據庫的方法，也可以是我們分析業務數據對象的方法。

我們用實體關係圖來對業務信息進行抽象和分析，將大大方便我們後期對產品的設計。由於本次不講產品設計，所以就暫且不展開。

實體關係圖非常的簡潔，包含三個元素：實體、屬性、關係。實體指的是我們抽象出來的概念，比如之前説的「課程」，又比如説「學生」，學生其實也是一種概念，他們都描述一類事物。

但是描述一類事物還不夠，我們還需要區分這類事物的不同個體。比如説上課這個業務，我知道你是學生沒有用，我還得知道你這個學生叫什麼，是哪一班的，是男是女才行。

所以每種實體還會有屬性，比如説「課程」有上課時間、課程類型等屬性；「學生」會有姓名，性別，學號，年級班級等等。如果是在產品設計階段，這些信息就會被存儲在一張「課程」、「學生」數據表當中，大概像下圖那樣。

一個實體有多個屬性之餘，還和其他實體之間存在着“關係”，因為它們通常不是獨立存在的，是因為業務而產生的。「課程」這種實體會與「教師」這種實體的關係為1:1的授課關係，「課程」和「學生」存在1:N的被授課關係。

通過這幾種方法，我們可以清晰地看到業務過程中的所有元素。

在這篇文章中，提出了對於業務的定義，有助於我們認清楚分析對象是什麼。同時也提出了關於“為什麼產品工作要先進行業務分析”的觀點。最後介紹了5種業務呈現方法，幫助我們對業務全貌形成理解。

作者：Lobster.；個人公眾號-：生猛龍蝦

本文由 @ Lobster. 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議