業務需求來源於業務，業務梳理的主要思路是去理清業務中的要素，以及業務方在業務過程中的問題和所關注的核心點、需求。文章分享了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協議