低代碼,能讓程式設計師脫離996嗎?| 甲子光年
甲子光年 · 科技 ·

低代碼,能讓程式設計師脫離996嗎?| 甲子光年

勢與洞見No522005年,在國內某大型化工廠工作的萬斌來

願程式設計師早日脫離996。

作者 | 小沐

編輯 | 火柴Q


趨勢與洞見No.52

2005年,在國內某大型化工廠工作的萬斌來到位於瑞士的世界第二大造紙廠參觀。

一般人印象中,造紙是非常傳統的製造業,而萬斌卻看到,在寬如候車廳、長如十幾節車廂、高約三層樓的車間裡,機器井然有序,管理人員加工人一共就5人,2人坐鎮中控室,3人負責巡查。

「簡直就像兩個世界!」前後參觀過國內外500餘家企業的萬斌對「甲子光年」感嘆。

彼時,歐美軟體市場發展早,企業信息化管理理念和投入走在前列,整個車間能實現數據流通,從生產、財務、採購到銷售協同性高,出錯率低。

而在中國,萬斌看到的是,企業需求的個性化世界第一,對IT行業挑戰極大,嚴重依賴高級技術人員,最終形成了全面項目化、價格畸高的市場。

4年後的2009年,萬斌創立搭搭雲,想將企業所需各類軟體抽象出通用模型、形成底層平台,通過配置和少量開發就能開發出能管理關鍵複雜業務的軟體應用,這一做就是10年。

這之後,一批持相似理念的公司陸續出現:

徐平俊在2010年創立從BPM切入的雲開發平台公司奧哲;任向暉在2011成立辦公協作SaaS公司明道雲;劉鑫在2014年成立移動應用開發工具APICloud。它們如今都匯入了近年來乘雲計算趨勢而起的一個新賽道——「低代碼」

低代碼,本質是一種類似「樂高積木」的理念——將通用、可重複使用的代碼形成組件化的模塊,通過圖形化的界面來拖拽組件拼成應用,從而在只寫少量代碼或不寫代碼的情況下,搭建軟體應用。

「降低成本、降低價格、降低技術和人員門檻,這是低代碼平台要解決的終極問題。」萬斌告訴「甲子光年」。

在相似的「降低開發門檻」、「更高效構建企業軟體」的需求下,APaaS、RPA和中台等實踐在中國的增多(可見《SaaS公司做PaaS:過去了就厲害,過不去就死》、《數據中台,下一個平台型創業機會》、《RPA:AI落地的接盤俠》)。

這些紛繁概念,正共同回應著雲時代,企業構建軟體系統的挑戰和機會——生產力與生產關係正同步變革,只依靠ERP、財務軟體等割裂的系統就能打理好公司的時代早已過去:

運營上,要求「實時在線」。

經濟活動整體數據化程度的提升,需要業務實時在線,倒逼企業搭建覆蓋面更廣的信息化系統,使用者已從管理人員拓展到前端業務人員;

戰略上,要求「敏捷創新」。

部分企業管理思維已在主動發生變化。數位化轉型的過程,是企業內部各條線向上「戰略對齊」的過程——充分理解管理層戰略,同步執行敏捷創新,以靈活應對多變市場,快速決策末端業務方向。

例如,過去很多中國企業的CFO只算帳,現在的CFO要做戰略財務管理;過去很多CIO只採購基礎設施,現在的CIO需要理解企業數位化轉型戰略,思考第二曲線;甚至最末端的業務人員也要靠近「一把手思維」,比如,阿里僅僅用數百名運營人員,就支撐了全年超5萬億人民幣的GMV,他們被稱為「CEO級小二」,因有數據和運營工具的支撐,他們可以直接做決策,讓企業實現「神經末梢」的靈敏反應。

落實到信息化系統上,「實時在線」,要求數據的打通和流轉;「敏捷創新」,要求空前靈活的開發能力——低代碼正在第二點上發揮作用。

今天,「甲子光年」的文章將聚焦在低代碼類產品的討論

