云凤蝶中台研发提效实践

云凤蝶中台研发提效实践

最近我们在蚂蚁内部发布了全新云凤蝶 2.0,把产品的重点由 H5 搭建彻底转向了中台方向。使用云凤蝶,快速制作高品质中台应用

我们目前聚焦于以下三个方面来服务中台业务:

  • 降门槛 让更多人进的来参与中台建设
  • 提效 是否可以做到 10 倍提效?
  • 提升体验 设计规范自动化落地,默认好用

本文主要探讨云凤蝶对于中台提效的理解,从研发模式的角度来看,我们对于十倍提效的达成思路。

1. 中台应用分层模型

相信不少同学听说过用户体验五要素,一个中台产品的从想法到实现落地,也是一个近似的分层模型。

中台应用分层模型

这不仅是一个过程模型,也是实现模型,如今我们写代码也是这么来写的:

  • 需求层 描述产品目标、功能范围,以人的视角诠释原始需求。目前还没有形式化语言支撑,以 PRD 的形式流转于 word 文档和语雀平台。产品经理工作在这一层。
  • 模型层 把所有业务概念和操作用形式化系统表述,把需求映射到计算机可理解的格式。这里是一个比较泛的分层模式,可以简单理解为充血的广义模型,涵盖了多层传统分层。后端工程师工作在这一层。
  • API 层 把所有的业务数据形式化,由于 BS 架构形成了天然边界。后端工程师工作在这一层。
  • 展现层 把所有的内容视觉化,使用交互承载所有的业务操作。产品经理、设计师和前端工程师工作在这一层。

在这样一个中台分层模型中,越靠上的部分细节越丰富,而越靠下的部分越靠近用于原始诉求,越简洁抽象。

基于这样一个分层模型,我们来思考,现有的研发模式是否足够高效。

2. 层间关系

2.1 层间具有推导性

一般来说下层一定程度上可推导出下层,上层一定要遵循下层约束。

例如需求层约束单笔转账金额小于 1 万元,那么模型层一定会遵循这个约束,绝对不会允许大于 1 万元的转账发生。模型层在这个基础上可能会补充额外的约束,例如只能是在账户余额大于转账金额的时候、转账目标账户没有被封禁的时候才允许交易的发生。经过这一层细节补充后,需求更加具体,约束更加详细。API 层和展现层又会遵循这一约束。

2.1.1 强推导性

如果是上层可完全由下层推导而出,那么是一种强推导关系。在这种关系下,平台能力满足的情况下,可通过 No-code 方式快速达成需求。

2.1.2 弱推导性

如果上层需要在下层推导结果中增加额外约束和细节补充,那么是一种弱推导关系。在这种关系下,兼具效率和可定制性的 Low-code 方式是更好的选择。

由于细节由下而上递增,所以越靠下层推导性越强,越靠上层推导性越弱。

在单一强组织架构内通过强制的高约束,可达成强推导性;但在广阔的企业开发市场,跨约组织或组织内层级结构庞大,完成高约束性治理是无法完成的任务,只能达到弱推导性。

2.2 层间提效的关键在于完成推导性过程

完成推导性过程是提效的重中之重,因为它会简化生产关系。如果上层可完全享受到下层的工作成果,而不需要换一种方式重建,将会大大节省时间,提高效率。

打通上下游生产资料壁垒是云凤蝶提效的主要抓手之一,这样更容易完成推导性过程。

例如,模型层建立的模型,是否可直接通过推导性帮助建立 API,甚至直接生成 API(取决于需要补充的额外信息,也就是是强推导性关系还是弱推导关系);API 是否可以通过对到行帮助建立展现层界面和交互,甚至直接生成 Form 和 Table 等业务界面;甚至模型层是否可以直接跨越 API 层,直接推导展现层。

如果想完成这种推导性关系,打通层间生产资料壁垒就是必须的,要建立一种稳定可被上层理解并加以利用的数据格式。

3. 层内关系

因为需求层的形式化语言探索业界还没有突破,所以不再讨论范围内。

对于除需求层外每一层的建立过程,如何才是更块更好的方式?如何搭配生产关系才会达到总体效率的最优?

3.1 使用 Low-code 研发每一层

层内关系

3.1.1 可视化研发

可视化开发不局限于 UI 绘制视图,是指基于 GUI 配置化、声明式的开发方式。

