7月6日，我们组织了第一次的轻流日（万能的谐音梗），主题是：无代码无边界。

发布了不少有趣的内容，感兴趣的了解一下。其中我们发布了轻流的一个重要的版本：轻流3.0。其核心是团队所明确的轻流定位：服务业务人员落地管理需求的无代码系统搭建平台。

在过去的两年时间里，我们从自研流程引擎出发，完成了从轻量级业务流程管理工具（BPMS）到跨行业跨场景跨职能的无代码系统搭建平台（aPaaS）的转变。

复杂度前置所带来的效能提升

从人员分工和结构层面来讲，传统的业务系统落地过程中往往需要经历5个层面的资源投入：

其中最大的成本及不确定性集中在以下两个阶段：

• 研发落地
• 持续迭代

通过敏捷、持续交付等研发管理策略可以很好地提升这个端到端流程闭环所需要耗费的时间成本，但是在每个单节点内所能削减的成本是有限的。职能本身的复杂程度让“全栈”这件事情变得很困难，项目成员的人数到了一定阶段在协作和沟通阶段会耗费大量的资源和精力。

降低应用落地过程中的代码干预、这也并非意味着不写代码，而是通过将研发资源投入到更大颗粒度的“轮子”打造中。经过需求提炼将应用层所需要的模块一次性封装从而支持多场景多应用中的多次使用。

这种方式更好地调配“组装”过程中的复杂度分布，从而降低了响应业务变化所需要耗费的成本，从根源上提升了团队/企业的效率和灵活度。

这种方式使得跨职能的互相赋能从原先的“直接赋能”转变为更为高效的“间接赋能”，

如今这些类”中间件“的服务或者产品在各个领域都逐渐趋于成熟：

不同领域的赋能所需要的封装程度不一，需求架构也是不一样的。我们所专注的是赋能业务人员可以逃离代码的束缚，自主进行系统落地，所以花了更多的心思在于理解和抽象一个组织一个业务系统所必须具备的“轮子”。

进过两年的摸索，我们逐渐确立了轻流的无代码产品矩阵：

之前的文章中也就这些板块进行了一定的介绍。抽离后的每个模块专注且专业、互相协调、互相搭配，不同的组装和调用方式会达到不同的效果

模块的数量以及模块内的子模块细分程度也直接决定平台所能支持的业务复杂度如何。

对立 | 统一

功能框架的愈发健壮必然地导致了系统易用性的下降。，面向“业务人员”，而非面向“开发”or面向“项目”的定位，直接的指向两者并非“可取其一”的关系，是要必须做到“兼得”的。

系统的健壮性和易用性，两者如何对立而有统一，是轻流的产品设计团队需要解答的问题。

在3.0中，我们有了新的思考：

1、健壮度

• 功能模块的健壮
• 技术架构的健壮

对一个定制平台来说，定制化需求的满足度是非常重要的指标，这也是客户选型过程中非常致命的一个点。不少的客户因为某个定制需求是否被满足而选择某一特定的平台。这也让无代码平台的产品具备一定的先发优势。

因为定制需求多如牛毛，把握封装的颗粒度非常的重要，颗粒度的大小决定了差异化需求的满足程度：

1、定制化的程度不一：

• 展现层的需求不一（排课、订房、设备巡检）
• 模型层灵活度过高（生产单的拆分与合并、绩效工资等复杂的数据计算场景）

满足了80%的定制化需求，剩下的20%往往是最难啃的。主要集中在需求极度非标的展现层和模型层；不同场景、不同角色对于业务入口的需求是不一的。

例如设备管理的场景，业务入口围绕摄像头展开；酒店订房的场景中、业务入口则是房间清单。对于一线员工来说多为操作行入口、而对于管理员来说多为展示型入口。在涉及到品牌、企业VI等因素，对于展现层的灵活度要求则更高；在复杂且非标化严重的生产环节，有着大量类似订单拆分及合并的需求，对于数据计算转换自定义的要求也是很高的，需求抽象难度高，通过无代码的方式实现目前也极具挑战性。

