2B 领域下的低代码探索之路

前言

大家好，我是钉钉宜搭前端一个小团队的负责人，在阿里做了五年的低代码。今天的分享我们不讲技术细节，主要会分享下我们这五年的探索过程和当前的市场分析，希望能给大家带来一个对低代码搭建不一样视角的认识。

什么是低代码

说起低代码（Low-Code）这个词，是在 2014 年，Forrester Research 第一次正式使用低代码来描述这个市场。国内也就是近几年开始流行的，以前我们这边叫「可视化搭建」，可视化搭建讲起来有个很大的缺点，就是很容易和数据可视化傻傻分不清楚。我还记得， 18 年的时候，当时做一个分享，主题是 「泛可视化搭建的解决方案」，我老板的老板说建议我把「泛可视化」改为「低代码」，我当时回复说不改，低代码听着有点 low，「泛可视化」高大上些。后来也不知道什么时候开始习惯了一口一个低代码，而且衍生了 Node-Code/Pro-Code。现在回想起来，当时是自己 low。

看下业界领军者对低代码的定义：

• outsystems: 「低代码是一种软件开发方法，可以更快地交付应用程序，并且只需很少的手工编码。低代码平台是一组工具，这些工具可以通过建模和图形界面来可视化应用程序开发。可以使开发人员可以跳过手工编码，从而加快了将应用程序投入生产的过程。」

• mendix: 「低代码开发是一种可视化应用开发方法。通过低代码开发，不同经验水平的开发人员能够通过图形用户界面，使用拖放式组件和模型驱动逻辑来创建 Web 和移动应用。低代码开发平台减轻了非技术开发人员的压力，帮其免去了代码编写工作，同时也为专业开发人员提供了支持，帮助他们提取应用开发过程中的繁琐底层架构与基础设施任务。业务和 IT 部门的开发人员可以在平台中协同，创建、迭代和发布应用，而所需时间只是传统方法的一小部分。这种低代码应用开发方法可针对不同用例开发各种类型的应用，包括将原有应用升级为支持 IoT 的智能应用。」

可以提炼出几个词：模型/建模、图形界面、拖放组件、加快、减轻。连起来就是：通过模型/建模、图形界面拖放组件可以加快应用开发，减轻了非技术开发人员的压力。其实从前端的角度看，低代码的鼻祖应该是它：

从我目前阶段的理解，低代码是这个：

当前市场分析

市场规模

根据 Forrester 的报告，2019 年该领域的规模估计为 38 亿美元，预计在 2021 年这一赛道的市场规模将增长到 152 亿美元，75％ 的应用程序将在低代码平台中开发。到 2022 年该市场规模将达到 212 亿美元。根据 Gartner 预测，到 2021 年应用开发需求的市场增长，将至少超过企业IT交付能力的 5 倍。到2024 年全球约有 65％ 的应用程序都将涉及低代码开发。（Forrester 、Gartner 全球最具影响力的独立研究咨询公司）

• 1、领导者：行业领导者既要表现出超强的执行能力（好的产品与良好的销售业绩相匹配），又要表现出具有远见（产品创新和相称的营销策略）的战略计划。LCAP 的领导者主要包括云 SaaS 提供商（Microsoft、Salesforce、ServiceNow），专业的低代码提供商（Mendix、OutSystems）以及混合 RPA 和低代码应用程序供应商（Appian）。这些供应商具有强大产品能力、市场影响力以及用户体验。

• 2、挑战者：在市场占有率、产品能力方面与领导者的差距并不是很大，未来有能力成为该行业领导者。

• 3、特定领域者：成为利基市场参与者不仅可以提供底代码应用平台技术，还混合了其他技术，例如，RPA、业务流程挖掘、BPM等技术。他们是 LCAP 行业的中流砥柱，拥有良好的发展空间。

• 4、远见者：远见者具有良好的合作生态以及市场发展策略，在产品创新方面也有很强的能力。但是在业务执行方面与领导者有着较大的差距。相信随着时间的推移他们会更上一层楼。

市场分类

目前我看到的市场上主要有两类：一种是基于表单驱动，核心能力是表单、流程、报表，在一定的场景下，可以快速的做业务交付，上手成本也比较低。比如：宜搭、简道云、明道云、氚云等。另一种是基于模型驱动，核心是领域模型、业务沉淀、完整性，有一定的技术壁垒，上手成本相对比较高。比如：Outsystems / Mendix / PowerApps / 奥哲云枢 / 金蝶云苍穹等。

市场布局