好的可视化 关键是对于常见实现路径的高层抽象,对众多处理细节的收敛。只要完成了这种可视化过程,说明完成了细节收敛,用户每一次操作都力挺万钧,以一当十,天然拥有高效率的特点。

不好的可视化 只是把代码世界里东西一一映射到可视化世界,不做多对一收敛,这可能会有降门槛的效用,但提效无从谈起。

3.1.2 代码研发

代码开发需要开发者掌握庞大的专业技能体系,但拥有全部的灵活性,功能强大。

3.1.3 Low-code 兼顾层内建设两种需求

由于企业开发市场对于交付效率和可定制性的双重追求,Low-code 平台成为这一市场最合适的开发方式,因为它兼具高效率和灵活性的特点。

所以,Low-code 平台需要解决好可视化开发和代码开发之间的关系,它是一种部件生产和生产线组装的关系。

3.2 层内提效的关键在于建立产业链式结构

3.2.1 富士康如何制造出高精尖产品 iPhone

下图是 iPhone 的供应链,红框内的是富士康。

产业链上游企业集中科技优势,生产有高精尖属性的大猩猩玻璃、屏幕模块、摄像头模块等,苹果公司输出设计(中台的需求层),富士康就可以做出整体高精尖的产品 iPhone。

富士康的核心优势,是以技能要求不高的方式流水线批量生产高精尖的 iPhone。

3.2.2 传统中台研发(Pro-code)

传统中台研发要求每个人掌握所有技能

基于代码做 bottom-up 式研发,成本高昂。以展现层为例,它要求每一个参与者是专家(资深的前端开发经验),它要求每个人都既会研发高科技的轮胎、齿轮、方向盘,也要掌握整车组装。在这样一个研发模式下,人员要求高,生产效率只能对人提出高要求以此提升生产效率,难以有量变的提升。

3.2.3 Low-code 中台研发

代码用于生产零部件,可视化用于组装。形成上下游分工的产业链式结构。

Low-code 中台研发,集中专家力量生产零部件,产品本身可低成本快速组装

在这样的分工模式下,专家做高科技研发,会有更多更优质的能力以组件化的方式被开发出来,而中台的建设是以流水线的方式进行组装。后者人员技能要求低,模式固定,因此生产力也会大大提高。

很容易做出对比,一家工厂生产 iPhone 的所有零部件并负责组装,对比以上产业链结构,那种生产力更高?

以展现层为例,我们认为,一个平台即便完成了可视化操作,但还是需要专业的前端技能或深度理解,那么就是失败的。因为这是一个要求博士学历的富士康,注定无法规模化生产。这也是我们特别注意控制产品透出的技术要求复杂度,对用户提出最小的技能要求范围。

4. 云凤蝶的提效思路

云凤蝶中台应用是 Low-code 平台,目前聚焦于展现层流水线的打造,将 UI 资产快速组装出可用站点。

做好工具属性只是满足提效的基本要求,更重要的是从横竖两个方向改善生产关系和打通生产资料壁垒。

4.1 层内建立产业链提效

UI 资产包 专家级前端工程师使用代码开发组件(UI 资产),完全交由 pro-code 优化专家的生产效率(未来可能转向 CloudIDE),是产业链的上游。

低代码组装 使用可视化 + 低代码方式组装 UI 界面和制作交互,是我们的核心生产线,是产业链的下游。

自由布局画布打破层内生产资料壁垒 工作在展现层的 PD、设计师和前端工程师工作产物无缝复用。

4.2 层间完成推导性提效

智能向导初探层间推导性关系 由 API 层弱推导展现层,允许用户在过程中补充额外信息(交互细节)。初步打破层间生产资料壁垒,目前正在建设中。

4.3 Next

模型层 下半年启动模型层建设,并在智能向导中打通模型 -> API -> 界面的推导过程,进一步打破层间生产资料壁垒。

5. 总结

我们认为:

  • 传统提效思路的努力方向“利其器”没有错误,是所有提效必须完成的第一步。
  • 生产力产生量变的更重要武器是改变生产力关系。能够打穿层级间、打通层级内,消除生产资料壁垒,层级内层级外下游都复用上游产物而不重建,会形成产业链式生产关系,从而效率最大化。

以上讨论仅针对于云凤蝶三大目标(降门槛、提效和提升体验)中的提效,云凤蝶在其他目标下的思考会陆续呈现。

发布于 2019-08-16

文章被以下专栏收录