按照維基百科的說法：

低代碼這個稱呼是 Forrester 在 2014 年提出，指那些用可視化方式創建應用的平台，特點是代碼量比傳統開發少的多，甚至無代碼，所以能提高開發效率。

我用上述方式和團隊夥伴描述低代碼，他們會一臉茫然；因為語言過于專業甚至聽完之後“似懂非懂”對不對？那如何簡單理解低代碼這件事呢？

在我看來，它更像一種快速開發應用軟件的系統。

市場或運營人員通過少量代碼甚至無代碼的方式在平台快速拖拽模塊，構建出協同表格、采購或生産管理等一些列智能和業務類的管理系統來滿足日常。

早些年，它的存在是為專業開發人員提供支持，幫助他們提取開發應用過程中繁瑣“底層架構”和“基礎設施”的任務；從而提高開發效率。

這兩年流行起來的關鍵要素是“協同關系”的變化；比如：

前線業務人員想快速構建一套協同表格來傳達信息，以往隻能編輯好“回傳”，在發送給使用人，現在隻需要上雲端或者某個系統中直接編輯就可以達到實時更新的效果。

它有颠覆性意義的根本在于客戶一方面在軟件上投入更低，另一方面顯著降低了開發難度，非專業人員也能快速使用，充分調動企業各方面資源，降低對昂貴開發者的依賴。

代碼可分為三類：1）專業代碼，2）低代碼，3）零代碼

對于專業代碼而言，它還有兩個名字，“高代碼”和“傳統代碼”；歸根結底是一回事，形容用傳統方式編寫網頁、應用程程序或者軟件。

如：你開發某款APP，企業需要招聘IOS和Android工程師、前端測試，PM等人員共同完成；這意味着開發者坐下來一行一行的敲擊，并不斷測試修改直到上線。

通常，這種類型的代碼為主要項目服務。當為大量用戶設定特定事物，并定做非常強大且獨立的産品時是種不錯的選擇；但這需要大量的時間、金錢和精力。

那如何寫出高質量的代碼呢？一般有兩種途徑：

其一：先有好的産品經理進行通盤考慮，然後用優秀的工程師從底層架構開始搭建，進而把優秀的代碼風格延續下去；猶如蓋大樓，地基決定上層建築。

其二：從糟糕的工程師開始，不斷進行重構；向優秀的設計方案不斷逼近，如同那句話“縫縫補補又三年”，不斷修複與完善。

進一步說，高代碼質量的建設基于優秀的商業模式，産品方案和業務流程，用例圖，架構圖不斷把關鍵和複雜部分設計出來。

市場需要低代碼的原因是企業越來越需要通過各種應用（App，小程序）來完善内部的信息流轉，強化與客戶的觸點鍊接；所以，低代碼本身是基于“場景”出發。

根據多方調查結果顯示，在大公司内部項目失敗的主要原因之一是缺乏溝通（poor communication）。

傳統開發模式下，業務産品、設計開發、測試與運維人員都有自己的語言，他們各司其職，這造成長期以來很容易形成一個個“豎井”（silos），讓跨部門的溝通變得困難而低效。

這也是當下為什麼熱門的敏捷開發和DevOps都在強調溝通，前者協同是生意，後者協同是組織和流程。

連經典的DDD（領域驅動設計）也在強調通過統一語言來減少業務和技術人員的溝通成本；因此，有低代碼後可以從根本改變，各種角色在統一平台緊密協助。

這種全新方式不僅打破職場豎井，還能通過可視化的語言和單一的應用（頁面/數據/邏輯），輕松對齊項目進度，從而實現敏捷開發模式；所以，統一視角的業務協同下，它有三個優勢：

1）人員聚合，2）應用聚合，3）生态聚合。

首先，将所有工作人員統一聚集到低代碼平台進行作業，促進流程标準規範化；其次企業内容各應用的數據是天然互動，通過聚合的方式打通能消除數據孤島問題。

再者當低代碼平台聚合足夠多的開發者，會形成無限想象力的生态體系；這無疑也是流程再造的根本。

最後說下零代碼（Zero-Code / No-Code），從分類角度看零代表是完全不需要寫代碼的應用開發平台；這并不代表它要比低代碼先進，它隻是做了一個更極端的選擇而已，徹底擁抱簡單的圖形可視化，完全消滅複雜的文本。

舉個例子：

很多準新人結婚會找“婚慶機構”咨詢關于場地布置問題，以前策劃師在手寫筆記本上通過畫圖為客戶展示效果。