2、行业场景存在业务壁垒：

• 政企单位中的文书管理
• 项目管理中的进度管理
• 订单管理、售后管理中的支付环节
• 合同管理中对于法律效应的依赖性

例如“支付”是一个相对独立、并非完全通用的能力，但是却在部分场景中是刚需甚至痛点：场地预约中的付费管理、售后服务中的服务费用收取…… 这些原本都是轻流难以打通的端到端流程闭环。

类似的场景还包括：

• 知识库、
• ETL、
• 网盘、
• 电子合同
• ……

简单地接口层面的打通在很多场景中并不能够带来统一的产品使用体验，这样的集成所带来的价值仅仅在项目制交付中体现，对于绝大多数客户来说依然是望尘莫及的服务。

数十万行的代码需要一个健壮的架构，如果没有一个足够优秀的架构，一段时间后产品的可维护性就变得很差，无法继续延展的补充。

不同的模块组合充满各式各样的边界情况，降低漏测率、提升稳定性是一场痛苦的持久战，需要耐心和毅力。

2、易用性

无代码平台和低代码平台之间最主要的差异还是集中于面相的用户群，轻流希望业务人员可以摆脱代码“牢笼”，甚至主导业务系统的落地，而业务人员中往往大多数并不具备足够的coding能力，这对于无代码平台的易用性的要求就会更高。

即便简单的跨平台集成某种程度上可以解决这些问题，但是这也违背了我们让业务人员主导系统落地的初衷。

这条路是非常艰难的，好在最近两年资本的渲染、同行的跟进，向我们这样的业务系统自主搭建平台越来越为人所知。很好地降低了新用户的认知成本，但是随着业务的深入，如何让用户使用工具更好地实现搭建诉求依然有很长的一条路要走。

在平衡易用性和健壮度的问题上，轻流3.0做出了自己的回答：我们通过封装和模块化将这些更深度的自主搭建能力以更产品化的方式呈现给用户，并且深度融合了自研的模块。

在全新的插件中心中，用户可以根据自己场景和行业的差异自主选择，一键开启。配合高可读性的文档讲解帮助用户自主实现业务系统能力边界的突破。

术 | 器

过去一年和各行各业的客户共创，我们打造完成了一个个拓展模块的研发，但是在整个定制化需求面前，我们还是稚嫩地像个宝宝，单靠我们自己的能力能够服务好的场景、行业维度是极其有限的。这就有必要讲到 另一个无代码平台的另一个至关重要的特性：开放。

器：开发者生态

轻流是不是一款工具？ 我觉得是的，因为通过轻流，不擅长coding 的业务人员可以最大化地发挥他的能力。但是工具的边界是显而易见，轻流无法解决产业互联网的所有问题，过去的一段时间里，我们同不同领域的“能力者”一起突破轻流的能力边界：

• Teambition：最佳项目管理解决方案共创
• 坚果云：独立的网盘解决方案
• 百度大脑：先进的ai图像识别能力
• E签宝：深度集成的电子合同解决方案

我们希望同产品人员、研发人员、其他产品等一同打造更多维度的具备优秀用户体验的产品化解决方案。我们即将推出的“开放平台”欢迎大家关注。

术：业务专家生态

在轻流，如果说我们专注于打造优秀的无代码平台是不准确的，对于轻流er来说，赋能各行各业的业务专家才是我们最迫切想要实现的。轻流是一家大学生创业公司，要说对于各行各业业务模式的理解，那真是远远不够，即便是自身所处的产业互联网行业，我们也是前行的探索者。而无代码搭建平台所需要具备的是能够服务各行各业定制化需求落地的健壮程度，恰恰需要与愿意通行的行业专家一同设计与实现。

轻流不仅仅是提供要提供低门槛的产品提供方，也是跨行业、跨职能的专家分享平台。我们所打造的【轻流学院】也正是为了这个目的而生的。

好嘞~ 最后分享一下我们的全新视觉形象，后续可以写篇文章专门跟大家聊聊这次形象焕新。

谢谢大家的阅读，点击即可免费试用轻流～