區(qū)塊鏈、低代碼、元宇宙、AI智能；

01

【先來說說背景】

這個(gè)概念由來已久，但是在國(guó)內(nèi)興起，是最近幾年；

低代碼即「Low-Code」；

指提供可視化開發(fā)環(huán)境，可以用來創(chuàng)建和管理軟件應(yīng)用；

簡(jiǎn)單的說；

就是可以通過各種組件的拖拽，實(shí)現(xiàn)頁面的創(chuàng)建，交互流程和邏輯，以及數(shù)據(jù)層面的管理，更加高效的實(shí)現(xiàn)需求；

早先在數(shù)據(jù)公司時(shí)；

見識(shí)過低代碼的應(yīng)用，也參與過部分研發(fā)，比如元數(shù)據(jù)平臺(tái)，BI分析等；

不過，當(dāng)時(shí)還是以數(shù)據(jù)管理的工具來定義項(xiàng)目，并非是低代碼；

從「2020年底」開始；

實(shí)際上，那個(gè)時(shí)間節(jié)點(diǎn)，低代碼平臺(tái)的應(yīng)用已經(jīng)形成趨勢(shì)了；

現(xiàn)在的公司，將「低代碼」平臺(tái)的使用「規(guī)劃」到「業(yè)務(wù)體系」中；

后來看，這是一個(gè)非常正確的決策；

在當(dāng)時(shí)的討論會(huì)議上，大Boss給的理念；

非核心業(yè)務(wù)全面集成到低代碼平臺(tái)中，將核心業(yè)務(wù)的邊緣流程，以實(shí)踐的方式遷出小部分到低代碼平臺(tái)中；

并且給了理由，是基于「行業(yè)趨勢(shì)」和「業(yè)務(wù)周期」的整體考慮，才做出的決策；

其實(shí)，所謂的降本增效，也會(huì)遵循上述的規(guī)律；

不過遭到技術(shù)部的「稍微」反對(duì)；

主管還當(dāng)場(chǎng)給了理由，說明為何不支持這樣的決策；

但是最終的討論結(jié)果，出自部門老大的建議；

不動(dòng)核心業(yè)務(wù)，先將「邊緣業(yè)務(wù)」遷入，根據(jù)「效果」再?zèng)Q策后續(xù)規(guī)劃；

當(dāng)然大Boss最終認(rèn)同這個(gè)結(jié)論；

以實(shí)踐三年后的今天來看，人和人的「差距」確實(shí)挺大的；

組織內(nèi)「Boss」層面的決策正確，「部門」層面的執(zhí)行節(jié)奏，「員工」層面的后知后覺；

有感覺到明顯的認(rèn)知「差距」；

02

【聊聊最初的疑惑】

客觀來說；

在研發(fā)領(lǐng)域內(nèi)，大部分玩家對(duì)新事物都有一定的「排斥」情緒；

新事物意味「打破習(xí)慣」和諸多「不確定」因素；

主觀來說；

個(gè)人雖然也有排斥新事物的心理，但是很少質(zhì)疑有趨勢(shì)性的事物，當(dāng)?shù)痛a應(yīng)用成為流行趨勢(shì)時(shí)，個(gè)人選擇跟隨就好；

技術(shù)部為何下意識(shí)的反對(duì)低代碼應(yīng)用？

從最近三年的實(shí)踐和采坑經(jīng)驗(yàn)來說，以下問題可能都會(huì)成為「否定」的因素；

【問題1】平臺(tái)選擇；

這里重點(diǎn)考慮兩個(gè)維度：普遍性和業(yè)務(wù)特性；

如果只是常規(guī)的業(yè)務(wù)數(shù)字化轉(zhuǎn)型，建議優(yōu)先從大的生態(tài)選擇，比如「某微」或「某釘」，相對(duì)而言會(huì)更便捷；

如果有行業(yè)定制化的需求，則需要有針對(duì)性調(diào)研，比如財(cái)務(wù)系統(tǒng)，人事管理等；

【問題2】成本困擾；

思考一個(gè)問題：

簡(jiǎn)單業(yè)務(wù)需求從整體協(xié)作去考慮，涉及的時(shí)間成本、人力成本、以及產(chǎn)品技術(shù)的維護(hù)成本；

計(jì)算成本之后，和低代碼平臺(tái)的費(fèi)用做對(duì)比；

客觀的「數(shù)字」最有說服力；