有零代碼後，他隻需基于平台的場景拖拽各種可視化素材，直接給出直觀展示。

選擇零代碼背後的原因是，公司期望盡可能降低應用人員的開發門檻，讓每個人都能成為開發者；這裡有個概念我們要清晰，“開發不等于寫代碼”，它是基于業務構建協同流程。

要知道，從專業角度出發即使非常專業的開發者，技術分工精細化的趨勢下（前端/後端/算法/運維）企業也很難做到獨立開發和運維整套複雜應用的全棧工程師，但零代碼能改變這一切。

但它也有局限性所在；比如：

一方面可視化的編輯器的表達能力遠不如圖靈完備的通用編輯語言，不引入代碼根本無法實現靈活定制和拓展；另一方面由于目标受衆是非專業人員，平台能支持的系統也是傻瓜式。

這隻能做到大業務的組件簡單堆疊，不支持顆粒化原子組件和靈活的布局；就好比你想更改一個icon的清晰的都很難。

總而言之，高代碼構建更高維度的業務和産品，零代碼是低代碼的子集，目前從市場看普适性和适用性均還未達到紅海效應；而低代碼則滿足少開發的場景使用。

可以說，自2021年1月釘釘落地“低代碼”應用之後很多人才開始關注此賽道。

有人認為低代碼革命來臨，也有人說低代碼可能導緻程序員失業，如果把時間拉長看也許你就不這麼認為。

從發展來看它經曆四個時間：

1980年IBM的快速應用程序RAD出現，2000年可視化編程叠代，2014年Forrester提出低代碼概念。

2016年國内相繼發布低代碼平台，2018年Gartner提出aPaaS和iPaaS的概念後市場逐步穩固。

由此可見此領域許多玩家早在幾年前就已經存在，比如國外低代碼領域一個巨頭OutSystems這家公司成立在2001年；FileMaker更是誕生在1985年。

所以，廣義上看它屬于SaaS中的分支，但成長速度和SaaS路徑對比明顯要慢很多；總之低代碼雖然說的很好，但市場發展并樂觀；原因歸屬兩個層面：1）技術成熟度，2）業務收益低迷。

• 第一個層面：

RAD（快速應用開發）、BPMS（流程）、可視化開發、模型驅動這些專業工具和名詞都有漫長曆史，它們是低代碼組成的必要條件，融合在一起顯然是新瓶裝舊酒，對不對？

或者你理性一點就不會這樣思考，原因是1980到2015年這段時間低代碼技術能力弱，表現亮眼的平台少之又少國内産品也尚未成型。

但由于投入成本沒那麼大，此期間也就為很多平台打下基礎；直到2015-2018年AWS、Google、Microsoft和Oracle等巨頭和資本入局市場才開始升溫。

看過經典管理書籍《跨越鴻溝》你會明白任何的技術都會遵守所謂的“技術成熟曲線”（The Hype Cycle）。

也就是說：你不可能一出生就直接跳過發育階段嗨翻全場被大規模采購和運用，是不是。

比如以模型驅動技術為例，雖十幾年前就有“理論體系”和“配套工具”的研究，但在技術背景下，由于能力不完備過于理想化等原因一直沒能在工業界走向主流。

從現在視角看，支撐低代碼的“老技術”已經通過幾十年的醞釀打磨變得穩固，另一些完美互補的新技術（e.g.雲原生、響應式web）均慢慢走向成熟，加上企業線上數字化的渴求，那低代碼也就順水推舟。

• 第二層面：

即使幾十年的低代碼技術已經足夠成熟，也一定在當年市場中産生現在的影響力，這是為什麼？

因為技術都是為業務服務的，早些年應用開發業務要比現在簡單，且需求者多半為「技術人員」而非現在市場、運營等其他崗位的人。

其次當年也沒有如今的多渠道，多樣化體驗和集成定制等需求，更不會成為企業級的标準配置，所以更缺乏快速變化的IT業務場景來推動交付。

雖然低代碼可以解決多端應用生成、雲原生架構、API集成；可放在當年業務背景下，加上技術不成熟；顯然整體的投入産出會有所下降，這不足以讓企業大面積采購來做解決方案。

如今不同，從外因講，中大企業的數字化服務市場，經過幾十年發展進入增長瓶頸期，不能從平台角度滿足軟件服務企業的業務增長需求，需要開辟新的賽道，于是中小企業的數字化轉型就被挖掘出來。

