編輯導語：產品建模是對產品需求進行抽象、整理、建立數據、梳理工作流程的過程，對于產品工作也十分重要，本篇文章作者結合“燃油方案”的改版分享了對建模的一些理解，對建模感興趣的小伙伴一起來看看吧，希望對你有幫助。

前段時間重溫了一波UML，除了復習了一波基礎的語法和使用場景之外，還有一個很重要的目的就是：學習如何建模。

關于建模，我之前看完了《大象：Thinking in UML》的前兩章后，寫了一篇閱讀筆記《一個掉頭發的問題：什么是建模？》，當時寫完了之后感覺對建模的概念稍微有些掌握，但是過了一段時間之后又開始有點生疏、模糊了。

于是最近我又重溫了這篇文章，同時又再讀了兩遍《大象：Thinking in UML》的前兩章，結合最近項目中遇到的一個小案例，我決定寫一篇關于建模實踐的心得文章，也就是這一篇。

一、簡單理解建模

關于建模的定義，我直接摘錄書上的解釋，因為我感覺這個定義挺準確的，也很簡潔。

建模（Modeling），是指通過對客觀事物建立一種抽象的方法用以表征事物并獲得對事物本身的理解，同時把這種理解概念化，將這些邏輯概念組織起來，構成一種對所觀察的對象的內部結構和工作原理的便于理解的表達。

上面建模的定義本身就和建模工作一樣非常抽象和難以理解。

我大概總結了一下我自己的理解，然后用借用一張圖和幾段稍微通俗的一些語言來概述它。

產品日常工作中需要使用建模，是因為我們需要對一些事物建立一些概念化的描述，然后以此來讓其他人理解這些事物。

例如業務提出的需求是做一個“采購系統”，但是“采購系統”這幾個字很虛無縹緲。

然后具體是怎么樣子，有什么功能，要怎么做，需要產品去逐步調研，設計。

然后建模，最后將建立好的模型通過一些圖形化或者文字化的表達，傳達給開發和測試人員等，最后大家認知達成一致之后，上線一款滿足業務需求的“采購系統”。

要完成建模，首先是確認抽象角度，這其實就是面向對象的一個分析過程。一個需求的背后有很多人，事，物和規則，單單拿“人”來說，也會有不同的抽象角度。

例如常見的就是按職位或者使用功能的角度來抽象，采購管理模塊的人分為“采購員”，“業務員”，“供應商”。

但是如果按使用系統的角色來抽象，則采購管理模塊的人可以分為“采購發申請角色”，“采購處理角色”，“管理員”，“采購審核人員”等。

不同的抽象角度匯聚在一起會構成“問題領域”，問題領域中那些重疊的部分其實就是需要重點關注并解決的問題，因為在不同的抽象角度都能得出此問題，則意味著該問題是高頻且核心的。

其次是確認業務用例，當我們在第一步的時候確認了若干個抽象角度之后，由于抽象角度背后是特定的場景，所以我們應該對相應的場景進行梳理。

例如我們是按職位或者使用功能的角度來抽象，這個抽象角度背后的場景就有“采購員在什么條件下要做什么事達成什么目標”，“業務員在什么情況下會需要發起采購申請？要如何發起？”，“在采購環節中要如何與供應商關聯，關聯之后能做什么”。

對業務建模的概述，如果說上述的大白話，還是讓你對建模有點琢磨不透，似懂非懂的話，那我拿一個我最近在做的實際案例來進一步解答你的疑惑。

二、為什么要做燃油方案

之前有提到過，海外倉尾程物流的費用一般包含兩個部分基礎運費+附加費，附加費中有一個比較特殊的“燃油附加費”，它的計算公式是（運費+部分附加費）* 燃油費率。

1. 尾程物流費用構成

燃油費率具有以下幾個特點：

1. 和時間有關系，不同的時間段，費率不一樣，所以費率的更新比較頻繁；
2. 和物流商有關系，不同的物流商，燃油方案（生效時間范圍和費率）不一樣，但是也有一些物流商的渠道是相同的燃油方案；
3. 費率是一個百分數（小數），需要乘以基礎費用才能得出具體的燃油費；

