如何在组织中有效地使用低代码工具？

Thoughtworks 第 28 期技术雷达中提出，市场中低代码平台能力在近些年取得巨大进步，但依然主要集中在解决中低复杂度场景问题，当面对复杂的业务场景时，仍然存在一定的平台限制。所以建议企业考虑采用低代码技术前，仔细深入评估自己的需求和低代码技术之间的平衡—有界限地使用低代码平台。

主要要点

低代码采用率正在增长，但它只适用于某些特定场景，并非所有场景。

低代码被认为是传统开发流程和实践的替代方案。但决策者需要了解其限制，并围绕应用程序开发建立适当的防护措施。

在决定是否选择低代码之前，先提出正确的问题，以确定它是否适合特定的应用程序需求。

低代码工具和平台，可以使不同团队创建有价值的软件系统，而无需编写和维护大量的自定义代码库，这为低代码工具赢得了几乎相等数量的支持者和批评者。

然而，一些预测显示，到2025年，使用低代码工具和平台创建的新应用程序比例可能高达70％。而持续存在的开发人员短缺，正在推动企业探索加快软件交付和减轻工作负担的新方法，因此越来越多的组织开始探索低代码能为他们做什么。

低代码工具和平台的能力在近些年取得了显著的发展，但质疑仍然存在——这是有一定道理的。尽管低代码工具有潜力增强新一代所谓的“公民开发人员”的能力，并通过低代码实现简单功能的搭建，进而减轻开发团队的压力，但事实是它们仍然并不适用于每种开发场景。

确定低代码是否适合你，并最终获得它可能为你的业务带来的价值的第一步，是了解它最适合什么样的场景。

何时（以及何时不）使用低代码

有很多因素会促使组织采用低代码方式开发。以下是最常见的四种情况，以及低代码在每种情况下的适用性：

场景＃1：应对开发人员短缺

由于全球范围内对开发人才的需求仍然远超过供给，所以能够让用户构建强大软件的工具前景非常引人注目。但如果只是因为组织中缺乏成熟的开发和编码技能，而选择采用低代码技术，可能会带来不必要的麻烦。

如果没有熟练的开发人员和IT专家来监督业务团队使用低代码创建的内容，你将得到“没有策略支持的软件”：业务部门也许会不断地定制不同的应用，来解决数字化需求，但它们之间几乎无法关联或聚合。这将是一种无法扩展的场景，并且与平台化思维等领先实践完全不一致。IT 领导层需要制定相应策略，并采取适当的措施，允许在适当的情况下开发低代码应用或解决方案，使业务用户能够在不产生大型复杂问题（技术债务、无法扩展的系统等）的情况下解决重要问题。

场景＃2：支持业务快速增长

对于早期阶段的扩张，低代码可以帮助快速创建新功能和服务，而无需大幅投入开发资源，这反过来也能保证他们的软件不会成为组织快速发展的瓶颈。

然而，这些组织需要认识到，他们使用低代码平台创建的某些解决方案最终可能必须被替换掉。否则，他们可能会发现其基础设施的核心部分是建立在欠灵活的基础上的。而这对于许多使用低代码构建的应用程序来说的确是一个挑战。

为了从低代码中获得最大价值，成长中的企业应该使用它来快速创建他们需要的功能，但要做好规划和准备，在未来某个阶段它们不再被需要时，用更强大的功能取而代之。

场景＃3：构建新的核心业务软件

软件对你的业务越重要，低代码就越不可能成为构建和维护它的首要选择。这并不是因为低代码缺乏构建关键应用程序的能力或复杂性，而是因为这类应用需要能够轻松扩展、增长和转型，而并不是所有低代码平台和工具都具备这样的能力。

即使你的应用最初设计很适合低代码，但如果它对你的业务极端重要，那么未来设计很有可能需要发展。你可能需要添加更复杂的功能，将其与其他应用程序集成或将其迁移到新的企业平台。如果业务部门和 IT 部门之间的合作没有进行适当的规划，这些事情就会变得更加困难。

场景＃4：增强业务部门能力

如果你的目标是赋予业务部门更大的技术自主权，并使他们成为公民开发人员，那么采用低代码工具是一个很好的方法。大部分低代码工具和平台是易于用户上手，团队可以快速开始管理和增强功能以满足自己的需求。

需要注意的是，即使他们手中拥有最直观的工具，IT 部门也应该参与低代码工具的选择、规划和扩展。并非所有低代码工具都是一样的，选择具有足够可扩展性、可伸缩性并且可以集成到更广泛的 IT 生态系统中的工具非常重要。

平衡的重要性

当低代码首次出现时，围绕该技术的大部分叙述将其定位为传统开发的替代方案——它将减少甚至消除组织对熟练开发人员的依赖。

事实证明，这种描述完全站不住脚，无论是它对低代码设定的不切实际的期望，还是它如何将低代码和传统开发流程定位为敌人或对立面。

问题不应该是“低代码还是传统代码？”而应该是“低代码在哪里可以最好地支持和补充我们的专家开发人员？”

通过在正确的场景中启用和鼓励低代码（通常是增强小型业务团队使用的软件功能），你可以加速交付、缩短周期时间并快速s满足业务需求，而无需完全废除当前的开发实践。

在保留核心 IT 和开发团队提供的所有控制、治理和战略输入的同时，增强业务部门能力并加速交付。两全其美是可能的，但前提是你取得了适当的平衡。

在选择低代码平台之前，领导者需要回答五个问题

在你开始选择低代码平台或工具集之前，确定低代码是否非常适合你当前的业务和需求非常重要。

你需要进行一些深入的评估，但回答以下这些问题会是一个很好的起点：

有多少人会使用你正在构建的软件？

更多的用户意味着更多的需求要适应，他有可能成为组织的核心业务软件，并扩展到低代码安全区域以外的位置（需要评估考虑结合传统开发）。
你想构建的是核心软件还是支持（边缘）软件？

你的软件越接近核心业务，那么尽可能地保持其灵活、可扩展和系统间关联性就越重要——你需要重新评估是否全部应用低代码技术来构建和维护它。
随着采用率的不断提高，你现在构建的软件是否会变得至关重要？

如果你已经知道需要构建或现代化的软件系统对业务极其重要，这恐怕不会是低代码的使用场景，除非你愿意接受低代码平台的限制。
你的团队准备好成为公民开发者了吗？

为了让低代码发挥其全部的潜在价值，你的团队需要有足够的热情采用它，并开始创建自己的应用。他们还需要有一定的软件应用熟练度，以及正确的心态，才能创建真正有价值的应用。
你真正想解决什么问题？

例如，如果你希望清除大量积压的工作，那么可能有比采用低代码更好的方法来实现这一目标。你可能试图解决流程效率低下的问题，而不是解决潜在的挑战。当然，你还是可以定义出通过低代码解决方案才能满足的特定需求。