提升B端产品灵活性最重要的手段——配置化

编辑导语：不同于C端产品面向大众，B端产品是面向企业用户的产品，是用来解决企业需求的，因而实现界面的可配置化成为提升B端产品灵活性的必要要求。本文作者从自身工作实践出发，对此展开了分析说明， 与大家分享。

为了应对更多的业务场景，较低成本的满足丰富多变的业务需求，B端产品在设计之初就要考虑较高的灵活性，这是B端产品设计中最重要的原则之一。

然而，当面对具体业务场景时，B端产品经理们很容易按照已明确的需求，做成固化的方案，从而导致开发同学在实现时代码都“写死”了，后面再想做些啥改动，真是难如登天。

要想达到B端产品较高灵活性的目标，需要从产品架构、实现方式、功能设计多个层面共同支持，作为产品经理，主要从功能设计层面进行思考。

此篇作为本系列开篇，先帮助大家建立全局认知。

01 如何提升灵活性？

总体来说，从功能设计上提升灵活性有两种思路：

第一：预测需求

即我们思考一个需求方案时，同时预测未来业务中可能发生的多种场景，并提前做好普适方案。

这种方式在一定程度上可以提升产品灵活度，但局限性也很强：

• 一方面需要产品经理对业务有非常深入的了解，才能预测得比较精准；
• 另一方面能够提前设想的场景是有限的，因此方案普适范围也是非常有限的，不可能做到完全灵活。

所以这条思路主要应用于需求场景较少且容易明确的功能。

第二：配置化

第二种思路就是我们这个系列要介绍的主角——配置化。将产品功能做成灵活可配置，通过不同配置的组合，来满足业务中各种“意想不到”的需求。

接下来进入正题。

02 什么是功能配置化？

不同的角度定义有所区别，从产品设计层面看：

功能配置化是用户通过 可视化的界面 ，采用 无代码 或 低代码 的方式，即可快速配置出满足自身需求的功能。

用人话翻译一下就是：用户直接通过系统界面就能配置出自己想要的功能，而不用找开发小哥排猴年马月的期。

大多数B端同学或多或少都接触过一些产品功能的配置化，小到一个自定义字段、列表排序，大到一个流程，乃至整个系统，都可以做成可配置的。

一些aPaaS厂商，如国内的明道云、简道云、氚云等，企业用户通过可视化的系统页面，无需代码即可从零搭建出许多业务逻辑较简单且通用的企业级应用。Tips：

aPaaS：全称是application Platform as a Service，即应用平台即服务，用于支持应用程序直接通过PaaS（平台即服务）开发、部署和运行，包括数据对象、权限管理、用户界面等。

因为是以SaaS的形式提供给企业用户，同时又具有开发工具（即PaaS）的性质，所以把它单独列为了aPaaS，可以理解为是一种介于PaaS与SaaS之间的形式。

前段时间陈果和任向晖两位大佬关于“低代码”的辩论，针对的就是这个。

那么无代码和低代码又是指的什么呢？

• 无代码是指用户在配置过程中不需要使用任何一种开发语言即可完成全部配置；
• 低代码是指用户在配置过程中需要自己写一些简单的代码，例如某些接口或SQL语句，主要应用于非常个性化的需求场景，大多数情况下是不需要的。

03 配置化的组成

那么一个完整的功能配置化包含哪些方面呢？要回答这个问题，需要从一个B端产品最基本的组成部分出发。

大部分的B端产品都可以抽象为以下四个部分组成（有的只有其中几项）：

• 业务数据管理
• 工作流执行与管理
• 分析图表
• 基础信息

而一个全面系统的功能配置化方案，就是针对这四个部分进行的，当然，这个粒度太粗了，没有办法直接做配置，我们再细化一下。

业务管理的配置化包括：

• 业务数据配置
• 业务逻辑配置
• 页面布局配置
• 辅助功能配置

工作流的配置化包括：

• 业务流程配置
• 审批流程配置

