作者 | 轻流联合创始人&CPO 严琦东

在当下的IT领域，低代码/无代码一定是备受关注的热词，然而低代码/无代码是不是伪需求？低代码/无代码是行业毒瘤吗？低代码/无代码时代，IT开发者会失业吗？······类似的话题讨论不断。

不过低代码/无代码并不是一个新词，实际上，2014年研究机构Forrester就正式提出了“低代码”的概念，这类平台面向的是IT专家或者平民程序员，以快速交付应用程序为目的，解决传统软件开发模式带来的周期长、成本高等问题；Gartner随后用基于aPaaS的高生产力平台（hpaPaaS）来命名这一类产品， Microsoft、Mendix等深耕低代码头部企业也逐步入局。

轻流《无代码未来十大趋势白皮书》（2022）

Gartner也曾预测到2025年，企业70%的新应用将由低代码/无代码开发。

目前行业内普遍认为低代码包含无代码，但我们通过观察发现市面上绝大多数低代码平台更加适合有技术基础的IT人员使用，而作为没有IT基础的业务人员却很难上手；而我所在的企业轻流一直致力于无代码平台的建设，我们认为无代码可以让不会写代码的人也可以像搭“积木”通过拖拉拽的方式建立企业管理系统，从这个角度来看，无代码平台适用的人群会更加广泛。因此，原先“无代码是低代码的子集”的观点正在被解构，低代码和无代码的边界也越来越明晰。

在这里，我们不去深入讨论低代码/无代码的概念，毫无疑问的是，数字化背景下，业务与IT的不平衡的发展关系，引发了越来越多新的需求，而技术变革又会影响着企业数字化进程中不同角色之间的关系。

那么在数字化进程中，一方面企业不断追求业务增长，另一方面低代码/无代码技术也在快速发展，而IT作为其中关键的角色之一，未来将何去何从？

我从一个故事谈起。

01

信息化的“大公司病”

之前跟一个从事信息化工作的朋友交流，他所在的公司人数超过了1.2万人，占去了所属行业国内30%以上的份额。2021年以来，公司明确数字化将会是公司下一阶段的重要战略之一。公司有着150人左右的信息化团队（这位朋友负责的团队人数约50人）面对这样的战略决定喜忧参半，动力和压力并进。我们针对企业进行信息化落地工作中的种种难题展开讨论。讨论过程中发现很多问题恰恰是具备一定信息化规模的企业才会有切身的体会，而这些问题也普遍存在于大部分的“大公司”中。

弊端一：核心系统运维难

该公司的系统是2015年开始设计，在2017年正式上线使用。5年的时间对于一个核心系统的生命周期来说并不算长，但是却疲态惊现，老迈地走不动路了。

由于各种原因，团队人员构成已经产生了很大的变化，最开始负责开发的同事已经不在了。项目初期的文档维护不规范导致老旧逻辑缺失，难以澄清。新的团队往往需要花费倍数的人力才能上手工作，团队的排错和修复工作都需要花费成倍的人力。

然而核心系统的稳定性往往牵扯到核心业务的正常运作，一个再小的错误都会直接导致不同程度的业务损失。所有的稳定性背后都是成本的投入，为了能够保障这种程度的稳定性，一个大型的信息化团队对于已有产品的维护和质量保障投入往往占去了超过50%的研发资源，这个数字随着核心系统的复杂度提升而不断攀升。

令人唏嘘的是，稳定性所带来的“业务损失”并没有减少，而是以“IT成本”的形式出现在了财报中。

弊端二：信息化协作链路长，响应糟糕

大公司的“大”首先体现在复杂庞大的组织架构上。该公司超过1.2万人，共有5家分公司以及分散在全国各地40家左右的实验室的。为了服务这1.2万人进行协作和管理，公司组建了150多人的信息化团队；而为了维护这样规模的团队，每年公司需要支付总计数千万的各项成本，堪比一个小型企业全年的营收。这样级别的投入对于大部分公司来说都是难以想象的。

中心化的IT信息化团队在企业内扮演了乙方的角色，承接各个子公司、业务部门的信息化需求。在资源有限的情况下往往出现互相挤占以及排队现象，往往一个非常小的功能需求排期就动辄数月的等待周期。不仅是排不上队，即便排上队伍了，落地质量也差强人意。庞大的组织架构弱化了部门与部门之间的联系，中心化的IT团队离业务一线越来越远，使得甲乙双方有着巨大的信息差和理解差，这种差距直接导致了最终需求的落地效果差甚至无法落地。

这些问题在这家公司的集中暴露并不是偶然，在大企业中属于普遍现象。大企业的信息化陷入了一个怪圈：“投入越来越多，效果却越来越差”。信息化的“大公司病”就像房间里的大象显而易见却又难以改变，所有人都默默的承担着，然后继续负重前行。

02

“甲乙方”式的协同存在的弊端

生产资料的稀缺性以及生产工具的使用壁垒导致了甲乙方的协作模式。这个基本原理在“信息化”领域同样生效。我们发现正是这种“甲乙方”的信息化协作方式的弊端，造成上述的种种乱象。

弊端一：甲乙双方对于需求的理解有断层差距

软件开发是一项具备高度专业性的工作，其包含了两项重要“任务”：

任务一：将抽象的业务需求设计为可操作的系统功能；

任务二：通过代码将任务一的系统设计进行实现；

