低代码(low-code)法则#2：创新之源——协作

原文：https://www.mendix.com/blog/low-code-principle-2-collaboration/

上文中说到模型驱动开发，是一条概括性法则，本文将继续为大家介绍“协作”法则，“协作”与“模型”是高度相关的，它值得我们深度讨论一番。
以下是对“协作”的陈述：
可视化接口是业务专家和技术人员之间传递信息最清晰的、无二义性的语言。

土豆和马铃薯

不同的人对现实世界的描述是不一样的。一个大家都通用的语言就是演示幻灯片(PPT)，另外一个就是计算机代码。所以大家在一开始合作的时候就存在代沟，直到大家都就某一可观事实、问题、解决方案达成一致，再用一个“语言”去描述它，否则事情将会毫无进展。

我们当然不否认团队里有一些多项能力成员。一些业务人员精通技术，可以直觉地理解数字化的全貌，并且知道代码如何运行。一些技术人员清晰地理解业务，理解商业价值和流程。但毕竟这样的人是少数。

代沟对结果的影响是比较大的。无效的沟通是IT项目失败的关键因素。各项研究调查表明，软件开发上花费的最大成本是“返工”，而返工最大的问题来源就是前期的代沟。

简而言之，越有效的沟通，就越能给客户带来越好的服务，产品在市场上就越有竞争力，一些历史遗留的系统也越能适应业务变化和挑战。

大家都能理解的“模型”语言

低代码开发平台提供的可视化开发环境是为了解决团队中的沟通问题，它可以加强团队成员中各个领域的专家的协作效率。

通过一个可视化的语言和图形化的示例，我们可以通过一些显而易见的方式清楚地表达存在的问题、需要解决的需求、现有的工具和资源。图例和图表——可视化语言在整个应用的生命周期都是通用的，可以表示出我们需要解决的问题，需要依赖的资源和逻辑。基于此，我们可以探索解决方案，构建测试计划和部署应用。

用一个通用的可视化语言进行工作，团队成员可以面对面地尝试各种idea，倒腾功能，调整接口。各方人员可以参与到细节的讨论中并作出有意义的贡献，因为这是所见即所得的，无需额外的翻译成机器代码或者文档演示(PPT)。

由于可视化的语言，对于大多数人的学习曲线比较低，团队中的每个人都能在应用开发的各个方面做出超出原有技能的贡献，如一个业务专家或者产品经理，可以先自己增加或裁剪一些功能，做出一个应用的粗略原型。而程序员可以通过这个原型清楚地了解到业务需求和流程，再用自己专业的技术技能，为这个应用优化和创新，已经跟现有系统架构集成，让应用更加具有用户体验和商业价值。这一切都是顺其自然的，当原有的需求是清晰的情况下，协作是真正开放的、具有创造力的。

高效的面对面沟通

大多数情况下，在传统的瀑布式开发模式中，业务团队和技术团队分别有一块白板记录进度和backlog，但是这两个团队却很少碰面。这势必会造成一些需求误解和生产力浪费。

当团队间沟通没那么困难的时候，大家更愿意坐下来用同一块白板来跟踪整体进度。这会加强彼此之间的联系，能知道对方最关心的是什么，积极地互相帮助。更重要的是，在相互交流的过程中，一些领域上很专业知识就不用再单方面地进行学习，也不需要额外花时间进行澄清。

及时的面对面沟通会帮助团队中的每个人注入最大化的工作效率。

低代码开发的协作全景

并不是说协作只能是实时的，或者只能让人提高效率。一个企业级的低代码平台拥有同步、版本控制、自动化，这些东西都不会过时。协作可以持续发生在任何时间、任何通道，团队成员来自五湖四海都适用。所有管理和流程的工具，如需求、story、task、反馈、进度跟踪等等，对所有人都可见。平台是天然内置敏捷工作流的，你可以参加任何一个你想参与的环节。

传统的开发模式中，总会发现某些领域的专家表达的内容，其他人并不一定真的理解。但在低代码开发中，所有人都在同一个虚拟的工作空间，使用通用的语言，团队之间的沟通也不会有障碍，他们之间也会紧紧地连接彼此。

反转：积压的需求

在熟悉了低代码开发的协作模式后，一些组织会发现一些有趣的、讽刺性地反转。以前总是业务团队催技术团队的开发进度，现在，技术团队将会“翻盘”，因为在这种协作模式下，迭代的速度回更快，需求的完成度和准确度会更高，业务专家要更频繁地对业务进行反思，触进业务和解决方案往更远的道路上前进。