真蓝海还是伪命题？上手低代码后，我开发了一套“临时工单”应用

2021年被一些行业观察人士预判为“低代码之年”。据Forrester分析师预测，在这一年将有75%的企业软件采用低代码技术构建；Gartner最新预测也指出，这一年全球低代码开发技术市场总额将达到138亿美元，比2020年增长22.6%。

低代码站在了风口之上，这已是一个毋庸置疑的事实。

但低代码实质上并非一个新鲜事物，甚至可以追溯到40年前IBM的快速应用程序开发工具（RAD）。早年间低代码一度备受争议，一方面不被专业开发人员承认，另一方面对低代码的目标用户-不懂代码的人来讲，操作门槛依然高，也并不受到认可。

由于云计算的发展、产品成熟度的完善，加之疫情对数字化需求的催化，多种原因推动低代码走入大众视野。近期，从阿里“云”“钉”加码，到腾讯，再到近期IBM、西门子等国外厂商加入，低代码借着“人人都是开发者”的风进入主赛道。

炙手可热，但低代码真的适合每一个人吗？真的能让一个代码小白也成为开发者吗？今天我们就来“实战”一下，用日常用的办公平台钉钉实际搭建一款应用，来寻求以上这些问题的答案。

实操：用低代码开发一个“临时工单”应用

为了充分体验搭建过程，笔者打算尝试搭建一个内容部门与其他部门需求对接所使用的应用，有点像内容团队的“临时工单”，来解决目前协同办公软件分工颗粒度过大、跨部门临时需求得不到重视、执行者无法了解任务优先级、领导不好把控进度等问题。

该应用希望实现的是：

1、临时需求能够通过需求方的录入，自动成为一个待分配的工作。

2、由相应负责人根据具体情况来分配人员执行。

3、执行人员可以通过了解任务紧迫程度，自行排列优先级，完成后上传结果。

4、由相应分工负责人和需求提出方来验收结果。

5、全程进度要一目了然，方便追责，有统计数据归档。

如果放在以前，不会编程的笔者只能对外求助，而这样一个不大不小的需求，也很难得到重视。现在我们可以考虑拿低代码平台尝试自己搭建，钉钉内有宜搭、简道云、氚云等低代码产品，本次我们选择宜搭来实操。

宜搭内可以选择空白应用搭建，也可以选择基于既有模板搭建。模板中心提供人事管理、行政管理、IT服务、疫情防控、财务报销、生产管理，采购管理等类型，数量超过了50个。

根据实际需求，笔者在模板中选择的是看似不太搭界的售后工单模板，看中的就是工单管理中服务申请、待派工单、待接工单、待处理工单、已处理工单以及满意度回访这一整套的售后管理流程，而这套逻辑正好适用于笔者的需求。

实际详细页面的编辑情况就像上方的动图一样，所有的内容都是组件形式，比如笔者想在页面内加入评分模块，只需要拖拽到相应位置即可。一阵疯狂的重命名、删减、拖拽之后，应用就基本有了雏形，可以试用了。

当然，如果需要实现一些复杂的功能，或者现有的组件并不能满足需求，目前还是需要代码和一些函数逻辑的。所以低代码对于编程小白而言，仍有一定的局限性，但对于有一定编程基础的人，可以方便、快捷很多，省去很多基础操作。

完成全部调整后，应用上线，邀请同事实测一下成果。同事在填写并发起申请后，相应人员会收到需求的消息提示。

点击可以查看需求的详情，相关人员来负责任务的审批工作，通过的话就开始分工操作。当然，如果不合理自然也可以拒绝。

通过之后可以安排相应的执行人员，完成需求的推进。

执行人员处理完成任务后，会有一个验收的过程，由需求提出者和分工负责人来进行验收、评价，以确认需求结束。

在整个过程中，也可以很清晰地查看到项目的进度，任务在哪个时间进行到了哪一步，卡在了哪里，都很明确。预期功能通过简单修改相同逻辑的“售后工单”模板确实得到了实现。

