我们为什么会失败？

在今天的网络中，我们站在前人的肩膀上，在他们已取得的成就的基础上继续前进。

失败就源于没有认识到这一点。

如果你曾经进入过公司的 IT 部门，那就去 DevOps 楼层吧。迎接你的将是一支人手不足的开发团队，他们戴着耳机，眼睛因为盯着屏幕而红肿。他们很可能太过专注，以至于在被问到问题时都不会回答。

他们为什么如此专注和睡眼惺忪？我见过传统开发人员为自己从头开始构建应用程序而感到自豪。如果有足够的时间和资源，喜欢自己动手从头开始构建可能会很棒，但对于资金有限的小项目来说，这往往是项目的失败。当像低代码这样的工具出现时，传统开发人员往往会对它们嗤之以鼻。挑战在哪里！

从头开始构建应用程序似乎需要很长时间。无法依赖其他人的工作可能会让简单的构建变得不必要地复杂。具有讽刺意味的是，当今没有一个现实世界的应用程序不依赖于 Node.js 或 Java 中的一些预构建库。

使用低代码平台 Mendix，它允许你从市场采购 Mendix- 社区构建的模块与预构建的 Node.js 库的概念相同。它消除了构建过程中不必要的复杂性，让您轻松交付最终结果。

有时，你没有可以利用的东西。这时你必须进行大量复杂的编码，在这种情况下，你希望公司其他人可以重复使用。在这种情况下，大多数公司仍会花时间制作可重复使用的组件， Mendix 试图进一步简化这一流程，但创建了一个内部公司市场，您可以在其中托管每个自定义扩展，您的公司可以在公司的网站和应用程序之间创建和共享特性和功能，同时安全地保护您的知识产权。

传统代码与低代码：一个实际的例子

让我们以创建数字化客户入职流程的想法来展示差异。

一家企业要求其开发团队开发一款用于客户入职的应用程序。

该应用程序需要具备以下功能：

• 与 Dropbox 集成以存储客户的数据和文档
• 查找客户地址
• 扫描重要文件并从中提取信息的能力
• 具有以数字方式签署和审查文件的能力。

以此为参考，公司的业务分析师为他们的 DevOps 团队创建了四个用户故事供其执行。

1) 作为用户，我希望与 Dropbox 集成，以便我可以将客户的文档存储在云中。

2）作为用户，我希望有自动地址查找功能，以便我可以轻松找到客户的地址。

3）作为用户，我希望能够使用该设备的相机扫描重要文件。

4) 作为用户，我希望能够以数字方式审查和签署文件。

由于部门内有两个团队，且没有其他新的活跃项目，因此公司决定让两个团队创建应用程序，并让它们在内部黑客马拉松中一决高下。

团队 1 是低代码团队，主要使用 Mendix 来构建和托管他们的应用程序。该团队由一名技术娴熟的开发人员、一名利用业余时间学习编程的财务部会计和一名擅长设计网站和应用程序的营销部设计师组成。

团队 2 由三名传统开发人员组成：一名 Java 开发人员、一名 C# 开发人员和一名 Node.js 开发人员。在这两种情况下，团队还可以接触更大的传统 Scrum 利益相关者，例如 QA 和业务分析师。

两周后，两支队伍向利益相关者展示了他们的应用，轮流展示他们的应用如何满足挑战中列出的用户故事。最终，胜者是第一队。

评委们审阅了提交的作品，并根据每个用户故事对其进行了评估。让我们来看看他们看到了什么。

1) 作为用户，我希望与 Dropbox 集成，以便我可以将客户的文档存储在云中。

团队 1 立即意识到有一个预构建的模块可用 Mendix  市场。他们以此为基础开展工作，很快就成功建立市场，并将时间集中在用户界面和代码记录上，正如他们在视频中所做的那样。

第 2 团队花费了大部分时间来尝试理解 Dropbox 的文档页面，尽管他们确实实现了可行的集成，但用户界面却粗糙且笨重。

2）作为用户，我希望有自动地址查找功能，以便我可以轻松找到客户的地址。

再次，团队 1 有一个可供下载的模块，并且能够快速连接它，重点是完善功能和文档。

第 2 组在决定使用哪种地址查询服务时遇到了一些困难。他们都对哪种服务最好有自己的看法，因此浪费了很多时间。最终，他们设法使用 Google 让其运行起来，但这再次不是第 1 组的对手。

3) 作为用户，我希望能够使用设备相机扫描重要文件。

此时，团队 2 知道他们落后了，并向该领域的专家寻求帮助。如果你从事过软件项目管理，你就会感觉到这里的问题。软件开发中一条著名的定律是布鲁克斯定律，它指出，“在延迟的软件项目中增加人力只会使其更晚。”通过引入新的团队成员来构建 OCR 功能，新成员将需要时间来赶上项目进度，然后他们还需要时间来了解当前的代码库。一如既往，事实证明这是正确的，项目落后得更多。

团队 1 能够保持其开发速度。他们使用了一个（是的，你猜对了）可用的模块 Mendix，没有图像识别经验的低编码人员很快就完成了任务，依靠他们最有技术的成员来完成。

4) 作为用户，我希望能够以数字方式审查和签署文件。

两个团队都为这个用户故事做出了类似的结果，但由于低代码团队能够利用他们的秘密武器（会计师知道当前系统中正确的流程），他们能够避免在复杂的用户流程中犯错误。他们有这么多剩余时间，他们也能够制作一个关于这个的视频。B 团队没有。

Mendix 让团队 A 可以选择通过上传现有电子表格来自动建模其应用领域模型，该电子表格会自动读取并在其应用领域模型中重新创建。最后，团队 A 利用 Mendix能够为所有必需的数据生成通用概述，因此，他们能够专注于应用程序的所有关键集成。

决策时间

评委很容易就选出了第一队作为获胜者——但是为什么呢？

从根本上讲，两个团队都满足了相同的要求——这是相同的技术，由相同的提供商处理，但团队 1 只用了一半的时间就完成了，其余时间则用于迭代和改进他们的产品。以下是他们能够创造的东西。

该团队还减少了他们所用模块未来更改带来的任何返工。例如，如果 DocuSign 库需要更改，这些更改将由模块的 Marketplace 创建者处理，而敏捷团队只有在更新模块后发生重大更改时才需要重构代码，而这些更改本应由连接器的创建者处理。

依赖他人的工作是可以的。这是一种进步。构建这些模块和代码库的人员和组织希望您使用它们。他们希望为您省去他们所经历的麻烦，这样您就可以专注于解决更大的问题。好处是，您可以使用它们来改进您的客户体验并构建数字客户入职流程。或者您可以利用它们以前所未有的速度创新和现代化任意数量的系统和应用程序。