我們採訪了包括阿里宜搭、SAP、奧哲、搭搭雲、APICloud、數式、輕流、明道雲和華閩通達在內的國內低代碼各類玩家,及在該領域有投資布局的盈動資本等機構,試圖回答:可能對企業運營、管理轉型至關重要的低代碼實踐,在國內到底進展幾何?


1.低代碼起勢

低代碼開發平台在中國一級市場的「走紅」,直接原因是OutSystems激起的水花

2018年6月,這家已成立16年、專注低代碼開發平台12年的公司一舉獲得KKR和高盛的3.6億美元投資,估值超過10億美元,成為新晉獨角獸。

OutSystems的同行同樣表現亮眼:

2018年8月,低代碼開發平台Mendix被西門子以7億美元收購;2019年5月初,上市軟體公司Magic又收購了低代碼開發初創公司PowPow。

國內市場同期也消息頻頻:

2018年5月,低代碼軟體開發平台搭搭雲(2009)獲千萬級人民幣A輪融資;

同年9月,可視化機器編程雲服務平台宜創科技(2014)獲清源創投戰略融資;

同年12月,無代碼業務流程管理系統搭建工具輕流(2015)獲近千萬人民幣Pre-A輪融資;

8月,軟體產品服務商數式科技(2019)獲盈動資本數千萬人民幣天使輪融資;

同月,PaaS平台研發商ClickPaaS(2017)獲晨興資本數百萬美元A輪融資。

此外,具有低代碼開發平台能力的玩家,比如做BPM(業務流程管理)起家的奧哲、提供APP開發工具的APICloud、辦公協作領域的明道雲等,也都開始對外強調自己的「低代碼」身份。

其中,奧哲連續在去年5月和今年3月連續獲阿里5千萬人民幣A+輪融和高榕資本上億元B輪融資。

從一級市場的動向來看,低代碼至少成了當前一個不錯的「融資概念」。

2.更多、更快、更深、更重要

但低代碼被視作機會,不僅僅是因為對歐美市場的追風和複製。

實際上,中國的創業公司和巨頭,在這一輪資本小熱潮之前,就已開始嘗試低代碼理念的產品。

如投資了奧哲的阿里,從2016年起就在布局低代碼,今年,這一產品正式被命名為宜搭,開始以阿里雲和釘釘為平台對外輸出。

而奧哲、搭搭雲等新近或融資的廠商,在低代碼領域沉澱已久,如奧哲2010年發布的「H3 BPM」,搭搭雲2010年推出的「九章全協同雲」等產品中都有類似低代碼的理念。

在海外市場,微軟在2015年發布的PowerApp、Google 2018年開始測試的App Maker等都是低代碼產品。

而AWS也已在2016年挖角了曾先後在Salesforce、谷歌和微軟有低代碼開發平台經驗的Adam Bosworth,暗中醞釀著自己的低代碼力量。

新老玩家齊聚,資本傾囊支持,看中的是低代碼背後的深層需求推力。

在2017年的一場校友聚會上,低代碼數據集成平台客戶數據中台Linkflow(2017)創始人盛馬田聽了聯想CIO Arthur Hu的演講,深受啟發。

Arthur Hu否定了傳統軟體廠商SAPOracle以往所做的BestPractice(最佳實踐),即把一家公司成功經驗複製到其他公司的做法;他認為現在每個大企業都有一定數量的開發者,其業務也都獨一無二,再按照以往的路數行不通:「大企業需要的是一種可以讓它快速應對各種市場變化,響應客戶需求的IT能力。」

這種從複製最佳實踐到越來越追求獨特化的變革,有兩個推動因素——雲計算的興起和移動網際網路的深化發展

「尤其是2018年後半年,企業上雲的拐點到了,大家都會談如何去轉型升級,因為業務在不斷發生變化。」無代碼業務流程管理系統搭建工具輕流創始人兼CEO薄智元告訴「甲子光年」。

雲計算改變了企業信息化基礎架構,移動網際網路發展帶來大量數據通道——企業的內部管理系統和對外業務都在經歷全面的在線化和數據化,它讓企業的信息化需求變得更多、更新、更深和更重要

更多是指,信息化系統從後端移向前端,軟體的使用對象從管理層的「一小撮人」向更為廣泛的業務人員甚至最終C端用戶滲透,需要支持的企業內用戶數量和需求數量都在增多。

