低代码业务开发人员何去何从（为什么低代码行业长不出大公司）

图片来源@视觉中国

文 | 新眸，作者｜鹿尧

当企业把数字化转型提上日程时，最先意识到的往往是战略需求，而不是业务要求。随着转型由浅入深，速度和质量决定了生死，这时候才发现现有的开发工具与开发方式，管理水平及人才配备，其实很难胜任新的生产需求。

之前有数据统计，从转型成功率上看，信息化程度较高的行业小于26％，而传统行业只在4％~11%区间。为了解决这个问题，行业里常规的逻辑，企业如果要真的跨越周期，必须先使用合适的新工具，无论是云计算、Serverless、各种Xaas，目的都是为了理想化的降本增效，低代码也是同样的道理。

Gartner认为，未来企业间互动、需要更多的设备接入，业务会更加分散，专业开发者的数量并不足以满足企业IT需求。供需矛盾间，可视化 拖拉拽的低代码平台能让所谓的平民开发者，即普通的业务人员也能进行应用搭建，成为平台的最终用户，写更少的代码，花更少的钱，干更多的事，这看起来非常诱人，而且蕴含了巨大的商业前景。

2018年是一个有趣的节点，随着OutSystems成为超过10亿美元的新晋独角兽，低代码概念也被大量曝光，国内低代码赛道在近几年也尤为火热。

中国低代码行业投融资事件汇总图源前瞻产业研究院

之后，从2019年阿里把内部产品宜搭正式对外商用，到两年后发布低代码开发聚合平台“钉钉搭”，腾讯上线微搭，华为有AppCube，百度有爱速搭，大厂之外，传统ISV躬身入局，一大批创业型选手也纷纷涌现。相比国内，国外巨头的布局更早，微软、谷歌、亚马逊都将低代码看作未来，也都拥有自己的低代码平台：PowerApps、Honeycode和Appsheet。

理想的状态是，低代码能将所有与应用开发相关的活动，都收敛到同一个平台，从而产生更多方面的聚合效应与规模收益，但事实的发展却并不顺利。

站在2022年这个节点上会发现，同为企业服务里的细分赛道，虽然近年来跑出不少低代码玩家，但既没有产生像erp里的用友、金蝶，更遑论crm领域的salesforce以及协同办公里的zoom。反而传出的更多是被收购的消息，比如西门子收购Mendix和TimeSeries、Magic收购PowPow、字节收购黑帕云。考古微软2005年开始投入的webform，InfoPath等工具，也早被时代淘汰，现在一些寄生大厂生态的明星厂商，名声并没有如雷贯耳。

愿景是美好的，不过现实中类似“低代码是不是伪需求、是否能真的商业化”的质疑声也一直不断，尽管理论上降低了开发门槛，但怎样让客户真正用起来，低代码还是难以实现纯粹的产品化推动。平台如果预设是代码小白，牺牲上限换短期效率，不仅会限制平台成长，是否真的增效也不一定；如果提供给专业开发者，作用又难免鸡肋，更不必说昂贵的变革成本。

为什么低代码里至今没有keyman，归根结底，这并不仅是战略层面拍脑袋能解决的问题，除了开发阶段，还要考虑产品的全生命周期，如果将价值认定框在降本增效的标准里，其实不太符合现实商业原则；数字化转型的过程中，风很大，具体到产品、市场、业务、用户、特定的应用场景，有太多的细节需要重新考虑。

01 厂商看技术，甲方看业务

模块化、可视化的编程方法由来已久。20多年前，微软的Visual Basic、Access以及Sybase PowerBuilder、Delphi Builder等编程工具风靡一时，都算作比较早期的低代码工具，多年来热度起起伏伏，很多人认为，如今不过是用“低代码”这个新瓶，装了表单、工作流、业务对象等旧酒，包装成面向业务应用层的低代码平台，本质仍是个OA自定义表单和自定义流程引擎而已。

到2020年左右，广义上的低代码开发平台包含低代码与无代码，前者面向程序员，后者提供给没有编程基础的业务人员，用友副总裁罗小江认为，“3-5年内可能低代码平台主要还是针对专业开发者，混合开发模式能够简化一些基础问题，程序员在此基础上做复杂开发。”低代码的成熟度，还停留在需要技术人员在一线业务员和开发商间做沟通的程度。

实际上，现在对于低代码的各种技术界定、渲染的实际意义不大，它的核心是为了解放生产力，那么业务逻辑比开发逻辑更重要。低代码之所以受市场追捧，源于数字化转型阶段的业务与产品供需矛盾。

