低代码能为企业IT解决什么问题？（低代码能为企业it解决什么问题呢）

2021年11月，【2021产品经理大会•深圳站】完美落幕。用友网络助理总裁刘鑫，以低代码开发为核心主题，分享了对于工具型产品设计和开发的思考。

用友网络助理总裁 刘鑫

以下为分享实录：

今天我所分享的核心主题是低代码。这个词近来大家也听说得较多，为何低代码近两年这么火？它跟企业的关注点、落脚点有紧密联系。可以相信的是，低代码起码还会再火三年，因为到今天为止，低代码在国内仍没有一个有效的、真实的逻辑。

今天我便会从一款低代码产品设计工具的诞生，来分析整个产品的设计思路。

用友有一条产品线，叫YonBuilder，它可以助推BIP 商业创新平台的完善，起到低代码前置和展示的作用。今年用友并购了APICloud，也表明了用友想做低代码的决心。不过Gartner的分析师更倾向于将低代码说为轻量代码。

相信大家都听过MADP和LCDP，这两个平台之间有什么关联？从过往Gartner的一个报告来看，左侧MADP象限里涵盖了一些公司，如Microsoft PowerAPP等，因此这些今天听说过的低代码开发平台公司，他们也有可能同时存在于移动应用开发平台的象限之中。

右侧即我们常见的低代码中台。二者紧密相连，假如你是一个低代码开发平台，那你也会是一个移动应用开发平台。

因此我们会发现，当我们访问Mendix或OutSystems网站时，对方除了说明自己是低代码平台之外，还会说自己是移动应用开发平台。

此外，低代码有没有标准？可能现下大家相对直观的感受便是，基本上所有软件公司都会说自己为低代码、甚至无代码公司。但其实低代码有自己的相关技术标准。从Salesforce代码开发平台来做分析。它主要由三个板块组成：

1. aPaaS heroku；
2. MADP lightning；
3. Marketplace AppExchange。

综上，低代码平台需要涵盖三种能力，即aPaaS能力——底层云端服务器的能力、前端偏重移动开发平台的能力。而在以工作流的方式操纵了底层的aPaaS能力以及表层的MADP之后，便形成了最终的低代码生态，或者是应用开发市场。

这三个方面涵盖之后，可以起到什么作用？

一、MADP/LCDP都是为了RAD

低代码本身需具有图形化、可视化、流程化的操作能力，主要应用于移动端产品。

企业需求正在逐渐变化，从最开始IaaS需求转变为PaaS需求，再过渡到RAD，即快速应用开发平台。不少企业近几年选择上云，会发现一个直接问题，即将企业的IT系统从内网移到外网、或者移到云上，似乎并不能解决核心问题。

而中台的本质即PaaS，到今天不少企业也发现：上了云、上了IaaS，中台也做了，但是核心问题仍旧没有解决。这就要求我们发现企业所想解决的问题本质为何：即不管利用中台或其他基础的云，产品一定要将满足所有业务需求应用开发出来。

再倒推来看，企业上中台或上云，核心目的即将最终应用开发出来，这也是近几年低代码这么火的原因。

因此关于RAD：无论IaaS或者PaaS，无论上云或者使用中台，都是过程而不是最终的结果。

而关于APP，各种应用（Web 小程序 移动应用 HTML5）才是最终承载业务的抓手。

现在企业数字化、智能化中最重要的矛盾存在于业务部门各种小的、甚至不太看得上的需求之中，IT部门在实现时，依旧周期长、成本高、问题大。

因此低代码未来一定会面向应用本身。近几年这么火，是因为它可以解决企业核心的、看似最平常的应用问题。

二、Low Code

那么低代码是不是只能做小的、轻型的应用？

这个问题其实对从业者来说打击性很大，因为人们可能会说低代码平台本身即低价值的，它只能做小程序、小应用。

好像的确是这么回事儿。

首先，低代码的主要能力涵盖的是小型应用，这里面有其自身的逻辑。

2015年，Gartner曾经有过这样一个分析象限，其中，应用场景分为三类。

其一，基础设施型应用。这类应用其实施周期、生命周期都相对较长，企业内部的实施周期大概为七年左右；与此同时，它在企业内部的存活周期可能会超过12年，变化相对较小。典型代表为ERP。

其二，差异化设施应用。这类应用的实施周期大致1-2年，存活时间大致1-3年，这类应用的典型代表为CRM。