拿 PowerApps 来举例，上面四个分别是 云 + 端 + 协同 + 低代码。已经是很大、很先进的布局了。从中我们能看到低代码平台只是其中的一部分。独木不成舟。独木舟，虽然简易也能用，但毕竟能力有限。

探索过程

用两句话来概括下：1. 始于表单终于表单；2.从技术到产品。

从 2015 年开始我们一步一步探索，做了很多很多，无论是技术上还是产品上。比如模型驱动、小程序搭建等。这里面的每一块都可以单出拿出来讲很久。这里我举几个例子简单描述下。

钉钉审批-表单

钉钉审批，这个搭建当时只有 8 个组件，功能也很简单，和现在相比也和易用。毕竟简单，这个仅仅是我们的开始，之后一发不可收拾。

中后台页面搭建

后来我们开始做中后台页面搭建，但在开始推广时，却受到了很大的阻力。我们开始给前端用，技术同学是来写代码的，就排斥这种高不成低不就的搭建平台产品，而且功能又不全，被骂的很惨。后来，我们给服务端开发用，当然服务端也是排斥的，不只排斥搭建，你说让我一个写 Java 的做前端的页面我就是排斥。但没办法，前端资源就是不足，再加上从上层开始推，那一年，效果突出，有些服务端的同学用的简直飞起, 他们自己做页面特别快，没有联调成本，接口都是自己定义的，想怎么搞就这么高，而且代码写的很规整。再后来，随着我们的功能逐渐的完善，比如多分支、回滚等功能。前端也开始渐渐接受了，平台侧有很多页面都是用平台自己搭建的。

服务化

当时我们部门的业务，大部分中后台系统服务端都能自交付。减少了很多前端资源。我们自己用舒服了，那我们就开始想让其他团队也能使用。但每个业务场景都不一样，默认的平台无法满足其他部门的诉求。所以我们开始做服务化。服务化就是我可以让其他团队也快速拥有低代码搭建的能力，并且可以做定制，比如组件定制、设计器面板定制。这样思路就打开了，不仅能支持其他团队的中后台场景，凡是和搭建相关的场景，都可以做。

比如这里例子，这个场景特别有趣，每次分享我会拿出来这张图，绝对布局的画布，构建好后，服务端会自己做特殊解析，最终显示在石墨屏上。类似这种例子有很多。包括后面要做的在线设计都是通过服务化来完成的。

代码互转/WebIDE

随着我们的用户量越来越多，复杂功能的实现和后续的可维护性受到了很多的挑战。典型的例子是：开始我的需求比较简单，用搭建快速完成了，但后面的需求评估下来，发现搭建满足不了。sb 了。然后我们开始做出码，将搭建产物转成代码，继续开发。

但是单纯做出码，没什么挑战，我们也考虑了不同角色的开发。当年的 WebIDE 也很火，预计我们通过 WebIDE 做了一套搭建和代码互转的功能。我们创造了我们自己的 DSL，其实也参考了 salesforce，有了自己的语言，很多事情都好做了，也可控。小程序也是这样的。

后面的路怎么走？

灵魂三问：1. 如何能把价值再做大？2. 低代码 or 零代码？3. 用户是谁？

再问：能否商业化呢？要不要商业化呢？如何商业化？

看竞品分析。

Salesforce / Power Platform / 金蝶云苍穹，他们的 PaaS 都是有明确支撑的业务领域，CRM / ERP。PaaS 是基于自身的 SaaS 长出来的。我们要主打那块业务？哪块业务能找到市场？如果单纯的做 PaaS，感觉最后做出的可能还是工具。工具类的竞品，像 Outsystems/ Mendix，他们提供是软件工具、方法和架构，可以快速建模、测试、部署、管理等，是一套完整应用开发的闭环（测试、部署、调试、稳定性等）。所以，单纯做工具, 最后被收购？像 Mendix。

支撑 SaaS 为目标？

我们要打的 SaaS 行业？蛋糕还有吗？

要考虑多租、二开等，技术复杂度极高。

再看看国内，简道云，背后是帆软-数据出身，氚云-流程出身。两个产品都偏零代码，产品体验做的都很不错。猜测应该都是先有独立的能力，后发展后低代码平台的。

结论呢？当然没有。竞品分析只能帮助我们多了解，具体的方向还需要自己去探索，去挖掘。

疫情带来的变化

疫情让我看到了：

• 疫情，业务变化之快。

• 企业创新，业务变化之快。

• 企业发展，核心是提效降本。