当深入到具体业务会发现，现在的商业链条很复杂，比如从供货端、各种营销渠道，到各个电商平台推广卖货，现有的进销存软件并不能整合管理从收集订单、组织生产，到调派库存发货的不同平台订单数据，也不能分析销售情况进行客户追踪。

于是，有预算的企业想要自己开发软件，但在需求、交付时间、质量都不可控的情况下，供需问题短期内很难解决。回到一开始，任何的企业软件都只是技术手段，技术最终要解决的是业务和管理的问题。所以，真正要讨论的就变成了低代码是否真的好用，商业化落地是否可行。

比如在C端，消费者的需求千变万化，供应商是很难靠卖纯粹低代码平台来赚钱，加上用户的产品认知度不高，市场教育成本不容忽视；为了维持基础能力，要兼顾定制的灵活性和运行的高性能，因为使用的人越多，边际成本才越低，这些对一般初创厂商来说压力山大。

如果在B端，考虑是否真的给企业客户降低了成本，并且满足个性化需求，这意味着企业结果导向。市面很多产品都是固定化流程设计，功能缺失或冗余难以避免，比如当你买了一个进销存系统，但当想统筹管理人员绩效时，就得去买另一个，这种情况下的理想场景是，企业人员能够按需自行设计多场景系统，听起来似乎更实用。

大企业的业务流程、数据逻辑往往按照业务规范去做，低代码平台加上成熟的解决方案，可以更快捷地搭建；但受限于服务能力边界，低代码有明显的天花板，它无法替代当下的中、高级开发工作需求。中小企业的使用意愿也会被高估，即使用轻量化场景来，满足这些业务逻辑更简单的企业，除了搭建成本，还要因为业务不规范的“削履适足”，低代码反而不容易应对。

现阶段，不论在C端还是B端，在业务还没有实现标准化，数据也没建立标准时，低代码平台都不可能满足任意复杂度的业务，这也让它的应用场景被局限在那些只能被标准化的领域里，完成业务的全面覆盖更不现实，还会对企业的数据治理、信息安全产生隐患。

敏捷、普适、丰富的场景、性价比高，这是每一个低代码厂商在宣传自家产品时会用到的ppt话术，也是资本喜闻乐见的故事。不过作为入局者，钉钉、用友和简道云的相关负责人都曾表示，低代码市场的宣传是有些言过其实的，拓荒的过程很艰难，目前的渗透率极低，在所有的行业里渗透率基本上都是个位数，甚至仅仅1%、2%。

中国低代码市场渗透率低图源洞见研报

在数字化浪潮中，RPA赛道的玩家们也正在经历类似的事情。由于低代码环境弱化编程需求，RPA市场边际扩大，并被认为是全球增速最快的细分软件市场，仅今年上半年，以达观数据、影刀为代表的国内RPA厂商累计融资金额达20亿，相关企业注册量接近400家。

但相较国外各领域对RPA的应用已经成熟，比如UiPath虽然验证了商业模式和落地场景的可行性，但国内的厂商仍在找试验田，具体到哪些业务流程适用RPA机器人，产品应用范围、边界及周期怎么定，市场还未实现规模化验证。加上产品功能的单一同质等问题，以至于国产RPA厂商客户年流失率平均在30%，远高于国外。

低代码和RPA的高开低走，其实不难理解，我们很多时候对于一个新兴概念的热捧，要远高于产品彼时存在的实际价值，即使它被认为是发展潜力巨大的风口，但在早期阶段，缺乏本土市场验证的情况下，产品是没有普适性的，更不是企业用来加速适应市场的“万能药”，与其忽视市场的复杂去盲目照抄，或者积极炒作甚至削足适履，都不如在适当的阶段做恰当的事更合时宜。

02 从低代码平台到生态

今年上半年，低代码厂商黑帕云正式停服，从被资本热捧到被字节收购，黑帕云是赛道热潮中首个退出的玩家，这件事也被看作国内低代码行业洗牌的开端。

低代码厂商图谱图源艾瑞咨询

在停服之前，有人评价黑帕云是综合能力最好用的轻量级数据协作工具。刚上手的时候可以直接当作Excel用，但它本身不仅比Excel更容易理解且支持协作，数据保存的完整性上也表现不错；接着在使用过程中加深对业务理解进一步升级业务系统，也就是说，软件本身并不是最重要，对业务和数据的理解、从而让业务系统不断生长的过程才是最重要的。

