低代码：趋势向左 价值向右

有句话是“抛开现象看本质”。

进入 2021 年，数字化带来的趋势几近渗透到各行各业，而低代码平台和零代码平台，其创建的应用程序，由于可以随着需求去轻松地进行定制和强化，也成为很多企业相继选择的工具，去帮助业务提高效率和降低项目成本。

正如低代码的火爆并非空穴来风，繁重的数据对 IT 人员依赖强，同时企业内部相对割裂的系统让数据联通存在难度。而低代码能够有效降低对开发和运维人员的依赖，让最明晰需求的业务人员去自行搭建，帮助企业快速建立“敏捷能力”。这让低代码成为重构软件开发中不可或缺的一部分。

那么为何要重构，用低代码重构能带来怎样的价值？客户永远是最了解业务实际痛点并最先给到启示之人。

本篇文章牛透社通过采访到四位低代码/零代码客户，分别来自制造、互联网资讯、建筑、地产四个不同行业，通过他们在低代码使用体验下的讲述，去寻找共性和差异，推敲重构力量的答案。由于涉及厂商和客户众多，本文略有编辑删减。

口述者：微制造创始人｜龙彪

微制造是专门为中小微工厂做的 SaaS。我原来在世界 500 强的制造业大公司工作，此前做的生产管理主要是经营生产，属于流程再造，不太涉及到技术。但是我个人对技术非常重视，曾做过咨询、硬件、嵌入式的硬件编程，再加上本身也是理工科背景，希望通过互联网的技术能将管理落实到更好。

1. 为何选择零代码

最初我们尝试自己做开发，成立团队做 SaaS 的管理软件。从底层写代码开始，这个过程不仅耗时耗力，而且我们做出的东西在每家客户那边各有区别，比如我们按照世界 500 强的最佳实践去做，但是毕竟我们面向的是中国众多企业的客户，管理上并不那么规范，这时候是让对方来适应我的软件，还是我去适应对方就是个问题。

如果对方来适应我，会涉及到很重的咨询问题，所以必然我们要做一些妥协，去适应客户开发成本上又很高，就会导致我们在做商业推广的时候很难受，单子接也不好，不接也不好。

由于客户的需求多种多样，拿一个标准品的 SaaS 很难去满足个性化需求，尤其我们在这个方向属于管理，每家特点不同就无法用一个标准产品来进行交付。

这件事如果我们自己开发，效率上无法满足客户需求，就开始尝试用低代码，此前我们自己开发时也尝试用过低代码，肯定这是个好方向，但也深知要想将低代码一套系统做到完备好用，要花费很大力气，而通过降低它的边际成本自会下降我们的总体成本。

所以当时在调研市面上的低代码工具，发现了明道云这款零代码，就试用了一下，当时也有尝试其他家，最后定下明道云是在 2020 年 6 月份。原因在于我们在前期试验过程中，拿客户此前的一些需求（那些需求点虽然不大，但我们自己没办法满足），用明道云试过之后发现不但能够交付，客户反馈也不错，因此下定决心用明道云来做总体交付。

2. 为何选择明道云

当时几家选型下来，明道云相对更均衡，整体的产品结构设计也比较符合我的设想。其实每个产品我也没办法花很长时间去体验细节，只能是第一眼看过去结构是否清晰，光这一点我就觉得很多产品做不到结构清晰。

遇到过某家产品的图表报表支持功能特别突出，但当我们在看审批和对数据的处理上，它的呈现方式是将其分离，把审批单独抽出来放在业务流程之外，在我看来硬生生的把它割裂开是很难受的一件事，我认为对审批的最终结果是要反馈到数据业务表里，明道云在这方面比较符合我们对软件产品的架构选择。

3. 关于实质性的业务帮助

零代码带来的改变我体会尤深，对内能将我们多个职能多个岗位的人，像是前端、后端、数据库、产品经理、测试众多角色去做一个产品。用零代码后，基本上一个人从头到尾就能完成，相当于一人身兼数职效率非常高，原来一个迭代基本都要两周以上，哪怕客户要改任何一个很小的点，也要两周后才能给到回复。

现在我们自己开发一个产品或者说交付一个项目，迭代周期甚至可以做到每天交付。当然对这个人的考验也更大，因为他不仅要考虑实现功能，还要考虑用户的体验以及平台特性。

对外来看，无需贴钱也能够接原来接不了的项目，成本上也算得过来；另一方面迭代速度加快我们能迅速响应客户需求，这样即便产品本身有一定瑕疵，也不会影响到客户满意度。

原来我们尽心尽力，也才能两个礼拜给客户答复，现在只要客户说出需求，我们能很及时地帮他去进行调整或增加。总体来说，对外让客户的满意度、成本、交付都得到大幅提升。

比如我们现在服务三一重工，最早是我们自己开发的一个标准品，因为我们自己对工业比较了解又做得足够用心，客户体验还是蛮好，但是客户满意的同时会希望我们再多加一些功能。

比如增添一些场内质量管理方面的功能，但是提完以后我们自己算一笔账觉得相对困难，评估下来大概按照原来的开发方式，起码是 4 个人花 2 个月时间才能够交付，但是算下来人力成本很高。我们只做标准品，希望能把相同的功能卖到 10 个客户那边，这样才能开始挣钱。

因为它的一些特殊点并不通用，这个时候我们只能算了，没这能力暂时不接这个活，等我们后来用低代码反过头去进行实验，拿原来不敢接攒下的需求去尝试，试完以后发现原来 4 个人 2 个月的活基本上 1 个人 2 个礼拜就搞定。所以我的亲身体验，零代码效率一定远超过 10 倍。

4. 关于限制

低代码像是一个粘合剂，因为它本来是云原生，开放性足够高，可以接入很多其他外部的工具甚至于他不提供的东西。比如说跟算法相关，我们可以做自己的算法放在自己服务器，利用 API 调完以后把结果返回去，实现更多功能。

像明道云这样的零代码公司，并不需要自己把它做到特别完善，只要在它的业务流程里能够 cover 住大多数需求，少部分需求诸如算法也可以交到外面来做，这部分就是他不具备但也没必要去做那么完备，会有一定边界。

还有一个问题，毕竟基于公有云很多服务是公有，当我们深度使用以后，会有很多并发问题。但我认为技术上是可以解决，顶多在前期增长最快客户量又大的时候，技术上相对吃紧，所以我认为这是一个阶段性的东西。我能够体会到明道云在努力做这方面的调整，所以这其实是属于低代码厂商都会面临到的类似问题。

5. 关于信任

零代码是解决信任特别好的事，原来只能拿原型工具去跟客户谈，你是不是要做成这样，我们画个原型你先看对不对，对了我们再开发，原型要做出很好的交互效果相对麻烦，所以当时我们在取得信任最后百分之二三十的非标部分时很吃力。

用零代码来建立信任就很快，只要对方有意愿做这件事，并认可我们的专业度，只要他说出我们标准产品里面没有的需求，我们也会按照客户需求迅速搭建，原来画原型的时间现在都能够把应用做出来。

所以客户的信任度高，一个很重要因素在于响应速度，响应速度越快，客户对你的信任程度就越高。低代码的好处在于所见即所得，你有怎样的需求可当场做一个简易版，要想用户体验调整更好一点，可能多花两天时间就能做出来，基本很少有哪家公司会认为我做一个这样的产品，能够在一周之内给他想看到的东西。所以基本只要一周以内给他，就已经超出客户预期。

口述者：艾瑞咨询信息管理部经理｜郝欣诚

我在艾瑞 2003 年成立时加入，在这里工作 18 年，在公司负责公司的技术体系，数据产品的研发，主要还是在做研究领域的数字化和大数据系统平台。

1. 为何选择零代码

艾瑞尝试低代码系统的初衷，实际上是要做一个 OA 系统的升级改造。我们上一代的 OA 是 Sharepoint 做的，Sharepoint 的代码系统尽管没那么低，但也已经属于低代码思想，能够满足我们的需求。这一代我们想找更简单的开发方式。

从我们的角度，OA 是为公司业务所服务，所以我们希望在能满足需求的情况下，资源占用越少越好。但 OA 系统不可能一次成型，每家企业都有业务迭代，客户迭代问题，很难说哪家公司要定做一个 OA，一次性能把所有需求谈清楚去做完整方案。我们自己也是感觉两年多时间没做升级，积累的问题太多，就干脆再做一套，把现有问题解决掉。

我认为一个公司 OA 系统若做得好，会下降对邮件和 Excel 的依赖，我们当时内部势头反而是上升，邮件和 Excel 去完成更多的管理工作，还在用大量邮件沟通，而不是在一个有序的状态下的表单沟通，就说明 OA 系统不能满足需求。

我们在上一代 OA 没切换之前，内部有些部门的业务目标管理用 OKR，有些用财务 KPI 指标，还有一些是以工作进度为核心的管理，这就导致用之前 OA 系统进行项目管理不能满足需求。最后就变成大家都用 Excel，无论申请资源还是跑流程都写邮件，相当于没有系统。

2. 为何选择明道云

其实我们一开始不知道零代码，还是按照低代码的开发模式在找产品，因为早年便结识明道云任总，我们就问到他们怎么看待这个产品。他们在听完我们的需求后，告诉我们这个项目他们完全能接下来，给我们仔细看了别家公司案例是做成怎样，为什么能很快的去满足需求，我们觉得很有道理，这才转向了以业务驱动的零代码。

其实我们八年前就用过明道的产品，当时明道还不是智能表单，属于工作协同平台。但是转向智能表单，是在我们参加完他们的产品发布会有了解之后，做选型的时候决定要用明道。

零代码首先给业务带来最明显的提升是迭代速度。明道比传统的 sharepoint 的开发时代快了太多倍，零代码平台严格来讲不是开发平台，而是配置平台。

业务流程描述形式，开会时间即能边听边做，流程怎么走，后面数据怎么出，都能在开会过程中完成讨论，会议结束之后设置个自动化系统，先去跑一个版本，有问题能及时群里反馈。这个迭代速度甚至不能用里程碑来衡量，基本上就是随时迭代，而且自定义的程度非常高。

第二是所见即所得的交付能力。以前做 Java 开发时，在前端、后端、数据库上，需求方和开发者之间有一个周期性分割和思想沟通上的隔阂，开发过程实际跟交付过程处于割裂状态。但零代码平台不存在这个问题，基本开会时间就已经在做，推快整个项目效率。

第三是 bug 比较少。由于属于配置性开发，不属于真正的代码性开发，就不存在发布版本问题，最多只是逻辑误判，而不会出现一个技术型 bug 崩溃导致流程走不下去。bug 少就能节约大量测试环节，甚至可以放心的让用户去直接测试。

第四是门槛变低以后能让更多人参与开发。有些 DIY 能力强的同事看到开发过程后领悟很快，会主动要一个开发者权限，自行做应用给部门用，形成一个社区性开发，让更多非专业的开发人员在内部做开发。这只有零代码平台才能实现，哪怕低代码平台，非开发人员也根本参与不了，所以我认为明道把这种零代码做到很强是可以取代某些开发人员的工作场景。

3. 关于限制

限制是由于每家公司都会有自己风格的界面和操作文化所导致，比如这个字段只能这样，最多只能改变它的某些属性参数，但不能够改变大的形态。

这种情况下所产生的自由度是会带来一些功能限制，比如某个界面，传统方法是点完某个按钮出来一个下拉菜单，直接把这三四个信息合起来进行选择，在一个小菜单上就能实现。但由于低代码平台界面控件选择有限，所以它在操作界面上相对受限，只能适应明道的操作方案。

另外从编程角度也受到部分限制，比如审批工作流，有种工作流没有设计过，这个时候我们会去找明道厂商询问有没有可能实现，可能出现的答案是：没打算实现以后也不会实现；现在没有但建议很好，后面的版本会把这个功能加上；再就是我们其实有这个功能，只是你不会用。

通常只有这三种回答，我们会感觉到还是要依赖厂商，不像定制开发可以任意提需求，基本都是回答可以做。从明道的角度来讲，一定要找共通性，所以对我们的需求，也不是 100% 满足。不过，我们提的需求里只有两到三成他们解决不了，这不是他们的路线，大部分是可以实现。

4. 关于实质性的业务帮助

我们收到的邮件、聊天系统、Excel 越少，证明 OA 比以前要做得好，因为很多流程可以跑在上面。我们一个基本评估指标是去看老板的邮箱，去挖掘还有哪些流程没有标准化，我们上海老板的邮箱事务性邮件，大概减少七成的样子。

上一代 OA 系统没有达到有效降低邮件的目标，反而带来了一些负向增加，系统本身设计还有一些不合理的地方，有些东西没考虑到选项不在，员工为了能让单子通过，反而要发一个邮件强调是 OA 上面没有选项。

这一代 OA 解决掉这个问题，基本员工说没有选项，直接解释一下为何要增添选项，只要我们评估下来功能正确，马上就可以加。上一代 OA 系统基本不可能实现，增添选项得去找工程师，改数据库，以及测试，所以低代码还降低了沟通碎片化的问题。

除 OA 以外，我们现在把一些数据生产系统也移到明道上。我们做市场研究每天要处理大量数据，有一些要写程序，有一些是由数据库来管理。自从用明道的工具，DIY 能力强的同事就能用这个工具来帮助他处理数据，我们把诸多数据后台的管理平台接到了一个平台上，只要有 API 和数据库，基本都可以连上去。

5. 关于明道云产品使用体验

其实我们也用过一些其他零代码，对比下来会发现很多界面不够精致，如果以 APP 市场所有的 APP 作为衡量标准，大厂的 APP 因为是为 To C 服务，产品的用户体验自然追求到极致。

明道的产品，相对更接近于大厂的消费级 APP 产品，无论是从 APP 端还是从 PC 端去浏览，不像是一个工业品。以往看到的给企业用的软件，总有一种工业味道，诸如字段排列比较随意，按钮偏左一点还是偏右一点，其实也无所谓，在 To B 的场合大家都可以容忍。

明道在这方面做的至少比我接触的几家要工整精致的多，我认为这对用户体验影响很大。当然，其它家也各有所长，只是从界面上来讲，他们选择的是以实用主义为准的路线。比如精简前端代码，输入数据时浏览器的效率更高，是明显不走用户体验风而是走简洁风，目的是为了操作响应更快。

国内有大量的精致的消费级网站、App 产品，我个人认可这种产品界面，现在我们已经被大厂的产品锻炼到，如果不顺着这个操作模式，就会觉得这是个问题。这件事已经形成一个标准思维，你必须 follow，这样同事根据直觉就能学会大部分基本操作，不需要更多时间来进行培训。

如果一个东西要反复讲，会花费大量时间成本，我们以前 OA 有一张操作手册叫常见问题，有六七十个问题。因为开发资源有限，一动就要动全身没法优化界面，最后就将这 60 多个问题写成文档，这两三年一直就是新人必问。这就不是一个好的系统，好的系统理论上只要熟悉业务就能看明白该怎么用。

所以明道云大幅缓解了我们对于基础性问题的回复工作，我们现在对新人的培训也着重在业务问题而不是操作性问题。

如果说服务客户可能现在还不太合适，因为它的界面可能达不到商业化的服务客户，尤其面对服务消费者，是要做花哨一点，用户体验也要再贴近于当时的场景，这个不适合用明道。但是管理包括给 To B 的客户做服务，这个界面已经足够友好。

6. 关于信任

我们本身是做 To B 的公司，做 To B 的生意大家都知道信任是基础，价值是动力，有价值有信任的生意才能做。其实我们跟明道有渊源，是十多年的老朋友，当时明道云还叫梅花信息，两家老板以前创业时候也一起共事过。

任总这个人从前做产品，就属于不管做什么事，都会往消费级上面要求，哪怕他做的是一个工业品，也会往消费上靠，尤其是在技术产品上面，我们并不担心明道在技术开发方面有一些低水平的 bug 或者低水平问题，我们基于对他十几年的认识，了解他的做事风格，这与他个人的职业素养或者价值观有关。

但我认为这只是个巧合，因为我们也做过其他产品的选型，假设没有信任基础的情况下，我们开始从头做，我们的方法就是多家产品特点，表格化横向对比，从逻辑当中去寻找价值，并在合作当中考察合作伙伴的品质。

有一定的信任基础，让我愿意亲自花时间去了解这个东西。如果是按正常流程，我们会先把市面上的所有家找出来然后列张表，优势劣势列清楚排着做一遍后再进行选择，但是有信任关系的话，是可以直接跳过一些环节进入到实质性环节。

7. 关于低代码的看法

低代码本身并不神奇，只是人类正常需求被更有效地得到满足。标配就是软件行业的开发标准得到提升，要求你具有更强的配置性。另外标准软件可配置性能力的提升，吃的是以前需要定制软件的市场，所以既然我看好低代码，其实是不看好传统定制软件行业的发展前景。

我觉得低代码其实并没有走到革命性的远，只是这本来就是标品软件，该做好的事儿没做好。以前软件你要学要用也不会为你做出什么改变，或者说改变成本极高，现在将这个级别拉低，salesforce 20 年前就已经明白这个道理。

口述者：绿城建筑科技集团有限公司｜信息管理部经理｜李杨

绿城建筑科技集团是绿城下属的全资子集团，主要做建筑地产下游产品，例如装饰、幕墙类，以及一些产业投资配套。公司未来 5 年规划，主要是科技装修方向，这也是母公司绿城中国给我们的任务。

1. 为何要搭建低代码

我们主要是想解决重代码下，外包人员不好控制的情况，我们作为地产下游的乙方施工单位，施工行业本来就是利润薄的一个部门，整个行业对信息化投入比例都很小。当时公司也遇到信息化发展瓶颈，第一是不确定未来的发展方向，第二是不知道信息化该如何跟公司业务匹配。

那时候我和领导两个人一块出去考察，参观下来发现同行还都是用重代码，并未给我们带来很多的未来方向启示。后来一家航空公司的小伙伴，跟我们分享了他的想法，说我们可以去了解低代码工具，这样简道云的产品进入到我们视野，但在和简道云团队对接初期时，我们也没感觉它的优越性在哪里。直到慢慢看过一些案例，以及他们详细解决方案讲解，当时感觉找到了低代码工具作为公司信息化的方向。

2. 为何选择简道云

我们 2020 年 9 月发现简道云，开始对接和试用，今年 6 月正式使用，目前我们的综合管理系统的产业配套板块已经用简道云完全覆盖了，其他板块也在尝试覆盖。

首先我们整个流程体系都在用帆软的 FineReport 跟 FineBI 这两款产品，这两款产品一直合作下来，从高层到一线员工，对产品的认可倾向性很高。

第二简道云可以和帆软集成，从前端的数据收集，到报表和BI数据上的展现，整个链条上技术实现上没有障碍。

第三也是最重要的一点，我们最看重的是简道云的更新速度，基本上一个月两到三次迭代。简道云团队会时常询问我们的需求和建议，主动打电话回访，让我觉得这家公司是负责任的。这三点是我选择简道云最主要的原因。

我们在选型时期，也了解过很多其他家产品，没有选择其他家一个直观原因是不提供试用。简道云给我的感觉比较友好，不但提供试用还提供技术支持。别家产品一定要先购买才提供技术支持和试用，这其实已经给人一个拒之门外的感觉。

另外简道云提出各个行业的解决方案吸引到我们。例如我们后面想研究离散制造这块业务，花了大量精力想把这个行业做起来，一方面能让我们成长，我们的经验也能放到简道云上进行推广。简道云在技术上给我们提供免费支持，我们是共同研究、相辅相成的一种关系，其他平台方没有这种优势。

3. 关于实质性的业务帮助

最直观的一点就是降低了我们信息化的投入成本，包括系统建设成本，人员投入成本。尤其是现场施工劳务人员的用人成本，重代码的时候花大心思，投入了大量的金钱和精力，但信息化也做的并不好，这是主要的一个致命问题。

其次，它的建设周期比较短，常规一套项目大概需要半年以上才能开发出来。自从采用了简道云，我们基本上一个月就能出一套应用、功能或模块。成为一个良性循环，业务部门提出的业务需求我们快速响应，响应之后他们会主动的提更多需求，以前重代码开发时，响应不够及时，客户也就懒得再去提，到现在大家都积极主动的来提供改进措施，通过信息化手段来落地。

我们正在上线的幕墙业务模块，传统用重代码开发基本都要半年以上时间，而且做出来之后，业务方对我们做出来的这套软件系统也不是特别满意，有很多的吐槽点，比如我们的动态成本，在重代码的时候一直没做出来。

上简道云之后，7 月 12 号正式开始立项调研开发，今天已经开发测试完，下个月 10 号就正式上线。除去中间一个月疫情的时间，实际干活时间也就一个月左右。

第三个是需求变更少且容易调整。我们在用简道云开发时，就发现过一次需求变更，当天就将它调整过来，不会影响到框架业务。

第四个在数据上，通过通用的接口来对接我们的数据库，避免通过Excel手工干预数据的大量重复工作，极大提高上线速度。

在建筑行业内没有一家企业能做到完全的动态成本，我们在用重代码的时候也讲不透，这是我们行业的一个关键痛点。

上了简道云以后，我的研究方向是想用简道云工具来搭建实现我们的所有过程动态，包括投标成本、清标成本、过程成本，将这三个维度作为指标性参考来落地，对于我们后期预警以及计划具有很好的参考性。

后续我希望这个部门变成生产力部门，输出我们的行业解决方案和行业经验。不单单是建筑施工，而是多业态复合型企业，每个人带课题去研究综合性多业态的解决方案，让我们的信息化部门也可以产生效益。

4. 关于限制

长期使用之后，我们发现简道云平台能解决一些标准的、通用的业务逻辑，比如制造业 CRM 客户管理，而解决行业或企业定制的需求还有困难。

例如我们建筑行业 BIM 、CAD、图纸设计这块专用工具，简道云还不具备这类能力，后来我们只做了一个 CRM 的展示，BIM 还是接我们的专用工具。因此简道云还不能够去覆盖专业上的工具，只能服务一些流程上的业务。

5. 关于改变

行业经常说技术不懂业务，业务不懂技术。现在我们可以完全将这个拿掉。业务部门最了解需求，那想要什么需求自己画出来之后，由技术去发挥技术力量。我们之前做了估算，从人力上来讲，以前我们开发人员需要配两到三个，现在一个人就能做出相同内容。

现在公司整个层面对信息化的信心也高，信息化人员工作方向更明确，以前信息化更像是一个部门工具培训的边缘部门，现在从整个公司层面得到改观。

在团队建设上，以前我们的UI表单都是由技术人员构建后再将它画出来。现在业务部门想要什么自己来画，我们信息化人员只帮他去做数据逻辑关联上的底层事情，更多的精力就考虑放在对部门管理、公司要求、行业还有哪些难点，更多去关注解决方案的事情，对我们来讲也更有意义和价值。

6. 关于信任

为什么对简道云有这样的信任，一开始我也不了解简道云，不了解帆软，因为集团母公司在用，我们也就跟着在用 Report。我们是在跟简道云技术人员对接过程中，遇到技术问题请他们帮忙时，他们响应速度很快，所以信任是在这个层面建立的，可以放心的交给他来解决问题，这是我的主要观点。

因为我们的业务基本上都是 B 端，用简道云搭建我们的业务系统，可以缩短开发和项目时间，产生的良好效果能影响到我们整个绿城的体系，包括我们下游的一些客户，以及 B 端供应商，他们看到我们使用低代码获得的巨大收益，会把我们树立成标杆来学习。

7. 关于低代码畅想

未来 90% 以上的中小型企业会使用低代码搭建自己的业务系统，特别是对信息化投入不高的小型企业，低代码覆盖率高且推广起来会很快。

因为低代码具有开发周期短的优点，信息化含量高、投入高的大型企业或是跨国性公司，也会适当采用一些低代码的开发方式，我们的母公司就用到简道云去实现某一块功能。

我觉得每家公司都在逐渐意识到低代码的优势，其实我们不算走的很靠前，有很大一部分企业已经走在我们的前面。去年我们还很少听到低代码的声音，而今年身边一些同行业的竞争对手都在陆续尝试使用低代码。

口述者：富力集团CIO｜马剑

我们是一家综合性的房地产，以开发房地产为主营业务的集团型公司。富力在业务发展中追求多元化的目标，在酒店、商业文旅、医疗康养，包括设计建造等领域都有涉及。

1. 为何选择得帆云

2018 年底，我们内部就已经在看应用开发平台，包括一些技术走向，只不过当时市场上还没有很明确的概念和产品。后来在我们把周边一些配套体系逐一构建后，进入到平台选型，对比了行业内一些不同厂商，正式定下跟得帆合作。

作为用户来说，从以往IT建设的经验教训来说，我们希望它本身具有融合性又有开放性。选择得帆其实有优点也有缺点，我们相对看重的是他们的团队。

得帆是一家技术风格较为鲜明的公司，包括整个团队在解决企业内部特定的复杂问题上具备很多经验。他们在关键方面的提升能力，也符合B端企业真正在技术平台落地时所面临的一些困难需求。

第二个它本身的开放性没有太多的生态绑定，能够从我们企业的角度去实现与其他体系的结合，比如服务的治理和 API、流程和用户体系的集成。