這里依舊是降本增效的策略：更低的時(shí)間，更高的效率，更少的成本，更多的回報(bào)；

【問題3】業(yè)務(wù)適用性；

低代碼應(yīng)用剛火起來不久，并沒有發(fā)展到各行各業(yè)都有成熟合適的解決方案；

所以針對(duì)低代碼平臺(tái)的使用；

最大的爭(zhēng)議點(diǎn)就是，沒有找到符合業(yè)務(wù)特性的平臺(tái)，但是管理層急于追求數(shù)字化和降本；

這種情況下；

如果盲目引入到業(yè)務(wù)體系中，后期難免會(huì)成為燙手的山芋；

所以充分的調(diào)研，以及對(duì)市場(chǎng)上各種案例的參考，從而客觀的分析公司當(dāng)前的業(yè)務(wù)階段，是否有必要引入低代碼應(yīng)用；

【問題4】復(fù)雜后的維護(hù)性；

涉及到一個(gè)決策問題，低代碼應(yīng)用到底誰來維護(hù)？

業(yè)務(wù)人員還是研發(fā)角色？

從實(shí)踐經(jīng)驗(yàn)看；

建議是由業(yè)務(wù)方將需求對(duì)接到研發(fā)團(tuán)隊(duì)，個(gè)人所在的組織中，是一個(gè)產(chǎn)品加一個(gè)研發(fā)，一起負(fù)責(zé)低代碼平臺(tái)的迭代；

值得注意的是；

低代碼應(yīng)用具有一定的使用門檻，在使用的時(shí)候需要遵循普遍的開發(fā)原則和規(guī)范，以此保證持續(xù)可維護(hù)性；

03

【簡(jiǎn)單聊聊原理】

在說低代碼的實(shí)踐之前，先來分析一下基礎(chǔ)性的原理；

如果是普遍的共性業(yè)務(wù)；

常規(guī)就是頁面的渲染和展示，數(shù)據(jù)層面的增刪改查，計(jì)算層面的加減乘除，當(dāng)然還要考慮模型整體的驅(qū)動(dòng)和交互邏輯；

如果是行業(yè)特色的業(yè)務(wù)；

則需要低代碼平臺(tái)中進(jìn)行深度定制化的功能，提供其特定的解決方案；

從技術(shù)角度進(jìn)行原理的簡(jiǎn)單分析；

在低代碼系統(tǒng)中，十分考驗(yàn)前后端的整體「封裝」能力；

前端，頁面中各種組件和工具的管理，交互時(shí)各種動(dòng)態(tài)計(jì)算，頁面整體的數(shù)據(jù)填充；

后端，提供整體的模型驅(qū)動(dòng)能力，封裝不同場(chǎng)景下的公共的交互接口，從而實(shí)現(xiàn)各個(gè)模塊的流程和邏輯；

數(shù)據(jù)，比較常規(guī)的手段有兩種；

【1】進(jìn)行縱向的表結(jié)構(gòu)設(shè)計(jì)，數(shù)據(jù)存儲(chǔ)層面使用鍵值對(duì)的方式，構(gòu)建搜索查詢的邏輯比較復(fù)雜；

【2】數(shù)據(jù)采用JSON的格式，在數(shù)據(jù)體量大的情況下，要考慮查詢效率問題；

【3】數(shù)據(jù)還要提供基礎(chǔ)的分析和導(dǎo)入導(dǎo)出能力，以及API層面或者數(shù)據(jù)通道的搬運(yùn)能力；

實(shí)際上低代碼應(yīng)用的現(xiàn)狀，還會(huì)提供各種應(yīng)用和生態(tài)的集成能力；

追求功能的全面性；

可以參考「某微」或「某釘」的低代碼平臺(tái)的集成能力；

04

【組織內(nèi)實(shí)踐案例】

明白低代碼的基礎(chǔ)原理之后，再來聊聊近「3年」的實(shí)踐；

首先要明確一個(gè)「認(rèn)知」；

如果只是從研發(fā)角度「縱向」看；

業(yè)務(wù)可能就是產(chǎn)品矩陣中所涉及的各種事務(wù)流程，以及參與流程管理和協(xié)作的各個(gè)角色；

角度沒有問題，但是有點(diǎn)孤立；

但是，「橫向」的從組織的整體來看；

即便拋開產(chǎn)品層面，還存在諸多的協(xié)作事項(xiàng)，業(yè)務(wù)流程的管理；

