前言

筆者負(fù)責(zé)一個(gè)業(yè)務(wù)型的前端團(tuán)隊(duì)，支撐云音樂數(shù)據(jù)相關(guān)的B端產(chǎn)品，需求吞吐量一直是一個(gè)關(guān)注的重點(diǎn)。

但想要提升團(tuán)隊(duì)交付量，無非兩個(gè)方向，增加人手，研發(fā)提效，加人顯然不符合當(dāng)前的經(jīng)濟(jì)環(huán)境，并且很有可能演變成 “面多加水，水多加面” 的人力黑洞，通過低代碼的方式，對現(xiàn)有生產(chǎn)過程的進(jìn)行改造，進(jìn)而提升生產(chǎn)力，是一個(gè)相對可行的方案

1.業(yè)務(wù)痛點(diǎn)

1.1 產(chǎn)品線較多，跨部門協(xié)同效率很低

由于是跨部門支撐，缺乏其他職能角色，對接的流程比較亂，且后端團(tuán)隊(duì)規(guī)模遠(yuǎn)超前端，各業(yè)務(wù)組競相鎖定人力，團(tuán)隊(duì)割裂，目標(biāo)混亂，前端很難做出價(jià)值

1.2 團(tuán)隊(duì)水位低，需求吞吐量很難提升

基層成員因能力受限，不能有效參與日常業(yè)務(wù)，需求大量積壓在頭部成員手中，導(dǎo)致交付吞吐量很難提升

2.如何將低代碼落地到業(yè)務(wù)中

2.1 外部協(xié)作流程重構(gòu)2.1.1 分類分級保障標(biāo)準(zhǔn)

我們將過去混亂的產(chǎn)品線進(jìn)行分類，將保障標(biāo)準(zhǔn)與業(yè)務(wù)價(jià)值錨定，將前端資源進(jìn)行聚焦

img

2.1.2 研發(fā)元信息標(biāo)準(zhǔn)化

為了進(jìn)一步約束上游需求側(cè)的產(chǎn)出，理清合作邊界，減少業(yè)務(wù)側(cè)對前端的強(qiáng)綁定，我們依托內(nèi)部的技術(shù)產(chǎn)品對研發(fā)流程進(jìn)行了元信息標(biāo)準(zhǔn)化，為低代碼落地創(chuàng)造 “技術(shù)條件”

• Overmind：云音樂自研產(chǎn)品，具備排期、拆分任務(wù)等事項(xiàng)管理，人力可視化的能力
• OX：云音樂自研產(chǎn)品，具備將 Java 代碼解析為接口文檔的能力，接口即文檔

img

2.1.3 雙周評審PK機(jī)制

為了保證上述方案能夠落地，前端主導(dǎo)發(fā)起雙周評審PK，需求先在后端內(nèi)部PK，再根據(jù) “分級保障標(biāo)準(zhǔn)”，一部被分流給后端搭建，一部分被擠出，我們會為其提供必要的使用培訓(xùn)、落地輔導(dǎo)，為低代碼落地創(chuàng)造 “機(jī)制保障”

2.2 團(tuán)隊(duì)研發(fā)模式轉(zhuǎn)型

在處理完流程機(jī)制上的問題后，需要對內(nèi)進(jìn)行研發(fā)模式轉(zhuǎn)型

2.2.1 混合式架構(gòu)遷移

全盤的重建顯然不現(xiàn)實(shí)，也沒必要，基于微前端的混合交付依舊是最優(yōu)解

2.2.2 團(tuán)隊(duì)站位重分配

為了提升基層人員的參與度，需要對各層級成員進(jìn)行重新站位，將過去只能由少數(shù)人員才能解決的問題，通過復(fù)雜度抽離，進(jìn)行下放，進(jìn)行生產(chǎn)力改造

2.3 團(tuán)隊(duì)的高階在做什么？

2.3.1 面向前端開發(fā)的輪子

我們的業(yè)務(wù)特征就是天天與數(shù)據(jù)打交道，可視化的訴求相當(dāng)多，在傳統(tǒng)的技術(shù)提效路徑下，我們已經(jīng)基于 ECharts 封裝了 React 組件，做到面向大部分場景的開箱即用，讓初級工程師、外包，在能夠兜住底線的情況下，進(jìn)行快速的交付

