2021年11月，【2021产品经理大会•深圳站】完美落幕。用友网络助理总裁刘鑫，以低代码开发为核心主题，分享了对于工具型产品设计和开发的思考。
用友网络助理总裁 刘鑫
以下为分享实录：
今天我所分享的核心主题是低代码。这个词近来大家也听说得较多，为何低代码近两年这么火？它跟企业的关注点、落脚点有紧密联系。可以相信的是，低代码起码还会再火三年，因为到今天为止，低代码在国内仍没有一个有效的、真实的逻辑。
今天我便会从一款低代码产品设计工具的诞生，来分析整个产品的设计思路。
用友有一条产品线，叫yonbuilder，它可以助推bip 商业创新平台的完善，起到低代码前置和展示的作用。今年用友并购了apicloud，也表明了用友想做低代码的决心。不过gartner的分析师更倾向于将低代码说为轻量代码。
相信大家都听过madp和lcdp，这两个平台之间有什么关联？从过往gartner的一个报告来看，左侧madp象限里涵盖了一些公司，如microsoft powerapp等，因此这些今天听说过的低代码开发平台公司，他们也有可能同时存在于移动应用开发平台的象限之中。
右侧即我们常见的低代码中台。二者紧密相连，假如你是一个低代码开发平台，那你也会是一个移动应用开发平台。
因此我们会发现，当我们访问mendix或outsystems网站时，对方除了说明自己是低代码平台之外，还会说自己是移动应用开发平台。
此外，低代码有没有标准？可能现下大家相对直观的感受便是，基本上所有软件公司都会说自己为低代码、甚至无代码公司。但其实低代码有自己的相关技术标准。从salesforce代码开发平台来做分析。它主要由三个板块组成：
- apaas heroku；
- madp lightning；
- 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数字业务的创新。而无代码无法满足企业将数字化当成核心竞争力的这一前提。
其二，快速试错，提升效率，即企业可以快速地变化、升级。
其三，图形化，即让业务团队参与进来。低代码平台其实很适合产品经理。以往产品和研发提需求时，如果研发态度不好，可能甚至会告诉产品这个需求无法实现。但是低代码时代来临之后，产品可以帮研发将事情做到七八成，研发只需完成剩下的部分。
而关于低代码开发平台的最终检验标准，有这三个方面：
- 能不能开发2c和智能硬件的应用；
- 能不能有效连接企业内部和云端的api；
- 具不具备三种能力：图形化、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工作的一个有效提升。
总结一下，产品经理需要有自己的坚持，这是最核心的道路。产品经理也需要拥有战略思维。
而作为一位产品经理，我们的想法是所有一切的来源。希望大家都可以成为一个独当一面、涵盖所有能力的产品经理，这其中可能需要一点天赋，大家可以校验一下自己。
ag凯发k8国际的版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