這些普遍不會(huì)被集成到產(chǎn)品矩陣中；

但是同樣值得「信息化」和「數(shù)字化」管理，從而打造「標(biāo)準(zhǔn)化」流程；

在引入低代碼平臺(tái)之后，會(huì)形成如下的應(yīng)用體系；

在工作中，如果涉及多部門間的「橫向」交集；

那么會(huì)接觸到很多第三方應(yīng)用，而非單純的研發(fā)部門搭建的產(chǎn)品體系；

有的應(yīng)用極具行業(yè)的特色，有的應(yīng)用傾向共性業(yè)務(wù)的管理，有的應(yīng)用傾向私域客群的維護(hù)；

不同平臺(tái)的共通點(diǎn)，都是可以提供定制化的低代碼能力；

最為關(guān)鍵的是；

這些平臺(tái)都提供「對(duì)外」的「交互」能力，可以是第三方應(yīng)用之間的交互，也可以是與內(nèi)部的產(chǎn)品體系交互；

在這種應(yīng)用體系內(nèi)；

組織在實(shí)踐近一年之后，各種核心的業(yè)務(wù)流程，都全面的信息化和數(shù)字化管理，并且從應(yīng)用層面打通了不同業(yè)務(wù)的交互路徑；

最后，經(jīng)過對(duì)比論證，業(yè)務(wù)流的「效率」得到極大的提升；

05

【實(shí)踐帶來的反思】

與低代碼平臺(tái)聯(lián)系最密切的一個(gè)概念，就是「數(shù)字化」；

在數(shù)據(jù)公司時(shí)；

見識(shí)到數(shù)據(jù)層面可以挖掘的價(jià)值，智能化的分析決策流程，但是缺乏應(yīng)用層面的數(shù)字化實(shí)踐；

現(xiàn)在的組織中；

強(qiáng)烈的追求業(yè)務(wù)數(shù)字化管理，并且有幸見識(shí)到了完整的實(shí)踐過程，才最終形成比較清晰的認(rèn)知；

不得不承認(rèn)，這是一個(gè)普通玩家，「后知后覺」的反思；

反思低代碼應(yīng)用；

各廠商基于自身所在的行業(yè)，以及技術(shù)和產(chǎn)品的實(shí)踐經(jīng)驗(yàn)，將其封裝在復(fù)雜的低代碼平臺(tái)中；

從而提供，各種「相對(duì)簡(jiǎn)單」的業(yè)務(wù)流模型搭建；

這樣可以支撐各種業(yè)務(wù)場(chǎng)景的數(shù)字化管理，并且低代碼搭建的產(chǎn)品，本身具備很強(qiáng)的靈活可變能力，都有助于效率的提升；

在業(yè)務(wù)完成數(shù)字化之后，自然可以提升各個(gè)場(chǎng)景的統(tǒng)籌效率；

對(duì)于當(dāng)下最熱門的「AI領(lǐng)域」來說，其依賴「數(shù)字化」的基礎(chǔ)，進(jìn)而推進(jìn)流程和決策的「智能化」管理；

反思技術(shù)的發(fā)展；

以前總覺得，所謂的信息化、數(shù)字化、智能化「遙不可及」；

但是區(qū)區(qū)幾年的時(shí)間，就已經(jīng)普及到各行各業(yè)；

成為當(dāng)下最大的熱點(diǎn)；

所以，面對(duì)新興事物的時(shí)候，快速理解和衡量其價(jià)值，確實(shí)會(huì)給認(rèn)知層面帶來巨大的差距；

06

【最后聊幾句問題】

隨著低代碼應(yīng)用的普及；

越來越多的業(yè)務(wù)人員具備「簡(jiǎn)單」的開發(fā)能力，必然會(huì)給部分研發(fā)人員的帶來負(fù)面影響；

無疑；

加劇互聯(lián)網(wǎng)的「內(nèi)卷」趨勢(shì)，本就卷得一塌糊涂的行業(yè)，現(xiàn)在更是雪上加霜；

然而趨勢(shì)的形成，不會(huì)以個(gè)人意志為轉(zhuǎn)移；

就像現(xiàn)在的「AI智能」一樣，領(lǐng)先的公司不會(huì)顧及反對(duì)的聲音一路狂奔，落后的公司一邊喊著反對(duì)又一邊瘋狂追趕；

真正的趨勢(shì)，本著不可逆跟隨就好的心態(tài)。

END