时间: 2021-07-30 13:03:07 人气: 7 评论: 0
编辑导语：短短的一年间，许多企业都把风口朝向低代码产品发展。传统企业舍弃Sass，投向“逆熵”能不能行得通？作者从六个方面进行了分析，我们一起来看下吧。
2020年钉钉宣布宜搭加入“钉原生”生态圈，成为了低代码在中国市场风光无两的时刻，也把“低代码”这个产品概念丢到了所有IT从业者面前。
从资本到各大企业战略决策层，都嗅到了风口的味道。短短一年间，电商企业、民宿企业、智能家居企业、传统SaaS企业、金融企业纷纷下注低代码，但很多企业的战略选择，止步于既有的舒适区隔靴搔痒，正在给自己铺就一场巨大的隐患局，随时都有可能成为下一个被人玩味的产品“小败局”。
讨论低代码产品之前，我们需要先来限定一下范围。如果回归本质，低代码绝对不是一个什么革命意义的新鲜概念，只是一个随着计算机编码技术发展，技术不断下放“平民化”的过程。
举例来说，相较于原生编写CSS、JS的前端编码模式，Elements这样的组件化封装就是一种低代码；同样的，一些交付企业自己定义的DSL标记语言，相较于直接编写Java代码，也是一种低代码。
诚然，这些都是低代码领域的不同赛道，但往往以开源或内部封闭生态的交付提效工具为定位，产品商业化价值相对有限，我们在此也就不做赘述。
我们要讨论的是以“搭建一个完整可用应用、提供完整运行可用交付环境”为目标的快速应用开发（RAD）PaaS产品。
Gartner在2020年魔力象限中定义在领导者（Leaders）象限的Salesforce、OutSystem、Mendix、Microsoft、Appian、ServiceNow无一例外均为此类产品。
如果我们把目光转回国内市场，可以发现一线大厂也基本选择了这个路线：阿里的宜搭、云凤蝶、华为的AppCube、**的微搭。虽然在能力层定位上略有不同，但基本的战略规划趋同，以后可以单开一帖对比一下他们彼此的异同。
熵，作为一个热力学概念，大家应该并不陌生，用来描述一个系统的混乱程度。除了描述一些物理现象，熵的概念一定程度上可以解释这个世界发展的客观规律——这个世间万物都**本能的朝越来越混乱的方向发展——这就是熵增原则。
仔细想想刚入住的新家是不是宽敞整洁，几年之后是不是四处都是难以断舍离的混沌景象。
回到我们IT从业者每天面对的软件应用，如果加上一个时间线来观察TA，是不是也是越来越复杂、越来越混沌。回想一下你经手的那些项目，随着从0到1、从1到N，是不是越来越复杂，当然，我们主观不愿承认，在变复杂的同时也越来越“混乱”。
我曾经经手过一个内容管理系统的重构项目。10年前，这个项目设计初衷，就是一个标准到不能再标准的CMS内容管理系统。
这在十年间，需求提出团队换了一拨又一拨，开发执行团队也换了一个又一个，项目从标准的CMS系统，新增了协作、分级审批、项目管理以及人事管理等一系列功能，项目越来越“混沌”。
十年之后的今天，已经没有哪个人可以讲得清这个项目的真正全景，也因此要想抽丝剥茧理出个头绪简直是困难重重。
做过这种老旧系统重构改造的朋友应该知道，这个例子只是窥斑见豹。一个软件系统的迭代发展就是一个十分典型的“熵增”过程。
经过几年迭代早已和最初的规划相去甚远，还记得最早的微信，是一个只可以进行文字信息收发的IM软件，再看看今天的微信社交、内容分发、金融、电商、应用分发，已经是一个十足的“混沌系统”。
熵增，是系统发展的必然规律，与产品领域规划无关、与产品团队的能力无关、与企业战略规划无关。
因此，作为一个“搭建应用的应用”，低代码平台的建设规划需符合这一客观规律。
在各显神通的低代码市场，也的确有一些团队基于自己的业务背景，进行了通过“逆熵”将产品“低代码化”的尝试。
这些团队背景，基本毫无疑问是SaaS产品出身，做低代码的初衷也很简单，就是通过配置化，替代不同项目交付的重复编码工作。
Odoo、Zoho和OpenERP是这个赛道比较典型的代表。
Odoo在企业开源应用领域曾经风靡一时，起家于ERP领域，随着市场拓展陆续在ERP、CRM、PLM领域有了较强的产品积累，为了更灵活的拓展产品边界，提供给用户灵活的企业应用解决方案，Odoo给出了自己的“低代码”答卷。
依托自己建设多年的开源软件生态，Odoo在自己的低代码平台Odoo Studio中整合了丰富的功能模块，共用户来“拼装”新的应用。
不同于通用低代码平台将最小模块拆分到组件力度，Odoo的功能模块更像是一个个独立的应用，例如记账、用户管理、MRP、PLM、设备管理、质量管理等模块。
对于用户，可以使用这些现有的应用拼装出一个自己所需的工作台，但如果现有的这些应用并不能满足你的需求，那么，则需要通过开源框架，用代码开发的形式编写一个新的应用模块。
同样，如果你需要让这些工作台上的应用协同起来，只能自己编写函数调用或者直接通过开源框架针对这些应用模块进行代码层面的二次开发。
从搭建应用的角度，Odoo应用市场的全部应用模块就是它的能力边界，Odoo Studio可以完成针对现有应用的拼装，但无法通过低代码拼装的形式产生一个全新的应用。
同样，某国产BPM厂商也交出了与Odoo类似的答卷。他们抽取自己BPM产品交付项目过程中一些常用的功能模块，以供之后进行复用，但由于本身提取的模块抽象程度不够，实际使用中不得不将“复用”变为“新增”，实际依然是新的一轮编码工作。
另外，由于模块不够标准，接口调用、数据连接用户很难上手，最终还是需要负责交付的工程师帮助用户完成。虽然售卖了低代码平台，但实际还是提供了SaaS交付级别的人力支撑。
这类产品普遍的方法论是基于已经成熟的SaaS系统，为了更灵活交付的目的，进行模块化的拆分，让一个已经成型的混沌系统有序化、标准化。
就像我们前文提到的，一个系统在演进迭代的过程中不断熵增，越来越混沌；而进行这种模块化的拆分就是一个“逆熵”的过程，在实际操作中**发现，由于模块与模块之间千丝万缕的联系，总是没有办法达到你想要的粒度，最终往往止步与一个完整的最小可用功能。
而对于一个工具，通用性直接取决于模块的抽象程度，粒度越小，就可以达到更高的抽象程度。
这类走“逆熵”路线的低代码工具，对于自己SaaS的交付场景，可能的确**有一些提效，但由于抽象程度不够，总是跳不出自己的领域，难以成为一个通用的低代码平台，最终也就成为了交付团队的低频工具。
这些SaaS交付型企业在低代码建设中选这条“逆熵”的道路，一定是有历史的包袱，这一点是无可厚非的，但是不是只有这一个答题思路，似乎不然。
我这里以国内某一BI厂商的低代码平台答卷为例，他们并没有试图通过低代码去解决他们现有SaaS产品的灵活交付问题，而是把低代码作为整个产品矩阵中的一个独立产品进行规划。
该厂的传统BI产品是解决数据统计、处理、分析、展示问题，为了补全产品阵列中的闭环，他们的低代码平台锁定了信息收集、工单流转的表单场景，并且着重建设了与原有BI产品的数据打通。
单独来看，表单场景似乎是相对简单，但是配合该厂的BI产品就完成了一个数据收集到分析的完整闭环。
本文由 @小博 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
