低代码这么火，为什么搞砸的这么多？

本文作者：得帆信息aPaaS业务线副总裁石雨田

火了这么多年，低代码的观念已经深入人心。但对于低代码的落地实践，尚未形成明确共识。今天，我想向大家分享得帆在众多500强企业和大中型企业应用的落地实践方法论。

低代码平台：不仅仅是“新瓶装旧酒”

01低代码的发展历程

低代码技术的发展历程可以分为以下三个阶段：

1. 概念萌芽阶段（1980年代至2000年代初）

80年代，IBM推出了RAD工具，标志着快速应用开发的早期尝试。

90年代，RAD方法和4GL语言的出现，进一步推动了快速开发的理念。

21世纪初，各类BPM和EAI平台的出现，为企业提供了可视化工具来设计和管理业务流程。

21世纪初，Oracle发布Application Developer Framework，为企业打造可视化的快速开发工具。

2. 概念提出与市场认可阶段（2014年至2018年）

2014年，Forrester首次提出低代码开发平台（LCDP）的概念。

2018年，Gartner提出aPaaS和iPaaS的概念，进一步明确了低代码平台的市场定位。

3. 生态体系形成与快速发展阶段（2018年至今）

2018年以后，低代码平台开始快速发展，中国市场逐渐形成完整的低代码生态体系。

低代码技术不断演进，成为企业数字化转型的重要工具，越来越多的企业和开发者开始采用低代码平台来加速软件开发流程。

这三个阶段概括了低代码技术从早期的概念探索到成熟应用的整个历程。从技术体系上来讲，随着应用的技术和体验要求逐步提升，低代码逐步开始支撑更为复杂的技术架构和用户体验的终端。

目前企业系统部署架构和终端支持基本的技术路径如下：

• 终端：客户端 -> web端 -> 移动端 -> 移动端(小程序，微应用)
• 服务器：直连数据库 -> J2EE标准应用 -> 云原生应用 -> 云原生(信创兼容)

02低代码的“旧”与“新”

如今在云原生普及、技术和安全要求的升级、企业移动办公入口的固定等诸多方面的因素影响下，开发一个企业管理应用的开发路径基本固定，低代码在加速企业应用构建上有了扎实的土壤。

在此基础上，如今低代码和之前的低代码，都意在加速构建企业协同应用和业务管理应用，解决以下两个问题：

• 降低应用搭建难度，加速应用搭建的效率
• 抽象应用搭建过程，降低应用的搭建门槛

由于企业如今IT应用的技术架构，服务运维，终端访问要求等远远高于以前应用的要求，解决同样一个业务场景，在IT上所花费的精力比之前要多不少。低代码应用需要将复杂的IT内容抽象成可视化配置和搭建的过程，并且需要支持更好的兼容性和扩展性。

所以低代码这个概念确实是“新瓶装旧酒”，在如今的环境下，使用低代码面临着不同挑战和体验。

火了6年了，低代码平台落地的主要路径和常见问题

低代码平台作为工具类产品，不能直接解决业务层面上的问题，而是通过加快研发效率，支撑业务应用的快速搭建，响应业务过程的创新和变化。

一般企业因为低代码平台的使用深度不同，会有不同的使用反馈，以下是我们在上百家客户哪里调研后，得出的典型路径：

01开发人员主导

有些企业内部是开发人员主导上手使用低代码，由于开发习惯和低代码设计层面的差异，大多数开发人员的评价是偏向负面的。

尤其是大型项目上线的节点，开发人员面临巨大的压力和持续性的高强度工作，往往会把原因归咎于引入了新的平台。从这个角度看，平台初期的使用和推广基本上是失败的。

具体建议如下：

01

针对此路径比较可行的办法是，开始前引入厂商低代码专家，协同一起做好需求的调研和评审，整理出哪些场景适合低代码搭建，哪些场景需要自开发实现。确定好需求大致的实现方案之后再动工，可能过程中会有一些碰撞，但是整体的实现和落地效果会好很多。

02

如果前期第一个项目落地效果较好，低代码的整体推广的阻碍可以说就基本抹平。如果企业安排这些熟悉的人继续使用和开发低代码，基本上使用效果都会比较好。

03

