前言：
回望過去的2021年，零代碼開發(fā)成為了一種潮流，它以一種不可阻擋的趨勢，席卷了各個行業(yè)。新冠疫情的爆發(fā)，讓企業(yè)數(shù)字化進程開始提速，低代碼技術經(jīng)過大量的案例驗證，已經(jīng)被證明是符合當下企業(yè)數(shù)字化的首選開發(fā)技術。先進的低代碼平臺，也正在重新定義企業(yè)現(xiàn)在及未來的數(shù)字化方式。
而國內，也涌現(xiàn)了很多零代碼廠商，作為一個近10年的零代碼玩家，見證過以表格服務器為代表的舊玩家的衰落，也見證了以云服務、輕應用搭建為主的新玩家的崛起。我們花大量時間分析對比了新老玩家們的優(yōu)劣勢，不斷深耕研發(fā)技術，一次次迭代，終于也有了自己的較成熟的低代碼產(chǎn)品。如果說互聯(lián)網(wǎng)是一個江湖，那零代碼領域也有自己的江湖， 在這個江湖里，魚龍混雜，學派眾多。
數(shù)字化浪潮下，零代碼廠商會越來越多，但是，To B 的產(chǎn)品真的那么容易做嗎？什么樣的團隊才能夠真正做出好的適配的產(chǎn)品？今天，我就想好好聊一下這件事。
在講這件事之前，我將主要從應用場景，零代碼產(chǎn)品，以及處理能力三個方面來深入分析一下目前市面上比較被大家熟知的零代碼開發(fā)領域的數(shù)字化產(chǎn)品。
一、應用場景
我們主要將數(shù)字化辦公的場景分為三類：
第一類是個人級的應用。典型的場景就是表格的數(shù)據(jù)整理，比如整理人員名冊，記錄銷售明細等?，F(xiàn)在我們通常用Excel或在線文檔來完成，這類的應用以離散型的場景居多。
第二類是輕量級的協(xié)作應用。典型的場景就是表單的收集和整理，以及流程審批等。業(yè)務和業(yè)務之間具有輕量級關系，這類的場景以點對點的線性場景居多，不會牽扯很長的業(yè)務線和不同條件關聯(lián)。比如防疫填報和收集，表格的下發(fā)和上報，流程審批等等。
第三類應用我們叫復雜的數(shù)字化應用，也稱為關系型應用。主要是以企業(yè)管理模型為基礎的各種業(yè)務流轉，這類的應用才是企業(yè)管理中最具典型性的應用。比如我們一個制造型企業(yè)生產(chǎn)制造過程中是以銷售開始財務結束的整個過程管理，所以也稱關系型應用。
以上三類場景是數(shù)字化辦公領域典型的應用場景，實際上前兩類的需求都是包含在第三類場景需求中，他是企業(yè)管理模型下的一個環(huán)節(jié)，第三類場景解決了，前兩類的需求也就解決了。
二、零代碼產(chǎn)品
所有的軟件廠商其實是圍繞這些應用場景提出自己的解決方案，誰的綜合方案最優(yōu)，誰就更具有競爭力，根據(jù)我們的理解，將市面上典型的零代碼開發(fā)平臺做了一個對比分析。
在產(chǎn)品的技術架構上，我們把所有的產(chǎn)品分為了兩大類，一類是以表格控件設計為主，一類是以拖拽控件設計為主。這兩種技術架構是目前零代碼開發(fā)平臺采用的主要模式，在技術選型上的不同也導致了大家在應用場景上有很大不同，這兩類產(chǎn)品中的典型代表分別是勤哲的Excel服務器和帆軟的簡道云。
簡道云控件式設計
勤哲直接采用了Excel表格與關系型數(shù)據(jù)庫關聯(lián)的方式來設計業(yè)務系統(tǒng)，它應該是國內最早做零代碼開發(fā)平臺的廠商（在02年左右）。在當時前端互聯(lián)網(wǎng)技術還不夠成熟，主要采用C\S模式的時代背景下，具有一定的競爭力。它的產(chǎn)品優(yōu)勢是基本上能夠處理與表格相關的所有管理業(yè)務，綜合了表格和數(shù)據(jù)庫的功能優(yōu)勢。
但劣勢也很明顯，設計和應用依賴于Excel，表格控件是這類產(chǎn)品的核心技術要素，但他們自始至終都沒辦法自主掌握。15年之后，前端互聯(lián)網(wǎng)技術迅猛發(fā)展，企業(yè)的產(chǎn)品選型都偏向以B/S架構為主，這類的產(chǎn)品慢慢的走向邊緣化。這也是為什么他最早誕生，也有自己的高光時刻，但沒有延續(xù)成為一家偉大公司的原因。與其說勤哲是被其它產(chǎn)品所打敗，不如說是落后的軟件開發(fā)生產(chǎn)力跟不上用戶日益增長的業(yè)務需求。
以勤哲為典型的產(chǎn)品中衍生了很多以”某表”命名的零代碼開發(fā)平臺，統(tǒng)稱為表格服務器，他們是照著當時勤哲這家菜館的生意好，又在旁邊開了幾家的模式經(jīng)營的。這些表格服務器產(chǎn)品也都沒有自主的表格控件，基本上都依賴微軟體系產(chǎn)品：Excel或者被淘汰的serverlight技術。
這些照著勤哲的思路另外打造的同款類似產(chǎn)品，雖然交互性不夠友好，表格控件無法自主，但在處理企業(yè)數(shù)字化問題時，能力都是非常突出的，它應該是當時最適合中國式管理下數(shù)字化問題的解決方式。
只是處理這些問題時，核心的表格控件問題一直沒有得到很好的解決。在勤哲02年誕生到現(xiàn)在的20來年基本沒有廠商能夠自主過，這些年我所了解到團隊中都嘗試過自主表格的努力，以及B/S架構的轉變，基本都以失敗告終。
直到17年前后誕生了兩款產(chǎn)品：Workfine和活字格。他們的平臺里才有了合適這類產(chǎn)品的自主表格控件。活字格所屬公司本身有自研表格控件產(chǎn)品，叫SpreadJS表格控件，有比較好的技術優(yōu)勢。但可能團隊是偏技術出生，產(chǎn)品解決方案有待優(yōu)化，使用門檻比其他產(chǎn)品高，本質上還是面向技術人員需要代碼實現(xiàn)的產(chǎn)品。Workfine的表格控件是深度集成在Workfine平臺中，專門為此開發(fā)平臺而設計的web表格，團隊是項目型出生，長期在現(xiàn)場一線處理各行各業(yè)業(yè)務問題后轉型做數(shù)字化產(chǎn)品，在產(chǎn)品解決方案上的優(yōu)勢比較明顯。
簡道云是帆軟旗下的產(chǎn)品，是比較典型的控件式設計產(chǎn)品，發(fā)展也很穩(wěn)健。帆軟以做報表和BI起家，最初他們是不做填報和業(yè)務系統(tǒng)的，簡道云的出現(xiàn)為他們的報表和BI工具提供了基礎支撐。
帆軟產(chǎn)品定位比較清晰，也在企服領域深耕多年，前期客戶和場景的積累為其產(chǎn)品的發(fā)展的提供了很好的驗證和鋪墊，是做工具型產(chǎn)品里面相當成功的企業(yè)。簡道云對自己的產(chǎn)品定位也非常清晰：輕量級應用搭建平臺。這個也從側面反映了復雜應用的技術門檻是比較高的。
從其產(chǎn)品的技術形態(tài)上來看，也做不了復雜的數(shù)字化應用。因為采用了控件式的拖拽設計，以及后端采用了非關系型數(shù)據(jù)庫，在設計過程中無法滿足個性化很強的樣式設計或者關系型很深的邏輯設計，這兩個因素恰恰是處理復雜關系型業(yè)務的關鍵點。
那為什么他們要采用控件式的拖拽設計和和后臺非關系型數(shù)據(jù)庫呢，這底層大多是出于商業(yè)模式和技術門檻的考量。
拖拽式控件會比表格式控件的技術門檻低很多。前面說過，近20年來，只有Workfine和活字格能夠自主表格控件，光一個表格控件的研發(fā)周期和技術門檻都讓絕大多數(shù)廠商望而卻步；同時拖拽式設計在視覺展示上會更吸引用戶，初期的使用門檻也會低一些。
采用非關系型數(shù)據(jù)庫的原因是大都是商業(yè)模式的驅動，因為大家初始都采用了SaaS模式，而非關系型數(shù)據(jù)庫在SaaS模式上比較有優(yōu)勢，當然云上的優(yōu)勢也帶來的私有化的劣勢。所以大家在做產(chǎn)品技術選型時，很多地方是有利有弊無法兩全其美，大家也是在不斷取舍中不斷摸索。
(圖表格控件可直接復制表格信息，拖拽控件的設計形式單一)
以簡道云為代表的第二類產(chǎn)品原則上都屬于同質化產(chǎn)品，像明道云，輕流，伙伴云，氚云等等。采用拖拽式控件+非關系型數(shù)據(jù)庫的技術，這種技術選型只能夠處理輕量級的數(shù)字化場景，所以他們能夠展現(xiàn)的案例中最復雜是類似進銷存或者CRM這樣的案例，購買其中的任何一款不會再購買第二款。隨著零代碼的普及，這里面的競爭應該也會越來越清晰化。
第一大類和第二大類產(chǎn)品中目前會有很明顯的場景區(qū)別，所以，兩個大類的零代碼產(chǎn)品之間會有自己獨立的一個市場空間，形態(tài)上也有很明顯的差異化區(qū)別，短時間相互之間是沒辦法取代的。
其實做這類的產(chǎn)品很重要的就是打磨的過程。廠家和用戶是一個協(xié)同共生，互相成就的關系。當廠家能夠積淀足夠的用戶量以及應用場景量，那么就能反過來以滿足更多用戶實際痛點需求為目的，將產(chǎn)品打磨地更精細。如果僅僅是紙上談兵的理解，很多時候產(chǎn)品是沒辦法落地的，或者應用也不會長久。
但我覺得表格式設計的產(chǎn)品中才會有真正的大魚。輕量級應用相對來說用戶粘性會弱一些，門檻低。復雜的數(shù)字化應用用戶價值高，粘性強。同時企業(yè)的數(shù)字化辦公應用絕大部分是在管理模型下的連續(xù)的、關系型的應用。
能夠處理復雜應用的工具，如果再解決了交互的細節(jié)問題，以及積累出豐富的有深度的案例，達到開箱即用和隨需調整的效果，這樣對場景的粘合也會更加的強，輕量級應用的需求也會慢慢被稀釋掉了。