在过去我们非常关注“任务二”的专业度却忽略了“任务一”中软件的业务逻辑设计同样具备专业性。大部分的IT开发者并不缺乏coding能力的专业度，但是缺乏对于业务需求/痛点的深度理解。大型企业的组织架构和业务流程往往庞大且复杂，大部分的IT开发者都距离业务一线非常遥远，而业务问题同时具备广度和深度，非实际经历很难有切身体会。

IT开发者能够意识到“需求理解”的重要性，但在大量的开发排期面前往往却有心无力。这种差距导致甲乙方的服务落地质量得不到保障。服务满意度较低。这种牺牲“开发质量”而追求“开发数量”的做法并不可取，但身处其中的IT开发者其中并没有能力扭转局势。

弊端二：甲乙方的中心化协同缺乏响应业务变化的灵活度

VUCA时代，企业业务变化的周期被大大缩短。对于信息化工作的灵活度有了更高的要求，超过59%的中国IT开发者认同其企业的软件开发速度需要加快。

然而甲乙方的协作模式下，企业内所有的业务系统需求，都通过一个庞大的信息化中心来完成，一个标准的研发流程包含需求梳理、方案设计、落地研发、质量测试、版本发布等等环节，每个环节都是专人执行。项目参与人数越多，协作难度越大。过程中的信息损耗、效率低下问题也是反复出现。各个业务部门对于中心化的排期资源抢占也变成了一种企业内的负和博弈，增加了不必要的成本支出。

这一切都使得响应周期过长，系统还未开发就变成了“过期产品”。这些都大大提升了信息化投资的风险，企业每年投入大量的资金进行信息化投资，大部分都处于无法明确收益比的情况。这也难怪大部分的企业主想做信息化但又不敢做。

面对这个现状，我们需要做出改变。

03

做出改变：从“甲乙方”到“圆桌式”

圆桌十二骑士的故事深入人心。传说中不列颠君王亚瑟（Arthur）所领导了这样一群优秀的骑士，骑士们在战场上冲锋陷阵，在圆桌上议论国内事务。近代以来，圆桌形式的会议屡屡在关键的历史节点中发挥作用，大大的加速了相关历史事件的节点进程。

“圆桌式”代表着平等的对话、密集的信息交互、各司其职的配合，即模糊了“甲乙方”的边界，也模糊了“生产者”和“使用者”的边界。回顾历史，我们可以看到各个领域的技术普及都是一场场的去“甲乙方”的革命。

从专业媒体到自媒体（模糊了内容消费者和内容生产者的边界）；
从专业视频到短视频（模糊了视频消费者和视频生产者的边界）；
……

技术和工具的门槛降低，使得使用者有能力参与到生产过程中，从而指数级地提升整体的生产力。

在刚过去不久的轻流第三届无代码探索者大会上，我们与国际知名数据公司IDC共同发布了新的系统搭建协作机制——圆桌式开发，它既不是依赖个人专家输出、也不是传统的甲乙方合作，而是一种更加扁平、敏捷的开发方式。在今年1月份轻流发布的《无代码十大未来趋势白皮书》和轻流的无代码未来趋势论坛中，轻流就预告了这种协作模式。

随着无代码等自动化技术的出现，我们欣喜地看到，源于“无代码系统搭建平台”的易用性和低门槛，“轻流”正在实现业务人员参与到信息化系统开发的历史性转变。越来越多的业务人员通过短暂快速的上手学习，完成了自身业务的数字化转型。通过应用软件技术的门槛降低，一种新的人才类型正在越来越多地出现在企业中，企业信息化的深度参与角色变得越来越多元，我们发现IT与非IT的之间的边界正在变得模糊。

不管是系统使用者还是专业开发者，都可以通过各自趁手的工具来发挥自身的优势在一个圆桌上密切协同高效敏捷地完成应用系统落地工作，这就是我们所倡导的——“圆桌式开发”协同方式，该方式让各种角色有能力在一个圆桌上通过高度协同、各司其职共同完成系统落地。

04

圆桌式开发中IT人员的角色转变

以无代码开发平台为基础的圆桌式开发方式也将会改变IT人员在企业信息化中的角色。

从大包大揽转变为侧重于核心业务系统的开发

在过去，IT信息化协作中由于编程的壁垒存在，业务人员没有能力参与需求落地。IT人员需要大包大揽所有的业务系统需求。而这中间80%以上都是非常简单的系统修改。IT人员在核心系统的管理和各个业务部门零碎的需求之间苦苦寻求平衡，不仅资源分配困难，一线业务的满意度也是非常低的。

通过无代码平台，业务人员也可以在自己的能力范围内实现一部分系统需求，不用再苦苦等待排期，大大缩短了整个落地周期。而这个过程中，IT资源也被大大的释放了，IT人员不需要在业务部门间疲于奔命，可以将更多的精力投入到核心业务系统的维护和激活中。

这不仅大大提升了IT的投入产出比，也提升了一线业务的满意度。

从系统需求的执行转变成信息化的技术赋能

圆桌式开发让企业摆脱了纯粹的中心化信息化，组成了一个个小型的开发圆桌。更多的业务人员能够深度参与到系统的开发过程中。为了让业务人员更好的开发系统从而为IT人员减负，企业需要在转型过程中培养一批具备无代码平台使用能力的“业务技术人员”，这样一种诉求下， IT人员将从一个业务需求落地的角色转变为赋能企业内更多人有能力进行系统开发的角色。

IT人员通过顶层的权限架构设计，为不同的业务部门进行不同程度系统开发授权，支持业务人员可以更好的展开系统落地工作。

遇到业务人员不乏解决的复杂问题时，IT人员也可以通过专业的编程技能，和业务人员一起协同开发，赋能复杂系统落地。