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

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

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

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

一、簡單理解建模

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

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

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

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

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

例如業(yè)務(wù)提出的需求是做一個“采購系統(tǒng)”，但是“采購系統(tǒng)”這幾個字很虛無縹緲。

然后具體是怎么樣子，有什么功能，要怎么做，需要產(chǎn)品去逐步調(diào)研，設(shè)計。

然后建模，最后將建立好的模型通過一些圖形化或者文字化的表達(dá)，傳達(dá)給開發(fā)和測試人員等，最后大家認(rèn)知達(dá)成一致之后，上線一款滿足業(yè)務(wù)需求的“采購系統(tǒng)”。

要完成建模，首先是確認(rèn)抽象角度，這其實就是面向?qū)ο蟮囊粋€分析過程。一個需求的背后有很多人，事，物和規(guī)則，單單拿“人”來說，也會有不同的抽象角度。

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

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

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

其次是確認(rèn)業(yè)務(wù)用例，當(dāng)我們在第一步的時候確認(rèn)了若干個抽象角度之后，由于抽象角度背后是特定的場景，所以我們應(yīng)該對相應(yīng)的場景進(jìn)行梳理。

例如我們是按職位或者使用功能的角度來抽象，這個抽象角度背后的場景就有“采購員在什么條件下要做什么事達(dá)成什么目標(biāo)”，“業(yè)務(wù)員在什么情況下會需要發(fā)起采購申請？要如何發(fā)起？”，“在采購環(huán)節(jié)中要如何與供應(yīng)商關(guān)聯(lián)，關(guān)聯(lián)之后能做什么”。

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

二、為什么要做燃油方案

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

1. 尾程物流費用構(gòu)成

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

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

圖源：FedEx官網(wǎng)

無論是從業(yè)務(wù)的角度，還是從技術(shù)的角度，燃油方案看起來都是一個很簡單的需求，容易理解，關(guān)鍵字段也很少，業(yè)務(wù)關(guān)聯(lián)性也不復(fù)雜。

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

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

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

1. Round1：參考競品來建模

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

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

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

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

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

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

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

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

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

第一版的建模：平鋪型。

確認(rèn)了視角之后，接下來就是挖掘場景，從“人”，“事”，“物”，“規(guī)則”幾個方面去構(gòu)建場景，然后發(fā)現(xiàn)了這種方案有以下幾個問題。

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

2. Round2：使用平鋪型+狀態(tài)限制來建模

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

第二版的建模：平鋪型+狀態(tài)。

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

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

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

狀態(tài)是通過每天的定時任務(wù)來判斷的，根據(jù)設(shè)置的日期和當(dāng)前日期進(jìn)行比較，判斷應(yīng)該在什么狀態(tài)。

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

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

3. Round3：采用樹狀結(jié)構(gòu)來建模

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

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

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

意識到這一點之后，我完全拋開了競品的干擾，直接從最本質(zhì)的需求和業(yè)務(wù)邏輯觸發(fā)，重新發(fā)掘新的建模視角，最后發(fā)現(xiàn)采用樹狀結(jié)構(gòu)才是更合理的解決方案。

第三版的建模：樹狀結(jié)構(gòu)。

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

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

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

最后，樹狀結(jié)構(gòu)可以保持燃油方案的簡潔，配置計費規(guī)則的時候選擇的是燃油方案的主檔信息，而在使用/調(diào)用燃油方案的時候，再根據(jù)日期時間去查詢該方案下的燃油明細(xì)。

當(dāng)然，對于燃油明細(xì)還是要確保生效日期范圍不能重復(fù)的，這樣計費的時候才能找到唯一的一條數(shù)據(jù)。

四、總結(jié)

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

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

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

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

其次是關(guān)于競品參考這件事也讓我有些頓悟，批判性思維在產(chǎn)品領(lǐng)域真是時用時新。

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

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

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

另一方面是在建模方面，我還是只是一個初學(xué)者，邊寫的時候還在邊找資料論證，我發(fā)現(xiàn)市面上關(guān)于這一塊優(yōu)秀的教材還是太少了。

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于 CC0 協(xié)議。