对SaaS系统而言，推崇的就是“按需购买”，依据用户的实际需求为用户配置对应的功能。但SaaS的多租户模型决定了系统不可能参照传统软件模式，在为用户部署时去掉不必要的功能。为适应多变的用户需求，SaaS软件只能实现功能可配置。那么SaaS如何才能做到功能可配置呢？

一、划分原子功能

所谓的原子功能也就是系统最小的组成单位，原子功能与原子功能间相互独立，互不重叠，所有的原子功能具有如下原则：

• 每个功能都具有价值
• 每个都不可细分
• 功能间互不重叠
• 功能间不循环依赖
• 整个系统功能是完整的

划分原子功能的最基本原则就是“每个功能都具有价值“，而且这种价值是相对用户而言的。只有对用户具有价值的功能才会被用户购买。

例如新建账号时，系统会对管理员输入的手机号及信息进行验证，但这种验证只是新建账号的一个步骤，并不能为用户带来任何价值，也就不能划分成单独的一个原子功能。

除关注功能所具有的价值外，划分原子功能时，需基于既定功能架构尽量细化，做到每个划分的原子功能都是不可细分的。例如针对表单的录入，用户在创建时往往会区分新建表单和提交表单，这两个操作对用户而言都是具有意义的，所以划分原子功能时，拆分新建表单和提交表单两个原子功能，会更清晰，更灵活。

在进行分解时，还需要关注原子功能之间的关联关系，做到不可细分，互不重叠。

注意，功能的分解需要保持系统的完整性，也就是说，划分出来的所有原子功能，要覆盖整个系统的功能，而不存在没有被划分的系统功能，确保系统功能的完整性

二、功能定义及依赖

在实际操作过程中，作为产品人员，还需要对划分的原子功能进行定义和建立原子功能间的依赖关系。

所谓功能定义其实就是对原子功能进行描述，定义它的名称，关键字，内容等相关信息。其中名称和内容便于对原子功能进行详细的描述，而关键字，重在对该原子功能进行唯一标识，在系统上需要时刻确保改该标识的唯一性。

除对原子功能进行描述，在划分过程中我们会发现，并不是所有的原子功能都可单独使用，有些功能需要依赖其他功能才能使用，功能与功能间存在一定的依赖关系。

例如，很多B端管理系统都具有“查看操作日志”这种功能，但“查看操作日志”往往依赖于“查看数据列表”，如果租户没有购买“查看数据列表”这个功能，那“查看操作日志”也是不能使用的。

所谓的功能依赖，就是指一个功能在没有另外某些功能的情况下是不能使用的 。

三、功能包设计

通过划分原子，对原子功能进行定义，及设计原子功能的依赖关系。我们基本实现了对系统功能的梳理，回到我们的出发点：为应对客户的“按需购买”而实现功能的可配置。

但其实，光具有原子功能，并不能高效的实现功能的可配置。

通过逐步细化及划分，系统原子功能数量急剧增加，可达到几十个，甚至可达到上百个。直接对这些原子功能进行管理是超级复杂的事情。而且这些原子功能之间的使用并不是完全独立，很多功能操作是相关。

例如客户的新建，查看，编辑，删除这些功能都是一起使用，往往不存在单独使用的情况。并且在前一步中我们也了解到，划分的原子功能之间是存在依赖关系的，而这些具有依赖关系的原子功能总是绑定起来一起使用，从使用场景也可以看出，具有相同使用场景的原子功能不是具有操作关联性就是具有依赖性。

所以在原子功能的基础上，整合具有操作关联性及依赖性的原子功能，以功能包的形式统一管理是十分有必要的。

所谓的功能包就是一组具有关联性，依赖性的原子功能的集合体，功能包的设计遵循高内聚，低耦合的原则，具有关联性的原子功能聚合在一起，而功能包与功能包尽量减少依赖关系，进而保证每个功能包都尽可能单独的进行操作使用。

四、定义销售包

功能包已经将具有关联性的原子功能集合在一起了，但对于客户而言，定义好的功能包仍不能单独使用。所以为了让客户购买后能够充分使用系统，还需要按不同的商业意图构建适合用户使用销售包。

销售包只是一种以向用户销售而定义功能包。例如但凡成型的SaaS应用都会有最小版，标准版，完整版。或存在按客户所属行业而定义的服务行业版，制造行业版等。这些都可以称之为销售包。

五、功能使用校验

在前面已经定义了原子功能，功能包，销售包。在实际使用过程中，对用户操作权限的校验还是基于原子功能的，通过验证改用户是否具有改原子功能的操作权限，进而实现系统功能权限的控制。

上述基本是针对功能可配置的大致简述，因为工作的需要，在不断实践及学习SaaS产品架构，前期已推出《SaaS可配置：数据可配置》，后期将会根据实际需要，不断完善。

本文由 @老鬼 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议