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

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

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

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

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

1. “低代碼”

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

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

誠然，這些都是低代碼領(lǐng)域的不同賽道，但往往以開源或內(nèi)部封閉生態(tài)的交付提效工具為定位，產(chǎn)品商業(yè)化價值相對有限，我們在此也就不做贅述。

我們要討論的是以“搭建一個完整可用應(yīng)用、提供完整運行可用交付環(huán)境”為目標的快速應(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)市場，可以發(fā)現(xiàn)一線大廠也基本選擇了這個路線：阿里的宜搭、云鳳蝶、華為的AppCube、騰訊的微搭。雖然在能力層定位上略有不同，但基本的戰(zhàn)略規(guī)劃趨同，以后可以單開一帖對比一下他們彼此的異同。

2. “熵”

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

仔細想想剛?cè)胱〉男录沂遣皇菍挸ㄕ麧?，幾年之后是不是四處都是難以斷舍離的混沌景象。

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

回到我們IT從業(yè)者每天面對的軟件應(yīng)用，如果加上一個時間線來觀察TA，是不是也是越來越復(fù)雜、越來越混沌。回想一下你經(jīng)手的那些項目，隨著從0到1、從1到N，是不是越來越復(fù)雜，當(dāng)然，我們主觀不愿承認，在變復(fù)雜的同時也越來越“混亂”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

六、小結(jié)

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

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

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