做Saas經(jīng)常會遇到一個問題：我們希望功能做成標準化的產(chǎn)品，但客戶總有自己的個性化需求。這種情況，如何解決？這篇文章，作者給到了自己的解決方案，大家可以參考一下。

01 沖突與矛盾

相信不少做 ToB 產(chǎn)品的同學(xué)都會遇上這個問題：標準產(chǎn)品與客戶個性化需求之間的沖突問題。

在某個 ToB 端細分領(lǐng)域中，想在已有的項目或者行內(nèi)通用規(guī)范的基礎(chǔ)上，提煉出產(chǎn)品標品（還談不上是 SaaS），這樣在面對新的客戶時，可以實現(xiàn)低成本、快速高效地完成交付。

形成行業(yè)產(chǎn)品標品是降低項目產(chǎn)品成本的有效方式之一，也是我們作為產(chǎn)品人的心念。

可是，在形成產(chǎn)品標品之后，我們怎么滿足客戶個性化需求？在 ToB 產(chǎn)品，個性化的需求是在所難免的，這也是 B 端產(chǎn)品的魅力之一，否則各行業(yè)的 SaaS 產(chǎn)品早就統(tǒng)一了市場。

話又說回來，如果是增量的個性化，這種稍微好處理一點，我們在原有產(chǎn)品功能的基礎(chǔ)上增加功能就好。然而，有些個性化需求會破壞原產(chǎn)品的邏輯結(jié)構(gòu)，這種不管是產(chǎn)品設(shè)計層面還是軟件編碼實現(xiàn)層面，都很難做到協(xié)調(diào)與統(tǒng)一。

甚至有很多公司分為兩個開發(fā)團隊，一個團隊負責(zé)標準產(chǎn)品的開發(fā)，另一個開發(fā)團隊負責(zé)開發(fā)客戶定制化需求，這其中的成本不言而喻。

那有沒有什么產(chǎn)品架構(gòu)可以形成產(chǎn)品標品又可以滿足客戶各種定制化需求？有問題肯定有解決方案，這個問題困擾了我們團隊很久，在總結(jié)過往項目經(jīng)驗及團隊思想碰撞過后，得到了一個優(yōu)雅的解決方案。

02 應(yīng)用的繼承與重寫

在介紹方案之前，首先了解一下面向?qū)ο笾嘘P(guān)于“類”與“繼承重寫”相關(guān)的概念：

• 類：一種用于描述現(xiàn)實世界中具有共同屬性和行為的事物的模板，是對現(xiàn)實世界中某一類事物的抽象描述，包含了一組屬性和方法。屬性用于描述對象的狀態(tài)，方法用于定義對象的行為。
• 繼承：子類繼承父類后，子類就可以調(diào)用父類的屬性和函數(shù)，這樣子類無需重復(fù)實現(xiàn)已有的邏輯
• 重寫：子類繼承父類后，若父類的函數(shù)無法滿足需求，可以在子類中創(chuàng)建一個同名的函數(shù)，在子類的函數(shù)中實現(xiàn)個性化需求，在實際執(zhí)行時會執(zhí)行子類的函數(shù)而不是父類的函數(shù)。

了解上面的概念后，我們知道了“類”其實是對有共同特征的事物的抽象表達，而繼承是為了方便復(fù)用，重寫可以優(yōu)雅地解決個性化需求。

那如果我們將一個業(yè)務(wù)應(yīng)用當(dāng)成一個“類”，業(yè)務(wù)應(yīng)用之間也支持繼承與重寫，這樣是不是就可以解決標品與個性化需求之間的沖突問題？

我們沿著這個思路再深入探討，假設(shè)我開發(fā)了一個相對標準的 CRM （客戶關(guān)系管理）系統(tǒng)：

1）如果客戶沒有個性化需求，就用標準的 CRM 交付；

2）如果客戶有個性化需求，就新建一個應(yīng)用繼承于標準的 CRM ：

• 通用的部分就使用標準的 CRM，不需要重復(fù)開發(fā)；
• 有新增的功能需求，比如加一個【客戶來源分析報表】的功能，這樣的功能并沒有破壞標準 CRM 的結(jié)構(gòu)，我們在新建的應(yīng)用中實現(xiàn)就可以的了，如果很有客戶都有這個功能的需求，我們再將這個功能加到標準 CRM 中；
• 需要對標準 CRM 中有些功能做調(diào)整，比如【客戶跟進】，客戶跟進的流程有定制化的需求，就在新建的應(yīng)用中重寫這部分的功能

初步的設(shè)想好像是可行的。

但是，要注意的是，“類”的內(nèi)部結(jié)構(gòu)（屬性和函數(shù)）是有一定標準的，繼承與重寫本質(zhì)是利用“類”的屬性和函數(shù)，對應(yīng)地，業(yè)務(wù)應(yīng)用內(nèi)的結(jié)構(gòu)也需要有一定的標準和規(guī)范，這樣才能和“類”一樣繼承與重寫。