2.3.2 面向后端的生碼工具

但是在低代碼平臺上，這個(gè)玩法是走不通的，因?yàn)榍昂蠖说拇罱ɡ砟钍遣灰恢碌模瑢?dǎo)致后端根本玩不轉(zhuǎn)

基于這個(gè)發(fā)現(xiàn)，我們基于平臺提供對 AST 的操作能力，誕生了面向后端的圖表智能搭建助手，這種基于一定組合規(guī)則的引導(dǎo)式搭建，在玩法固定的交互設(shè)計(jì)下，是一種非常適合非前端研發(fā)角色的生碼工具

3. 階段數(shù)據(jù)

3.1 團(tuán)隊(duì)需求吞吐量

在前端團(tuán)隊(duì)結(jié)構(gòu)劣化挑戰(zhàn)下，依舊取得了需求吞吐量提升約 100% ，有效支撐了持續(xù)膨脹的業(yè)務(wù)

并且做了進(jìn)一步的占比分析，上述舉措確實(shí)能讓基層人員有效承接業(yè)務(wù)需求，解決了長期“頭重腳輕”的問題

4. 能得到哪些有用的經(jīng)驗(yàn)

4.1 LowCode 核心是讓開發(fā)者享受到模板紅利，部分新增需求可以通過模板快速交付

相信很多研發(fā)者看到低代碼會覺得，瀏覽器中托拉拽的搭建方式看似高級，在可維護(hù)性、可拓展性上存在很大瓶頸，但我認(rèn)為這只是產(chǎn)品層面的展示形式，Tango本身基于源碼的低代碼方案，這些問題都不大

低代碼的核心是讓開發(fā)者享受模板紅利，通過減少編碼的工作量，來換取效率的提升

這種操作在ProCode時(shí)代是一個(gè)慣用操作，只不過我們選擇了將模板進(jìn)行在線化管理，打破過去的項(xiàng)目禁錮，將單個(gè)開發(fā)者可見，變成了全局可見，讓模板紅利變得更加普惠

4.2 長尾需求可通過低代碼模式 “換道超車”

所有的項(xiàng)目都希望自己的需求能盡快上線，但資源有限，往往會導(dǎo)致長尾需求的積壓，通過低代碼的方式后端自閉環(huán)，讓長尾需求 “換道超車”，讓前端開發(fā)者專注于核心業(yè)務(wù)，而不是被長尾需求拖累

4.2 依托 LowCode 的生產(chǎn)方式改造，是一個(gè)相對經(jīng)濟(jì)的解決方案

懟人力是一個(gè)短期很有效的方式，如同玩游戲一樣，大力氪金一定出活，但在現(xiàn)實(shí)中我們往往要面對招聘、落地、成長等一系列時(shí)間和經(jīng)濟(jì)成本，依托 LowCode 拉低門檻，讓過去不能參加，不能有效參加的成員都能參加進(jìn)來，是一個(gè)非常經(jīng)濟(jì)可行的解決方案

5. 依舊存在的問題

5.1 業(yè)務(wù)側(cè)資產(chǎn)的相對匱乏

舉一個(gè)例子：為什么后端會覺得上手成本高？

我認(rèn)為直接原因上是由于平臺側(cè)提供的物料，大多都是原子化組件，頁面的成型完全依賴開發(fā)者對組件的組合與配置，在當(dāng)前業(yè)務(wù)側(cè)資產(chǎn)的相對匱乏下，只能依賴前端編碼來彌補(bǔ)這部分差距；

把 “從零到一搭建” 轉(zhuǎn)變?yōu)?“修改頁面模板”，大幅減少頁面成型的工作量

我們希望改變后端搭建頁面的流程，把 “從零到一搭建” 轉(zhuǎn)變?yōu)?“修改頁面模板”，大幅減少頁面成型的工作量，其中需要大量的業(yè)務(wù)側(cè)資產(chǎn)的沉淀（樣板間、業(yè)務(wù)組件封裝）

繼續(xù)閱讀：

未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動力 | RPA新聞 | 推動中國RPA生態(tài)發(fā)展 | 流 > 代碼在云音樂數(shù)據(jù)業(yè)務(wù)中的落地實(shí)踐與思考