圖源：FedEx官網

無論是從業務的角度，還是從技術的角度，燃油方案看起來都是一個很簡單的需求，容易理解，關鍵字段也很少，業務關聯性也不復雜。

起初的時候我也不以為然，感覺就是一個很簡單的需求，差不多想了一下，然后找競品也看了下，就輸出了一個產品設計方案，準備到時候快速評審一下。

但是實際上我前后改了三個版本才解決這個“小需求”，期間還一度讓我感覺自己是不是進入了“知識詛咒”，陷入了“死胡同”出不來了。

三、因為建模失敗，改了三個版本

1. Round1：參考競品來建模

參考了好幾個競品之后，我發現大家對燃油方案的設計都是最簡單的平鋪型的設計，也就是把所有創建好的燃油方案按時間排列。

燃油方案也是一個比較抽象的概念，為了讓大家更好地理解它，所有我們在對其進行建模的時候，需要先確認一個抽象角度，因為確定了角度就會讓我們有一個目標。

“平鋪型”就是一個建模的角度，通過這個角度，我們得到了目標：平鋪式的展開所有的燃油方案，以便于更簡單方便地對燃油方案進行管理。

而管理燃油方案就會涉及到多個場景，這就是建模的第二步———找出特定的場景。

我們需要創建燃油方案，編輯燃油方案，刪除燃油方案，應用燃油方案等，以上這些是場景中的“事情”，然后借此我們還需要去挖掘這個場景中的“人”和“規則”。

當我們確定了抽象角度，找到了這個角度背后的場景之后，建模也就完成了大半。

最后要做的就是對這些場景進行梳理和推敲，是否能夠完全滿足業務的需求，有沒有遺漏的點或者阻塞的點等。這其實也是UML中梳理用例的過程，所以當我們在梳理用例的時候，本質上也是在做建模這件事。

如果一個抽象角度不能完成建模，那就要繼續回到第一步，發掘更多的抽象角度，從實際的工作經驗來看，簡單需求可能一個抽象角度就可以完成建模，但是復雜需求往往需要多個角度，多個場景，多個用例同時構建才能完成建模。

讓我們再回到燃油方案建模這件事的起點時刻，首先要做的就是去發掘它的抽象角度，從多個競品的實現方案上來看，平鋪型的視角是用的最多的，所以我們第一版也采用了平鋪型的視角去建模，去梳理業務用例，去完成產品設計。

第一版的建模：平鋪型。

確認了視角之后，接下來就是挖掘場景，從“人”，“事”，“物”，“規則”幾個方面去構建場景，然后發現了這種方案有以下幾個問題。

1. 方案平鋪后數量太多，會不斷新增，使用的時候不太方便；
2. 燃油方案需要經常更新，而且有些時候會提前設置，等到時間點后生效，平鋪型的燃油方案不利于更新，如果修改已有數據，則破壞了正在生效的計費方案；如果追加新的燃油方案，則必須要求燃油方案重名，用戶操作出錯的風險太大；

2. Round2：使用平鋪型+狀態限制來建模

鑒于平鋪型的視角會有一些問題難以解決，我們在短暫的討論后決定要調整一下方案，換一個視角來發掘業務場景，試圖找到更好的解決方案。

第二版的建模：平鋪型+狀態。

在第二版的方案中，我們引入了一個新的“狀態”字段。大多數場景還是和第一版一樣，只是通過狀態來做一些核心業務邏輯的判斷。

燃油方案名可以重復，重復意味著使用一個燃油方案后，當后續不斷的新增/修改燃油方案后，只要名稱是可以匹配的，就可以使用這個燃油方案來計費。

然后通過狀態來判斷，“生效中”的燃油方案不能重名，只有一個，“未生效”和“已失效”的燃油方案可以重名，可以有多個。

狀態是通過每天的定時任務來判斷的，根據設置的日期和當前日期進行比較，判斷應該在什么狀態。

這個方案最后還是被我們評審的時候Pass掉了，原因是還是有一些風險點和體驗不好點，原因如下：