那問題來了，怎么定義應(yīng)用內(nèi)的結(jié)構(gòu)呢？

03 解構(gòu)業(yè)務(wù)應(yīng)用并模塊化

長期設(shè)計具體的產(chǎn)品功能需求容易陷入繁瑣的細節(jié)問題而難以站在更高的維度重新審視產(chǎn)品結(jié)構(gòu)，這是很多產(chǎn)品人面臨的窘境。不管是為了產(chǎn)品的健壯性還是為了個人的發(fā)展，都很有必要時不時地用頂層設(shè)計思維重新思考產(chǎn)品。

在分析了大量業(yè)務(wù)應(yīng)用后，我們發(fā)現(xiàn)，業(yè)務(wù)應(yīng)用基本都是由菜單功能、導(dǎo)航框架、業(yè)務(wù)流程、后臺數(shù)據(jù)邏輯、任務(wù)、事件訂閱等模塊組成，當(dāng)然，不是所有的模塊都是必需的，根據(jù)應(yīng)用的實際業(yè)務(wù)需要可做對應(yīng)的調(diào)整。如此拆解之后，我們自然而然地就想到了將應(yīng)用模塊化，模塊之間盡量解耦，但同時需要提供一種機制保證各模塊之間可以相互通信，比如功能之間可以相互跳轉(zhuǎn)，在菜單功能中可以調(diào)用后臺數(shù)據(jù)邏輯，在業(yè)務(wù)流程中可以觸發(fā)事件訂閱等等。

模塊化的顆粒度可以根據(jù)實際的業(yè)務(wù)應(yīng)用來做劃分，我這里是將低代碼平臺作為業(yè)務(wù)應(yīng)用開發(fā)的解決方案。如果是純業(yè)務(wù)應(yīng)用，可以換一種思路將應(yīng)用模塊化，比如按照功能的維度，訂單模塊、用戶模塊、系統(tǒng)模塊等等，每個功能模塊包括前端頁面、數(shù)據(jù)表結(jié)構(gòu)、數(shù)據(jù)流轉(zhuǎn)邏輯等等，利用功能來劃分，也需要做到模塊與模塊之間盡量解耦，模塊之間不要有太多的耦合。

將應(yīng)用模塊化之后，我們再將模塊類比于面向?qū)ο缶幊趟枷胫械摹邦悺?，這樣應(yīng)用之間的繼承就可以具體到應(yīng)用內(nèi)模塊的繼承，實際的業(yè)務(wù)實現(xiàn)本身也是落實到應(yīng)用的模塊中。

04 方案實踐與落地

當(dāng)然上面介紹的還只停留在方案思維層面，而在實際操作中，不管是在產(chǎn)品開發(fā)框架還是產(chǎn)品設(shè)計架構(gòu)上都有很大的挑戰(zhàn)，需要保證框架有足夠的靈活性和擴展性。

我們前期投入大量的精力來建設(shè)底層基座平臺，包括應(yīng)用開發(fā)、應(yīng)用模塊化、提供應(yīng)用繼承機制、應(yīng)用商城、應(yīng)用安裝部署、應(yīng)用可視化運維等能力。

在應(yīng)用開發(fā)維度，我們將業(yè)務(wù)應(yīng)用中的模塊抽象為不同類型的元素，比如頁面元素、數(shù)據(jù)表元素、后臺任務(wù)元素、業(yè)務(wù)流程元素等等，元素支持繼承與重寫?；诓煌愋偷脑貏?chuàng)建的實例元素（一個對象就是“類”實例）組成一個業(yè)務(wù)應(yīng)用，對于后續(xù)的擴展，增加元素類型就可以了。

利用這些元素開發(fā)好一個標準 CRM 系統(tǒng)并上傳到官方應(yīng)用商城作為應(yīng)用模板，沒有個性化需求的客戶直接從應(yīng)用商城安裝就可以了，若有個性化需求，新建一個空白的應(yīng)用繼承于標準 CRM 系統(tǒng)

這樣在面對下面這場的個性化需求就可以從容應(yīng)對了：

• 在客戶表新建再加一個字段，重寫【客戶表】數(shù)據(jù)表模型即可；
• 增加線索合并邏輯，重寫【線索合并】頁面邏輯即可；
• 增加一個跟進分析的功能，在新建的應(yīng)用中增加一個功能即可；
• …

從產(chǎn)品上線到現(xiàn)在， 2 個月不到的時間就解決了幾十個有定制化需求的客戶問題。雖然平臺建設(shè)的前期成本會比較大，但在后續(xù)的項目交付中，極大地提升了項目交付效率并優(yōu)雅地解決了標準產(chǎn)品與客戶個性化需求之間的沖突問題。

當(dāng)然肯定還有很多優(yōu)雅的方案可以解決產(chǎn)品標品與客戶個性化需求之間的沖突問題，如果你對這方面感興趣，歡迎可以在評論區(qū)留言或者私信，好的方案都是在溝通碰撞中乍現(xiàn)的！