編輯導(dǎo)語：短短的一年間，許多企業(yè)都把風(fēng)口朝向低代碼產(chǎn)品發(fā)展。傳統(tǒng)企業(yè)舍棄Sass，投向“逆熵”能不能行得通？作者從六個(gè)方面進(jìn)行了分析，我們一起來看下吧。

一、PaaS級(jí)低代碼產(chǎn)品風(fēng)口已來

2020年釘釘宣布宜搭加入“釘原生”生態(tài)圈，成為了低代碼在中國市場(chǎng)風(fēng)光無兩的時(shí)刻，也把“低代碼”這個(gè)產(chǎn)品概念丟到了所有IT從業(yè)者面前。

從資本到各大企業(yè)戰(zhàn)略決策層，都嗅到了風(fēng)口的味道。短短一年間，電商企業(yè)、民宿企業(yè)、智能家居企業(yè)、傳統(tǒng)SaaS企業(yè)、金融企業(yè)紛紛下注低代碼，但很多企業(yè)的戰(zhàn)略選擇，止步于既有的舒適區(qū)隔靴搔癢，正在給自己鋪就一場(chǎng)巨大的隱患局，隨時(shí)都有可能成為下一個(gè)被人玩味的產(chǎn)品“小敗局”。

二、我們先從這兩個(gè)關(guān)鍵詞開始

1. “低代碼”

討論低代碼產(chǎn)品之前，我們需要先來限定一下范圍。如果回歸本質(zhì)，低代碼絕對(duì)不是一個(gè)什么革命意義的新鮮概念，只是一個(gè)隨著計(jì)算機(jī)編碼技術(shù)發(fā)展，技術(shù)不斷下放“平民化”的過程。

舉例來說，相較于原生編寫CSS、JS的前端編碼模式，Elements這樣的組件化封裝就是一種低代碼；同樣的，一些交付企業(yè)自己定義的DSL標(biāo)記語言，相較于直接編寫Java代碼，也是一種低代碼。

誠然，這些都是低代碼領(lǐng)域的不同賽道，但往往以開源或內(nèi)部封閉生態(tài)的交付提效工具為定位，產(chǎn)品商業(yè)化價(jià)值相對(duì)有限，我們?cè)诖艘簿筒蛔鲑樖觥?/p>

我們要討論的是以“搭建一個(gè)完整可用應(yīng)用、提供完整運(yùn)行可用交付環(huán)境”為目標(biāo)的快速應(yīng)用開發(fā)（RAD）PaaS產(chǎn)品。

Gartner在2020年魔力象限中定義在領(lǐng)導(dǎo)者（Leaders）象限的Salesforce、OutSystem、Mendix、Microsoft、Appian、ServiceNow無一例外均為此類產(chǎn)品。

如果我們把目光轉(zhuǎn)回國內(nèi)市場(chǎng)，可以發(fā)現(xiàn)一線大廠也基本選擇了這個(gè)路線：阿里的宜搭、云鳳蝶、華為的AppCube、騰訊的微搭。雖然在能力層定位上略有不同，但基本的戰(zhàn)略規(guī)劃趨同，以后可以單開一帖對(duì)比一下他們彼此的異同。

2. “熵”

熵，作為一個(gè)熱力學(xué)概念，大家應(yīng)該并不陌生，用來描述一個(gè)系統(tǒng)的混亂程度。除了描述一些物理現(xiàn)象，熵的概念一定程度上可以解釋這個(gè)世界發(fā)展的客觀規(guī)律——這個(gè)世間萬物都會(huì)本能的朝越來越混亂的方向發(fā)展——這就是熵增原則。

仔細(xì)想想剛?cè)胱〉男录沂遣皇菍挸ㄕ麧崳瑤啄曛笫遣皇撬奶幎际请y以斷舍離的混沌景象。

三、熵與系統(tǒng)演進(jìn)

回到我們IT從業(yè)者每天面對(duì)的軟件應(yīng)用，如果加上一個(gè)時(shí)間線來觀察TA，是不是也是越來越復(fù)雜、越來越混沌?；叵胍幌履憬?jīng)手的那些項(xiàng)目，隨著從0到1、從1到N，是不是越來越復(fù)雜，當(dāng)然，我們主觀不愿承認(rèn)，在變復(fù)雜的同時(shí)也越來越“混亂”。

