跳到主要内容

如何利用低代码弥合 IT 与业务之间的差距

如何利用低代码弥合 IT 与业务之间的差距

Arn Burggraaf 个人资料照片

过去几年,传统开发发生了巨大变化。过去,开发完全由专业程序员完成,他们唯一的重点是尽可能高效地创建应用程序。开发应用程序背后的商业原理在他们的编码决策中几乎没有起到什么作用。开发人员的责任只是用尽可能少的精心编写的代码来构建他们被指示开发的应用程序。

然而,以这种方式规划和构建应用程序有点像从两端开始铺设火车轨道。一端的市场规划和另一端的编码可能需要非常谨慎和熟练。但是,当业务和开发团队在中间相遇时,他们不仅会发现他们建造的轨道不对齐,而且一个团队为有轨电车建造轨道,另一个团队为子弹头列车建造轨道。

这就是为什么公司更频繁地雇佣既有商业知识又有编程知识的人——能够从中间延伸出这条轨道的人。Gartner 称这类专业人士 业务技术人员 并将它们定义为 “为内部和外部业务用途构建技术或分析能力,但存在于 IT 部门之外的员工。” Gartner 估计 商业技术人员占劳动力的 41%.

商业技术专家的影响

在代码编写者的时代,业务领导会告诉开发团队:“我们需要一个能满足市场需求的应用程序。”开发过程会消失在黑匣子中,几个月后,一个应用程序就会完全成型。

该系统的问题在于,几个月后,市场可能会变成完全不同的景象。 Mendix, 罗尔德·克鲁特会说:“应用程序到最后都会过时。”他的意思是,当你完成一个应用程序的开发时,你对促使你创建这个应用程序的业务需求的理解就已经发生了变化。

业务技术人员在应用交付生态系统中的存在使业务需求在开发过程中始终处于首位。根据 Gartner 的说法,将业务技术人员整合到多学科开发团队中 使该团队的表现率翻倍Gartner预计,到2024年,80%的技术服务将由商业技术人员构建。

为了最大限度地发挥这种性能影响,公司正在将其业务技术人员的技能与强调不断迭代而不是最终交付应用程序的开发流程相结合。这使他们能够在每个迭代周期中不断评估其业务需求,并将其与应用程序产生的业务价值进行比较。

重要的招聘素质

公司越来越多地试图通过提供客户体验来脱颖而出。但 Gartner 发现,70% 的客户体验领导者 在创建项目时遇到困难. 聘请了解客户旅程的业务技术人员是确保开发项目与客户体验需求保持一致的关键方法。低代码和无代码平台不需要丰富的开发经验,因此将业务技术人员纳入员工队伍变得容易得多。任何有创新想法的员工都可以在经过最低限度的平台培训后将其变为现实。

开发的民主化使得组织在做出招聘决定时改变了他们的优先事项。当您组建团队来创建创新解决方案或核心应用程序时,您不再需要关注候选人的技术知识或他们的开发专业知识。您不再需要在他们的简历上寻找正确的要点。

相反,你可以根据一些品质来评判候选人,这些品质可能比较无形,但也是组织成功不可或缺的,比如创造力、商业头脑和分析能力。招聘标准从寻找知道如何使用工具的人转变为寻找知道如何用工具构建什么的人。

改变建造方式

组织雇用人员构建应用程序的变化不可避免地带来了组织构建这些应用程序的方式的变化。创建复杂的、跨企业解决方案的时代即将结束。这些类型的项目需要深入的开发专业知识,而业务技术人员正在将这种专业知识挤出组织。它们还需要将资源和控制权集中在 IT 团队手中,而低代码工具正在使这种组织模式过时。

相反,组织必须开始分散应用程序开发。他们需要相信每个团队都知道哪些解决方案最适合他们的需求,并为这些团队提供构建这些解决方案的工具。多年来,这种外包开发责任的做法,即“影子 IT”,因担心合规风险和不兼容的系统而受到组织的反对。但商业技术人员 让影子 IT 走出阴影.

这并不是说应用程序开发已经变成了一场混战。协调和​​领导对于及时高效地构建有效的解决方案仍然至关重要。有几种模式可以遵循, Mendix 有帮助客户按照这些模型进行组织的经验。

卓越中心例如,允许组织创建一个中央存储库,其中包含开发专业知识、可重用组件和治理指导,业务团队可以在构建其专业解决方案时访问这些存储库。这些团队可以构建为 融合团队 它将具有不同知识专业(编码、销售、市场分析、物流、合规)的成员聚集在一起,以在特定时间范围内创造出特定的产品。

以下是有关融合团队的更多信息:

每个人的任务都是一样的:创造成功

应用程序开发民主化的最终目标是,借助 Mendix 低代码平台的最终目标是停止 IT 人员从一端开始、业务人员从另一端开始的模式。我从来不明白这一点。无论你来自销售、人力资源、IT 还是营销部门,每个人都应该从同一个业务目标开始,对吧?所以让我们停止关注候选人的背景、培训或专业知识。让我们关注他们是否会帮助我们的业务取得成功,然后将他们所需的工具交到他们手中,以取得成功并帮助公司扩大规模。

选择你的语言