從内因角度出來，中小企業數字化轉型迫在眉睫，黑天鵝導緻轉型進行的提前；以傳統餐飲為例，他們需要建立在線訂餐、客戶管理、營銷管理、員工辦公等各種系統。

目前市面的中小公司有兩種狀态：

1）瘋狂踩坑，2）一張白紙。

前者他們吃過各種定做APP、小程序/H5的虧，投入巨大收入效果甚微；後者初創公司想做技術，但又沒有較多成本預算花在人工運維上。

除此外，對大公司來說，想開發款軟件内部流程環節複雜，這無疑沒辦法快速試錯。

據此在内因、外因的共同作用下，低代碼成為被風口選中的行業；加上資本的湧入無疑就火爆起來。

被高估還是被低估

查理·芒格有個經典的思維模型叫做“10-10-10”原則。

講的是在決策時思考三個問題，即：這個決策在10分鐘後會産生什麼影響？10個月後、10年後呢？在我看來，低代碼的價值短期被高估，長期被低估。

為什麼？不妨我們看一組詳細數據。

全球權威的技術研究和分析公司Gartner發布的《2021年中國ICT技術成熟度曲線報告》（以下簡稱“報告”），首次将低代碼應用開發平台（LACP）作為新興技術熱點被納入。

帆軟旗下産品簡道雲憑借完善的産品和輕量級的交付被入選LCAP （代表廠商），也是國内首家。

Gartner的報告研究常規覆蓋20多項新型技術和實踐，也就是說在過去幾十年中低代碼并未能夠真正拿出台面；而今天居然以新賽道的方式出現，這無疑反應該技術在全球的崛起與未來增長的潛力。

《2021年中國ICT技術成熟度曲線報告》

把視野放到國内，從行業規模看，2021年海比研究院數據表明中國低代碼廠商約有120家，IT桔子盤點投融資情況達15起。

預計到明年能達到200家的體量；以頭部為代表的有簡道雲、明道雲、帆軟、飛書、金蝶等。

從市場份額角度出發，今年低代碼規模達到28.5億；未來五年複合增長率為49.5%，明年可達42.6億；2025年預計達到142.2億；從使用者需求，低代碼平台被分為四種類型：

1）場景應用型，2）産品研發型

3）平台生态型，4）技術賦能型

場景應用是為具體細分領域業務而打造，開發側重于企業自用；生态屬于頭部布局中軟件的某一分支；技術支持則代表更底層的算法、區塊鍊等方面的協同；收入模式占比最高的是前三者。

我們能得出什麼啟發呢？

低代碼在全球視角下經過幾十年沉浮，終于以穩定增長模式進入大衆視野并且被市場所認可；智遠根本兩則“報告”總結，認為呈現三種趨勢：

首先，2020年将會有40%-60%的企業使用低代碼開發應用，其次企業從獨立研發APP開始向數字化平台轉變，并且将大企業數字化應用作為基礎設施。

再者大量平台的出現，會加速企業核心業務的系統開發；進一步說，低代碼能夠支撐起高複雜度，高技術、超大規模的應用開發。

并且将整個鍊路覆蓋到以客戶管理、運營流程、生産、配送為代表的核心業務部分；這種結構性的變化并且還會持續細分。

由此可見，頭部巨頭正在以生态為中心引入“低代碼”廠商；整個大市場熱度呈現先抑後揚；國内這麼多家低代碼公司突出賽道的關鍵點在于：1）産品使用門檻要低，2）行業積累要深耕。

也就是說：低代碼公司和巨頭平台結合，找到某個點切入細分和小衆市場，聚焦一個領域做深做透；深度運營和培訓客戶并建立壁壘，才能實現長期主義共赢。

如何選擇低代碼公司

資本有好有壞，難免也讓“創業項目”變形。

因為創始人的對賭協議想快速回籠資金而忽略産品體驗的公司不計其數，有些則默不作聲的打磨技術，在市場沒有任何聲音也很多。

在混戰的低代碼江湖中，中小企業要不要用低代碼或怎麼選适合自己公司的産品呢？這裡有三個思考：

• 1）産品公司實力，創始背景

首先如前所述，目前屬于行業爆發期，誇張點看似乎沒有一家低代碼公司不說自己是“專業軟件”公司的；那麼，借此風口來搶杯羹的大有人在。

假設因為預算而選擇家新創立或“團隊基因”一般的公司，可能以後在數據和産品使用方面的坑會踩不完。

我并非說“新創立”的公司不行，而是我們要看準合夥人資曆，對行業思考以産品定位等各要素；那大公司或上市公司背景就一定好嗎？未必。

