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

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清楚医院科室问诊的大类需求,但无法一一照顾到某一科室的具体情况。那该科室的医生是不是了解?当医生可以随手开发应用,解决自己工作的问题,还可以不断将新需求、新想法补充进来,沉淀、创新的可能性更大。

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

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

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。