以前買ERP,其實是核心人員在用,現在我們的系統則是全員使用。」奧哲創始人兼CEO徐平俊對「甲子光年」說。

更快是指,在系統前移,向全員滲透的情況下,軟體自身的疊代也不斷加速。

更深是指,軟體解決的問題已不再受限於具體管理職能,而是要不斷擴展新邊界,解決包括數據打通、流程優化和創新業務在內的多樣問題。

更重要則是指,在數位化時代,信息和數據能力成為企業應對瞬息萬變市場變化的核心能力,因而開發能力和速度成為企業競爭力的重要一環,稍有延誤,機會便稍縱即逝。

「現在系統和業務結合得更多了,業務可變性又很強,這就需要強大的IT能力。」數式科技投資方盈動資本合伙人蔣舜告訴「甲子光年」。

更多、更快、更深和更重要,四者疊加,軟體應用的開發需求暴增。

以往,企業解決這些開發需求的方式無非兩種:一是內部或外包做定製化開發;二是直接買成品,部署軟體。

然而,兩者都已無法滿足當下需求

定製化開發雖足夠個性化,但開發周期長、投入大;而且中國軟體開發人員緊缺,集中在網際網路、金融等行業,大量傳統行業「嗷嗷待哺」。

「他們只會修電腦、招投標,如果讓企業自己的IT人員做交付,比較難。」某有多年軟體開發經驗的低代碼從業者對「甲子光年」評價,整體上,國內傳統行業IT人員的開發能力很弱。

直接買軟體,則可能造成功能浪費或不適用——企業買的SaaS產品可能有100個功能,但企業只需要10個。

此外,由於近年來,企業越來越多的業務開始信息化、數據化,軟體應用買得越來越多,財稅、HR、CRM、OA不一而足,結果越架越亂,導致數據煙囪林立,難以統一管理

低代碼開發,理論上,則能很好地避免定製化開發和買現成產品的弊端。

它能在滿足一定個性化的情況下,縮短定製化開發的周期,通過高可配置、可變動的「樂高式」工具,來快速解決企業各種多元化的、多變化的需求。

以OutSystems為例,其開發應用程式界面就如同一個文檔編輯器,只不過中間是一塊搭建應用流程的空白版,可以通過拖拽旁邊的功能組建進行搭建,此外,在需要寫代碼的地方,可以直接插入已有的代碼庫里的代碼,不用再手動輸入,這樣能大大提高效率。

作者|小沐編輯|火柴Q趨

OutSystems開發程序的界面

目前OutSystems的產品已能提供從用戶體驗設計到後端集成、大型應用開發和管理等全棧開發能力。

國內廠商的產品也初步顯現價值。

比如奧哲徐平俊介紹,奧哲的氚雲能幫開發者實現5分鐘配置一張業務表單、5小時搭建一個專屬應用、5天落地一個管理方案。

搭搭雲萬斌介紹,他們在佛山的一家工廠客戶已使用搭搭雲平台做了包括ERP、供應鏈、財務、OA、人力資源和項目管理的全系統應用,這種龐大的系統工程如果用傳統開發方式,一般需要至少 10人工作1年以上,而現在只需要2個人用 6-8個月就能完成。

同時,低代碼也能解決軟體應用過多、過亂和數據煙囪的問題。因為用同一個低代碼工具/平台開發出的不同業務的軟體應用,如HR、CRM等,能天然數據互聯互通。

最先定義低代碼市場的Forrester曾在2014年預測,該市場將從2015年的17億美金增長至2020年的155億美金,實現近10倍的跨越。

3.誰都沒有驗證

但預估的數字,並不能解決眼前的難題。在雲計算變革帶來的新需求推動下,國外低代碼賽道雖已有獨角獸,國內同行卻還處於艱難的開局期

多位採訪對象對「甲子光年」評價:中國低代碼領域還沒能成功驗證商業模式。

「國內的低代碼市場,無論從產品能力,整個理念,技術深度和廣度上都沒超過國外廠商。」阿里雲SaaS加速器負責人黃省江表示。

