無代碼產品演進的一些思考(來自輕流產品總監)

7月6日,我們組織了第一次的輕流日(萬能的諧音梗),主題是:無代碼無邊界。

發佈了不少有趣的內容,感興趣的瞭解一下。其中我們發佈了輕流的一個重要的版本:輕流3.0。其核心是團隊所明確的輕流定位:服務業務人員落地管理需求的無代碼系統搭建平臺。

在過去的兩年時間裏,我們從自研流程引擎出發,完成了從輕量級業務流程管理工具(BPMS)到跨行業跨場景跨職能的無代碼系統搭建平臺(aPaaS)的轉變。


複雜度前置所帶來的效能提升

從人員分工和結構層面來講,傳統的業務系統落地過程中往往需要經歷5個層面的資源投入:

其中最大的成本及不確定性集中在以下兩個階段:

◉ 研發落地

◉ 持續迭代

通過敏捷、持續交付等研發管理策略可以很好地提升這個端到端流程閉環所需要耗費的時間成本,但是在每個單節點內所能削減的成本是有限的。職能本身的複雜程度讓“全棧”這件事情變得很困難,項目成員的人數到了一定階段在協作和溝通階段會耗費大量的資源和精力。

降低應用落地過程中的代碼干預、這也並非意味着不寫代碼,而是通過將研發資源投入到更大顆粒度的“輪子”打造中。經過需求提煉將應用層所需要的模塊一次性封裝從而支持多場景多應用中的多次使用。

這種方式更好地調配“組裝”過程中的複雜度分佈,從而降低了響應業務變化所需要耗費的成本,從根源上提升了團隊/企業的效率和靈活度。

這種方式使得跨職能的互相賦能從原先的“直接賦能”轉變爲更爲高效的“間接賦能”,

如今這些類”中間件“的服務或者產品在各個領域都逐漸趨於成熟:

不同領域的賦能所需要的封裝程度不一,需求架構也是不一樣的。我們所專注的是賦能業務人員可以逃離代碼的束縛,自主進行系統落地,所以花了更多的心思在於理解和抽象一個組織一個業務系統所必須具備的“輪子”。

進過兩年的摸索,我們逐漸確立了輕流的無代碼產品矩陣:

之前的文章中也就這些板塊進行了一定的介紹。抽離後的每個模塊專注且專業、互相協調、互相搭配,不同的組裝和調用方式會達到不同的效果

模塊的數量以及模塊內的子模塊細分程度也直接決定平臺所能支持的業務複雜度如何。


對立 | 統一

功能框架的愈發健壯必然地導致了系統易用性的下降。,面向“業務人員”,而非面向“開發”or面向“項目”的定位,直接的指向兩者並非“可取其一”的關係,是要必須做到“兼得”的。

系統的健壯性和易用性,兩者如何對立而有統一,是輕流的產品設計團隊需要解答的問題。

在3.0中,我們有了新的思考:

1、健壯度

◉ 功能模塊的健壯

◉ 技術架構的健壯

功能模塊的健壯:滿足更多的定製化場景

對一個定製平臺來說,定製化需求的滿足度是非常重要的指標,這也是客戶選型過程中非常致命的一個點。不少的客戶因爲某個定製需求是否被滿足而選擇某一特定的平臺。這也讓無代碼平臺的產品具備一定的先發優勢。

因爲定製需求多如牛毛,把握封裝的顆粒度非常的重要,顆粒度的大小決定了差異化需求的滿足程度:

差異化的影響維度

1、定製化的程度不一:

◉ 展現層的需求不一(排課、訂房、設備巡檢)

◉ 模型層靈活度過高(生產單的拆分與合併、績效工資等複雜的數據計算場景)

滿足了80%的定製化需求,剩下的20%往往是最難啃的。主要集中在需求極度非標的展現層和模型層;不同場景、不同角色對於業務入口的需求是不一的。

例如設備管理的場景,業務入口圍繞攝像頭展開;酒店訂房的場景中、業務入口則是房間清單。對於一線員工來說多爲操作行入口、而對於管理員來說多爲展示型入口。在涉及到品牌、企業VI等因素,對於展現層的靈活度要求則更高;在複雜且非標化嚴重的生產環節,有着大量類似訂單拆分及合併的需求,對於數據計算轉換自定義的要求也是很高的,需求抽象難度高,通過無代碼的方式實現目前也極具挑戰性。