去年因为我留杭过年，所以参与到了疫情项目，用宜搭来做健康打卡，从大年三十一连续在家干了两周，7 * 24 小时待命。

健康打卡应该大部人都用过吧，看着简单，其实背后有很多复杂，有针对员工的，有针对 HR 的，还有针对海外的。

需求变化之快。今天加个高风险城市、明天加个海外地区。有需要各种定制。

一个前端，全链路完成，快速试错，快速上线。如果没有低代码平台，真搞不定。

总结

冰山理论。部分人认为的，包括 5 年前的我也是这样认为的，拖拽设计器 == 低代码。后面在深入做了两年后，发现有 物料、多端、出码、布局、逻辑、国际化、监控、模板、协议、服务化、帮助体系 这么多功能要做。再往后做，要从 2B 的视角去看，就像之前微软的那边的局部，云、协同、端。后面还有很多的未知等着我们...

再回到现实，总结五个点。

场景壁垒。我觉得我们需要寻找更多的「场景壁垒」，比如，疫情下，快速交付的场景，为什么疫情下大家会选择宜搭而不是选择其他开发模式，因为快且场景不是特别复杂，快需要找需要快的场景，这种场景其他方式无法完成，这就是壁垒。

完整性。用户需要在这个一个平台上能把所有研发相关的事情全部做完。完整性也包括了可维护性。可控的开发质量、维护性和升级成本；二次需求开发。

生态。产品完整性有了后，就可以打造开发生态，通过更多的开发者生产更多的物料、服务。同时平台可以连接更多的物料、服务。

连接。这里的连接有两层含义，一个是产品之前的连接，一个是数据的连接。产品的连接可以产生 1 + 1 > 2 的效果。目前的趋势，在改变传统的 ERP/CRM 大而复杂的软件系统。越来越多小而灵活的应用产生，而且随着企业的创新需求变化越来越快，系统越来越多，但不能做成烟囱，数据的连接尤其重要。

灵活性和易用性。灵活性和易用性的平衡如果做不好，那把平台做屎也很容易。我看过一个竞品，真的做到了代码完全交互化，0 代码，但稍微复杂点的应用那个逻辑流，就是前端的逻辑用交互编排的方式。那个复杂，根本没法二次维护。

未来，低代码将成为B端服务领域的基础设施，低代码必将颠覆传统开发方式。欢迎来一起探索低代码未来的方向。

 阿里宜搭招聘 

✄  校招/社招

• 宜搭生产力平台部，隶属于钉钉事业部，是一个致力于服务千万中小企业进行企业办公自动化及运营平台数字化转型的建设者，更是阿里巴巴及蚂蚁集团内部高效协同办公的重要支撑者。

• 宜搭产品官网：https://www.aliwork.com/

• 通过表单、流程及报表的数字化、智能化手段和数字技术能力，助力阿里 10 万余员工的高效协同办公，提升阿里组织活力与创新力，推动阿里巴巴这家多元、多样、多业态经济体的组织数字化全面升级。

• 同时基于阿里内部最佳实践，部门正通过技术产品化，服务于更多政府及中小企业的数字化治理，为政企数字化转型提供重要支撑。

职位描述

主要负责宜搭生产力平台部的企业级低代码搭建平台、企业级办公自动化系统、企业级 ERP、CRM 等系统、 政务专有化产品、移动端产品等研发工作；

• 负责宜搭生产力平台部核心业务系统的前端开发工作；提升企业系统的整体用户体验和前端技术；
• 负责表单、流程、报表相关的复杂业务搭建平台开发；增强平台能力和页面性能；
• 有良好的洞察能力，能够通过新技术、业界优秀产品的分析调研来提升我们的产品体验；

岗位要求

• 至少两年以上业务系统开发经验，有较强的协同、合作能力；

• 良好的计算机基础和编程能力，精通 HTML/CSS/JavaScript 基础，理解 HTTP 及相关协议，熟悉浏览器和移动平台特性，了解行业技术发展；

• 熟悉 react, vue, ES6, typescript, npm, webpack, redux, mbox, nodejs 等主流前端技术栈；

• 两年及以上前端相关工作经验，主导或独立负责过一定规模产品前端，有一定的前端架构能力；

• 了解 Hybrid 体系，React Native，Flutter，小程序等有一种以上的实际使用经验，了解对应框架的生态以及负责业务的行业动态；

• 熟悉低代码搭建相关的前端技术是加分项，有 GitHub 开源社区贡献是加分项；

• 对技术有强烈的进取心，具有良好的沟通能力和团队合作精神、优秀的分析问题和解决问题的能力。

简历投递: