低代码赋能业务人员

中国软件行业协会在《2020中国低代码开发平台十大发展趋势》中提到2021年市场对于应用开发的需求将五倍于IT公司的产能。为填补这一产量缺口，低代码除了帮助现有IT技术人员提升工作效率之外，还能带来更低的学习门槛，让业务人员具备一定的软件开发能力，进一步扩充软件开发力量，加速信息化建设。

一、什么是业务开发者？

在低代码技术被命名之前，国际知名的研究机构们就提出了“业务开发者/平民开发者”的概念。这两个概念与专业开发者对应，专指那些向业务部门汇报但开发能力来辅助业务发展的员工。这些人和向IT部门报告的专业开发者不同，他们的主要工作职责是业务发展，软件开发只是一个辅助性工作，通常不会有相关的考核指标，得到的资源也较为有限。在传统的编码开发时代，业务开发者较为少见，有能力从事辅助性软件开发的业务人员主要集中在数据分析师、软件公司的程序员（程序员的主要工作是开发软件产品或对外交付软件项目，而不是辅助性的软件工具）等具备编程能力的人群。而低代码技术的出现，让更多的业务人员可以成为业务开发者，比如构建订单管理应用的销售主管、人事档案系统的HR、库存盘点APP的库管人员等。

整体而言，业务开发者具备以下特征：

• 具备技能：通常没有计算机相关的教育背景，部分掌握Excel等办公软件的常用功能

• 考核指标：能否完成业务目标是核心指标，通常不包含信息化建设相关内容

• 学习意愿：不得不参与软件开发，通常没有主动学习IT相关技术的动力和投入

二、低代码对业务开发者的价值

与帮助IT技术人员提升软件开发效率不同，低代码对于大多数业务开发者而言，是解决了“能不能开发软件”的问题。这就意味着，业务人员可以根据自身的应用场景，快速构建起对应的软件应用，减少了与IT部门协调确认的沟通成本，在IT部门资源紧缺的背景下，尽快扫清信息化死角。

业务开发者构建的应用主要有以下几类，除数据报表应用的业务逻辑复杂度较高而且通常需要与第三方系统集成，对业务开发者有较高的学习能力要求外，其他应用场景相对简单，更适合业务开发者使用低代码构建。

三、业务开发者面临的管理和技术挑战

从理论上讲，业务人员从事软件开发确实有很高的价值，可以有效降低企业在信息化的投入，并尽快见到成效。然而，从管理到技术，业务开发者和IT技术人员都存在较大的差异，需要面临更大的挑战。从研究机构的数据上看，业务开发者的学习门槛和应用场景深度广度的矛盾已经成为了很多企业实施低代码技术失败的主要原因。所以，在引入低代码技术，让业务开发者承担企业信息化建设之前，企业仍然需要做好预期管理和组织管理优化，循序渐进。

3.1 软件质量：“短平快”优先于可维护性

相比于有明确发展规划和专项预算保障的IT部门，业务部门对信息化的要求通常与当前面临的问题紧密相关。有需要解决的问题，而且IT部门无法及时解决时，业务团队才会临时做出预算，为自己开发软件。

向业务部门汇报的业务开发者在软件开发上的投入更加碎片化，峰值虽然较高，但不可持续。而且，随着软件应用走上正轨，业务部门大概率会在第一时间将后续的维护工作移交给IT部门，即从业务开发者交接给IT技术人员。如果在较短的时间周期内，业务开发者没有按照预期完成软件的开发和交付，业务部门就失去了将其留在自己团队的最大理由。该项目则很可能直接搁浅或移交给IT团队，进入开发队列。而对于业务开发者而言，项目已经失败了。

所以，大多数业务开发者会更关注如何以最快的速度将应用开发完成并投入使用，实现“能用”的基础目标，而不是将精力投入到软件质量和可维护性等方面。“短平快”成为业务开发者构建应用的关键词，而这很可能互对软件的可维护性埋下不可忽视的隐患。相比之下，需要长期维护信息系统的IT部门中，IT技术人员则必须将质量与可维护性（包含功能扩展、数据一致性、系统集成等）放在重要的地位，否则就是给自己和其他团队成员“挖坑”，难以持续发展。

3.2 学习偏好：对学习投入更加敏感

不可否认，业务开发者在技术能力上可能会比IT技术人员者稍微弱一些，但这更像是业务开发者运行模式的结果，而不是原因。

为了进一步达到“短平快”的目标，应对不可持续的软件开发工作，业务开发者通常对学习投入更加敏感。除非通过当前岗位之外的工作熟练掌握了某些软件开发技能，业务开发者在学习软件开发技术中投入的每一分钟，都会拖慢项目交付的速度，扩大项目失败的风险。这是很多业务开发者最不愿意看到的情况。

抛开项目本身，相比于IT团队完善的职业发展道路和持续的实战机会，业务开发者在软件开发技术上的学习显得更加没有“性价比”。因为，业务能力才是业务开发者最显著的优势，也是其最大资本；而开发能力，还不知道什么时候才会再次用到。如何让业务开发者也有通过学习不断提升开发能力的机会和动力，是摆在业务开发者领导面前的难题。

3.3 风险偏好：对运维风险更加敏感

从学习投入低、更关注短期效果两个特点，我们不难看出业务开发者构建的应用比IT技术人员的质量风险更高一些。然而，业务团队对数据错误、系统可用性低、数据安全性差等系统运维风险的敏感性却不会因为开发者不同而展现出明显的差异。更麻烦的是，业务开发者本身处在业务团队，一旦他们构建的应用出现问题，所有损失将由该业务团队自行承担。在很多中大型企业中，这种风险不容忽视。

事实上，决定风险敏感度的首要因素是该软件的应用场景。在应用场景的类型上，企业上下对生产、销售、投资等核心业务系统的风险敏感度更高；OA、人事等边缘应用的敏感度更低。在数据操作能力上，负责人对仅读取数据的数据分析应用更加放心；而对那些需要写入数据，尤其是向核心业务系统写入数据的ERP二开等应用，要求更加严格。所以，让IT部门的技术人员专注于核心业务场景、需要写入数据的场景，边缘应用请相关业务团队的业务开发者参与，是一个被广泛接受的“最佳实践”。

四、“业务人员做软件”的风险与出路

2021年12月，国内知名IT媒体——T研究发布了《2021中国低代码/零代码全景产业研究报告》，其中重点关注了采用表单驱动技术路线，提供给业务开发者的使用的低代码开发平台在企业落地的挑战，并通过走访已经引入低代码但效果不如预期的企业客户，汇总了业务人员使用低代码平台开发软件应用失败的主要原因。

报告显示，“低代码的能力有限，无法支撑复杂业务场景”和“即使经过培训，业务人员依然无法顺畅使用低代码平台”两者成为失败原因的前两名。结合报告的上下文，T研究揭示了在“业务人员开发软件”的目标下，低代码平台的两难问题：既不简单易用、也不能打硬仗。

不能否认，软件开发是一个将现实中的问题用计算机所擅长的方式重新进行梳理和呈现的过程。在软件开发的过程中，开发者不但需要理解业务场景在现实中的运作逻辑，还需要具备必要的计算机相关知识，才能将其“翻译成”计算机擅长的样子。不同的应用场景中，这个翻译的难度存在很大的差异。比如，在简单的数据填报应用中，现实中的一张问卷可以直接对应为软件中的一个表单，而问卷中的问题则对应了表单中的数据字段。这类应用通常也称为“单表应用”，即便没有受过任何编程训练，甚至在大学中没有学习过计算机原理，业务开发者依然可以在低代码平台上轻松地完成整个应用的构建。但是，对于出入库管理这种业务逻辑稍显复杂的场景来说，现实中的一张出库单则需要对应成“出库单表”、“出库单明细表”、“商品元数据表”、“仓库元数据表”等多个数据表，才能确保这个应用具备一定的可维护性，并保障数据的一致性。开发这个类型的应用，需要业务开发者具备一定的计算机知识，或者至少有意愿在学习数据库相关知识上投入数小时甚至数天的时间。对于大多数企业中为业务成果负责的业务开发者来说，为了做系统而需要学习数据库知识，这种投入显然是不现实的。

综上所述，企业在为业务人员引入低代码技术时，需要清楚地认识到业务开发者所擅长的应用开发场景，正确管理对低代码技术的预期。在平台选择上，建议将平台技术能力的优先级提升到学习门槛之上，优先保障该低代码平台可以满足复杂应用场景所需，避免后期因切换低代码平台而造成返工。在实践上有如下建议，供有意推进业务人员开发软件的企业信息化决策者参考：

• 推荐业务开发者构建使用频率不高，不需要与企业核心业务系统集成的单表型应用，如数据填报和流程管理

• 如果业务开发者有意愿、有投入来学习更多计算机基础知识，特别是数据库相关知识，可以逐步参与到档案管理、数据报表等稍复杂的多表应用开发

• 如果业务开发者构建的应用需要长期使用，推荐IT技术部门参与数据库结构设计等底层关键技术环节的评审，降低未来的维护成本

• 如涉及到与核心业务系统集成，强烈推荐IT技术部门进行全程指导和审查，以确保业务开发者构建的应用不会影响到企业核心系统的稳定运行。

扩展阅读

• 【技术博客】平民开发者≠技术差！真正发挥平民开发者的创造力，光有低代码还不够