其三，创新型应用。这类应用生命周期短，规划周期和实施周期不能超过6个月。该应用在企业内部的生命周期大致在一年之内；同时要求快速交付。这类应用适用于持续集成、以及敏捷开发等场景。

第三类应用就是我们今天所说的小应用、小程序。

那么这几类应用谁来督导、发行？这类应用多为部门发起，所处理的事宜大多也为企业内的“杂事儿”。比如HR计划做一次内部的健康筛查，此时会需要建立这类小应用；比如传统IP覆盖能力产值，这事儿会由IT部门主导。因此可以看到，第三类应用有着典型的不同。

今天的企业为何要上云？前两种应用并不是企业上云的目的，尽管企业内网的ERP、CRM等东西可以挪至外网，但这并不具备任何实际价值，仅是移动搬家时代的体现，可以让场景使用相对丰富而已。但本质上，内网已经可以满足原有需求。

因此大家应有一个直观认识，低代码并非只能做小型应用，云上用户之所以上云，是为了快速开发和迭代，满足业务部门的需求。因此，低代码开发平台主要是为了解决新问题，主要用来做基于移动和云的、业务部门发起的创新型的数字化智能化应用。假如技术人员、IT部门不能很好地满足业务部门的数字化、智能化需求，此时企业便需要借用低代码平台来打造数字化的竞争优势。

另外，低代码的推广不能只讲太多技术说的话，这并不适用于低代码的全球市场环境。

国内低代码公司的从业人员大多讲的和国外不一样，他们借助低代码的概念，讲的是中台。而今天的低代码虽然涵盖了中台的能力，但这并不是它的核心要务。低代码所需解决的，是公民开发者如何参与到企业的IT进程中的问题；真正的赋能公民开发者才是低代码的价值。而如何提升IT部门效率的问题，才是传统PaaS或中台所需解决的。

那什么“不是技术的话”？如outsystems，这是全球低代码领域内的一个标杆公司，单笔融资了上亿美金。可以看到，它所讲的是customer experience，即利用低代码平台可以做出拥有更佳用户体验的应用；operational efficiency，即自身效率的提升，实现系统的现代化；还有digital transformation等等。

因此，低代码并不等于中台，它只是涵盖了中台的能力。更核心的在于它能不能做出更好的、比如和outsystems相似的分配标准。

因此低代码有这样几个特点：

• 少量代码：降低重复性工作；
• 快速试错：提升效率；
• 图形化：让业务团队能参与进来。

其一，进入行业较久的互联网朋友们可能听过一些DISCUZ系统；在当时，有些系统可以以无代码的方式拖拽式生成一个手机网站，以及适用于各种场景的、基于论坛和新闻展示为模式的建站系统。

但是无代码并不具备核心竞争力。与之相对，低代码的基础标准是这样的：涵盖了aPaaS的能力、涵盖MADP，以图形化、可视化、流程化的方式进行组合，驱动底层的PaaS和表层的MADP，最终形成低代码。

因此，低代码不代表无代码，它需要一定的代码工作量，其目的是为了让业务部门参与整个过程，形成完整的组合和有效的低代码应用，实现APP数字业务的创新。而无代码无法满足企业将数字化当成核心竞争力的这一前提。

其二，快速试错，提升效率，即企业可以快速地变化、升级。

其三，图形化，即让业务团队参与进来。低代码平台其实很适合产品经理。以往产品和研发提需求时，如果研发态度不好，可能甚至会告诉产品这个需求无法实现。但是低代码时代来临之后，产品可以帮研发将事情做到七八成，研发只需完成剩下的部分。

而关于低代码开发平台的最终检验标准，有这三个方面：

1. 能不能开发2C和智能硬件的应用；
2. 能不能有效连接企业内部和云端的API；
3. 具不具备三种能力：图形化、MADP、aPaaS。

早期低代码开发平台只能做表单式，但是能否做好2C体验的产品，才是低代码平台的核心价值之一。

今天的低代码开发平台也需要很好的连接能力，毕竟现下企业做应用时，并不要求完善自身内部的所有程序，它可能会用到多家的系统。因此连接能力是必须的，这也是PaaS的能力之一。

而以图形化的方式进行组合，可视化驱动底层的PaaS和表层的MADP，则是衡量一个低代码平台有效性以及真实性的基础标准。

三、企业怎么用？

低代码开发平台给企业IT解决什么问题？给谁用？

Forrester是相比Gartner更早定义低代码的公司。在分析报告里，它提出了低代码的两种定义：

