起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識低代碼產品的“逆熵”小敗局
編輯導語：短短的一年間，許多企業都把風口朝向低代碼產品發展。傳統企業舍棄Sass，投向“逆熵”能不能行得通？作者從六個方面進行了分析，我們一起來看下吧。
一、PaaS級低代碼產品風口已來
2020年釘釘宣布宜搭加入“釘原生”生態圈，成為了低代碼在中國市場風光無兩的時刻，也把“低代碼”這個產品概念丟到了所有IT從業者面前。
從資本到各大企業戰略決策層，都嗅到了風口的味道。短短一年間，電商企業、民宿企業、智能家居企業、傳統SaaS企業、金融企業紛紛下注低代碼，但很多企業的戰略選擇，止步于既有的舒適區隔靴搔癢，正在給自己鋪就一場巨大的隱患局，隨時都有可能成為下一個被人玩味的產品“小敗局”。
二、我們先從這兩個關鍵詞開始
1. “低代碼”
討論低代碼產品之前，我們需要先來限定一下范圍。如果回歸本質，低代碼絕對不是一個什么革命意義的新鮮概念，只是一個隨著計算機編碼技術發展，技術不斷下放“平民化”的過程。
舉例來說，相較于原生編寫CSS、JS的前端編碼模式，Elements這樣的組件化封裝就是一種低代碼；同樣的，一些交付企業自己定義的DSL標記語言，相較于直接編寫Java代碼，也是一種低代碼。
誠然，這些都是低代碼領域的不同賽道，但往往以開源或內部封閉生態的交付提效工具為定位，產品商業化價值相對有限，我們在此也就不做贅述。
我們要討論的是以“搭建一個完整可用應用、提供完整運行可用交付環境”為目標的快速應用開發（RAD）PaaS產品。
Gartner在2020年魔力象限中定義在領導者（Leaders）象限的Salesforce、OutSystem、Mendix、Microsoft、Appian、ServiceNow無一例外均為此類產品。
如果我們把目光轉回國內市場，可以發現一線大廠也基本選擇了這個路線：阿里的宜搭、云鳳蝶、華為的AppCube、騰訊的微搭。雖然在能力層定位上略有不同，但基本的戰略規劃趨同，以后可以單開一帖對比一下他們彼此的異同。
2. “熵”
熵，作為一個熱力學概念，大家應該并不陌生，用來描述一個系統的混亂程度。除了描述一些物理現象，熵的概念一定程度上可以解釋這個世界發展的客觀規律——這個世間萬物都會本能的朝越來越混亂的方向發展——這就是熵增原則。
仔細想想剛入住的新家是不是寬敞整潔，幾年之后是不是四處都是難以斷舍離的混沌景象。
三、熵與系統演進
回到我們IT從業者每天面對的軟件應用，如果加上一個時間線來觀察TA，是不是也是越來越復雜、越來越混沌。回想一下你經手的那些項目，隨著從0到1、從1到N，是不是越來越復雜，當然，我們主觀不愿承認，在變復雜的同時也越來越“混亂”。
我曾經經手過一個內容管理系統的重構項目。10年前，這個項目設計初衷，就是一個標準到不能再標準的CMS內容管理系統。
- 清晰的角色：創作者、編輯者、發布者、閱讀者
- 清晰的功能：增、刪、改、查。
這在十年間，需求提出團隊換了一撥又一撥，開發執行團隊也換了一個又一個，項目從標準的CMS系統，新增了協作、分級審批、項目管理以及人事管理等一系列功能，項目越來越“混沌”。
十年之后的今天，已經沒有哪個人可以講得清這個項目的真正全景，也因此要想抽絲剝繭理出個頭緒簡直是困難重重。
做過這種老舊系統重構改造的朋友應該知道，這個例子只是窺斑見豹。一個軟件系統的迭代發展就是一個十分典型的“熵增”過程。
經過幾年迭代早已和最初的規劃相去甚遠，還記得最早的微信，是一個只可以進行文字信息收發的IM軟件，再看看今天的微信社交、內容分發、金融、電商、應用分發，已經是一個十足的“混沌系統”。
四、“逆熵”能不能行得通
熵增，是系統發展的必然規律，與產品領域規劃無關、與產品團隊的能力無關、與企業戰略規劃無關。
因此，作為一個“搭建應用的應用”，低代碼平臺的建設規劃需符合這一客觀規律。
在各顯神通的低代碼市場，也的確有一些團隊基于自己的業務背景，進行了通過“逆熵”將產品“低代碼化”的嘗試。
這些團隊背景，基本毫無疑問是SaaS產品出身，做低代碼的初衷也很簡單，就是通過配置化，替代不同項目交付的重復編碼工作。
Odoo、Zoho和OpenERP是這個賽道比較典型的代表。
Odoo在企業開源應用領域曾經風靡一時，起家于ERP領域，隨著市場拓展陸續在ERP、CRM、PLM領域有了較強的產品積累，為了更靈活的拓展產品邊界，提供給用戶靈活的企業應用解決方案，Odoo給出了自己的“低代碼”答卷。
依托自己建設多年的開源軟件生態，Odoo在自己的低代碼平臺Odoo Studio中整合了豐富的功能模塊，共用戶來“拼裝”新的應用。
不同于通用低代碼平臺將最小模塊拆分到組件力度，Odoo的功能模塊更像是一個個獨立的應用，例如記賬、用戶管理、MRP、PLM、設備管理、質量管理等模塊。
對于用戶，可以使用這些現有的應用拼裝出一個自己所需的工作臺，但如果現有的這些應用并不能滿足你的需求，那么，則需要通過開源框架，用代碼開發的形式編寫一個新的應用模塊。
同樣，如果你需要讓這些工作臺上的應用協同起來，只能自己編寫函數調用或者直接通過開源框架針對這些應用模塊進行代碼層面的二次開發。
從搭建應用的角度，Odoo應用市場的全部應用模塊就是它的能力邊界，Odoo Studio可以完成針對現有應用的拼裝，但無法通過低代碼拼裝的形式產生一個全新的應用。
同樣，某國產BPM廠商也交出了與Odoo類似的答卷。他們抽取自己BPM產品交付項目過程中一些常用的功能模塊，以供之后進行復用，但由于本身提取的模塊抽象程度不夠，實際使用中不得不將“復用”變為“新增”，實際依然是新的一輪編碼工作。
另外，由于模塊不夠標準，接口調用、數據連接用戶很難上手，最終還是需要負責交付的工程師幫助用戶完成。雖然售賣了低代碼平臺，但實際還是提供了SaaS交付級別的人力支撐。
這類產品普遍的方法論是基于已經成熟的SaaS系統，為了更靈活交付的目的，進行模塊化的拆分，讓一個已經成型的混沌系統有序化、標準化。
就像我們前文提到的，一個系統在演進迭代的過程中不斷熵增，越來越混沌；而進行這種模塊化的拆分就是一個“逆熵”的過程，在實際操作中會發現，由于模塊與模塊之間千絲萬縷的聯系，總是沒有辦法達到你想要的粒度，最終往往止步與一個完整的最小可用功能。
而對于一個工具，通用性直接取決于模塊的抽象程度，粒度越小，就可以達到更高的抽象程度。
這類走“逆熵”路線的低代碼工具，對于自己SaaS的交付場景，可能的確會有一些提效，但由于抽象程度不夠，總是跳不出自己的領域，難以成為一個通用的低代碼平臺，最終也就成為了交付團隊的低頻工具。
五、傳統SaaS是不是必然會走入這樣的困境？
這些SaaS交付型企業在低代碼建設中選這條“逆熵”的道路，一定是有歷史的包袱，這一點是無可厚非的，但是不是只有這一個答題思路，似乎不然。
我這里以國內某一BI廠商的低代碼平臺答卷為例，他們并沒有試圖通過低代碼去解決他們現有SaaS產品的靈活交付問題，而是把低代碼作為整個產品矩陣中的一個獨立產品進行規劃。
該廠的傳統BI產品是解決數據統計、處理、分析、展示問題，為了補全產品陣列中的閉環，他們的低代碼平臺鎖定了信息收集、工單流轉的表單場景，并且著重建設了與原有BI產品的數據打通。
單獨來看，表單場景似乎是相對簡單，但是配合該廠的BI產品就完成了一個數據收集到分析的完整閉環。
六、小結
- PaaS級低代碼產品本質是快速應用開發工具
- 應用的演進迭代逃脫不了系統熵增的客觀規律，低代碼產品的設計需要順應這個規律
- 傳統SaaS企業要注意，不要將自己囿于簡單通過低代碼方式完成交付的戰略困境
本文由 @小博 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自?Unsplash，基于 CC0 協議
博主是做apaas么？
是滴是滴 之前做傳統apaas