现如今，公司商业应用程序的数量和种类多到让人无所适从，举例来说，一家中等规模的公司就有 800 多个。虽然很多人喜欢将这说成是 SaaS 失控的一个案例，但这并不是真正的问题所在。真正的问题是，这些应用程序中的大多数现如今都是由非开发人员管理的。

我所说的开发人员并不是指会编码的人。我认为，不一定非要会编码才能成为一名开发人员。更重要的是像工程师一样思考。当一家企业的 CRM、HCM、ERP、LMS、MAP 以及几十甚至几百个第三方应用程序，被那些没有接受过训练、不会像开发人员那样思考的人修改、构建和管理时，他们所追求的短期结果会导致长期的灾难。

在这篇文章中，我将说明一下，为什么我认为 2022 年适合这些公司迎头赶上，开始培训并推动人们转型为商业应用无代码开发人员。

没有工程师会导致技术债务瘫痪

我所接触的很多中大型公司都会遇到一个简单的问题：管理员想取消商业应用程序中的一个字段，那可能是 Salesforce、NetSuite 或 Zendesk。他们怀疑没有什么地方使用这个字段。他们没有看到任何活动，如果能把它清理掉就好了。但是，他们无法确定。他们以前试过，这个字段对他们的一个公式来说至关重要，这个公式出问题会导致业务部门的部分仪表板失效，因为担心这个，所以他们没有采取任何行动。Salto 首席执行官 Rami Tamir 称这是 技术债务瘫痪 。放大到企业范围，这是一个严重的问题。

比如说，销售团队想改变选单上的选项，但 CRM 团队花了一个季度的时间才弄明白，而在这一个季度里，有不少交易被误导了。或者，董事会决定进行 IPO，但却意识到，无法使他们混乱的 NetSuite 实例及时符合 SOX 标准。或者，营销团队想要加强电子邮件活动来解决潜在客户短缺的问题，但商业应用程序团队却需要 6 个月的时间来移植这些部分。

这些问题会以各种方式表现出来。考虑下我从客户那里听到的这三个真实的例子。

一家国际化 SaaS 公司使用了 NetSuite ERP。在他们财年的最后一天，许多关键的报表突然停止了工作，他们无法结束这个季度。整个团队争分夺秒，但直到深夜才发现，有人在生产中改变了一些“保存的搜索”，却不知道他们的实现中有其他关键的部分在使用。

一家大型零售商使用 Zendesk 作为客户支持系统。一名管理员直接在生产环境中定义触发器时犯了一个小错误，向几十万不知情的客户发了一封令人困惑的电子邮件，然后变成了大量新的工单。

一家大型的公共 SaaS 公司无法弄清楚为什么它的销售线索转化率出现大幅下降。经过几个月的分析，该公司终于发现，由于 Salesforce 中有一个工作流卡住了但未被检测到，所以就没有把某项活动的线索分配给销售代表。这些线索就这样搁置在那里，无人问津。

所有这些问题都会对资产负债表产生实实在在的影响。它们使企业的竞争力下降。随着这些问题的复杂化，企业的发展速度会越来越慢，而那些规模相对较小的、灵活的竞争对手将悄悄地赶超他们。无论企业在允许每个业务部门选择自己的系统以快速行动方面做了什么权衡，最终都会为错误和失误所扼杀。而这一切主要都是因为这些系统不是在受过培训的开发人员的指导下开发的。

开发人员是汲取了六十年智慧的人

如果公司希望他们的商业系统在其发展过程中保持正常运行，就需要解决两个问题。第一个是关注软件开发领域，并以良好的实践为指导，比如 组织中使用的DevOps和敏捷开发方法 。

近 60 年来，软件开发人员一直在处理与如今的商业应用经理类似的问题：他们需要一种方法，让许多远程团队协同构建一个高度分布式的系统。这需要通过质量检查来确保没有漏洞，需要预生产环境来确保测试不会导致什么后果，需要版本控制来维护应用程序的多个版本，以防出现问题。

