對于B端產品經理而言，UML的思維是幫助B端產品進行業務調研的利器。本文結合自己的實踐經驗，與大家分享如何應用UML思維做B端產品，希望對你有所啟發。

B端產品們做業務調研工作時，是不是經常遇到這些情況：

1）公司業務復雜，極容易錯漏某個重要的業務節點，等你把原型都出好了，業務過來說他們還有XXX情況需要加入系統。

2）公司部門利益不一致，每個部門都覺得應該優先實現他們的需求。

前段時間我閱讀了大象希形老師的書籍《Thinking in UML》。大象希形老師是在IBM有10年豐富經驗的架構師，這本書集合了他工作中的經驗心得。

閱讀完這本書后，我發現UML的思維是幫助B端產品進行業務調研的利器，每一位B端產品都應該具備這種思維。

在運用這種思維之前，我也經常陷入雜亂的業務規則、沖突的業務需求中，不知道如何處理。

但是運用了UML思維后，我在處理公司級別的大項目，且截止時間僅有一個月的情況下，我保質保量地梳理出了項目需求的所有脈絡，推進項目順利完成交付。

通過這篇文章，我把這次實踐后的經驗分享出來，希望能幫助到大家。

（友情提示：本篇文章干貨滿滿，讀完一遍后可以先收藏，實際運用的時候再翻出來回顧。）

一、UML思維是什么

想要理解UML思維是什么，首先需要了解UML是什么。

UML（Unified Modeling Language）中文名稱是統一建模語言，又稱標準建模語言。是一種為面向對象系統的產品進行說明、可視化和編制文檔的一種標準語言。

那UML思維是什么呢？

UML思維我認為可以簡單地理解為“面對對象的方法”。

在軟件領域，有兩種常見的術語：面對過程的方法、面對對象的方法。

什么叫面對過程，什么叫面對對象呢？

面對過程方法認為我們的世界是由一個個相互關聯的小系統組成的，就像DNA一樣，整個人體都是由這樣的小系統用嚴密的邏輯組合而成。并且面對過程的方法假設這個過程是穩定的，不會改變的。

在使用“面對過程方法”做設計時，我們需要找到過程的起點，順藤摸瓜將這個過程中牽扯的因素逐一分析出來，理清這個過程中的因果關系，最后到達過程的終點。

而面對對象的方法認為我們的世界是由各不相干的獨立個體組成的。過程不是這個世界的本源，過程是由一些“對象”通過特定的規則組織起來的。

如果把世界比喻成汽車，那么對象就是汽車上每個不同的零件。

不同的零件組合成了汽車，不同零件之間的組合也會達到不同的效果。如果規則允許的情況下，我們還可以將零件隨意更換。比如材質可以從鋼鐵換成鋁合金的，來源可以從工廠A換成工廠B的。

面對對象的方法不考慮對象之間的因果關聯，只是在需要的時候把他們拼合在一起，這種方法能更好地應對我們現在面對的復雜業務。

二、如何把UML思維運用到業務調研中

可能看到這里，你會覺得：“UML思維也太抽象了！我要怎么用UML思維做需求分析呢？”

其實只需要記?。合葘I務當成是一輛汽車（整體），然后拆汽車里的零件（部分），最后將零件拼合起來（連接）。

一般我們常見的業務調研方法是這樣的：先明確調研目標，再選取調研對象，然后明確自己的調研方法，執行調研計劃，最后得出結論。

可是這樣的調研方法太寬泛了，調研對象怎么選取才是正確的？是所有相關人員都要調研嗎？執行調研計劃該怎么做才能得到用戶最準確的需求？我該怎么提問？

而運用了UML思維，業務調研流程能夠更被細化，對我們的具體工作更有指導意義：先是明確調研目標，再梳理業務中所有的人事物（整體），然后確定業務主角、訪談業務主角（部分），最后得出結論（連接）。

針對我細化的每一個步驟，下面我會仔細講一下怎么落地，和這么做的好處。

為了大家更好地理解，我會輔以我自己參與過的項目案例舉例說明，大家可以結合案例去更好地理解。

步驟1：梳理業務中所有的人、事、物

1.1 為什么這么做

為什么第一個步驟是先梳理業務的整體呢？

因為這么做有兩個好處：第一個，了解業務的整體能讓我們更快速地把握業務背后的邏輯。第二個，了解整體業務能避免我們在需求調研的過程中遺漏了業務細節。

如果我們在開頭不是梳理整體，而是梳理某個業務節點，那我們很快就會被繁雜的業務擾亂自己真正的目標。

之前我在為公司的會員體系搭建管理系統時，就因為一開始太著眼于具體的會員升級規則，會員購買折扣之類的需求，反而被彎彎繞繞的業務規則弄得不知道如何下手，影響了工作的開展。

并且因為我的切入點是某個會員規則，由這個會員規則再帶出了其他業務事件，這樣切入和梳理，非常容易遺漏了業務中某個人或某些業務事件。