有些企業雖有曆史但通過兼并收購方式買下某個産品是為補齊每年财報短闆，營收業務開展方面顯得好看。

所以他們通過此手段趕緊發布低代碼平台好抓緊搶占客戶，技術方面肯定不行的，無疑你就成了小白鼠。

其次是産品的發布時間，一般來看2015年左右的公司無疑在此行業算做足詳細調研。

因為2015年左右低代碼經曆過一次低谷期，也許當時他們前身并非是該行業，但能确定押注此賽道并活到現在說明創始團隊的眼光具有前瞻性。

再者從公司内部出發，落地某個項目時難免會遇到今天開發的功能沒用上，過段時間發現此功能又有用，所以版本的管理也很重要。

有些企業雖内部運用該軟件，但能否支持協同開發還是有必要的；除非是内部特别小驗證的項目，這方面我相信負責過項目的人應該非常感同身受。

• 2）業務是否真需要低代碼

不論從高管視角還是業務出發，很多公司整體認知對“低代碼”并沒有概念；即“他們不知道這個東西是什麼”或“我用它解決什麼問題”；當對産品了解後才知道“原來可以這麼幹”。

一般來說，企業不會用低代碼從零開發整套核心業務，比如ERP/CRM、甚至BOS智慧運營系統等；如果需要直接買套成熟解決方案即可。

所以就目前而言，低代碼更适合核心數字化系統之上，構建創新類的應用和敏捷運營類的運用；用最土的話表達是“解決企業到用戶之間最後一公裡的事情”。

那麼比較适合用低代碼的場景有哪些呢？我總結為5大方面：1）門戶端，2）數據操作和展示端，3）業務流程端，4）移動端，5）基于所有表格的運用

門戶包含APP，小程序，PC網站；數據方面包括通過鍊接企業内部的數據庫把生産經營打通，進行展示和簡單互動沉澱；業務流程包含跨部門協助、OA審批、人力财務等。

舉個例子：

現在要辦場1000人規模的行業大會，我們可以通過低代碼構建人員分工，物料明細和協同進度完成整體策劃執行，它可以像OKR一樣讓所有人看到每個人都在做什麼，從而來相互配合。

在移動端具體表現有核心經營系統管理系統，如考勤打卡；表格運用場景相對比較多，譬如基于數據庫的表單收集整理、統計處理等。

這是我從市場運營視角出發的角度整理，不難看出，以上五種類型算是覆蓋企業80%的數字化系統，除此外還覆蓋更多行業基本面，如教育、文旅、零售、金融等，不一而論。

• 3）是否是三位一體

通過分析國外的低代碼領導型公司，可以得出他們在業務上的創新方式是“組合式”。

比如Outsystems之前是做BPM（業務流程管理），SAP、Microsoft之前是做aPaas和MADP（移動開發平台）的重組，Kony也是做相似。

由此可見，把BPM，可視化和aPaas融合加上組件雲原生經曆市場打磨才形成“低代碼”平台；所以說這三種能力是國内公司也不可缺失的，總結為：1）MADP，2）可視化，3）aPaas

第一：大部分低代碼平台基于模型驅動橫跨平台開發能力，MAP能夠更好地應對中小公司數字化業務和創新的需求，持續演進的組件可根據需求快速建立新的建模器和産品服務。

第二：“可視化拖拽編輯器”是基本配置，若這方面不能解決就不能稱為低代碼平台，難道讓一個收銀員或運營寫英文表格嗎？顯然不現實。

第三：aPaas是PaaS（平台即服務）的子形式，它能支持應用程序在雲端開發和部署，能提供軟件開發中的基礎工具給用戶，包括數據對象、權限管理、用戶界面等；沒有此能力企業無法私有化部署。

基于三者之上所謂的一體是什麼呢？即：配套的生态。

換句話說，通過此低代碼平台能不能完成和其他雲與企業内部的數字化鍊接打通的能力很重要。

總而言之，不同平台都有自己的定位，假設沒有這三者基礎我想企業沒必要選擇，從價值鍊角度出發，它也是基于企業數據産生“信息環”當中必要的一環。

總結一下：

我們會看到各種新技術（算法）、模型和産品的問世，複雜的讓人難以理解對不對？

但好像它們都逃脫不了舊公司和新産品的組合；或新公司裝舊産品使用“新宣言”。

任何B2B企業以客戶需求為核心出發進行場景細化，萬變不離其宗好；你看，時間從不語，卻回答了所有問題。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部