我曾經(jīng)經(jīng)手過一個(gè)內(nèi)容管理系統(tǒng)的重構(gòu)項(xiàng)目。10年前，這個(gè)項(xiàng)目設(shè)計(jì)初衷，就是一個(gè)標(biāo)準(zhǔn)到不能再標(biāo)準(zhǔn)的CMS內(nèi)容管理系統(tǒng)。

• 清晰的角色：創(chuàng)作者、編輯者、發(fā)布者、閱讀者
• 清晰的功能：增、刪、改、查。

這在十年間，需求提出團(tuán)隊(duì)換了一撥又一撥，開發(fā)執(zhí)行團(tuán)隊(duì)也換了一個(gè)又一個(gè)，項(xiàng)目從標(biāo)準(zhǔn)的CMS系統(tǒng)，新增了協(xié)作、分級(jí)審批、項(xiàng)目管理以及人事管理等一系列功能，項(xiàng)目越來越“混沌”。

十年之后的今天，已經(jīng)沒有哪個(gè)人可以講得清這個(gè)項(xiàng)目的真正全景，也因此要想抽絲剝繭理出個(gè)頭緒簡(jiǎn)直是困難重重。

做過這種老舊系統(tǒng)重構(gòu)改造的朋友應(yīng)該知道，這個(gè)例子只是窺斑見豹。一個(gè)軟件系統(tǒng)的迭代發(fā)展就是一個(gè)十分典型的“熵增”過程。

經(jīng)過幾年迭代早已和最初的規(guī)劃相去甚遠(yuǎn)，還記得最早的微信，是一個(gè)只可以進(jìn)行文字信息收發(fā)的IM軟件，再看看今天的微信社交、內(nèi)容分發(fā)、金融、電商、應(yīng)用分發(fā)，已經(jīng)是一個(gè)十足的“混沌系統(tǒng)”。

四、“逆熵”能不能行得通

熵增，是系統(tǒng)發(fā)展的必然規(guī)律，與產(chǎn)品領(lǐng)域規(guī)劃無關(guān)、與產(chǎn)品團(tuán)隊(duì)的能力無關(guān)、與企業(yè)戰(zhàn)略規(guī)劃無關(guān)。

因此，作為一個(gè)“搭建應(yīng)用的應(yīng)用”，低代碼平臺(tái)的建設(shè)規(guī)劃需符合這一客觀規(guī)律。

在各顯神通的低代碼市場(chǎng)，也的確有一些團(tuán)隊(duì)基于自己的業(yè)務(wù)背景，進(jìn)行了通過“逆熵”將產(chǎn)品“低代碼化”的嘗試。

這些團(tuán)隊(duì)背景，基本毫無疑問是SaaS產(chǎn)品出身，做低代碼的初衷也很簡(jiǎn)單，就是通過配置化，替代不同項(xiàng)目交付的重復(fù)編碼工作。

Odoo、Zoho和OpenERP是這個(gè)賽道比較典型的代表。

Odoo在企業(yè)開源應(yīng)用領(lǐng)域曾經(jīng)風(fēng)靡一時(shí)，起家于ERP領(lǐng)域，隨著市場(chǎng)拓展陸續(xù)在ERP、CRM、PLM領(lǐng)域有了較強(qiáng)的產(chǎn)品積累，為了更靈活的拓展產(chǎn)品邊界，提供給用戶靈活的企業(yè)應(yīng)用解決方案，Odoo給出了自己的“低代碼”答卷。

依托自己建設(shè)多年的開源軟件生態(tài)，Odoo在自己的低代碼平臺(tái)Odoo Studio中整合了豐富的功能模塊，共用戶來“拼裝”新的應(yīng)用。

不同于通用低代碼平臺(tái)將最小模塊拆分到組件力度，Odoo的功能模塊更像是一個(gè)個(gè)獨(dú)立的應(yīng)用，例如記賬、用戶管理、MRP、PLM、設(shè)備管理、質(zhì)量管理等模塊。

對(duì)于用戶，可以使用這些現(xiàn)有的應(yīng)用拼裝出一個(gè)自己所需的工作臺(tái)，但如果現(xiàn)有的這些應(yīng)用并不能滿足你的需求，那么，則需要通過開源框架，用代碼開發(fā)的形式編寫一個(gè)新的應(yīng)用模塊。

同樣，如果你需要讓這些工作臺(tái)上的應(yīng)用協(xié)同起來，只能自己編寫函數(shù)調(diào)用或者直接通過開源框架針對(duì)這些應(yīng)用模塊進(jìn)行代碼層面的二次開發(fā)。