直接切入具體需求的處理方式就好像在走一個迷宮，不停走進死胡同再出來，磕磕碰碰，最終才能找到了正確的道路?？墒侨绻覀兡芤婚_始就能從整體俯視整個迷宮，那我們就能更快地找到正確的道路。

所以通過一開始就把業務整體給梳理清楚，能夠避免我們遺漏了業務中某個人或某些業務事件，也能更方便我們了解業務的全局。

1.2 怎么落地

為了更好地梳理業務中的人、事、物，我們需要依靠一個工具——業務用例圖。

用例圖是UML中十分基礎和常用的圖，主要元素有業務主角和業務用例兩個。我通常用小人的圖案表示業務主角，橢圓來表示業務用例。

用例圖通常使用在我們業務調研的過程中。通過梳理業務所有的相關角色，和這些角色在業務中會進行的活動得出用例圖。

以我做的充值卡業務為例，通過對組織架構和崗位職責的閱讀，可以大概了解到他的角色組成和業務用例是這樣的：

他們用業務用例圖來表示是這樣的：

通過業務用例圖，我們能更清楚地看到業務中人、事、物之間的關系，也能注意到某些事件可能存在跨多個部門的情況。遇到這種情況時，需要我們在需求設計時需要額外注意。

步驟2：確定關鍵角色

2.1 為什么這么做

通過上一個步驟我們已經把業務中所有的人事物都整理出來了，但這并不代表著我們要對所有的人都進行調研。

如果碰巧我們負責的系統牽涉部門較多，涉及人員也較多的情況下，往往時間和精力都不允許我們對每位用戶都進行訪談。

最好的方法是我們找到業務流程中的關鍵角色，僅對關鍵角色進行訪談。

提前整理出關鍵角色，也能夠讓我們對自己的系統目標有更清晰的認知，避免被一些雜亂的需求和業務流程擾亂了思路。

2.2 怎么落地

如何確定關鍵角色？

在確定關鍵角色之前，首先需要我們確定系統邊界。

系統邊界可以簡單理解為：系統提供哪些功能？使用角色是哪些人？

如果你的系統沒有明確的目標，那你就永遠無法定義使用你的系統最關鍵的人群有哪些。

就好比我們寫一篇文章，如果我們寫的文章沒有一個明確的目標，那么我們永遠也無法知道誰會愿意點開文章查看，誰會愿意將文章全部看完。

這里還是繼續以充值卡的業務為例子：

剛才我們已經主要梳理出了我們業務中包含的所有人、事、物，這時候我們定位充值卡系統主要提供——充值卡配置、充值卡購買/退款、充值卡售賣、訂單管理、用戶消耗記錄、充值卡業績看板的功能：

那么我們可以從業務用例圖中篩選出，主要使用這些功能模塊的人群有——銷售、銷售組長、財務、用戶。

通過系統的邊界，我們就能確定充值卡業務的關鍵角色是銷售、銷售組長、財務、用戶。

薪酬專員雖然在我們業務流中也有被梳理出來，但是這次系統實現的功能和薪酬專員不會直接相關，所以薪酬專員不算是業務主角。訪談時主要針對確定下來的角色進行訪談就好了。

步驟3：調研關鍵角色

3.1 為什么這么做

怎樣的調研才能讓我們更準確地獲取到用戶需求？

答案就是我們要以用戶視角去調研關鍵角色。

如果不以用戶視角出發會怎么樣呢？下面聽我講個小故事：

想象一下，我們生活在自行車剛被發明出來的時代。

今天我們剛領了工資，走入一家超市，想給自己買一輛自行車，這時候導購人員非常熱情的招呼了你，并向你這么描述這輛自行車：“這輛自行車是個交通工具，它由剎車系統和傳動系統組成…”

相信我們聽到這句話一定會一臉懵，不知道自行車是做什么的，對我們有什么用處。

但如果導購人員換了種方式和你介紹：“自行車可以通過踩動腳踏來讓自行車快速前進，讓你更快到達目的地。當我們手捏著剎車，就可以使自行車停下來?！?/p>

這種介紹方式，是不是瞬間清晰了很多？

同樣的例子換成我們將要搭建的系統。系統還沒有被搭建起來，誰也不知道系統會長什么樣子。如果我們在業務調研的期間就先入為主的以計算機的視角去描述系統，可能最后得到的結果和業務想要的結果會出現偏差。

3.2 怎么落地

那么我們怎樣去以用戶視角做調研呢？其實非常簡單，在訪談的過程中，我們可以重點詢問調研對象這四個問題：

1. 您對系統有什么期望？
2. 您打算在系統中做什么事情?
3. 您做這件事情的目的是什么？
4. 你就希望這件事情做完后有什么樣的結果？

這4個問題本質上的思路就是詢問對方希望系統能幫助解決什么問題，理由是什么，和他希望最終能達成什么目的。

理由和目的能幫助我們判斷使用者操作某個動作是否是一定要在系統實現的，這個動作最終是不是能帶來價值的。