第三个非常重要的方面，是需要从客户那里积累大量经验，这方面得帆实践经验会更成熟。我们所了解到得帆在很多客户这边，并不是以卖产品高溢价的方式，我印象里一直记得张桐总所说，如何评判成功项目：一是能收回钱，二是有后续合作(二期三期），三是能带客户去现场参观。我觉得这三方面是蛮实在的一种说法。

2. 关于上低代码的初衷

本身低代码要解决的是应用开发问题，如果从整个数字化转型或者是管理的角度，解决的又是一个效率问题，如何将现在不确定的业务在短时间内更好的给到用户，给到这个公司一个快速响应，解决的也是一种业务队伍变化速率上的理解问题。

在富力我们并不是叫低代码平台，叫做应用开发者体系，低代码是其中一环。现在整个的应用开发很大程度上是基于我们的各种多端的应用，包括基于互联网的应用。

这种情况下我们需要考虑，第一我们要有云计算的基础设施配套，能够支持基于现在原生的技术框架。比如现在整个的 docker 容器，能够便于我们最终在应用实践的形态层面，更好的适应现在这种模式。

第二需要在开发的整个的供应链条上进行拉通，包括 devOps、CMDB、这些要能够跟本身的开发工具去进行拉通和联动，它不是单一存在。

第三在基础网络安全层面要构建相应的能力去配套。要考虑到用户在使用应用中，会通过多端多链路的任何地点任何端去使用你的应用场景或功能。

所以除了可见功能之外，还需要有很强大的一种公共或者是共享服务能力，去将下层各类后台系统的内容进行一定封装改造，形成组件化的服务，以后低代码可能最终面向的是能够构建应用服务的市场。

3. 关于实质性的业务帮助

一种是平台的建设。

第二个是我们一些示范性的应用，也跟我们自身对于以后像特别是这种在企业中间还有其他的一种能力或者组织的转型有关系。

真正引入低代码之后，最大的影响实际是建立在组织相应的一些转型基础上。低代码跟用户沟通和设计的体验更好，会加快项目本身的成果孵化。能够在用户需求和预期上拉齐，对项目的风险控制，包括开发质量，以及整个的迭代周期都能起到促进。后面也会在相对有规范的方式下，注重原来专业化工作的纵深发展。

很多时候用户在使用中的问题包括新需求，要有一个很长的周期去解决。现在有了低代码和我们自己相关的研发体系配套，只需重点关注核心工作，把作为专业角色的能力去更好外延。所以我们并不是关注纯粹一个点上的问题，而是整套体系，在满足业务变化上更高质量的去理解和实现客户需求。

我们现在重点放在 iPaaS 和 aPaaS 上。iPaaS 层面我们更多是做集成能力相关，aPaaS 主要用于应用构建和共享服务的构建。

解决具体应用开发上面，第一怎么在整个开发的过程，对于角色或者是组织转型上起到一个推动作用，让大家重新定位和改变自己的工作方式，包括提升工作技能。

第二个是应用开发本身，能更精细化的管理整个产品的交互过程。结合我们自己研发体系，包括整个 devOps 的供应链，能够打开我们原来传统开发过程中的黑盒子，清楚的看到整个软件产品生产过程，并进行更好的把控。

第三个是我们在体系下面也在做相应的软件开发规范，去改变后边对于供应商的一些生态结构。前面关于设计大的原则把控我们已经足够清晰，就能找更多价格低廉多种类的供应商去参与到项目中。

4. 关于限制

其实我觉得任何工具，任何软件都有自己的边界。再去选择一个东西的时候，一定不是说因为看到了低代码，所以要去选低代码。首先要自问想要解决什么问题，现在转化成想达到的结果。

如果说现在有什么不足，我认为限制就是短时间里大部分没有业务性的解决方案，缺少一个业务模型，企业若没有积累沉淀自己的业务模型，低代码就只是一个小场景化的开发工具；而企业有相应的业务能力和业务积累后，就可以用低代码去进行相对复杂的业务应用重构。但通常低代码没有，这是一个普遍问题。

第二个就是围绕这个基础，可能有一些特定的应用场景和界面交互的方式构化。这些是原来应用厂商积累更深的地方，低代码还没有达到这个程度。

所以主要还是看人，它的缺点在于自身对于它的定位，还在于客户的一个选择和考虑，就怕是错用，或者把低代码的预期和价值抬得过高。不管是IT用户还是业务用户，在面对新概念的时候容易产生一种误区。特别像低代码技术性比较强，很多时候对于 IT 用户没法甄别。

5. 关于信任

不管是得帆跟我们合作，还是我们再去服务自己的客户，都是首先要诚信，因为没有用户的信任想做任何创新都不能够持续。

如果从IT的角度，很多公司在提科技以人为本或者科技向善，这里面最核心的就是说通过你的服务过程和产品体验。

另外在合作的过程中，对技术的信任也至关重要，大家要诚实讲出能做什么不能做什么，这个问题其实不必回避，不能为了销售行为去刻意夸大，永远不要忽视用户的判断力。

所以在跟客户沟通时不是在秀自己多好多强，让别人取得信任的前提是要传递价值，这个价值是基于别人需求的价值，要先看到别人的需求和你传达的东西是否匹配。

6. 关于低代码未来发展看法

我觉得这个东西一方面是要通过一些新的概念，去思考一些新的价值，概念可能会带来一些新的思考和创想，它不完全是坏的，但需要审慎一点，去看到它的本质和核心，解决问题才是关键。以前讲不要拿着榔头去找钉子，首先应该要去明确想解决的问题。

我认为低代码是阶段性的技术发展产物，以后会以不同的技术形式解决问题。现在低代码能够做应用、做场景、做服务，但当以后应用场景、服务触点、和形势发生变化后，需要有新的技术，现在的低代码就不能满足。

比如说最近看到像微软的 Hololens，它就是基于 VR 、AR 或者 3D 的一种场景来进行交互。但是低代码的生命期应该会蛮长，现在刚好处在炒作期，企业客户需要仔细甄别，也需要实践过程中能够真正运用得当。

我觉得以后大多数公司都会在自己的产品用到低代码，就像以前的 Java 架构，现在的云原生的支持容器架构，以后低代码会成为一个基本能力。但是基本的能力不代表着谁都可以做的很好，而且在企业的环境中间，不希望被生态绑定。

其实我觉得现在还是缺少一个真正能够得到用户信任有号召力的平台。但市场是多样化的，就像有很多大的云服务商，自己也提供云计算技术、以及 IaaS、PaaS，包括研发生态。

未来企业可能会将多种能力进行组合，我觉得这种生态意味着大家不会偏信某一家公司，而是会综合更多不同公司最好的能力来做组合。我始终认为低代码是一个阶段性，会在其他技术的推动下发生新的变化。