盈動資本合伙人蔣舜也非常坦承:「我覺得並沒有純粹的、標準的低代碼創業公司。只是今年投資本身沒有什麼題材,大家都會去看一看。

目前,從商業化落地的方式來看,國內的低代碼公司主要有兩類:

一類是基於低代碼工具的雲平台,同時服務第三方開發人員或有開發需求的客戶,這是一個看起來很美的「生態故事」。

這類玩家主要包括SAPOracle、金蝶、浪潮和Zoho等老牌軟體廠商,以及阿里雲、Salesforce等IaaS、SaaS巨頭;另有一些創業公司也在嘗試這條路徑,如奧哲、搭搭雲、APICloud和明道雲等。

這種打法與OutSystems最接近。2006年起,OutSystems原有的、為電信運營商提供敏捷開發服務的業務遇到瓶頸,他們做了兩件事:

產品轉型,開始直接銷售開展原業務時積累的開發工具,也就是它們低代碼平台的核心——客戶既包括有開發需求的企業,也包括一些以開發、實施為業務的軟體外包公司。

同時,Outsystems也會使用自己的低代碼工具為客戶做更高效地開發。

在2011年進一步上雲,將收費模式從賣軟體License變為訂閱後,OutSystems還開啟了新的平台模式——開發者和企業可以使用OutSystems快速定製自己想要的產品。

此後,這家公司真正迎來了快速增長,在2012年到2017年的6年間,年營收平均增速達41%,2018年的增速又打破了自己的記錄,達到了66%。

目前,OutSystems已疊代了第11版,客戶包括豐田、大眾、平治 、現代、 Bentley 、英特爾、施耐德電氣、理光等。

第二類是主要以低代碼工具來支撐自己的產品或解決方案。

這類玩家多為創業公司,比如輕流、數式科技、Linkflow和華閩通達等。

其中,輕流主攻的領域是BPM,數式針對的是協同採購和全渠道銷售領域;Linkflow是客戶數據中台,能讓業務人員將多渠道的客戶數據進行精細化管理。而工程建設領域的信息化服務商華閩通達,則是在內部打造了基於規則化法的無編碼信息系統快速開發平台R平台。

同時,第一類有平台業務的公司里,如奧哲、搭搭雲、明道雲和APICloud也都會用自己的低代碼工具來開發產品,以直接解決客戶的需求;奧哲在BPM領域有多年積累,搭搭雲和明道雲的產品包括協同、CRM、ERP等各類型管理應用,APICloud則涉及各類移動應用前端開發。

在這第二種模式中,低代碼其實是一種產品屬性或能力,它的核心價值是降低SaaS產品的研發成本,提高交付效率,而且可讓部分有能力的用戶自己做配置,提升客戶的體驗。這與「甲子光年」之前討論過的APaaS的作用非常相似。

但兩類玩家各有各的挑戰。

對第一類玩家而言,低代碼開發平台雖有OutSystems的明確對標,但中外市場階段不同、特點有差異,一個最大的分別就是上文提及的國內企業客戶自己的開發能力太弱,所以習慣性地尋求貼身服務。

「很多企業都在想,需要一個大數據工具、人工智慧能力,但很少會說我需要一個開發工具。」APICloud創始人劉鑫告訴「甲子光年」,「客戶的需求並不是一個低代碼平台,而是低代碼能夠產生的價值。」

簡要來說,就是企業客戶不喜歡DIY,這類平台真正要實現價值,要麼拉著別的合作夥伴一起上,要麼自己上,總之得把最後一公里落實了。

拉著合作夥伴的邏輯,就是生態的邏輯。

SAP雲平台業務拓展總監Gavin Du告訴「甲子光年」,通用軟體只能解決80%的業務需求,剩下的20%需要合作夥伴或客戶自己解決。SAP雲平台可以為開發者提供快速擴展、集成SAP解決方案的低代碼開發能力。

「形成生態後,還可以探索更多商業模式。」 Gavin說,比如合作夥伴可將已開發的產品放到平台上形成「應用超市」,進而獲得更多收益等。

但在平台這條路上,巨頭和初創公司實力目前看起來不對等。

一是已經進入該領域的阿里已在內部的多種場景中錘鍊過自己的產品。

