數棧產品分享：乾貨解讀資料中臺產品「模組化」設計思路

一、前言

在做企業服務類(ToB)的產品時，我們經常會遇到如下場景：

每個客戶拿著他們的需求清單，來諮詢我們的產品是否可滿足他們的訴求。如圖所示：

每個客戶的需求有重疊的內容，也有不一樣的內容，而這些需求，在某一領域均具有較強的通用性。

如何滿足這些客戶需求的同時又能使各個需求沉澱為標準功能，而不僅僅是為了交付專案？這成為ToB類產品經理思考最多的問題。

為支撐客戶訴求，基本的做法是抽象各個需求，落地為標準功能，將各個功能拼裝成一個產品。但是一段時間後大家就會發現功能越堆越多、產品越做越龐大，但是使用者體驗卻越來越差，產品開發維護越來越困難。
如何既能滿足客戶訴求，又能解決產品存在的這些問題？模組化設計是一個方向。後面我們展開介紹下，數棧在模組化設計方面的一些經驗供參考。

二、 模組化設計介紹

（一）目的

• 從商務銷售的角度說，產品模組可自由組合報價，貼合不同客戶的需求，提高產品銷售的成單率。
• 從產品研發的角度說，減少重複造輪子的現象，提高研發效率和產品擴充套件性。

（二）落地經驗
模組化設計在數棧平臺的落地實施，從大到小主要分為下面三種方式：

• 子產品化
• 公共模組
• 元件/外掛化開發

1、子產品化
1）需求背景：
每個客戶，甚至同一個客戶在不同階段，對資料中臺的理解都不盡相同。

• 比如客戶A是個中等規模企業，希望能有款產品幫助他建設離線數倉，滿足基本的資料開發訴求，那數棧的離線開發模組就可以滿足他們的訴求。
• 比如客戶B是個大型的集團企業，希望能從資料開發、資料服務、資料治理等多個方面搭建起集團資料中臺，那就得輸出一整套數棧去滿足該客戶。

2）設計思路：

• 產品上——根據業務邏輯，各個模組獨立解耦，定位升級為子產品，負責解決不同的業務場景訴求。
• 商務上——銷售時可單獨報價輸出，也可組合報價輸出。

3）落地成果：
數棧作為一款資料中臺產品，其中包含了：離線開發、實時開發、演算法開發、資料服務、資料資產、資料質量、智慧標籤等子產品，每個子產品可解決不同的業務場景訴求，並支援獨立、組合部署。

2、公共模組
1）需求背景：
數棧的各個模組獨立化成子產品後，雖然可以解決不同的業務場景訴求，但是在資料中臺這個框架內，仍然會存在一些相同的基礎功能訴求，比如使用者體系、資料來源管理、任務運維等。如果每個子產品內部獨立實現，會存在兩個問題：

• 增加了使用者的使用成本。比如相同的使用者、相同的資料來源需要在各個子產品內多次維護，而且還容易造成理解歧義。
• 增加了產品的研發成本。相同的功能需要重複實現，重複造輪子，浪費研發資源和運維成本。

2）設計思路：

• 剝離各個子產品中的通用功能作為公共模組，統一進行維護管理，然後為各個子產品提供服務。
• 公共模組的設計需要充分調研各個子產品的訴求。對於通用訴求，抽象出標準功能；對於擴充訴求，提供配置化功能；對於個性訴求，由子產品自行實現。

3）落地成果：

3、元件/外掛化開發
1）需求背景：
如果說前兩部分的模組化設計是對產品經理能力的考驗，那這部分內容更多是對開發人員的要求。

下面介紹我們在日常工作中遇到過三個問題場景：
a、產品設計時，需要新增一個輸入框，要求是：屬於必填項、內容格式限制中英文、長度限制255字元。

需求很簡單，但是每次評審時，產品經理都得給研發說明如果為空時怎麼提示、內容不符合格式要求時怎麼提示、長度超過限制時怎麼處理，溝通成本極大，而這僅僅是整個原型設計中1%都不到的內容。

b、產品設計時，需要複用另一個模組中的表單，表單中維護的各個表單項、表單項關聯邏輯均相同。
功能完全一致，但是研發調研後發現，原有的表單處理邏輯和業務處理邏輯強耦合，導致表單程式碼無法複用，需要重新獨立開發。

c、在產品迭代過程中發現存在一類需求，更新相對頻繁，需求邏輯具有一定共性，而且更新不會涉及已有功能的改動。
這類需求對於開發，和公共模組之於產品類似，可以抽象為一種公共技術能力對外提供服務。比如我司經常會遇到的需求有：新增支援一種資料來源、引擎新增一種任務型別等。

2）解決方案：

• 前端沉澱標準元件庫。對於一些常用的設計，透過元件複用來減少開發和產品的工作量；目前我們已沉澱30+前端元件，並在持續迭代中。
• 程式碼的低耦合設計。這部分要求比較虛，而且沒有非常明確的邊界，依賴開發經驗和對業務的理解，需要持續成長。
• 外掛化設計。區分應用層程式碼和底層程式碼，底層程式碼進行外掛化封裝，可為上層不同的應用提供支援，在支援快速迭代的同時又不會影響已有功能，這樣應用層開發可以投入更多地精力去支援業務。目前已落地：資料來源外掛、資料同步外掛、Engine外掛、血緣解析外掛。

三、 總結思考

模組化設計是一種解決方案，並不是最終目的，因此，在產品設計時不能為了模組化而模組化。尤其是產品初期，此時產品功能並不豐富，而且為了快速迭代搶佔市場，並不適合投入較多的精力去做這個事情。但是一旦產品進入穩定發展期，產品經理和研發同學都應該開始思考模組化設計在日常工作中的應用了。

模組化設計並不是產品換個名稱、獨立做個頁面就是模組化了，業務層面如何劃分、模組之間如何配合、外掛剝離的邊界在哪，程式碼邏輯怎麼解耦等等，這些都是需要思考的地方。