如果开发人员专门负责商业应用，他们就会把这些习惯和工具带入这个过程。他们会从可重用性、关注点分离和弹性的角度来思考问题，会使用类似于 Git 这样的工具来管理分叉、分支、合并和提交修改，允许多人协作并减少人为错误。也许最重要的是有整体思维。

如今，大多数管理商业应用的团队都处于孤岛之中。你有 CRM 团队，财务应用团队，还有各种形式的“公民开发者”购买和管理的 SaaS，每个人都在努力减轻自己团队的工作。这些系统中的大多数都大到足以成为自己的生态系统，并包含许多产品。它们也会集成并分享数据。深谙软件开发方法和原则的人，对这个问题的看法与如今大多数人的看法大不相同：这不是将 800 多个产品集成在一起。它们是一个产品——公司的操作系统——新增的任何产品在构建和管理时都需要考虑整体的完整性。

而这只是第一个问题。第二个问题是：许多商业应用的构建也不是为了让那些具有开发思维的人去管理。

也就是说，大多数商业系统的构建都考虑到了用户的成长。构建的系统界面是为了让终端用户能够完成工作，而不是让管理员把一切都安排好。此外，如果从应用程序生命周期发展的角度考虑，构建只是为了解决第一步的问题。

图片来源

也就是说，它们没有提供原生功能，让你可以做开发人员可能会想做的事，如版本管理、搜索整个代码库的能力、管理多个环境的能力，以及在某些情况下，将变更从沙盒推送到生产环境的基本能力。现在，有些应用提供“开发”环境，但很少能提供你所需要的一切。

值得庆幸的是，第二个问题的解决方法就是第一个问题的解决方法：把软件开发人员的知识教给更多的商业系统管理员。经常，开发人员并没有他们需要的所有系统，因此，他们会构建或借用他们需要的东西来完成工作，使用 Git 工具将他们正在构建的东西抽象成可管理的块，使用工单系统来记录和排定优先级，并在需要时构建自己的工具。

如果商业系统管理员经过培训后开始像开发人员一样思考，那么他们就会开始争取更多这样的功能，我敢打赌，更多的商业系统供应商会构建这些功能。如果他们不这样做，那些新科“开发人员”将像工程师一样，希望能自己构建。

无代码，没问题

还记得之前的那三个真实的案例吗？那些在使用 NetSuite、Zendesk 和 Salesforce 时遇到问题的公司？其中每一家都采用了无代码 DevOps 工具和方法，构建系统防护栏。

这家使用 NetSuite 的国际化 SaaS 公司已经为其最重要的配置实现了告警。如果有人对保存的搜索所做的修改会影响结束本季度工作，那么管理员就会收到告警。

使用 Zendesk 的大型零售商现在禁止管理员直接修改生产环境。相反，他们从 DevOps 中借鉴了“版本管理”和沙盒的做法——每个管理员在自己的沙盒中开发配置，然后将其移到另一个沙盒中进行整合，再移到另一个沙盒中进行测试，然后才在生产环境中实施。

这家错失销售机会的大型公共 SaaS 公司现在使用了一个 DevOps 工具，让它可以查看每个 Salesforce 组织的完整“蓝图”，并能够进行检查和修改。当有重要的工作流不工作时，他们就可以发现并测试，然后在几天而不是几个月内修复它。

是时候培养无代码开发人员了

如果商业应用世界从过去 60 年的软件开发思维、框架和方法中吸取了经验，那么你看到的技术债务瘫痪就会少很多。销售和营销团队因运营受阻的情况会更少。公司发展受商业系统阻碍的情况也会更少。

我相信，系统应该和业务同步发展，并支持业务的增长。实现这一目标的唯一途径是增加无代码开发人员。

作者简介：

Gil Hoffer是 Salto 首席技术官和联合创始人。这是一家软件即服务（SaaS）应用集中式管理工具供应商，帮助业务团队获得商业应用的控制和可见性，其方式类似于 DevOps 对 IT 的改革。他曾任甲骨文公司软件开发副总裁和以色列国防军首席技术官。

原文链接：It’s Time to Start Growing No-Code Developers

链接: https://www.fly63.com/article/detial/11899