宜搭產品經理蒲軼梅告訴「甲子光年」,阿里內部的HR、行政、財務和項目管理等多種應用的快速構建中都有宜搭產品;在前端業務上,如今天貓超市大促前的運營流程也是用宜搭,業務人員可自己用宜搭來設置商家報名流程和設計選品應用。

「我們輸出的是經過阿里自身發展過程中遇到問題與困難的解決方案,包括技術、業務、管理思想上的沉澱。以技術為例,阿里有著處理雙11高並發、大數據量的技術優勢,這是同類廠商所不具備的。」蒲軼梅說。

二是阿里作為IaaS廠家,有生態基礎也有搞生態的動力,對宜搭而言,盈利暫時不是急迫目標。

「我們可以不用關注短期商業盈利問題,可以有更多資源和時間投入到產品打磨、客戶服務中。雲廠商做低代碼更容易把生態做起來。」阿里雲黃省江說。

第二條路,自己上,其實就變成了目前低代碼的第二類模式,即把低代碼作為一種能力和屬性。

一些本來瞄著平台或對外講平台的公司,實際上也在開展這類業務。

在2009年成立的搭搭雲也於去年發布生態戰略,將低代碼平台開發給開發者使用,但同時也向客戶直接提供OA、HR、CRM、ERP、項目管理等SaaS產品。

這是一條務實之路,但馬上也會面臨此類公司的共通問題,那就是產品可複製化難,容易淪為項目制和外包,迷失在分散的需求中

正如搭搭雲萬斌感嘆:「我可以這麼說,在整個市場上都還在探索。現在還沒有形成集中的市場,還都是長尾市場,大家依然在過苦日子。但它確實是未來軟體開發的模式和方向。」

而且,不管是第一條路還是第二條路,低代碼理念本身的產品化就很難

「如果回到2009年再去做一次選擇,我可能就不敢幹這個事兒。」搭搭雲創始人萬斌表示,在創業第三年,公司就陷入了最困難、黑暗和絕望的低谷:從親朋好友借來的100萬種子資金已花光,剛開始落地的項目尚顆粒無收。

市場遠遠比萬斌想像中更複雜,「最初我做的功能引擎太幼稚了。」第一位客戶是重慶的一家家電製造企業,「勉強交付、客戶並不滿意。後來又把系統重新調整了一遍。」

做低代碼不是直接去造房子,而是做一套能反覆造各類房子的引擎和系統。雖然不需要攻克尖端技術,但技術的複雜度極高。

「我們在打造流程引擎時,踩過無數坑。」輕流薄智元告訴「甲子光年」,低代碼的坑首先還不在於不了解行業邏輯,它面臨的挑戰類似創造一門新的程式語言的挑戰,要提前想好整體框架和邏輯,以應對高可配置需要的各種可能性,「有時當新寫的B邏輯去調用已有的A邏輯時,你才發現A邏輯不完善,就需要把A邏輯推倒重來。」

一個產品無法解決所有問題,到最後不管是面向哪種使用者,都會發現國內企業太多、太複雜,產品很難做到普適性。

4.可配置的軟體和更廣闊的市場

低代碼背後的大邏輯:軟體正在吃掉一切,開發者日益成為企業的核心資產,服務開發者的中間層也變得重要。

「甲子光年」之前報導過的APaaS、RPA以及美國市場近兩年很火的微服務等概念,都處於類似的底層通用基礎設施和上層標準化產品之間的「中間層地帶」,共同應對著企業越來越靈活的開發需求。

圍繞開發需求的創新會繼續沿兩個方向發展:

一是直接提高開發效率,這也是目前的低代碼工具主要在做的事。

客戶數據中台Linkflow創始人盛馬田以自己公司的市場部為例,需要掌管的營銷渠道系統就高達15個。此時打通各個系統,讓數據流動就成為新的需求。而低代碼客戶數據中台恰好能高效、快速、低成本地解決這類問題。

「讓更多重複性工作由機器替代人完成,這也是科學發展的規律。」APICloud創始人劉鑫談到,低代碼開發平台始終不變的核心價值就是提升開發效率。