分析图表配置化包括：

• 可视化图形配置
• 统计表配置

基础信息配置化包括：

• 用户、组织配置
• 角色配置
• 权限配置
• …

我们用下图整理一下：

图1 功能配置化的组成

从这张图中大家可以看出，功能配置化是个系统且庞大的工程，涉及到产品的方方面面，想要做好，需要投入巨大工作量，因此关于配置化的思考越早越好，拖得越晚，产品越臃肿复杂，所需付出的成本越高，当产品复杂到一定程度后，最后会发现与其在现有产品的基础上做配置化，还不如重做。

04 配置化的步骤

无论做哪方面功能的配置化，都可以总结为以下三大步：

图2 配置化三大步

4.1 抽象

抽象是指提炼出你要配置功能包含哪些对象，即这个功能有哪几个组成部分，例如页面布局的配置，可以抽象出页面元素、位置、大小、颜色、样式几个对象，我们的配置化，就是针对这些对象进行的。

图3 页面布局抽象配置对象

在抽象配置对象时，有以下几条重要原则：

第一：根据需求进行抽象

一般来说，在没有其他要求的前提下，抽象出的对象也应该满足MECE原则，即这些对象组合起来就能形成最终的完整功能，同时这些对象相互间没有交叉。

不过在实际功能设计中，我们其实只需要根据具体需求，抽象出需要做配置的对象即可，例如需求只是想换个皮肤，那只需要抽象出“颜色”做成可配置就行了；如果需求是想做页面元素可以调整区域，那只需要抽象出“位置”。

第二：明确抽象对象间关系

抽象出的几个配置对象虽然独立，但不是毫无关联，需要思考清楚这些对象之间的关系是什么，相互之间是如何影响的，例如位置、颜色、大小、样式都是在元素的基础上实现的，先有页面元素，才有其他的配置，这个关系就会影响到我们设计这个功能时，需要考虑顺序、主次。

第三：不同的功能配置化抽象方式不同

很多同学一说到配置化，首先想到的就是模块化，以至于将这两者等同起来了，其实这是片面的认识，例如前面说的页面布局的配置，用的就不是模块化的原理。

模块化本质是一种从业务角度，对业务数据做的内聚和解耦，所以模块化的抽象方式适合业务数据和业务逻辑的配置，但并非适合所有的功能配置。

当配置对象抽象出来后，需要针对它们进一步的细化——分解。

4.2 分解

分解是对配置对象再次细化，以达到最小粒度。做好配置化最重要的一环，就是确定好最小粒度。

什么是最小粒度？在功能配置化场景中，最小粒度是指产品中有完整功能意义的最小组成单位。

在这个定义中，最小组成单位比较好理解，不过前面有个修饰语——有完整功能意义。

那么怎样才算完整功能意义呢？在不同的配置化场景中，这个结论还不一样，举个例子：在业务数据的配置化场景中，对某个业务数据的增删查改，从功能角度可以定义为四个功能（最小粒度），但这样定义对用户来说没有任何意义，也不完整，因为新增完了啥也干不了，看都不能看，那有什么意义呢，而真正有意义的是一个业务数据完整的增删查改合集，这个才是业务数据配置化的最小粒度。

但是，在角色权限的配置化场景中，增删查改就可以定义为四个不同的最小粒度，因为这四个功能对应四个权限，不同角色或用户的权限就是有区别的，所以在这个场景中增删查改就是四个最小单位。

所以，我们在定义最小粒度时要结合配置化场景来看。

4.3 重组

将前面分解后的最小粒度按不同规则排列组合，进行重组，就能配置出新的一套功能出来了。

到这里，关于配置化基础认知方面的介绍就完了，接下来文章将进入实操干货部分，来告诉大家这些配置化具体怎么做。

下一篇：业务数据配置化

 

作者：周翔；公众号：周翔Fly；个人微信：zhouxiangxgg

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

题图来自 Unsplash，基于CC0协议。