在此基础上，如果企业想往更多的团队推广低代码，需要组建一个低代码支持团队。为没有低代码的意识和概念的同学，提供培训和需求评审，过程中的技术支持，这样才能在企业内部做好推广。企业也可以举办一些培训、训练营、比赛，帮助大家熟练使用。

02业务人员主导

有些企业内部是业务人员主导上手使用低代码，他们一般会从小的场景切入，很快搭建好几个场景应用。这个时候低代码平台会获得比较好的评价，因为低代码平台确实能将业务层面的问题快速落地。

开发到一定程度后，业务人员会发现产品不一定能支持有些功能配置，提给产品的需求周期比较长，如果自己实现的话需要一定程度的开发对接，这个时候就比较麻烦了。

具体建议如下：

01

一般情况下，低代码开发到一定的阶段，需要懂技术的同学帮忙，一起通过代码的方式支持、扩展、补充低代码平台的能力。如果团队技术同事比较忙，这会成为一个比较大的瓶颈。

02

针对此情况，企业可以在项目过程中提前和团队沟通前期积累的需求，提前预约好IT资源。如果前期无法确认，也可以联系厂商团队一起商量好哪些业务场景需要扩展开发成通用的组件，后续根据实际情况由团队内部开发或者外采实施开发都可以，完成对于企业自身业务场景有帮助的组件或服务的落地和积累。

03直接采购低代码

有些企业直接采购低代码平台，采购后先集成企业内部的各类基础设施，集成好之后作为基础平台，供各个业务部门和事业部使用。将低代码平台作为基础平台赋能业务部门，帮助各个事业部IT的信息化场景快速落地。

这个时候一般遇到的问题是各个业务部门五花八门的过来之后，平台侧的同事对于平台也不算特别精通，遇到各种需求经常响应和支持不及时，业务部门给的压力一般特别大，接到的投诉也比较多。

发生这类情况最核心的原因是，平台引入之后，由于平台侧的同事对于低代码平台了解时间不长，没有经过项目的历练，推广又比较快，导致对于业务部门的支持力度不够，最终推广落地困难。

具体建议如下：

01

比较好的办法是平台引入后，内部先找到一两个试点的小项目，让平台侧负责的同事做好基础验证工作，熟悉场景应该怎么实现。另一方面在推广之前可以联系厂商团队，找到比较契合企业的推广案例和方案，选定一到两个比较“痛”的业务部门，做好场景的落地孵化和支持。整个过程一定要多沟通，多复盘，扎实把头两个部门做成KOL，在组织内部做成推广标杆。

02

同样在这个过程中，遇到比较复杂的需求场景的建设，前期可以和厂商一起组建低代码运营团队，做好场景分析，识别在低代码中怎么实现合适。

03

与此同时，企业也要逐步培养属于企业自己的低代码人才，让他们可以独当一面。

低代码平台的选型和落地要求

根据以上落地的实践，企业想要用好低代码，离不开自身的“功课准备”和厂商的支持。厂商的支持，既包括产品能力，也包括服务能力。我们总结了优秀的低代码厂商应具备的特征：

• 支持在企业内部本地化适配：低代码落地到本地，需要有比较好的本地化能力的支持，主要是品牌，主题，名称等，方便在企业内部持续推广属于企业自己的效率工具；
• 满足企业内部技术和安全要求：针对企业内部的安全，信创等各方面的基础要求能满足，保证在如今的情况下产品是合规的；
• 具备良好的可配置能力：低代码最终是为了加快应用的开发实现效率，降低开发门槛，所以具有良好的可配置能力，方便向更为广大的人群推广是必要条件；
• 有良好的扩展性：在这个阶段低代码平台还没有办法满足企业100%的数字化需求，那么在使用过程中的开放性和扩展性，就成为企业内部落地的必要条件；
• 很好的厂商支持能力：低代码产品在选型过程中可能看到都是好的一面，实际落地上确实还是有诸多问题，是需要厂商强有力的支持和培训才能比较好的落地，这里选择强有力支持的厂商也是尤为关键的一点。

国内低代码行业的发展，离不开客户企业持之以恒的信任和探索。作为低代码厂商，得帆将提供更优质的产品服务，帮助更多企业做好低代码落地，不仅要用上低代码，更要真正用好低代码！