代码在云音乐数据业务中的落地实践与思考

后台-系统设置-扩展变量-手机广告位-内容正文顶部

前言

笔者负责一个业务型的前端团队,支撑云音乐数据相关的B端产品,需求吞吐量一直是一个关注的重点。


但想要提升团队交付量,无非两个方向,增加人手,研发提效,加人显然不符合当前的经济环境,并且很有可能演变成 “面多加水,水多加面” 的人力黑洞,通过低代码的方式,对现有生产过程的进行改造,进而提升生产力,是一个相对可行的方案

1.业务痛点

1.1 产品线较多,跨部门协同效率很低

由于是跨部门支撑,缺乏其他职能角色,对接的流程比较乱,且后端团队规模远超前端,各业务组竞相锁定人力,团队割裂,目标混乱,前端很难做出价值

1.2 团队水位低,需求吞吐量很难提升

基层成员因能力受限,不能有效参与日常业务,需求大量积压在头部成员手中,导致交付吞吐量很难提升

2.如何将低代码落地到业务中

2.1 外部协作流程重构2.1.1 分类分级保障标准

我们将过去混乱的产品线进行分类,将保障标准与业务价值锚定,将前端资源进行聚焦


img

2.1.2 研发元信息标准化

为了进一步约束上游需求侧的产出,理清合作边界,减少业务侧对前端的强绑定,我们依托内部的技术产品对研发流程进行了元信息标准化,为低代码落地创造 “技术条件”

  • Overmind:云音乐自研产品,具备排期、拆分任务等事项管理,人力可视化的能力
  • OX:云音乐自研产品,具备将 Java 代码解析为接口文档的能力,接口即文档

img

2.1.3 双周评审PK机制

为了保证上述方案能够落地,前端主导发起双周评审PK,需求先在后端内部PK,再根据 “分级保障标准”,一部被分流给后端搭建,一部分被挤出,我们会为其提供必要的使用培训、落地辅导,为低代码落地创造 “机制保障”


2.2 团队研发模式转型

在处理完流程机制上的问题后,需要对内进行研发模式转型

2.2.1 混合式架构迁移

全盘的重建显然不现实,也没必要,基于微前端的混合交付依旧是最优解

2.2.2 团队站位重分配

为了提升基层人员的参与度,需要对各层级成员进行重新站位,将过去只能由少数人员才能解决的问题,通过复杂度抽离,进行下放,进行生产力改造

2.3 团队的高阶在做什么?

2.3.1 面向前端开发的轮子

我们的业务特征就是天天与数据打交道,可视化的诉求相当多,在传统的技术提效路径下,我们已经基于 ECharts 封装了 React 组件,做到面向大部分场景的开箱即用,让初级工程师、外包,在能够兜住底线的情况下,进行快速的交付

2.3.2 面向后端的生码工具

但是在低代码平台上,这个玩法是走不通的,因为前后端的搭建理念是不一致的,导致后端根本玩不转

基于这个发现,我们基于平台提供对 AST 的操作能力,诞生了面向后端的图表智能搭建助手,这种基于一定组合规则的引导式搭建,在玩法固定的交互设计下,是一种非常适合非前端研发角色的生码工具


3. 阶段数据

3.1 团队需求吞吐量

在前端团队结构劣化挑战下,依旧取得了需求吞吐量提升约 100% ,有效支撑了持续膨胀的业务


并且做了进一步的占比分析,上述举措确实能让基层人员有效承接业务需求,解决了长期“头重脚轻”的问题


4. 能得到哪些有用的经验

4.1 LowCode 核心是让开发者享受到模板红利,部分新增需求可以通过模板快速交付

相信很多研发者看到低代码会觉得,浏览器中托拉拽的搭建方式看似高级,在可维护性、可拓展性上存在很大瓶颈,但我认为这只是产品层面的展示形式,Tango本身基于源码的低代码方案,这些问题都不大

低代码的核心是让开发者享受模板红利,通过减少编码的工作量,来换取效率的提升

这种操作在ProCode时代是一个惯用操作,只不过我们选择了将模板进行在线化管理,打破过去的项目禁锢,将单个开发者可见,变成了全局可见,让模板红利变得更加普惠

4.2 长尾需求可通过低代码模式 “换道超车”

所有的项目都希望自己的需求能尽快上线,但资源有限,往往会导致长尾需求的积压,通过低代码的方式后端自闭环,让长尾需求 “换道超车”,让前端开发者专注于核心业务,而不是被长尾需求拖累

4.2 依托 LowCode 的生产方式改造,是一个相对经济的解决方案

怼人力是一个短期很有效的方式,如同玩游戏一样,大力氪金一定出活,但在现实中我们往往要面对招聘、落地、成长等一系列时间和经济成本,依托 LowCode 拉低门槛,让过去不能参加,不能有效参加的成员都能参加进来,是一个非常经济可行的解决方案

5. 依旧存在的问题

5.1 业务侧资产的相对匮乏

举一个例子:为什么后端会觉得上手成本高?


我认为直接原因上是由于平台侧提供的物料,大多都是原子化组件,页面的成型完全依赖开发者对组件的组合与配置,在当前业务侧资产的相对匮乏下,只能依赖前端编码来弥补这部分差距;

把 “从零到一搭建” 转变为 “修改页面模板”,大幅减少页面成型的工作量

我们希望改变后端搭建页面的流程,把 “从零到一搭建” 转变为 “修改页面模板”,大幅减少页面成型的工作量,其中需要大量的业务侧资产的沉淀(样板间、业务组件封装)

未经允许不得转载:RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展 | 流 > 代码在云音乐数据业务中的落地实践与思考

后台-系统设置-扩展变量-手机广告位-内容正文底部