開發者目前是各低代碼開發平台競爭的重要資源。據APICloud介紹,他們已在移動開發領域積累了超過80萬的註冊開發者,其中2%為活躍開發者。Outsystems稱自己在去年新增了6000多名開發者,把這視為營收之外第二重要的指標。

二是讓業務人員更好地與開發者溝通,這其實才是開發工作中最難的部分,也是低代碼未來的一大趨勢——零代碼。

阿里雲黃省江分享了宜搭的案例,據他介紹,在他們服務的一家河北的印刷材料包裝廠中,一個對業務流程非常熟悉初中學歷員工,僅花1個小時,就用宜搭的產品做了一個簡單的進銷存系統。

率先實現零代碼,真正「幹掉開發」,讓廣大業務人員也能使用的可配置化的軟體將是一大趨勢。

而且這是一個大分母市場,這也是盈動資本蔣舜投資低代碼項目的主要原因,「這種巧妙的技術解決方案,有可能在企業服務市場分一杯羹。」蔣舜說。

至於誰能在推動未來的過程中獲得商業紅利,目前國內市場還處於早期,各廠家依然得回到現實,實打實出產品和競爭。

對雲計算巨頭和SaaS巨頭來說,他們會繼續自己的生態之路,且短期在單獨的低代碼產品或功能上並沒有太大的盈利壓力。

創業公司在目前的巨頭日益壟斷基礎設施的情況下,可能很難把平台之路發揚光大,更務實地做法是先把低代碼作為一種快速開發的工具,提高自己生產效率。

值得關注的切入點,仍是企業目前最急需解決的痛點。

T研究2019年4月的檢測數據顯示,目前國內企業使用最多的Top 5 SaaS應用是協同OA、雲客服、DSP、HR和雲存儲,針對這些有大需求的領域做低代碼模塊是眼前的機會。

另一個新機會是,IT之外,IoT的蓬勃發展也需要低代碼助力。

這是因為物聯網的應用更為廣泛,且開發更複雜、難度更高。

構成物聯網系統的傳輸層、感知層、支撐層、應用層和平台層都需要大量的複雜開發。物聯網平台需要調度「雲、管、邊、端」各方資源,還要兼顧傳感、語音等交互方式,隨時保持5G、Wi-Fi在線等,還要適應環境各異的物理空間裡的各種狀況,這比在PC或手機端上做開發難度大得多,包括工程師駐場費用在內的研發成本也更高,人才也更短缺。

低代碼類工具恰好能幫助降低物聯網領域的開發工作門檻,緩解成本、人才等一系列痛點。

且物聯網是一片規模巨大的藍海,據麥肯錫預計,2025年全球物聯網市場規模平均將達7.4萬億美元。

能否抓住這些機會,關鍵還是看to B競爭的核心——產品好不好用。在打磨產品這個硬功夫上,其實各玩家沒有捷徑。

從低代碼開發平台的產品特點來看,APICloud創始人兼CEO劉鑫認為應該有三個標準:aPaaS、MADP(移動應用開發平台)、可視化拖拽式少量代碼生成。

華閩通達董事長楊中慶分享了他理解的低代碼平台成的關鍵評判視角:效率提升程度、成本和軟體架構的合理性:

第一是,從業務到軟體的快速轉化,包括業務人員與程式設計師的轉化和溝通問題、工具的易用性等;第二是如何降低開發成本;第三是能夠搭建大型的、複雜的各種應用系統;第四是符合現代的開源和主流架構,能否實現各種部署方式以及實現軟體開發的二次、三次甚至多次配置開發。

早在1982年,James Mratin就發表論文《APP Development Without Program》,描述了搭建App不需要寫程序的構想。

成立於2001年的Mendix、成立於2002年的OutSystems和成立於2004年的ServiceNow,國外的低代碼玩家都經歷了多年的發展,才走出先平後陡的增長曲線。

中國的低代碼乃至零代碼發展尚需時日。

願開發者早日脫離996。

願程式設計師早日脫離996。

END.

聲明:文章觀點僅代表作者本人,PTTZH僅提供信息發布平台存儲空間服務。
喔!快樂的時光竟然這麼快就過⋯
繼續其他精彩內容吧!
more