1. “未生效”的燃油方案如果重名且生效日期范圍有重合，則會導致當自動生效的之后，“生效中”的狀態可能會同時有兩條；如果限制了不能重合，則又要限制“未生效”和“生效中”的也不能重合，這樣感覺和狀態又無關了，引入這個概念沒多大的意義，因為方案一就是限制了不能重合；
2. 定時任務更新狀態可能會失敗，需要引入重試機制或者兜底機制；兜底的機制是每次用的時候再去查當前的日期是否滿足生效日期范圍，如果每次都要查，那么定時任務更新狀態也沒意義了，直接實時用時間去判斷就夠了；

3. Round3：采用樹狀結構來建模

因為方案一有一些漏洞或者體驗不好的點，所以才想到了方案二，引入了一個狀態，但是實際在處理這個狀態的時候，發現很是雞肋，有用但是又不完全有用……

看似一個簡單的需求，但是設計出來的產品方案總是有明顯的漏洞和瑕疵，我感覺可能一開始的思路就錯了。

也就是說：競品們采用的從平鋪型視角去建模，有可能本身就是錯誤的或不好用的。

意識到這一點之后，我完全拋開了競品的干擾，直接從最本質的需求和業務邏輯觸發，重新發掘新的建模視角，最后發現采用樹狀結構才是更合理的解決方案。

第三版的建模：樹狀結構。

首先，燃油方案名稱本來就是一個索引，一個殼子。

業務說經常要更新燃油，這里的更新只是對燃油方案中的明細進行更新，常見的就是修改生效日期、失效日期和燃油費率，燃油方案名稱一般來說是不會修改的，也不能修改，因為方案是一直被計費規則所使用的。

其次，燃油方案還有一個很關鍵的場景需要滿足，就是對已經發生了的物流費進行重新計算的時候，需要使用物流發生的時候的燃油明細去計費，也就是歷史的燃油明細也很重要，需要留底備用。

最后，樹狀結構可以保持燃油方案的簡潔，配置計費規則的時候選擇的是燃油方案的主檔信息，而在使用/調用燃油方案的時候，再根據日期時間去查詢該方案下的燃油明細。

當然，對于燃油明細還是要確保生效日期范圍不能重復的，這樣計費的時候才能找到唯一的一條數據。

四、總結

最后回過頭來看的時候，燃油方案這個需求確實比較簡單，我們最終使用的方案也沒有特別的創新或者顛覆性的改造，但是整個經歷卻很跌宕起伏，很讓我觸動。

一個小小的方案，因為一開始的建模方向搞錯了，導致陷入了一種不撞南墻不回頭的境地，讓我總是在自我懷疑，為啥別人可以這樣做，我自己這樣做的時候卻不行了呢？

通過三次的建模，三種不同的視角帶來的差異也讓我特別驚訝，很多時候我都以為建模只是在復雜場景下才用的上的比較玄乎的技能，但事實上好像簡單場景也能用得上。

只是場景過于簡單我們大多數時候第一反應切入的視角就已經可以做到最優解了，所以對建模視角的選擇這個事情不會有太深刻的記憶。

其次是關于競品參考這件事也讓我有些頓悟，批判性思維在產品領域真是時用時新。

大家都在用的方案也不一定是最優解的方案，錯誤的概念和理解傳播的多了，用的人多了，也不能改變它是錯誤的本質。

這一篇文章寫了2個禮拜，斷斷續續始終沒有靈感和動力一口氣寫完。

一方面是工作節奏太緊了，抽不出太多的時間。

另一方面是在建模方面，我還是只是一個初學者，邊寫的時候還在邊找資料論證，我發現市面上關于這一塊優秀的教材還是太少了。

用這個案例來闡述我對建模的理解，也許沒有我想象中那么貼切，或者有一些理解可能還是錯誤的。如果你在此領域有更好的案例或者學習教程，歡迎與我溝通交流。

#專欄作家#

我叫維他命（Vitamin），微信公眾號：PM維他命。前PHPer，做過在線教育類產品，也做過4年多的跨境倉儲物流方向的產品，目前是一位外貿SaaS領域的供應鏈產品經理。主要專注于WMS/OMS/TMS/BMS/ERP等領域，分享供應鏈相關的產品知識。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議。