其一，面向企业内传统IT开发团队，给专业研发人员使用的开发平台。

其二，面向业务团队，即非传统IT人员群体使用的开发平台，即公民化开发者。

因此在国外，Low Code 分成两种产品模式，面向不同的群体实现输出。当下在国内，我们很少听到有人专门面向产品经理提供低代码工具，更多的还是第一种，可能通过模型驱动，提供专业的IT数据，但这种工具对我们而言还是太复杂了。

那么，企业到底该怎么用低代码开发平台来做应用？

而我作为产品经理、作为低代码开发平台分析师，我又该如何设定我的产品？

首先，面向经过培训的业务团队，我们给他使用的应该是图形化、可视化的工作台。且要想让这类非专业人员使用低代码，我们可以从普通互联网用户角度出发来进行思考，满足他们的需求。

其二，代码部分应该如何配合这类人员？则应当让业务团队优先处理各种需求，让碎片化的需求规范化（如输出PRD、专业的Axure原型等），进而推动业务向研发团队行进。

举个例子。比如HR部门发起一个诉求，此时需要进行需求梳理，再设计产品原型UI等。在分析完整个流程之后，我们会发现，图中标黄的部分在原本IT能力范围之外，标绿部分则是企业IT人员所擅长的。

因此我们在想，关于前半部分，我们是否能够做出一个工具将其串联起来，并跟后半部分也串联起来，形成一个完整的流程，让每一个小的需求都在规范流程里流走，并形成一定的技术标准。即产品经理最后画出的原型会变成代码，最后IT团队则可以轻松地完成剩余事情。为此，我们划定了右侧部分，将其变为标准化的流程。

而码前便是基于这样的逻辑下诞生的。它可以做什么事呢？

首先，它可以将Idea快速孵化，利用现成的事物实现高度复用，缩减时间周期。比如开发注册页面，此时我们可以挑选模板，这些模板的核心功能并无太大差别，利用模板，我们实现引导页面复用、通用化功能复用等，不仅输出了产品原型，更是完成了低代码的输出。

其二，降本增效；即一个人便可以完成多个人的工作，可能未必专业，但是减少了沟通环节；之后再交付专业人士。

其三，管理便捷，即所有流程都可以被串联起来，在一个平台上实现通用化的流转。

而这能起到什么帮助？

比如，可以帮助业务部门精准地描述企业IT数字化需求，利用模板方式创建引导，进行产品设计，形成高保真的、可实时保存的云端协作原型设计。低代码开发也可以实现前后同步驱动，联动前端开发与后端开发。

以上便是我对产品经理可使用的、低代码工具的设计和思考。

说回一个问题，是不是人人都可以做产品经理呢？就我个人经历而言，这个问题的答案是否定的。

产品经理可以分为两种，其一，会画原型的产品经理；其二，也是大家更为追求的，即可以从战略角度出发、把控整条产品线的产品经理，这类产品经理需要对市场方向等方面有所思考。

而我们做低代码，也是基于整体方向的思考上进行。因此我觉得，产品经理其实跟艺术创作类似，都需要一些天赋。做研发的，可以学习计算机、学习自动化；做UI的，则大多是美术出身；这些角色都是有地方可以进行学习的。但是学校里并没有专门开设一门关于产品经理的课程。

举个例子，为什么微信PC端一定要扫码登录？按我个人理解，使用PC端登录微信的场景相对较多，此时输入用户名、密码进行登录反而更为简单快捷，为何从产品出现伊始，它就要求用户PC端必须扫码登录呢？

可能最开始关于这个产品设想，研发团队并没有太多思考。但今天微信仍在坚持，我觉得，这便是一个产品的逻辑，是产品的坚持和设计。每家产品都有自身的战略思考，不会轻易地被用户调研左右，因为用户需求调研所得的需求很可能都是伪需求。更核心的，还是在于思考。

而码前这个工具可以做什么？当下我们梳理产品需求的时候，大多按页面进行处理；生成这些页面之后，码前支持将所有页面导出为一个个对应的sketch文件。最简单的逻辑在于，这一方式可以防止页面遗漏，这也是对UI工作的一个有效提升。

总结一下，产品经理需要有自己的坚持，这是最核心的道路。产品经理也需要拥有战略思维。

而作为一位产品经理，我们的想法是所有一切的来源。希望大家都可以成为一个独当一面、涵盖所有能力的产品经理，这其中可能需要一点天赋，大家可以校验一下自己。