導讀：在大型B端産品中，不可避免的出現各種配置，配置如同一個個控制閥，決定着業務的走向，并實現saas産品的千人千面，以滿足不同客戶的訴求，适應不同行業的業務場景。但在随着産品的發展，配置項也越來越多，逐漸變的不可設計與維護。給什麼做的配置？配置是如何生效的？好的配置具有什麼特點？如何确定配置的維度？針對這些問題，筆者就以自身的工作經驗，來給大家說一下如何進行複雜B端系統的配置功能設計。

一、給什麼在做配置？

在開始配置之前，我們要想清楚，我們到底在為什麼在做配置。

軟件系統是現實世界的抽象，在《THINK IN UML》一書中，表述了現實運行的機制：人驅動系統、事體現過程、物記錄結果、規則控制運行。由于我們不可能利用一套固定的規則滿足所有客戶的業務場景，故我們需要支持規則可調整，調整規則的功能，就是配置功能。

我們習慣用用例（use case）的方法來抽象現實世界的需求，一個完整的用例定義由參與者、前置條件、場景、後置條件構成，其中：

• 參與者通過系統輸入物與系統交互，可以是輸入的一段指令，一筆訂單，一個商品信息等；
• 前置條件：發生這個用例的前提條件，即輸入物滿足什麼條件才可以發生這個用例
• 後置條件：發生這個用例之後的結果，會産生哪些影響

那麼當我們翻譯成UML的語言時，配置就是定義前置條件和後置條件的系統功能。

那麼當我們判斷輸入物滿足什麼條件時，還是分兩類：

• 當輸入物存在時，即滿足條件。如：當OMS系統發出打印指令時，即調用配置中指定的打印機進行打印；
• 當輸入物的屬性和預設規則滿足時，即滿足條件。如：當ERP推送商品價格數據到OMS中，由于商品價格數據這一個輸入物的所屬類别分類屬性，滿足預設規則1，則自動加價5%；

當我們分析會産生哪些影響時，我們可以分三類：

• 邊界類：影響操作界面是否可查看可操作，或者接口是否可用。權限控制RBAC設計模型和接口的訂閱配置，就是典型的對邊界類造成影響的配置設計；
• 實體類：影響數據庫表，文檔或其他具有持久化特征的數據的格式、内容；如OMS系統設計中的審單功能中，會根據配置在訂單上加上贈品商品行；
• 控制類：影響控制程序，工作流，算法體是否起作用；如OMS系統中，訂單會根據配置來決定是否直接跳轉到某個狀态，如退單長時間未審核，則自動同意的配置

在複雜的B端系統中，我們往往發現一個業務無法用一個用例就描述清楚，導緻配置設計還是無法進行，如這個業務場景：

ERP将商品資料同步到OMS，OMS加工後，同步至各商城。

由于用例體現了參與者的願望，用例的執行結果應對參與者來說是可觀測和有意義的，那麼顯然，同步商品資料到各商城，對于業務的起點ERP來說，并不是其願望，也不可觀測，但是不存在沒有參與者的用例，用例不應該自動啟動。由于參與者可以是非人的，換句話說，參與者可以是用戶的一個指令，或者是上遊系統的通知，故我們往往将用例根據參與者的不同進行拆分。以筆者參與的OMS産品為例，我們根據長期的實踐，習慣根據參與者的不同，劃分為三種不同的用例。不同種類的用例，配置一般影響的類别也不一樣：

• 輸入用例：比如上遊訂單系統同步訂單至OMS、ERP系統同步商品資料至OMS。配置一般影響邊界類；
• 處理用例：比如訂單打印、訂單拆單合單、訂單履約、商品價格加價處理。配置一般影響控制類；
• 輸出用例：比如OMS輸出訂單發貨清單至ERP、OMS系統同步商品價格至上遊平台。配置一般影響實體類；

我們可以整理出下圖：

二、配置設計要求

上文我們了解了在給什麼在做配置，那麼一個好的配置應該滿足什麼條件呢？

第一：配置邏輯自洽

1、根據輸入物屬性識配自己的規則時，規則之間不能相互沖突；

我們拿商品價格策略配置舉例：

當我們識别商品的價格屬性去适配規則時，我們應使用MECE分析法，按照完全窮盡，相互獨立的原則，将屬性的枚舉值整理出來，當無法完全窮盡時，應設置默認規則；

2、配置與配置之間不能互相沖突；

我們仍拿商品價格策略配置舉例：通過識别商品的價格、所屬平台、所屬門店等屬性去适配規則時，可能會出現同一個商品同時滿足多個配置的情況；

這種情況下，我們需要先判斷多個配置是否可以疊加：

可以疊加：當對實體類進行配置設計時，一般策略是可以疊加的。在這種情況下，可以增加配置疊加規則，如設置上限\下限：加價策略都是以輸入的原價為基準進行加價，累次加價不能超過原價的8%

不可以疊加：需要增加策略沖突時的應用規則

• 應用最新的配置：适用最後更新的配置；
• 指定策略優先級：為配置分配優先級，在配置不可疊加時，選擇優先級最高的生效；