收购后不久关停，有人将原因归为飞书的核心产品多维表格，后者功能与黑帕云类似，虽然字节在低代码领域行事低调，但多维表格本身也是低代码的一个体现。飞书向来采取all in one 的策略，大客户的需求大多由飞书自己来做，随着业务的深化，用低代码去满足海量需求可以算是布局未来。

互联网巨头都在低代码领域加紧布局，像黑帕云的例子并不鲜见，虽然小企业的品牌变现能力对于大厂来说并不诱人，但沉淀下来的核心技术、产品理念和经验的确是有价值的。这也反映出，在本身冲突就很多的低代码赛道，走中小客和PLG增长这一路线的小团队，想要实现商业变现难上加难。

阿里的思路不太一样，在赛道之外，低代码起着“连接”和“高效办公”的作用。草蛇灰线，从2019年张勇首提“商业操作系统”，希望帮助企业实现品牌、商品、销售、营销、渠道管理、物流供应链等多环节的数字化；次年，钉钉升级为大钉钉事业部，并融入阿里云智能事业群，钉钉成了云服务的平台。

钉钉推出的低代码开发聚合平台”钉钉搭”，聚集了宜搭、简道云、氚云、轻流在内的8款主流低代码厂商，金蝶、用友、纷享销客等也是钉钉生态一员。与其说是细分赛道里的低代码平台厂商，钉钉更像一款协作办公平台，基于协同密度来建设应用生态，这样一来，对原有的存量系统服务，面对复杂且分散的业务，钉钉起到连接器和整合的作用。

同一时期，用友完成ERP到BIP，从产品服务模式升维到平台服务模式。2020年发布的低代码平台YonBuilder为用友自身、伙伴、客户的应用开发提供统一开发输出的能力，帮助用友BIP实现商业落地。YonBuilder的存在和后来加入的APICloud，完善了用友的服务链条，和钉钉主打平台及应用生态不同，用友侧重开发者生态和低代码产品。

在传统软件转云的厂商，和互联网玩家纷纷进军低代码的情况下，构建生态成为共识，意味着现阶段很难出现直接对标Airtable、Notion的独立产品。这类似曾经国内爆火的BI赛道，随着大厂BI产品销声匿迹，大部分独立BI厂商以被收购、退出市场或抱团取暖收尾。同样作为一种辅助性工具，从狭隘的定位上，低代码是否会重蹈覆辙还需观望。

03 比起开发，说搭建更合适

如果打开知乎搜索低代码，会发现很多人的字里行间不乏抱怨。“别的不说，单就工作量是一点都没有减少，反而平添了很多很多的麻烦，不用‘低代码’平台分分钟就能开发出来的功能，用了之后得花更多的时间。”

因为目前大部分低代码平台都是高度封装，高度耦合的开发模式，所有功能必须得按照平台既定的规则开发,假如只是简单的增删改查，导入导出，聘一堆薪资不高的外包去用低代码写重复度高的业务，那确实是没有问题。一旦遇到客户有类似五彩斑斓的黑的要求，平台现有的功能又无法满足，很多人连Excel都不会用，更别提改代码，最后只能是做开发的人来返工。

虽然不论是Gartner还是IDG，市场都对低代码的未来表现高度热情，但局中人冷静发言，“它既不是模式的问题，也不是资本问题，而是赛道问题。低代码产品好像什么需求都能做，但是好像每种需求又做不好。”简道云联合创始人单兰杰认为，低代码最大的问题，是这种产品形态怎么能够持续地满足客户需求。

确实是这样，低代码可能会是程序员的一把工具，但不会成为颠覆行业的东西。正如前言，同为企业服务里的细分赛道，低代码这一支尤其分散，看似每一项业务都能适配，但实际的业务用途目前还是狭窄，大多限于简单的行政类、人事类需求，例如工作流和表单流转，大软件的部分功能延伸，面向企业用户的快速补充开发。企业的核心业务如生产、销售、采购库存等，还是要用传统的erp，这些很难用低代码去实现。

它的出发点是好的，我们倾向认为低代码弥补中小企业开发人员数量上的不足，但开发是一回事，能用起来是另一回事。低代码能力是否会变成一个与Office套件一样普及的基本办公职业技能，尚不可知；未来是继续加功能，还是开放更多的接口，做交付动作满足需求，还是产品保持简洁，通过一些其他模块，或应用市场的方式去解决问题，这些也不好回答。

,