背景简介
请允许我想象一下这样的场景:一个刚起步的金融服务专业人士在一个资源有限的咨询团队中工作,期望在有限的预算范围内,用个性化的服务不断给客户带去惊喜。(听起来很熟悉,对吗?)他们的团队在增长,客户越来越大,合同越来越苛刻,但他们的关注水平并没有改变。
通常,“敏捷”和“精益”会变成“在没有足够开发人员资源的情况下保持运营”和“使用其他工具将超出预算”。
处于这种状况下的企业可以将他们在客户服务方面的技能和经验、在金融服务方面的专业知识与那些了解他们业务语言的软件工程师结合在一起,并从中受益。即便是在资金充足、结构健全的企业中,在寻找、雇佣、聘用和整合人才方面的预算和资源也有很多限制,而且他们也仍然能够从一个能够重新培训现有人才、使他们变得更加“危险”的解决方案中受益。
企业内部的低代码/无代码变革
为推动数字转型,软件开发正在向“内部”转移——迅速取代终端用户计算(EUC)——企业需要快速创新并利用好这些工具,他们要面临的风险从来没有像现在这么高过。特别是金融服务公司,他们试图从集中化和精简现有的软件开发能力中获益,也包括从头开始构建这种能力(之前是外包出去的)。
这样做是为了提升安全性和减少阻力。金融服务公司需要处理大量的敏感数据,安全是机构和客户都关心的主要问题。将软件开发保持在企业内部,可以减少可能被网络犯罪分子利用的漏洞,减少可信任的敏感数据方以及敏感数据传输方,客户的资产负债表上也少了一项需要担心的问题,即现有的团队如何能够更快、更便宜地提供相同水平的服务!
低代码/无代码平台正在快速提升企业快速开发健壮、具备安全性的应用程序的能力。这些例子包括非常有针对性的Genesis,一个专门为金融市场构建的低代码/无代码平台,以及“一战式”的Appian,一个用于构建企业应用程序的通用低代码/无代码平台。在低代码/无代码的世界里,“公民”开发者被授权构建应用程序,缓解了 IT 部门的压力。
我们是有可能实现快速、稳定、高可用的软件开发的,事实上,它们是互补的结果。在这篇文章中,我将分享一些用于有效提升软件开发效率的可行性建议。我们将 Nicole Forsgren 博士等人所著的《Accelerate》一书所提及的四个关键指标和持续交付基金会提供的 2021 年持续交付状态报告所呈现的行业数据作为参考。
1. 部署频率
该指标的定义为:向用户发布变更的频率,可以是每半年一次,也可以是一天多次。
使用低代码/无代码平台可以减少摩擦,加快更新和发布之间的交付速度,从而提高部署频率。通过消除对 IT 团队部署的依赖,将编码过程简化为逻辑步骤,可以在短时间内做出必要的更新,快速识别并修复逻辑序列中出现的问题。如果低代码平台能够帮你快速而简单地构建额外的特性,那么你也能够同样快速地将它们发布给最终用户。
提高部署频率的一些额外策略:为团队配备充足的人员;调整企业结构,确保不存在可能会拖慢工作流程的冗余;采用自动化部署;在开发过程中将 QA 作为优先考虑事项;在整个项目时间表中留出足够的测试时间。
除此之外,对用户反馈做出响应,快速迭代修复错误,这是向用户表现出你的积极性的一种关键的方法。根据《Accelerate》一书的说法,“精英”的部署频率是指“按需(每天多次)部署”,这要求一个团队随时准备向用户发布更新,无论是否重要。持续交付报告显示,在部署频率方面,只有十分之一的开发人员能够做到“精英”部署。
你的应用程序可以解决某些问题,但不能解决所有问题。来自客户的挑战会不断变化,你的解决方案也要跟着变。
2. 变更的发布时间
该指标的定义为:向用户发布变更需要多长时间,可以是半年,也可以是一小时。
与部署频率类似,高效的变更发布时间(从代码提交到在生产环境中成功运行需要多长时间)体现了企业或团队的响应速度。这个指标关注的是变更实现的速度,而不是频率。2021 年持续交付状态报告显示,对于近三分之二的开发人员来说,从提交代码到在生产环境中成功运行至少需要一周的时间。
优化这一指标可以让用户知道你的更新和实现流程是没有问题的,你专注于尽可能快地保持用户体验的更新。
在缩短变更发布时间方面,低代码/无代码平台和工具具有显著的潜力。低代码平台提供了环境灵活性,可以使用传统的编程环境、傻瓜式操作环境或两者的结合。低码平台提供了一系列逻辑单元,我们可以随意组合它们,底层程序员或者“公民开发者”都能理解和使用它们(相比传统的编码),这有可能让整个团队都能向用户发布变更,从而节省了时间,打开了新的视角。有了低代码/无代码平台,更多的团队成员可以与客户一起迭代工作,快速构建一系列实验,以最小可行性规模来测试他们的想法是否可行。我们可以在较短的变更或反馈周期内知道哪些想法与市场契合,从而在这些想法上加大投入。
一些缩短变更发布时间的策略:利用多个开发环境对软件进行整体测试,尽早发现问题;与 QA 紧密合作,确保漏洞被移除;来自管理者清晰的期望设定和项目管理,让工作流程更顺畅。
3. 恢复服务的时间
该指标定义为:恢复服务要多长时间,可以是半年,也可以是一小时。
各种非预期的中断、服务事故和能力缺陷,都会对产品的声誉、品牌和用户关系造成严重威胁。人们可以接受这些事情的发生,虽然你无法控制何时发生,但可以控制在发生中断事件时快速做出响应。2021 年持续交付状态报告显示,有一半的开发人员表示他们可以在不到一天的时间内就能从非预期中断中恢复服务。
低代码/无代码平台,特别是那些能够显示关键质量指标和运行状态的平台,可以极大地简化识别和修复服务事故的过程。在比传统代码更高的抽象级别上可视化查看部署的能力是快速定位和纠正那些可能导致发生中断的坏代码的关键。低代码/无代码平台为工程师和管理者提供了高层的可视化视图,帮助他们更好地协调恢复策略。
缩短服务恢复时间的其他策略:在开发时小心翼翼,避免大量潜在的中断;在企业中培养一种带有紧迫感的文化;为事故捕获和报告开发一个健壮的仪表盘,确保不会遗漏任何一个事故。
4. 变更失败率
该指标定义为:出现故障的次数,可以是 76%到 100%部署失败,也可以是 0 到 15%部署失败。
通过使用低代码/无代码平台来简化和抽象软件开发过程,开发团队可以降低他们的变更失败率。当低代码/无代码平台具备正确的抽象级别,它们可以提供更多的“黄金路径”来构建系统,降低潜在错误的数量。变更失败率通常会随着团队经验的增长而降低,低代码/无代码平台可以在这方面提供帮助,它们可以让团队成员更快上手,帮助他们有效利用平台,并引导他们采用最佳实践。
《Accelerate》一书根据变更发布到生产环境后导致的服务降级(例如,导致服务损害或服务中断)和后续需要补救(例如,需要进行修补、回滚、向前修复、打补丁)的百分比将该指标划分为不同的组(或者说范围)。换句话说,就是你的产品的故障率是怎样的?根据书中的定义,可接受的频率为 0-15%,也就是说,你的产品大约有 10%的时间发生故障并导致服务中断。异常值的失败率高达 46-60%(见下图)。
变更失败率越低,说明你的产品越健壮,它有强大的代码基础,防止出现频繁的服务降级,并在一开始就“预判”到了潜在的问题。
与恢复服务的时间类似,优化变更失败率的一些策略:在开发时小心翼翼,避免大量潜在的中断;在企业中培养一种带有紧迫感的文化;为事故捕获和报告开发一个健壮的仪表盘,确保不会遗漏任何一个事故。此外,确保有一个健壮的问题管理系统,在事故发生时能够立即捕获它们。
这些在低代码系统中是什么样子的?
正在进行数字化转型的企业必须采用可以引导它们走向持续交付的原则和实践——例如,持续集成、测试自动化、持续交付、自动化安全,等等。低代码系统的这 4 个关键指标不仅为企业提供了软件交付成功的度量,也是企业能力的风向标。
低代码/无代码系统是企业实现这些关键指标的一种可行方法,不仅事关“速度”(通过部署频率和变更发布时间来衡量),也事关“稳定性”(通过变更失败率和服务恢复时间来衡量)。
团队应该利用这些平台来减少摩擦,提高开发和发布之间的交付速度。将编码过程简化为逻辑步骤,可以快速识别和修补潜在的问题。如果低代码平台可以帮你的团队快速简单地构建出额外的特性,你就可以快速地将它们发布给最终用户。与传统的代码开发相比,它们具有固有的效率。调试得到了简化,补丁、新特性或对现有代码的更改都可以直接实现。团队中的底层程序员甚至是“公民开发人员”都可以轻松地掌握和利用这些工具,整个团队都可以将变更发布给用户,不仅节省了时间,也打开了新的视角。
此外,低代码/无代码平台最大的一个优点是为团队提供了可视化部署的能力,这比传统代码高了一个层面,这是快速定位和修复可能导致停机或需要进行更新的代码的关键。代码少了,出错的可能性也就降低了,团队可以将他们的注意力集中在持续改进和交付上,提升业务表现和用户满意度。
为什么这对企业来说很重要
那些优先考虑 DevOps 并加快软件开发和采用速度的企业将比那些没有进行类似投资的企业更具有竞争优势。金融服务公司应该继续在加速软件开发,特别是低代码和无代码平台方面投入,原因如下。
这些公司必须增强其软件产品的稳定性,并提升交付速度。持续交付报告显示,在所有行业中,对金融服务公司的软件交付“稳定性”要求最高,交付“速度”排名居中。这是有道理的,因为金融服务产品无法承受故障,故障率和服务恢复时间都有可能对个人、企业或商业客户造成重大后果。
交付速度(通过部署频率和变更发布时间来衡量)不是什么大问题,因为金融服务公司更关注产品的功能性,而不是交付给用户的速度。然而,随着银行和其他金融机构面临来自科技公司和金融科技初创企业创新商业模式的冲击,能否留住客户很可能变成能以多快的速度为低代码/无代码的采用奠定基础,以提高与其他行业相比本已平庸的软件开发和交付速度。
与传统编码相比,低代码/无代码系统有助于简化软件开发过程,从而进一步加强稳定性,以防止故障的发生。此外,这些工具可以帮助金融机构显著加快软件交付速度,为客户提供新的、更有用的产品。
让企业了解低代码/无代码平台的重要性
虽然一些分析师认为,在 DevOps 加速方面,行业已经“跨越了鸿沟”(借用 Geoffrey Moore 的说法),但广泛采用低代码/无代码和数字化转型的最大障碍仍然在于金融社区的员工、高管和用户(客户)缺乏对它们了解。
在推广低代码/无代码解决方案时,关键的是要接触金融专业人士,并用他们能够接受的方式与他们沟通。软件开发加速平台确实为整个企业提供了巨大的价值,而更为重要的是要向金融服务专业人员提供有意义的用例,将潜在的解决方案与他们所面临的业务挑战联系起来,并向他们说明短期和长期的 ROI。
企业应该深入挖掘现有人才,用这些工具给他们重新赋能,获得竞争优势,而不是去寻找外部开发供应商,因为他们不会像内部员工那么了解企业的业务。
结论
低代码和无代码平台在金融市场上具有巨大的潜力——从简单的业务流程管理(BPM)到更复杂的用途。它们为业务专业人员赋能,让他们能够为客户创建应用程序,在传统软件开发教育和人才(即工程或 IT 部门)之外,以一种前所未有的方式创新和解决问题。
客户总是对低成本、快速上线时间和最低限度的最佳解决方案感兴趣。随着行业的发展和低代码/无代码平台变得越来越复杂,对于金融服务专业人员来说,在企业中寻求采用这些工具将变得越来越重要,以免自己被更多着眼于未来的竞争对手所抛弃。
作者简介:
Tracy Miranda 是持续交付基金会的执行董事。她曾在 CloudBees 担任开源社区总监,在那里她领导开源团队,围绕 Jenkins 和 Jenkins X OSS 创建繁荣的开源社区。她是 Eclipse 开源社区的前董事会成员和资深人士,有 IDE、EDA 和半导体方面的背景。
原文链接:
Faster Financial Software Development Using Low Code: Focusing on the Four Key Metrics
评论