在测试过程中，我们发现不论应用是否上线，都是可以随时去调整的，比如我们实测时候同事发现部分环节应该对权限管理进行调整，这确实是笔者搭建时遗忘了，笔者抓紧去添加关于这部分的设置就可以了。

体验小结：简单，但依然存在一定门槛

应用的搭建非常迅速，整个过程用时大概是一个多小时，期间主要用时都是梳理应用的逻辑，也就是想结构、想每一个地方该是什么，实际去动手的工作量反倒是不多。

事实上，大家看了笔者的搭建过程应该会明白，用低代码搭建应用很简单，甚至要比PPT套模板要简单得多。在理清应用的逻辑的情况下，就像搭积木或者拼乐高玩具，只需要会用一点点电脑就可以完成搭建操作。

1、实际使用确实可以不用代码，完成一些简单应用的搭建。纯粹不需代码时，可能更像是搭建，开发的感觉比较弱，拖拽可以解决绝大部分需求。

2、模板多（且会越来越多），如果碰到适合的模板，基于模板搭建会更快，原因在于模板很多时候已经提供了应用的设计逻辑，直接改造即可。

3、后期调整简单，上线后可根据实际需求随时微调，不用来回找客服、找IT。

4、并且诸如我们常挂在嘴边的“大数据”，低代码平台也提供数据分析的类目和插件，模板会在数量和匹配程度上不断延伸，这意味着搭建应用时修改的地方会越来越少。也就是说，低代码平台在提高效率方面还会不断的强化。

5、当然，笔者在体验中也发现了一些使用中的问题：

1）应用框架误删后无法恢复，只能重新搭建，无法通过“撤销”挽回，说明还不是特别智能，存在优化空间。

2）对于编程小白仍有一定局限性，偏复杂的应用和功能会涉及到函数的调用，仍需要编程基础才能理解。

3）应用首页PC版横向布局看起来会比较奇怪，和移动端的适配有一些优化空间。

低代码的价值在哪？

那么，仅仅是“低门槛”和“高效率”就值得整个行业追捧吗？当然不是。虽然低代码至今依然存在一些局限性，但至少初步做到了将IT开发的能力赋予给不懂IT的人，这会带来不少价值。

第一，低代码精简了数字化的难度。软件千千万，但为什么数字化转型很成功的传统企业却不多？一旦有成果显著的，也被称为各行各业的标杆。

软件具备通用性，即便是行业化软件，也是挖掘、梳理、凝聚特定行业的普遍问题后研发，大部分的数字化难点在“如何将通用软件，变成契合特定一家企业的系统”。这就出现大量边边角角但又特别重要的细碎需求，也是数字化落地的重要卡点。

低代码让这些边角需求的数字化，变得简单。通用系统有了，销售部门、生产部门、财务部门的差异需求，简单的自己也能解决，复杂的再找专业人士。

第二，低代码解放了创造力，为企业带来创新的可能。以前，应用是IT或者外包公司来开发，他们可能对行业有一些理解，但依然很难完全理解需求方的想法，比如IT清楚医院科室问诊的大类需求，但无法一一照顾到某一科室的具体情况。那该科室的医生是不是了解？当医生可以随手开发应用，解决自己工作的问题，还可以不断将新需求、新想法补充进来，沉淀、创新的可能性更大。

第三，对于个人，是一种高效工作的工具。以上两点更多是从公司的视角来论述，但低代码的受众还是要个人，熟练运用这种工具，可以快速搭建一些日常工作，甚至生活中的小应用，不用“等人帮你解决问题”。

实战体验中，总体来讲用低代码开发一些表单、流程类应用，要比想象中的更加简单。

低代码确实能降低开发的准入门槛，让更加了解业务流程的、但没有编程基础的人有可能参与到应用的构建中，这与“让听得见炮声的人来做决策”异曲同工。