我上次写过 模型驱动开发 以及它如何真正成为“统治一切的一条原则” 低代码应用程序开发第二个原则“协作原则”确实与模型理念密不可分，但它非常重要，值得单独关注和讨论。
我们是这样表述的：
协作：视觉语言是在业务领域专家和开发人员之间传递知识和想法的最清晰、最明确的方式。
“我说 po-TAY-toe，你说 po-TAH-toe。”
我们每个人看待和描述眼前现实的方式都不同。当一方的母语是 PowerPoint，而另一方的母语是计算机代码时，你们从一开始就面临沟通挑战。除非双方就 A) 他们所看到的内容（无论是在看问题还是解决方案）和 B) 描述它的语言达成一致，否则就无法取得任何有意义的进展。
每个团队中，每个人的知识和专长都各不相同。一些商务人士精通技术，能够直观地了解数字环境和软件的工作原理。其他人则不然。一些技术人员真正了解市场、商业概念和流程。其他人很少涉足技术领域之外。
这种沟通不畅的后果是巨大的。沟通失败是 IT 项目失败的主要原因之一。我们从各种研究中得知，软件预算的大部分都花在了返工上，而沟通问题是导致返工的主要原因。
简而言之，业务和 IT 之间的沟通越好，解决方案就越好，无论是推出用于服务客户和将产品推向市场的新数字范式，还是改进遗留系统以满足不断变化的业务需求。
每个人都能理解的“模范”语言
低代码平台的可视化开发环境专门用于解决沟通难题，从而增强团队成员之间的协作，无论他们的专业领域或技术敏锐度如何。
有了强大的视觉语言和图像，每个人都可以清楚地了解问题或需要解决的问题，以及可用于构建解决方案的工具和资源。对象和形状、图表和图形、依赖关系和逻辑的表示——视觉语言是 通用语 整个生命周期，从定义问题、探索解决方案，到构建、测试和部署应用程序。
通过使用通用的视觉语言，团队成员可以坐在屏幕前尝试各种想法、研究功能或调整界面。各方都可以理解讨论的细微差别并做出有意义的贡献，因为他们可以亲眼看到一切。无需解释代码或翻译 PowerPoint。
由于视觉语言的学习曲线很短，团队成员很快就能为超出其主要技能范围的应用程序创建方面做出贡献。例如，业务分析师或产品工程师实际上可以自己草拟应用程序，或添加、删除或重新排列组成应用程序的组件。相反，核心开发人员可以对业务流程或客户交互方案带来新的视角，并提供创新想法来优化效率或用户体验，从而产生更大的业务影响。这一切都是实时发生的，每个人都可以看到。在真正开放、协作的环境中，没有任何智力会被浪费。
面对面互动的力量
很多时候，在传统的线性瀑布式开发方法中，业务团队在业务角落写白板，而开发团队在 IT 角落写白板，这种情况确实很常见。而且，两者从不碰面。这肯定会造成误解，并导致事与愿违的浪费时间。
当人们使用同一种语言时，他们就更容易坐在一起，在一块白板或屏幕上表达自己的想法。他们彼此建立联系，读懂对方的非语言交流，了解对方的顾虑，融入对方的热情之中。最重要的是，他们分享彼此的知识。一个领域越新或探索得越少，知识转移就越重要。
实时、面对面、 亲自 沟通有助于团队中的每个人最大限度地参与并更聪明地工作。这些会议变成了每个人 希望 参加。
协作低代码格局
这并不是说协作必须实时或面对面才能有效。企业级低代码平台将内置并自动化同步和版本控制，因此任何人都不会过时，并且协作可以在任何时间和任何渠道继续，无论团队成员是在不同的办公室还是在不同的大陆。所有管理和流程细节（如需求、用户故事、任务、反馈、修订跟踪等）的工具都触手可及。对敏捷工作流程的支持已内置其中。您可以随时了解情况。
在传统的开发模式中，领域专家们会用对方无法理解的语言互相交谈。但在低代码平台中，当每个人都在同一个虚拟空间中工作并使用共同的语言时，沟通环节就可以毫不拖延地完成。团队可以独立工作，但仍然与整体紧密相连。
彻底解决积压问题
一些组织在掌握了低代码平台中的协作技巧后，看到了开发动态中一个有趣的、或许具有讽刺意味的转折。通常，现在是 IT 等待业务团队，彻底颠覆了典型的业务等待 IT 的瓶颈。通过协作的魔力，专业开发人员能够比以往更快地进行迭代，解决方案也比以往更准确、更相关。业务专家必须重新训练自己，以更快地做出反应，以保持解决方案的进展。
无需翻译
当业务人员和开发人员使用同一种语言交流时（如在可视化模型中），无需翻译，每个人都能理解提出的问题和不断发展的解决方案，迭代速度很快，每个人都能参与从最初的想法到部署的整个过程。协作可以快速构建正确的解决方案并减少返工。
成功实施协作原则，您将立即进入更加有效的应用程序开发流程。