2、行業場景存在業務壁壘:

◉ 政企單位中的文書管理

◉ 項目管理中的進度管理

◉ 訂單管理、售後管理中的支付環節

◉ 合同管理中對於法律效應的依賴性

例如“支付”是一個相對獨立、並非完全通用的能力,但是卻在部分場景中是剛需甚至痛點:場地預約中的付費管理、售後服務中的服務費用收取…… 這些原本都是輕流難以打通的端到端流程閉環。

類似的場景還包括:

◉ 知識庫、

◉ ETL、

◉ 網盤、

◉ 電子合同

……

簡單地接口層面的打通在很多場景中並不能夠帶來統一的產品使用體驗,這樣的集成所帶來的價值僅僅在項目制交付中體現,對於絕大多數客戶來說依然是望塵莫及的服務。

系統架構的健壯:滿足系統可用性

數十萬行的代碼需要一個健壯的架構,如果沒有一個足夠優秀的架構,一段時間後產品的可維護性就變得很差,無法繼續延展的補充。

不同的模塊組合充滿各式各樣的邊界情況,降低漏測率、提升穩定性是一場痛苦的持久戰,需要耐心和毅力。

2、易用性

無代碼平臺和低代碼平臺之間最主要的差異還是集中於面相的用戶羣,輕流希望業務人員可以擺脫代碼“牢籠”,甚至主導業務系統的落地,而業務人員中往往大多數並不具備足夠的coding能力,這對於無代碼平臺的易用性的要求就會更高。

即便簡單的跨平臺集成某種程度上可以解決這些問題,但是這也違背了我們讓業務人員主導系統落地的初衷。

這條路是非常艱難的,好在最近兩年資本的渲染、同行的跟進,向我們這樣的業務系統自主搭建平臺越來越爲人所知。很好地降低了新用戶的認知成本,但是隨着業務的深入,如何讓用戶使用工具更好地實現搭建訴求依然有很長的一條路要走。

開箱即用、亦可量體裁衣

在平衡易用性和健壯度的問題上,輕流3.0做出了自己的回答:我們通過封裝和模塊化將這些更深度的自主搭建能力以更產品化的方式呈現給用戶,並且深度融合了自研的模塊。

在全新的插件中心中,用戶可以根據自己場景和行業的差異自主選擇,一鍵開啓。配合高可讀性的文檔講解幫助用戶自主實現業務系統能力邊界的突破。

術 | 器

過去一年和各行各業的客戶共創,我們打造完成了一個個拓展模塊的研發,但是在整個定製化需求面前,我們還是稚嫩地像個寶寶,單靠我們自己的能力能夠服務好的場景、行業維度是極其有限的。這就有必要講到 另一個無代碼平臺的另一個至關重要的特性:開放。

器:開發者生態

輕流是不是一款工具? 我覺得是的,因爲通過輕流,不擅長coding 的業務人員可以最大化地發揮他的能力。但是工具的邊界是顯而易見,輕流無法解決產業互聯網的所有問題,過去的一段時間裏,我們同不同領域的“能力者”一起突破輕流的能力邊界:

Teambition:最佳項目管理解決方案共創

堅果雲:獨立的網盤解決方案

百度大腦:先進的ai圖像識別能力

E籤寶:深度集成的電子合同解決方案

我們希望同產品人員、研發人員、其他產品等一同打造更多維度的具備優秀用戶體驗的產品化解決方案。我們即將推出的“開放平臺”歡迎大家關注。

術:業務專家生態

在輕流,如果說我們專注於打造優秀的無代碼平臺是不準確的,對於輕流er來說,賦能各行各業的業務專家纔是我們最迫切想要實現的。輕流是一家大學生創業公司,要說對於各行各業業務模式的理解,那真是遠遠不夠,即便是自身所處的產業互聯網行業,我們也是前行的探索者。而無代碼搭建平臺所需要具備的是能夠服務各行各業定製化需求落地的健壯程度,恰恰需要與願意通行的行業專家一同設計與實現。

輕流不僅僅是提供要提供低門檻的產品提供方,也是跨行業、跨職能的專家分享平臺。我們所打造的【輕流學院】也正是爲了這個目的而生的。


好嘞~ 最後分享一下我們的全新視覺形象,後續可以寫篇文章專門跟大家聊聊這次形象煥新。


謝謝大家的閱讀,點擊即可免費試用輕流

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章