大热的“无代码”是伪需求吗?

“无代码运动”是几千年以来驱动技术创新的核心原则的演变: 不断对以前仅一小部分人可用的过程工具或介质进行公民化拓展并通过此倍增人类创造的潜力。

上一篇文章,分享了关于“无代码”产品设计易用性和健壮性对立统一的一些思考。今天想聊聊无代码之于软件工程发展历史的必然性。

“无代码运动”是几千年以来驱动技术创新的核心原则的演变:

不断对以前仅一小部分人可用的过程工具或介质进行公民化拓展并通过此倍增人类创造的潜力。

各个领域的公民化运动

在印刷机问世之前,批量生产书籍的唯一方法是手工制作,这使得传播信息和知识不仅很慢而且昂贵。一本羊皮纸的《圣经》在中世纪可是土豪才能拥有的资产,相当于一座葡萄园的价格。

书籍如此昂贵,你还会为中世纪大部分人是文盲而感到惊奇吗?

然而1440年印刷机的发明以崭新的方式大规模生产和发行新文本成为可能。现如今,如果你想让文字发布到世界各地,只需要敲击几下键盘即可。

随着这些基础技术的公民化普及,世界范围内的出版数量与日俱增(配图为200年中每100万人中新书的出版数量增长)

同样的事情也发生在音乐和电影领域,技术及其使用方式对人的创作产生了巨大影响。过去我们需要专业的录音棚以及价格昂贵的录制设备才能进行相关创作。

如今更多的数字化分发渠道、线上流量的剧增、自媒体平台的兴起(BiliBili、抖音、youtube等)以及公民化设备的技术跃迁(移动手机的摄像头质量在过去几年有了大幅度提升)让人们可以在没有太多前期资源的情况下依然分享自己的创意和想法。

在B站,每天有10W条视频被发布,而在youtube上,每天上传的内容可以连续播放80年。这里面90%的内容都是通过手机拍摄的。————《影视飓风》
每年发布的新电影数量

更低成本、更多渠道的媒体技术使用让这个时代成为了创造力爆棚的时代。人们使用某种媒介的机会越多,我们越容易获得这种机会、创造力、产出和创新。

那么在“软件设计开发”这个领域,历史会重演吗?

软件研发的历史

再回答这个问题之前,让我们先回顾一下软件工程的大致发展历程:

1、汇编时代(1946—1953 年)

“远古时代”的软件是通过机器语言编写的,机器语言是内置在计算机电路中的指令,由 0 和 1 组成(二进制数字)。因此,只有少数专业人员能够为计算机编写程序。

2、高级程序语言时期(1954—1964 年)

该阶段软件开始使用高级语言(与之对应机器语言和汇编语言被称为低级语言)编写,高级语言的指令形式类似于自然语言和数学语言,不仅容易学习,方便编程,一定程度上提高了程序的可读性。

在这个时期,进行软件编写工作的人开始被称为:“程序员”。

3、结构化程序理论设计阶段(1965—1970 年)

该阶段处于结构化程序设计理论,伴随着的是处理器的运算速度大幅度的提高。因此需要编写一种程序,使所有计算机资源处于计算机的控制中,这种程序就是操作系统。

数据库管理系统 DBMS(Database Management System)也是在这一时期出现的。

1968 年,北大西洋公约组织的计算机科学家在联邦德国召开国际会议并正式提出了:“软件工程”这个名词。

4、结构化程序时代(1971—1989 年)

这个阶段标志性的事件有:C语言的面世、Macintosh 的可视化图形界面彻底改变了人机交互的方式、Pascal 及Modula-2 等基于结构化规则设计的语言面世。在这个时期,更多用途的软件逐渐面世,例如文字处理、电子制表、数据库管理软件等。

5、大发展阶段(1990至今)

万维网(World Wide Web)的出现开启了万物互联的时代;面向对象的程序设计逐步代替了结构化程序设计,成为最流行的程序设计技术。这个时期,Microsoft 公司的崛起让软件工程进入到了大发展阶段。

早期互联网

开发模式的大升级下依然存在的问题

完善的系统软件、丰富的系统开发工具、商品化应用程序大量出现以及通信技术和计算机网络的飞速发展,极大的降低了软件研发的门槛和成本。

从国内的研发生态角度看这个趋势,最具影响力的事件则是2018年微信小程序提出的“云开发”理念。“云开发”让前端工程师从前到后完成业务发开的闭环。“云开发”将“DB优化”、“弹性扩容”、“攻击防护”、“灾备处理”等进行了封装,让程序员可以专注于业务实现,这是一种开发模式的大升级。

即便如此,计算机、软件工程的门槛依然存在,对于大部分人来说是一项难以置信的专业任务。软件工程极高的壁垒所带来的问题包 含但不限于以下的几项:

问题1:生产模式在没有本质改变——高居不下的边际成本

软件研发的成本不仅仅是在一期交付上,更多的是后续不断地迭代成本,需求的增删改所带来的研发边际成本非常之高。

不少的企业级软件项目在多年的迭代维护后往往面临“举步维艰”的地步:代码维护的压力越大、关键的研发岗位经不起人员变动、项目推动困难……

问题2:需求增长速度与生产消化速度之间的矛盾

这几乎是一个业内共识,即需求的消化速度永远赶不上产生的速度。需求池的维护以及排期的制定是困扰产品经理以及项目经理的大难题。

消费级互联网日趋饱和的大背景下,产业互联网全面崛起。信息化成为了所有企业绕不开的话题,这势必会带来企业级软件需求的激增。

近年来,我国SaaS市场规模占全球比重不断提升,由5年前的2.93%提高到今年的7.65%,预计2020年还会有明显提高。如何更快、更好地响应这些需求,是一个亟待解决的问题。

问题3:需求方与生产方之间难以逾越的沟通壁垒

程序思维和业务思维是两种截然不同的思维模式。程序不懂业务、业务不懂程序,沟通效率的地下已经成为软件型项目最大的拦路虎。

————

为了尽可能好的解决(严格意义上说来应该是“适应”)上述的这些问题,各种各样的团队提出了各个角度的解决方案(主要偏向于方法论):

  • 敏捷研发:快迭代、小版本的模式降低高边际成本所带来的风险;
  • MVP:最小化的可行产品,在最小的范围测试客户群痛点,降低前期的验证成本。
  • DevOps:通过促进开发、技术运营和质保部门之间的沟通、协作与整合从而提升开发效率的概念。
  • ……

方法论及理念只能部分解决问题,核心的问题依然存在。如今,我们依然需要更好的解决方案、更快的迭代及反馈。

软件研发的公民化运动

在《人月神话》中,Brooks博士认为软件工程所要解决的任务分为两个:

主要任务 : 打造构成抽象软件实体的复杂概念结构。

短短一句话中充满了复杂的定义,简单来说就是将抽象需求进行具象化地整理。产品经理每天的工作就是围绕这个“任务”展开的。在《用户体验要素》这本书中,作者Garrett将这个命题进行了分解,通过5大要素及1个简洁的工作流清晰地讲解将抽象需求整合成具象模型的方法。(配图五大要素)

从抽象需求到具象产品过程中经历的5个环节

次要任务 : 使用编程语言表达这些抽象实体映射成机器语言。

紧接着的次要任务则不难理解了,根本的目的则是主要任务所产出的具象化模型映射成为机器能够理解的语言。上文中我们提到的软件工程的历史则是“如何更好地解决次要任务”的历史。

而如今的无代码产品则是在新的时代背景下对于“次要任务”的新的解答,其核心是解决了两个任务关键节点之间的根本脱节。

更高模块化的场景中,无代码产品具备极高的可用性

主要任务在漫长的历史上产生了极大的变化,例如toC和toB场景下的软件从一开始的需求开始就是迥异的;相比较toC场景,toB场景的主要任务在漫长的时间里并没有太多本质的区别,反而某种程度上逐步提炼出了最佳实践,模块化的程度更高了,这也直接影响了2B领域无代码技术的逐渐成熟。

已经存在的一些单项能力去代码化无一例外都是围绕企业服务场景的:表单、报表、流程、数据库、页面、事件……的定义能力;这些能力在各自的领域大放异彩,具备极高的可用性。

公民化运动:从“编写”到“创建”

上世纪60年代,软件的编写者自身往往是使用者,几经波折,我们几乎迎来了“软件的使用者是设计者自身”的时代:

如果你需要一个个人网站,webflow可以满足你;

如果你需要一个业务数据库,airtable可以满足你:

如果你需要报表,PowerBI 可以满足你:

使用zapier,你可以生成一个工作流,并且串联多个系统。

在从前,当你有一些创意一些想法的时候,往往需要大量的准备和投入才能实现,过程中的内容一个环节都可能导致失败。但如今,当你准备好的时候,一个个成熟的无代码平台也都准备好随时听候差遣了。软件消费者和软件生产者之间的界限越来越模糊,某种意义上来说我们正在经历一场变革。

无代码平台并不是什么新鲜的事情,甚至具备了极高的可用性,如果将这些已有的成熟单项能力进行了 集成,那么我们可以做很多事情。而轻流则是这中间产品矩阵完备,兼具健壮性和易用性的代表之一。

无代码产品的基本框架介绍

轻流的无代码aPaaS架构:

轻流讲系统搭建抽象成四个维度的工作,分别是:

  1. 展现层
  2. 业务层
  3. 模型层
  4. 整合层

