做Saas经常会遇到一个问题：我们希望功能做成标准化的产品，但客户总有自己的个性化需求。这种情况，如何解决？这篇文章，作者给到了自己的解决方案，大家可以参考一下。

01 冲突与矛盾

相信不少做 ToB 产品的同学都会遇上这个问题：标准产品与客户个性化需求之间的冲突问题。

在某个 ToB 端细分领域中，想在已有的项目或者行内通用规范的基础上，提炼出产品标品（还谈不上是 SaaS），这样在面对新的客户时，可以实现低成本、快速高效地完成交付。

形成行业产品标品是降低项目产品成本的有效方式之一，也是我们作为产品人的心念。

可是，在形成产品标品之后，我们怎么满足客户个性化需求？在 ToB 产品，个性化的需求是在所难免的，这也是 B 端产品的魅力之一，否则各行业的 SaaS 产品早就统一了市场。

话又说回来，如果是增量的个性化，这种稍微好处理一点，我们在原有产品功能的基础上增加功能就好。然而，有些个性化需求会破坏原产品的逻辑结构，这种不管是产品设计层面还是软件编码实现层面，都很难做到协调与统一。

甚至有很多公司分为两个开发团队，一个团队负责标准产品的开发，另一个开发团队负责开发客户定制化需求，这其中的成本不言而喻。

那有没有什么产品架构可以形成产品标品又可以满足客户各种定制化需求？有问题肯定有解决方案，这个问题困扰了我们团队很久，在总结过往项目经验及团队思想碰撞过后，得到了一个优雅的解决方案。

02 应用的继承与重写

在介绍方案之前，首先了解一下面向对象中关于“类”与“继承重写”相关的概念：

• 类：一种用于描述现实世界中具有共同属性和行为的事物的模板，是对现实世界中某一类事物的抽象描述，包含了一组属性和方法。属性用于描述对象的状态，方法用于定义对象的行为。
• 继承：子类继承父类后，子类就可以调用父类的属性和函数，这样子类无需重复实现已有的逻辑
• 重写：子类继承父类后，若父类的函数无法满足需求，可以在子类中创建一个同名的函数，在子类的函数中实现个性化需求，在实际执行时会执行子类的函数而不是父类的函数。

了解上面的概念后，我们知道了“类”其实是对有共同特征的事物的抽象表达，而继承是为了方便复用，重写可以优雅地解决个性化需求。

那如果我们将一个业务应用当成一个“类”，业务应用之间也支持继承与重写，这样是不是就可以解决标品与个性化需求之间的冲突问题？

我们沿着这个思路再深入探讨，假设我开发了一个相对标准的 CRM （客户关系管理）系统：

1）如果客户没有个性化需求，就用标准的 CRM 交付；

2）如果客户有个性化需求，就新建一个应用继承于标准的 CRM ：

• 通用的部分就使用标准的 CRM，不需要重复开发；
• 有新增的功能需求，比如加一个【客户来源分析报表】的功能，这样的功能并没有破坏标准 CRM 的结构，我们在新建的应用中实现就可以的了，如果很有客户都有这个功能的需求，我们再将这个功能加到标准 CRM 中；
• 需要对标准 CRM 中有些功能做调整，比如【客户跟进】，客户跟进的流程有定制化的需求，就在新建的应用中重写这部分的功能

初步的设想好像是可行的。

但是，要注意的是，“类”的内部结构（属性和函数）是有一定标准的，继承与重写本质是利用“类”的属性和函数，对应地，业务应用内的结构也需要有一定的标准和规范，这样才能和“类”一样继承与重写。

那问题来了，怎么定义应用内的结构呢？

03 解构业务应用并模块化

长期设计具体的产品功能需求容易陷入繁琐的细节问题而难以站在更高的维度重新审视产品结构，这是很多产品人面临的窘境。不管是为了产品的健壮性还是为了个人的发展，都很有必要时不时地用顶层设计思维重新思考产品。

在分析了大量业务应用后，我们发现，业务应用基本都是由菜单功能、导航框架、业务流程、后台数据逻辑、任务、事件订阅等模块组成，当然，不是所有的模块都是必需的，根据应用的实际业务需要可做对应的调整。如此拆解之后，我们自然而然地就想到了将应用模块化，模块之间尽量解耦，但同时需要提供一种机制保证各模块之间可以相互通信，比如功能之间可以相互跳转，在菜单功能中可以调用后台数据逻辑，在业务流程中可以触发事件订阅等等。

模块化的颗粒度可以根据实际的业务应用来做划分，我这里是将低代码平台作为业务应用开发的解决方案。如果是纯业务应用，可以换一种思路将应用模块化，比如按照功能的维度，订单模块、用户模块、系统模块等等，每个功能模块包括前端页面、数据表结构、数据流转逻辑等等，利用功能来划分，也需要做到模块与模块之间尽量解耦，模块之间不要有太多的耦合。

将应用模块化之后，我们再将模块类比于面向对象编程思想中的“类”，这样应用之间的继承就可以具体到应用内模块的继承，实际的业务实现本身也是落实到应用的模块中。

04 方案实践与落地

当然上面介绍的还只停留在方案思维层面，而在实际操作中，不管是在产品开发框架还是产品设计架构上都有很大的挑战，需要保证框架有足够的灵活性和扩展性。

我们前期投入大量的精力来建设底层基座平台，包括应用开发、应用模块化、提供应用继承机制、应用商城、应用安装部署、应用可视化运维等能力。

在应用开发维度，我们将业务应用中的模块抽象为不同类型的元素，比如页面元素、数据表元素、后台任务元素、业务流程元素等等，元素支持继承与重写。基于不同类型的元素创建的实例元素（一个对象就是“类”实例）组成一个业务应用，对于后续的扩展，增加元素类型就可以了。

利用这些元素开发好一个标准 CRM 系统并上传到官方应用商城作为应用模板，没有个性化需求的客户直接从应用商城安装就可以了，若有个性化需求，新建一个空白的应用继承于标准 CRM 系统

这样在面对下面这场的个性化需求就可以从容应对了：

• 在客户表新建再加一个字段，重写【客户表】数据表模型即可；
• 增加线索合并逻辑，重写【线索合并】页面逻辑即可；
• 增加一个跟进分析的功能，在新建的应用中增加一个功能即可；
• …

从产品上线到现在， 2 个月不到的时间就解决了几十个有定制化需求的客户问题。虽然平台建设的前期成本会比较大，但在后续的项目交付中，极大地提升了项目交付效率并优雅地解决了标准产品与客户个性化需求之间的冲突问题。

当然肯定还有很多优雅的方案可以解决产品标品与客户个性化需求之间的冲突问题，如果你对这方面感兴趣，欢迎可以在评论区留言或者私信，好的方案都是在沟通碰撞中乍现的！