下面以充值卡業務來舉例，因為文章篇幅原因，這里我只展示銷售組長的訪談記錄前半部分，但是每個人的訪談記錄的思路都是一樣的。

我們在做訪談的時候不一定要照搬上面的4個問題，記住最底層我們需要了解到的信息是對方希望系統能幫助解決什么問題，理由是什么，和他希望最終能達成什么目的。

訪談對象：銷售組長

問：關于充值卡業務，您對系統的期望是什么？(希望系統能幫助解決什么問題)

答：我希望系統能展示清楚充值卡的消耗明細，用戶知道自己花了多少，剩余多少。我們內部也要知道。然后我希望能清楚地展示每位銷售他售賣的充值卡金額，和他售賣的這些充值卡消耗情況。

問：我了解了。那充值卡的相關功能搭建起來后，您首先得能看到用戶的消耗明細，然后和您組內銷售售賣的充值卡消耗明細。還有其他的嗎？(希望系統能幫助解決什么問題)

答：還有營收計算。我們現在每個部門的充值卡業績分開來了，這個要統計清楚。

問：好的。下面我想針對這些點展開細聊。我想先請問一下，咱們知道用戶充值卡消耗明細的目的是什么嗎？我們負責銷售的同時，還要負責后續的消耗嗎？（理由是什么）

答：不負責的，一個是充值卡還有錢的用戶，消費可能更大。我們想先挖掘這些用戶。還有用戶也會找我們對消費明細，我們也要答上來。

問：明白了。充值卡的消耗明細主要還是希望幫助您達成挖掘用戶的目的對嗎？對數這個工作雖然有，但應該不是主要工作內容。（達成什么目的）

答：沒錯的。我希望針對充值卡剩余金額，能分類展示。剩余較多且快到期的，我們可以優先挖掘。剩余較少的，可以慢點再挖掘。

問：您剛才提到需要知道銷售售賣的充值卡消耗情況。咱們工作中還是得對自己售賣的充值卡是否消耗了負責對嗎？（理由是什么）

答：算是。這個不影響我們的績效也沒有KPI，只是財務會催促我們。

問：那這個功能的主要目的您是希望給您一個展示，提早知道消耗情況？（達成什么目的）

答：是的。（通過這里我們可以判斷，其實銷售組長只是想知道消耗情況，好配合財務部門的工作，這個需求的價值是不如第一個需求的價值大的。）

…

…

（這里的訪談內容和上面的內容比較相似，限于文章篇幅略過）

…

…

問：非常感謝您今天抽出時間來參與訪談。

答：不客氣的，您有問題再問我。

通過訪談，我們又能進一步整理出每一位角色對系統的需求。這些需求我們也可以通過用例圖來表示：

1）用戶：用戶可以購買充值卡、在購買的時候可以選擇充值卡付款、同時可以查看自己的消耗金額、剩余金額。（經過訪談，了解到銷售不希望用戶對充值卡可以退款這個事情感知太強，所以相比一開始的業務用例，我們的系統用例則刪除掉了用戶可以退款的用例。）

2）銷售：銷售可以自行生成充值卡訂單，可以查看自己的售賣記錄，同時可以幫助用戶發起充值卡退款。

3）財務：經過訪談，了解到財務要進行退款審核、查看和導出訂單、同時需要收到異常消耗的警報。

4）銷售組長：經過訪談，了解到銷售組長要查看用戶消耗記錄，充值卡銷售情況和要在營銷活動期間能根據本組的情況進行一定程度的充值卡套餐配置。

相比于一開始的業務用例，這里的用例圖會更具體，細化到系統要實現的功能模塊。

步驟4：輸出結論

將整體、部分都梳理清楚后，我們需要輸出結論，也就是把每個部分連接起來了。

這時候我們需要產出的就是業務流程圖。如果業務體量相對不是特別大，那么到這個步驟我們系統的一些基本模塊也可以產出來了。

通過最后產出的業務流程圖，這時候我們設計的框架就已經出來了，前期準備的工作到這里也基本告一段落，下面可以開始梳理具體的需求內容了。

寫在最后

相信你通過閱讀我的文章，能夠大致了解利用UML思維去做需求調研的主要流程和要點。

我們再一起回顧下，利用UML的思維去做業務調研主要為以下四個步驟：

1. 梳理業務中所有的人事物。利用業務用例圖整理起來，并且要和業務方過一下是否還有遺漏。
2. 確定業務主角。從梳理出來的人事物中，利用系統邊界的概念，篩選出業務主角。
3. 訪談業務主角。從用戶的角度出發，詢問用戶對系統的期望。
4. 輸出調研結論。輸出業務流程圖、系統的包含的大體模塊。顆粒度可以粗一些。

以上就是我利用UML的思維細化了自己業務調研的經驗分享，希望對大家同樣能有啟發。

因為我也是位讀者，對書中概念的理解可能存在偏頗的地方，歡迎大家找我一起討論。