是时候开始培训无代码开发人员了。

目前，公司的商务APP数量和种类多得令人望而却步，如一家中型公司就有800多家。 很多人喜欢把这说成是SaaS失控的一个例子，但这不是真正的问题。 真正的问题是，这些APP应用程序大部分目前由非开发人员管理。 我说的开发者不是会编码的人。 我想如果不会编码，就不一定不能成为开发者。 更重要的是，像工程师一样思考。 如果一家企业的CRM、HCM、ERP、LMS、MAP和几十到几百个第三方APP由未经培训、不像开发人员那样思考的人员进行更改、构建和管理，则他们需要的短期在这篇文章中，我将解释为什么我认为这些公司适合在2022年赶上来，并开始培训，让人们转变为商业APP的无代码开发者。

没有工程师会导致技术债务瘫痪。在我接触的许多中小型企业中，问题很简单。 管理员想取消业务APP证明中的字段。 那可能是销售基金、网站、Zendesk。 他们怀疑没有地方使用这个字段。 他们没有看到任何活动，所以能打扫它就好了。 但他们不能确定。 我以前试过，这个字段对他们的公式非常重要，如果这个公式出现问题，业务部门的一些仪表板就会失效。 担心这个，他们什么也没做。 Salto首席执行官Rami Tamir将其称为技术债务瘫痪。 扩大到企业范围是个严重的问题。 例如，销售团队试图改变菜单选项，但CRM团队花了一个季度才明白。 在这个季度，很多交易都被误解了。 或者，董事会决定进行IPO，但发现无法让他们陷入混乱的NetSuite实例及时符合了SOX标准。 或者，营销团队试图加强电子邮件活动以解决潜在客户短缺问题，但业务APP团队需要六个月的时间来移植这些部分。 这些问题以各种各样的方式出现。 想想我从客户那里听到的这三个真正的例子吧。 某国际化SaaS公司使用了NetSuite ERP。 在他们财政年度的最后一天，许多重要报告突然中止了工作，他们无法结束这个季度。 整个团队争分夺秒，直到深夜，才有人在生产中更改了“搜索保存”，却不知道他们的实现还有其他重要部分。 一家大型零售商使用Zendesk作为客户支持系统。 一位管理员在生产环境中直接定义触发器时犯了一个小错误，向数十万名不认识的客户发送了令人困惑的电子邮件，成为了大量的新工作单。 一家大型公共SaaS公司未能查明为什么销售线索转化率大幅下降。 经过几个月的分析，该公司终于发现Salesforce中堵塞了工作流，但没有将某个活动的线索分配给销售代表。 这些线索就那样放在那里，无人问津。 所有这些问题都会对资产负债表产生真正的影响。 会降低企业的竞争力。 随着这些问题的复杂化，企业的增长速度越来越慢，规模相对较小、灵活的竞争对手悄悄地赶超他们。 无论企业为了让各业务部门能够选择自己的系统进行快速行动而做出了什么样的权衡，最终都会因为失误和失误而被扼杀。 因为这些系统主要不是在受过训练的开发人员的指导下开发的。

开发者是一个获得了60年智慧的人，如果公司希望业务系统在其发展过程中正常运行，需要解决两个问题。 第一，关注软件开发领域，指导良好的实践，包括组织使用的DevOps和敏捷开发方法。 在过去的60年里，软件开发人员一直在处理与现在的业务APP应用经理同样的问题。 需要一种方法，让许多远程团队合作构建高度分布式的系统。 这需要通过质量检查来确保没有漏洞，需要提前构建生产环境以确保测试不会产生任何结果，还需要进行版本控制以维护多个版本的APP应用程序，从而避免出现问题。 如果开发者专门从事业务APP应用，他们会将这些习惯和工具带入这个过程。 他们从可复用性、关注点分离和灵活性的角度考虑问题，使用Git这样的工具管理分支、分支、合并和修改提交，多人协作以减少人为错误。 也许最重要的是有整体的思考。 目前，管理业务APP运营的团队大多位于孤岛上。 您有一个CRM团队、一个财务和APP团队，以及一个由各种形式的“公民开发人员”购买和管理的SaaS，每个人都在努力减少自己团队的工作量。 这些系统大多大到足以成为自己的生态系统，包含很多产品。 合并和共享数据。 熟悉软件开发方法和原则的人对这个问题的看法与当今许多人的看法大相径庭。 这不是要整合800多个产品。 这些是——个产品的操作系统——中的新功能，在构建和管理时必须考虑整体完整性。 这是第一个问题。 第二个问题是，很多商业APP的构建也不是为了由具有开发思维的人来管理。 这意味着，许多业务系统都是在考虑用户发展的基础上构建的。 的系统界面的构建是为了帮助最终用户完成工作，而不是让管理员安排一切。 另外，从APP应用的生命周期发展的角度来考虑，构建只是为了解决第一步的问题。

图像源也就是说，它没有提供开发人员想做的任何本机功能，包括版本控制、搜索整个代码库的能力、管理多个环境的能力，以及在某些情况下将更改从沙箱推送至生产环境的基本能力。 目前，一些APP应用程序提供了“开发”环境，但很少能提供所需的一切。 幸运的是，第二个问题的解决方法是第一个问题的解决方法，就是向更多的商业系统管理员传授软件开发者的知识。 开发人员往往没有所有必需的系统，因此他们构建或借用所需的内容来完成工作，然后使用Git工具将正在构建的内容抽象为可管理的块，使用工作单系统记录优先级，并根据需要构建自己的工具。 当业务系统管理员经过培训并开始像开发人员一样思考时，他们就会开始获得更多这样的功能。 我想可能有更多的商业系统提供商在构建这些功能。 如果他们不这么做，那些新科的“开发者”就像工程师一样，希望能自己构建。

没有代码，没关系。 还记得前面三个真实的案例吗？ 使用NetSuite、Zendesk和Salesforce时遇到问题的公司是？ 各家采用无编码的DevOps工具和方法，搭建系统防护栏。 这家使用NetSuite的国际化SaaS公司对最重要的配置发出了警告。 如果对保存的搜索进行更改可能会影响季度工作的完成，管理员将收到警告。 使用Zendesk的大型零售商目前禁止管理员直接修改生产环境。 相反，从DevOps学到了“版本控制”和沙箱方法——每个管理员都在自己的沙箱中开发配置，将其移动到另一个沙箱中进行集成，然后移动到另一个沙箱中进行测试，并在生产中实施。 这家错过销售机会的大型公共SaaS公司现在可以通过DevOps工具查看各销售团队的完整“蓝图”，并进行检查和修改。 如果关键工作流不起作用，他们可以发现并测试它，然后在几天而不是几个月内修复。

是培养无代码开发者的时候了。 如果商业APP世界从过去60年的软件开发思维、框架和方法中吸取经验，看到的技术债务就会少很多。 销售团队和营销团队很少会影响运营。 公司的发展受到商业系统阻碍的情况也越来越少。 我相信系统应该与业务同步发展，支持业务的发展。 实现这一点的唯一方法是增加无代码开发者。 作者： Gil Hoffer是Salto首席技术官和联合创始人。 它是软件即服务( SaaS ) APP应用程序集中管理工具的提供商，可以帮助业务团队控制和查看业务APP应用程序，就像通过DevOps进行IT改革一样。 他曾任甲骨文公司软件开发副总裁和以色列国防军首席技术官。 原文链接： it’stimetostartgrowingno-code developers