第二：配置變更有迹可循：重要的業務配置，需要提供配置變更日志查詢，記錄配置修改人與修改時間

第三：配置影響的前後數據對應：如果配置影響的是實體類的修改，則應在數據庫中記錄時，需記錄數據原值和配置影響後的數據，不應在同一個字段，用配置影響後的數據直接覆蓋原數據。實體類的新增則不需要；

第四：高拓展性：系統的能力建設是持續的，配置的設計可以延續标準的工作流程不斷拓展新增；

第五：配置規則可理解：需要提供必要的功能指引，配置規則的入口和操作方式需要符合用戶的認知；

第六：不同維度的繼承關系清晰：在不同維度設計同一個配置時，需要理清楚是否要繼承父輩維度的配置，一般要支持可配置是否要繼承繼承父輩維度的配置，以免造成修改此維度的配置後， 又因為繼承了父輩維度的配置，導緻修改配置不生效；

三、确定配置管理的維度

我們發現，存在配置需要對輸入物的多個屬性進行識别以決定應用哪個規則的情況，那麼我們配置的維度如何設計呢？

當我們隻有一項配置時，我們當然可以如下設計：

但是如果我們每次新增一個配置，就長出一個新頁面，很快就會發現：

用戶操作成本高，需要從大量的配置中，找到對應的配置進行操作；

配置設計拓展困難，每次新增配置，就要做一個新的頁面；

這時，我們可以查看一下系統的領域模型，找到輸入物的共同屬性，來組織配置功能的架構：

這時我們發現，雖然輸入物繁多，業務場景各不相同，但是他們都有一個共同的父類：渠道店鋪。如果此時，渠道店鋪作為輸入物的一個屬性，參與配置規則生效的匹配，則可以将渠道店鋪這個屬性抽離出來，作為配置管理的維度，如：

這樣做的好處是，用戶可以在一個頁面，完成多個配置，而不用不停的切換頁面。

我們也可以看到，渠道店鋪可以繼承渠道、渠道商家、商家、店鋪的配置，我們可以根據真實的業務訴求，以盡量減輕用戶配置負擔為目标，靈活的選擇配置的對象。

當某個用戶在配置時，一個屬性不同的枚舉值對應的規則一樣，例如期望所有美團渠道的店鋪都适用自動打印配置時，我們到最小的配置維度【渠道店鋪】去一個一個配置，無疑還是增加了用戶的操作成本。這時我們就可以考慮将其父類作為配置的維度，子類繼承父類的配置規則。

四、配置的入口怎麼設置

确認配置的入口，我們一般這麼做：

STEP1: 根據配置操作人确認在哪個系統上做配置；

STEP2: 根據業務用例上的參與者劃分不同的配置模塊；

STEP3: 根據配置維度，聚合配置功能；

STEP4: 易用性改造

以下為筆者負責的OMS系統中配置功能的統計（數據已脫敏）：

關于易用性改造，我們一般做以下事情：

在業務或數據相關頁展示配置入口；

利用接近原則，在業務或數據相關頁展示配置入口。利用接近原則是一個心理學名詞，指對于彼此接近的事物，人們總會下意識地将他們建立某種關聯性，并視為一個整體去看待。這麼設計可以減輕用戶的認知成本。例如：

将業務流程中配置形成SOP；

如一個商家的系統進行初始化時，需要進行履約相關配置、庫存價格策略配置、前台作業系統配置等，如果一個一個去找相關的配置，則學習成本較高，容易出現配置遺漏等情況，那麼我們一般将業務流程抽象為一個SOP，在SOP中，展示對應配置的入口。例如：

3、支持查詢配置

提供全局性的查詢功能，支持查詢對應的配置。例如：

五、示例：配置設計的流程

這天，運營給我反饋了一個問題，希望可以新增訂單自動打印的功能，以支持OMS系統在多個業務節點下，可自動打印小票，而不用店員再去手動點擊，而且要可以控制預約單在預約送達時間前1小時打印，由于門店使用的打印機型号不同，還要支持為不同的打印機配置不同的打印模闆。

我識别到此需求後，我按照以下工作流程，進行了配置的梳理：

STEP1: 識别參與者，抽象用例：抽象出用例，才能拆分配置功能。強行在一個配置裡，将所有業務規則都體現，是不現實的；

STEP2: 确定要配置的内容，确定配置的維度；

STEP3：根據配置的操作人和配置的維度，确認配置的入口；

最終可以整理出這個表格，接下來我們就可以根據這個表格、進一步梳理業務流程圖、整理原型、撰寫PRD了。

六、結語

配置設計紛繁複雜，今天我以實際的工作經驗，給大家介紹了我對B端配置設計的一些思考，希望可以給大家一些思路，并且引導大家思考功能設計背後的邏輯，權當抛磚引玉吧，畢竟抄競品簡單，但是競品因何發展成這個樣子，其中的邏輯判斷，與設計權衡，才是我們應該了解的。

本文由 @kathic 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,