展现层、业务层、模型层的结合满足业务系统搭建的需求,整合层则解决了企业内多系统数据孤岛的问题

展现层(界面引擎)

提供了丰富的页面框架及样式自定义能力,通过可视化的图形配置界面,减免了大量JS/CSS/HTML的代码。

    • 多种业务组件
    • 多端适配运行良好
    • 访问权限控制(连接企业内外)
可视化的界面设计/搭建工具

业务层(流程引擎、表单引擎、报表引擎、事件引擎)

通过业务人员最熟悉的表单界面为载体承载大量前端自定义事件。解决了大量业务逻辑问题,无代码的流程引擎支持串联自动化事件,我们称之为Q-Robot,帮助业务人员解放双手。

    • 表单构建、前后端计算能力、
    • 流程模型可视化搭建
    • 业务所需的报表构建
    • 丰富的事件拓展、支持跨系统执行
拖拽式的表单构建器国内最早的模块化的流程引擎业务所需的报表构建丰富的开箱即用的事件引擎,支持跨系统执行

模型层(数据库引擎)

面向业务人员的数据库定义工具,尽可能地将操作“去代码化”,以业务人员能够理解的交互和可视化界面呈现给用户。上手简单、配置灵活。

    • 可视化的数据库建立、
    • 支持业务所需的数据增删改查功能
    • 基于权限角色分配数据权限
    • ......
可视化搭建的业务数据库,上手门槛极低

整合层(连接引擎)

高度封装的连接模块,简单地配置即可进行跨系统的数据连接,将ERP、CRM中的数据进行调用和同步,消灭数据孤岛,为遗留系统提供现代化的可能。

    • Q-Source数据源自定义
    • Q-Linker跨系统数据关联
    • Q-Reminder 跨系统提醒推送
    • Q-Authentication鉴权自定义
    • SSO单点登录、webhook、openAPI
高度封装的连接模块

面向不同受众(用户画像)的无代码平台,设计出发点也是不同的:

  • 面向业务人员:表单交互模型搭建入手 (轻流的选择)
  • 面向技术人员:数据库模型搭建入手

轻流的产品设计初衷并非是要替代程序员原本的工作,就如前面我们讲到的 “对以前仅一小部分人可用的过程工具或介质进行公民化拓展,并通过此倍增人类创造的潜力 ” ,这才是轻流真正的目的。

Give people wonderful tools and they'll do wonderful things————苹果对于上面这句话的理解

基于这样一个愿景,我们眼下最重要要解决的则是“如何让业务人员可以尽可能快的体验到“亲手创造”业务系统的自在和快乐”这个问题。“易用性”的重要性在这个背景下被放大了。

与此同时,易用性和健壮度的对立统一则成了我们所面对最棘手的难题。我们在不断摸索中,也开始找到一些方法,后续慢慢会跟大家分享我们的思考。

让我们来聊聊破坏性创新

今年初去世的 克里斯坦森 毕生最伟大的著作《创新者的窘境》中提到一概念叫:破坏性创新;

这个理念深深影响了苹果、微软等巨头企业;书中所描述的“以下犯上”在整个商业史上比比皆是:个人计算机对于计算机市场的颠覆、小容量编写硬盘对大型企业级硬盘的颠覆……

甚至到如今,我们的身边所充斥着那些我们无法忽视的趋势:移动端计算平台的崛起、计算能力主导的影像系统、新能源汽车……每天都在为我们演示破坏性的创新如果通过“猥琐”的发育逐渐成为主流需求而改变历史轨迹。

11月11日发布的苹果最新计算平台,掀起了科技圈的一阵热议

近些年,在2B企业级市场,我们看到具备破坏性创新特点的模式或产品不断涌现:云计算、SaaS化……

我们认为无代码平台也是这个信息化浪潮中的一员。

一些无法忽视的趋势

“到2024年,无代码/低代码应用程序开发将占应用程序开发活动的65%以上。”————Gartner预测

在刚刚过去的国庆节,大洋彼岸的北美,一个新的无代码独角兽悄悄地崛起——unqork宣布已完成20700万美元的C轮融资,估值为20亿美元。总融资达3.5亿美元。

稍早一些的9月14日,业务数据库自定义工具Airtable宣布以26亿美元的估值募集了1.85亿美元的D轮融资,这个估值比2018年底的11亿美元又翻了一番还多。而轻流 在疫情这样一个特殊时期下,也获得了来自源码资本领投的数千万A轮融资。

很多人都觉得 如今的无代码平台“噱头大于实际”、“更像是玩具”、“可用性还比较低”。

对于从业的我们来说,我们也不否认通过“无代码平台”完全替代现有企业及软件交付模式在现阶段还不是很切实际。

不过在这样一个积累即是壁垒的赛道,明天总归是充满光明的~

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表