聊聊中後臺產研一體化:引子

語言: CN / TW / HK

「降本增效」是人們在生產過程中永恆不變的話題、永遠的追求——於公,長久看可以讓企業減少開銷並提供更為穩定、優質的產品;於私,能夠使自己減少重複無營養的勞動,將精力投入到更為「高精尖」的地方,有助於自我成長,為自己為企業創造更大更多的價值。

提效的方式

現在想一下,在純 Web 開發或大前端結合 Web 服務的領域中,提效的方式都有什麼?

單點提效

從前端角度看,絕大部分前端團隊都在不遺餘力地去封裝自己的工具庫、UI 元件庫、腳手架與構建工具,有些能力強點的團隊還會封裝應用開發框架、視覺化原始碼搭建工具等。

從設計角度看,每個部門都會搞自己的設計規範/設計語言/設計體系,整理出一份設計側的 UI 元件庫,並制定一套 Design Token 用於與其他設計及前端溝通交流和設計與研發之間的聯動。

從後端角度看,貌似沒有什麼可提效的空間——後端語言大多公司用的是 Java,相關生態體系已經很健全,頂多做些業務層面的封裝。

從產品角度看,產品經理的工作就是接收/提出需求,做一些產品層面創收和改進相關的事情,這類思維活動為主的基本只能通過提升思維能力去提效了。

鏈路提效

同工種或者說分工內提效的天花板清晰可見,很容易就會到達瓶頸。要想更進一步,自然而然也必須要跳出自己所處角色的視角,橫向尋求上下游間的打通,共同提效。

以前端為中心與其他環節進行打通的話,大概是這麼幾種手段:與設計之間是設計稿與前端程式碼互轉,即 D2C、C2D;與產品之間是需求文件轉程式碼,即 P2C;與後端之間是採用 FaaS,即常規意義的「前後端一體化」。

產研一體化

上述幾種鏈路提效方式的思考角度,一般都比較表層,仍是以自己或他人的職能為出發點,而不是從問題的本質開始探求解決方案——雖然每個分工角色的交付物不同,但它們都應是同一樣事物的體現。

那麼,那個「同一樣事物」是什麼呢?

是模型與流程,或是業務概念、概念之間的關係以及相互間的作用,又或是業務知識。

所以,鏈路級的提效最關鍵的一點就是領域驅動的統一建模,作為全鏈路的唯一可信來源(Single Source of Truth)。這意味著,從需求/產品、設計到開發、測試,都要基於同一份「資料」進行。

簡要作業流程

產品整理各類需求,劃分出各種業務概念,明確它們之間的關係和作用規則,這一過程就是在建模,最終會產出模型和流程。

建模結束後,產品可以在沉澱了 UI 元件、邏輯函式等物料的應用搭建平臺上結合建模的產物製作「原型」,「原型」即最終頁面。

若已有物料中沒有想要的 UI 元件和邏輯函式等,可以用佔位符之類的方式標註下,讓設計和開發去補上。而 UI 元件和邏輯函式等的研發,既可以走線下又能夠走線上。

協作模式變革

從上面的簡要作業流程可以看出,從需求到研發最重要的角色基本只有產品和後端——產品負責領域建模和「原型」搭建,後端負責程式碼及資料連線,設計和前端被「踢」了出去,業務研發流程得到了精簡。

從另一方面來看,也應該去儘可能減員——

軟體開發過程就是從接到需求到產出符合需求的可用軟體的過程。在這一整個鏈條中,源頭是需求提出方,然後經過產品、設計、開發、測試等不同崗位的人處理。

雖說源頭是需求方,但更實際的源頭是需求方的意願。這個「意願」是不是「真(true)」的,首先要打個問號。然後資訊在傳遞過程中肯定會有所損失,每個傳遞的節點能力越差損失得越多。

資訊在每個人那裡輸入、輸出時,因為知識、理解力、表達力等因素,多多少少都會發生變形,為了儘可能「保真」,必然的選擇就是減少傳遞環節,也就是減少參與人數,盡最大可能讓需求方的意願直接變成符合需求的可用軟體。

那設計和前端幹嘛?要被裁了嗎?!當然不是!雖然他們離業務比較遠,業務研發流程基本不需要他們,但應用搭建體系的物料開發和維護需要他們啊!在這裡,他們對團隊的價值能夠最大化。

總結

本文簡單梳理了在純 Web 開發或大前端結合 Web 服務的領域中一直以來大家為提效所做的各種嘗試,並描繪了「產研一體化」在我腦中的輪廓。

目前主要是幾個大廠以提效為目的在「產研一體化」方向進行探索,我在這個方向上也有了比較具體的有待嘗試落地的想法,待日後慢慢道來。

「反混沌」體系下的「Fxxk Design」和「Future.js」就是「產研一體化」這盤棋上的棋子。

「產研一體化」是中後臺應用低程式碼化程序的一部分,也是前端工業化程序的一部分。