從搭建應(yīng)用的角度，Odoo應(yīng)用市場(chǎng)的全部應(yīng)用模塊就是它的能力邊界，Odoo Studio可以完成針對(duì)現(xiàn)有應(yīng)用的拼裝，但無法通過低代碼拼裝的形式產(chǎn)生一個(gè)全新的應(yīng)用。

同樣，某國產(chǎn)BPM廠商也交出了與Odoo類似的答卷。他們抽取自己BPM產(chǎn)品交付項(xiàng)目過程中一些常用的功能模塊，以供之后進(jìn)行復(fù)用，但由于本身提取的模塊抽象程度不夠，實(shí)際使用中不得不將“復(fù)用”變?yōu)椤靶略觥保瑢?shí)際依然是新的一輪編碼工作。

另外，由于模塊不夠標(biāo)準(zhǔn)，接口調(diào)用、數(shù)據(jù)連接用戶很難上手，最終還是需要負(fù)責(zé)交付的工程師幫助用戶完成。雖然售賣了低代碼平臺(tái)，但實(shí)際還是提供了SaaS交付級(jí)別的人力支撐。

這類產(chǎn)品普遍的方法論是基于已經(jīng)成熟的SaaS系統(tǒng)，為了更靈活交付的目的，進(jìn)行模塊化的拆分，讓一個(gè)已經(jīng)成型的混沌系統(tǒng)有序化、標(biāo)準(zhǔn)化。

就像我們前文提到的，一個(gè)系統(tǒng)在演進(jìn)迭代的過程中不斷熵增，越來越混沌；而進(jìn)行這種模塊化的拆分就是一個(gè)“逆熵”的過程，在實(shí)際操作中會(huì)發(fā)現(xiàn)，由于模塊與模塊之間千絲萬縷的聯(lián)系，總是沒有辦法達(dá)到你想要的粒度，最終往往止步與一個(gè)完整的最小可用功能。

而對(duì)于一個(gè)工具，通用性直接取決于模塊的抽象程度，粒度越小，就可以達(dá)到更高的抽象程度。

這類走“逆熵”路線的低代碼工具，對(duì)于自己SaaS的交付場(chǎng)景，可能的確會(huì)有一些提效，但由于抽象程度不夠，總是跳不出自己的領(lǐng)域，難以成為一個(gè)通用的低代碼平臺(tái)，最終也就成為了交付團(tuán)隊(duì)的低頻工具。

五、傳統(tǒng)SaaS是不是必然會(huì)走入這樣的困境？

這些SaaS交付型企業(yè)在低代碼建設(shè)中選這條“逆熵”的道路，一定是有歷史的包袱，這一點(diǎn)是無可厚非的，但是不是只有這一個(gè)答題思路，似乎不然。

我這里以國內(nèi)某一BI廠商的低代碼平臺(tái)答卷為例，他們并沒有試圖通過低代碼去解決他們現(xiàn)有SaaS產(chǎn)品的靈活交付問題，而是把低代碼作為整個(gè)產(chǎn)品矩陣中的一個(gè)獨(dú)立產(chǎn)品進(jìn)行規(guī)劃。

該廠的傳統(tǒng)BI產(chǎn)品是解決數(shù)據(jù)統(tǒng)計(jì)、處理、分析、展示問題，為了補(bǔ)全產(chǎn)品陣列中的閉環(huán)，他們的低代碼平臺(tái)鎖定了信息收集、工單流轉(zhuǎn)的表單場(chǎng)景，并且著重建設(shè)了與原有BI產(chǎn)品的數(shù)據(jù)打通。

單獨(dú)來看，表單場(chǎng)景似乎是相對(duì)簡(jiǎn)單，但是配合該廠的BI產(chǎn)品就完成了一個(gè)數(shù)據(jù)收集到分析的完整閉環(huán)。

六、小結(jié)

• PaaS級(jí)低代碼產(chǎn)品本質(zhì)是快速應(yīng)用開發(fā)工具
• 應(yīng)用的演進(jìn)迭代逃脫不了系統(tǒng)熵增的客觀規(guī)律，低代碼產(chǎn)品的設(shè)計(jì)需要順應(yīng)這個(gè)規(guī)律
• 傳統(tǒng)SaaS企業(yè)要注意，不要將自己囿于簡(jiǎn)單通過低代碼方式完成交付的戰(zhàn)略困境

本文由 @小博 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議