01.
前言
2021開年“低代碼”接力“中臺”燃起了熊熊之火,引發了眾多業內人士論戰。其中有兩種極端的觀念,一種是“低端炒作”、“無用玩具”,另外一種是“顛覆行業”、“取代碼農”。
若說“顛覆”、“取代”,事實上,低代碼、圖形化的開發模式存在至少已有20年歷史了,又豈能在今天突然顛覆?
若說“低端”、“玩具”,事實上,國外低代碼平臺OutSystems估值超10億美元,Mendix被7億美元收購;Amazon、微軟、阿里、騰訊等國內外IT巨頭,以及大量傳統軟件廠商、新興SaaS廠商紛紛押注,如此估值與勁頭,又豈能以“無意義”一言概之?
所以,先別急著下定義,我們多角度來看一看。本文將分兩篇,上篇主要從行業角度聊,偏BRD/MRD,主要話題是低代碼火爆的背景、優勢、劣勢,主要用戶、客戶,企業選擇及行業競爭等;下篇主要從產品角度聊,偏PRD,主要話題是低代碼平臺技術模式、產品架構、核心引擎、配套能力等。
02.
低代碼火爆背景
低代碼是一種軟件開發模式,簡單“拖、拉、拽”即可快速搭建軟件。本文默認無代碼是低代碼的一種形態,兩者具體定義此處不再贅述。
低代碼的形式是“可視化編程”,核心是“復用”。像中臺一樣,提高復用率是低代碼的關鍵。但單單“復用”不足以解釋今年低代碼平臺的火爆,低代碼突然火爆的原因是什么?
2020年的疫情沖擊不容忽視,它挑戰了很多企業原有的商業模式、協作模式,數字化經濟的繁榮、信息化需求的激增,造成程序員供需失衡。
云計算技術的成熟、移動化的趨勢等,為低代碼2.0提供了技術基礎。萬維網出現前夕,計算機網絡是一座座孤島,互聯網打破了這些孤島。同樣,如今的信息孤島、云端孤島屢見不鮮,曾經的低代碼作為開發工具也只是在構建孤島。但“低代碼+云”的想象力將不止于此,如果能形成“互聯、共生的生態”,它有可能會打破當前應用與應用,企業與企業,開發者與開發者之間的孤島,大大提高代碼復用率,進而引發一次效率的飛躍。
國外低代碼平臺成功商業化,國內“互聯網+”、“數智化轉型”風口等都是催化因子。
03.
低代碼的劣勢
鑒于當下不冷靜的態勢,先聊聊劣勢,潑盆冷水清醒一下。
低代碼平臺本身是一個開發框架,能在平臺上造出什么很大程度依賴于框架本身的能力。在當前階段,諸多低代碼玩家憑著BPM(業務流程管理)、BI(數據分析)等廝殺于企業協同領域,無怪乎很多看客視低代碼為“玩具”。
但同時也應該看到,一方面,即使“玩具”也能為許多企業信息化轉型提供很大助力;另一方面,已經有玩家開始向APP、游戲甚至更高的層面探索,承載核心業務、復雜應用、多變的C端未來可期。
雖然很多低代碼平臺標榜自身靈活性強、解決企業個性化需求,但其前提是在框架能力范圍內。如果個性化需求剛好不在框架能力范圍內,二次開發實現成本、時間都不容小覷。若企業所選的低代碼平臺剛好又不夠開放,對平臺支持和升級的強依賴性會讓企業有苦難言,這便是所謂“鎖定”。
但同時靈活性高,又可能造成易用性下降,靈活性與易用性的平衡對低代碼平臺來說是個挑戰。
很多低代碼平臺框架對開發者是黑盒,這給開發者帶來兩大問題,一是活難干,二是沒前途。
1)活難干是在開發時一旦遇到Bug、性能等問題,由于不清楚內部實現邏輯,問題排查無從下手,代碼調試要反復切換界面,只能浪費時間干瞪眼等平臺支持時。
2)沒前途是專業程序員高度依賴低代碼平臺,而疏于Coding會造成能力蛻化,這長期來看意味著失業和放棄未來。
專業開發者是低代碼生態中極重要的參與者,如何讓專業開發者自愿入局對低代碼平臺來說也是個挑戰。
普通業務人員是低代碼平臺關鍵用戶,但讓業務部門把低代碼平臺用起來,至少要跨過3個門檻:技術門檻、心理門檻、動機門檻。
1)技術門檻,稍有技術含量、需要一定學習成本,就可以攔下很多人;
2)心理門檻,很多人會出于畏懼新事物和學習而拒絕接受;
3)動機門檻,以往業務方動下嘴就能拿到軟件,現在讓他動手自己干?很多人的懶惰是赤裸裸的現實。
1)跨越技術門檻,可以采用無代碼,但需要平衡靈活性的妥協;
2)跨越心理門檻,需要產品講好故事、做好交互設計,調整如“BPMN圖、ER圖、外鍵、函數、腳本”等專業詞匯,盡量避免觸發用戶畏懼心態;
3)跨越動機門檻,需要找到足夠痛的場景,通過行業模板、業務模板、交互設計等打造足夠簡單的操作方式。
低代碼平臺降低了應用開發成本,如果應用爆發式增長,出現大量無人或較少人使用的應用,則對業務價值不大,卻會帶來額外的認知、管理成本。同時,應用數和使用人數的增長,也會給平臺性能帶來挑戰。另外,用戶追求個性化前端呈現與平臺固化的前端呈現也是一種需要應對的矛盾。
總之,低代碼是個好東西,框架本身可以大大提升效率,但同時,它也存在著一些問題。莫要“成也框架,敗也框架”。
04.
低代碼的優勢
看了很多低代碼平臺的劣勢,也莫要灰心,先讓克里斯坦森為我們打打氣。他在《創新者的窘境》中定義了“顛覆式創新”,即比市場上現有產品更為便宜、更為方便的替代品,它服務于低端消費者或新消費群體,步步蠶食傳統產品的市場份額,最終取代傳統產品的統治地位。低代碼平臺是否是顛覆式創新,我們拭目以待。
1)學習成本降低是普通業務人員即可操作,為IT研發資源不足的企業降低人力成本。
2)開發成本降低是對于開發者而言,可以復用既有能力,減少低價值代碼耗費時間,同時,很多需求變更可通過配置方式實現,縮短了開發、運維等時間。
3)其他成本如溝通成本、測試成本,甚至云架構方式降低硬件成本等。
-
通過配置即可滿足一批新增或變更需求,直接避免了低價值代碼開發時間,開發效率提升10倍并不夸張,同時,也意味著客戶響應效率的極大改善,這是比開發效率更重要的事!
Bug界有個絕對真理,“代碼越少,Bug越少”,低代碼平臺開發應用所需的代碼量決定了其Bug量極少,甚至,“No Code,No Bug”。
低代碼平臺與“中臺”也有類似之處,由專家級開發團隊打造便于進化的高質量代碼。采用“復用”、“統一”的理念,降本增效、打破孤島。同樣,低代碼平臺也需要警惕“中臺陷阱”,本欲“賦能”業務,不料變成瓶頸,以至業務“無能”。
主要包括3方面,高度貼合業務、緩解低價值需求資源困境、提升程序員價值。
1)高度貼合業務。一個好的B端產品不是功能牛X,而是恰好能解決客戶當下的問題。這就需要產品可以適應不同成熟度的客戶,而不是一個標準方案走天下。筆者曾持此理念幫多省、多家運營商落地研發協同平臺,針對不同客戶成熟度給不同解決方案。傳統的標準化產品無法支持此理念,但低代碼平臺卻具備這個能力,筆者對低代碼平臺的信念之一也源于這種經歷。
2)緩解低價值需求資源困境。IT團隊總會面對做不完的需求,縱有人把控ROI,也難免頻繁出現一種怪相“業務方叫的急,上線后卻不用”,這種低價值需求對開發資源的占用是極大浪費。對于低價值需求,先用低代碼平臺滿足基礎需求可以改善這種困境。另外,也需要思考一個問題,“低價值需求真的價值低嗎”,這些被判定低價值的需求很難拿到開發資源,只能永遠在等排期,而低代碼平臺卻能給這些“死刑需求”生存空間,這些低價值需求有可能會是組織創新的一個源泉。
3)提升程序員價值。低代碼可以幫程序員減少在低級重復性工作上浪費時間,從而可以有更多時間專注于高價值的代碼,可以更深入業務,以更匹配的方式滿足業務需求。
“低代碼平臺+云”的生態,讓程序開發這門生意,上升到了互聯網的層面,兼具了互聯網四大效應,梅特卡夫效應、雙邊市場效應、規模經濟效應、協同效應。這才是低代碼2.0的想象力真正所在!打破信息孤島,讓應用與應用、企業與企業,開發者與開發者互聯共通,給“復用率”一次質變!
05.
目標用戶分析
低代碼的終端用戶可以分為3類,完全不懂編程的業務人員、專業編程的開發人員、拉通業務與技術的運管人員。不同的終端用戶定位,決定了低代碼平臺不同的演進方向,其重要性不言而喻。
業務人員的常見痛點之一是“做不對”,開發交付的軟件跟預期有偏差,低代碼平臺給了他們親手打造高度匹配業務需求應用的機會,無需再罵IT能力弱了。此處祭出一個比喻,“低代碼將像PPT一樣普及”。PPT給了很多人表達自我的機會,然而,卻沒多少人能用好PPT,這是PPT這個工具的問題嗎?
我們(低代碼平臺)如何幫業務人員寫好PPT(用好低代碼)?提供以下4種策略。
1)培訓。通過培訓讓業務人員理解工具的邏輯,能解決的問題,常用的方法等。讓業務人員在遇到問題時有意愿嘗試用工具解決,培訓方法如幫助中心、視頻教程等。
2)模板。懶得想、懶得動、想不清這些現象司空見慣,教一個人快速提升PPT水平的最佳方式就是直接給他一個寫好的模板,讓他簡單改改就成。所以,很多低代碼平臺走的也是這條路線,把行業內的最佳實踐編輯成模板,最大限度為用戶提供便利。
3)教育。這是培訓的進階狀態,不只是教人用PPT了,也教人寫PPT的思路。低代碼平臺深耕細分行業、細分業務領域,結合工具輸出專家在該領域的最佳成功實踐,讓用戶在使用工具時也能有業務認知成長。另外,培訓業務也是一項收入,一個護城河。
4)外包。有些人不愿意浪費寶貴的時間自己寫PPT,此時,花點錢讓別人代寫也是種方法。低代碼平臺提供或與此類代搭應用的人合作,也可以為用戶提供價值,此類人與后面要聊的“運管人員”多有重合。
開發人員的常見痛點是“干不完,沒前途”,時間總能被無盡的需求、Bug、變更、重構等塞滿。然后,辛苦數年,35歲被掃地出門。純靠低代碼平臺難以滿足用戶的全部需求,而且在滿足用戶的基本需求后,個性化是必然的趨勢,“福特T型車的興衰”是歷史之鏡。想服務好客戶,必然要與專業開發人員共生。
如何打造開發人員愿意參與的低代碼共生生態?提供以下3種策略。
1)插件市場。低代碼平臺專注最通用、簡單的業務,保障平臺基礎的易用性。一部分具有通用性的復雜業務,通過插件的方式由用戶自主選擇,以提供一定的靈活性。采用類似AppStore的思路,引入獨立開發者開發插件,這樣既能滿足用戶的個性化需求,又能為獨立開發者提供賺錢門路。
2)開放對接。改善低代碼平臺“黑盒”屬性對開發者的不友好,為開發者做故障排查定位提供幫助。另外,平臺通過API等方式支持與第三方服務之間靈活對接,為開發者提供自由選擇的空間。
3)產品層次。通過產品架構設計讓產品具備層次性,即給一線業務人員、二線運管人員、三線開發人員提供不一樣的產品能力。對于業務人員,采用“無代碼”,以絕對的易用性解決最急迫的業務需求;對于運管人員,采用“無代碼+插件”,解決一部分個性化需求;對于開發人員,采用“純代碼+API”,迎合開發人員使用體驗,明明可以幾行代碼搞定的事,就不要讓開發者蹩腳的在界面里“拖拉拽”了。
運管人員的常見痛點是“等不及”,面對客戶、領導的直接壓力,恨不得擼起袖子下手干。只恨接不下開發兄弟的絕招,“You can you up,no can no BB”。此處,運管人員泛指那些介于業務和開發之間的角色,如產品經理、項目經理、運營人員、咨詢師、售前等。這些中間角色既能站在業務角度思考問題,又具備一定的軟件思維和技術功底,是低代碼平臺的理想用戶。他們可能是最有意愿花時間研究產品使用方法的群體了,滿足他們的需求需要低代碼平臺的UI設計、產品交互和配置能力強大,以迎合不愿將就、略有挑剔的他們。
06.
目標客戶分析
低代碼的消費客戶可以分為2類,企業和軟件廠商。客戶是收入的直接來源,關乎低代碼平臺的生存。但客戶畫像這個話題很難聊,一方面它需要細化,泛泛而談沒有意義;另一方面,平臺在生存探索中,可能會不斷調整。
企業又可按行業、規模等細分,不同類型企業需求不同,甚至審美風格也有獨特偏好。如中小企業相對價格敏感,IT人員匱乏,能滿足需求即可,追求簡單、易用、速度,偏好整套打包方案;大中型企業通常已建成部分系統,可能涉及系統對接、二次開發等,注重安全,相對強勢,個性化要求多,講究產品專業性、先進性等。不同類型企業,需要的方案不盡相同,有些僅需要低代碼平臺的自由流程定制能力,作為信息化能力補充滿足邊緣需求;有些需要在特定業務領域先進價值主張,解決企業特定的問題;而有些則需要完整解決方案,并通過簡單配置作為主要協同工具。
包括傳統軟件廠商和ISV,很多傳統軟件廠商仍在基于流程引擎幫客戶做定制開發,低代碼工具可以作為攪局者殺入這一領域,幫軟件廠商壓縮團隊規模,以更低成本、更快速度完成項目交付。而定位ISV則需要平臺本身具有巨大的客戶量,這是巨頭們廝殺的領域。
07.
企業如何選低代碼平臺
企業面對這個問題通常有2個選擇,選擇自建低代碼平臺,或選擇購買第三方低代碼平臺。
在決策是否自建之前至少要考慮清楚3個問題,引入低代碼的目的是什么?比購買第三方軟件ROI更高嗎?公司是否有足夠的實力折騰?有些中型企業可能會認為低代碼技術門檻并不高,拼裝流程引擎、表單設計器、報表設計器等即可,但事實并非如此簡單。低代碼平臺看似簡單,但建設成功率并不高。除了要面對本文所講的低代碼的劣勢,還至少會面對3個問題:
1)成本高,低代碼平臺是個持續建設的過程,對架構師能力要求極強,還需要解決可能的性能瓶頸問題,而性能問題解決不易。
2)缺人才,作為一個不通用的內部開發框架,幾乎沒有開發人員會傻到為此葬送前程,公司會因此面臨極高的開發人員離職率,頻繁的人力更換不僅成本高,而且會影響業務發展。
3)速度慢,一旦有個性化或超出平臺能力之外的需求產生,就需要對平臺框架進行升級,而框架升級通常速度緩慢,此時,業務只能等待;同時,如果沒有平滑的升級策略,整個開發團隊會反復深陷在應用重構之中。
選購低代碼平臺也需要謹慎,選平臺容易,換平臺難。不同的企業場景不同,無法推薦某家平臺絕對適合所有企業,本文僅提供5個通用因素以供參考。
1)自身需求。這是最核心的考量因素,不應該對比產品的功能數量、技術亮點等,而應該先明確自身的需求,尋找一個與自身需求相匹配的平臺,是需要一個全套平臺?還是需要靈活的流程自定義功能?
2)公司實力。如果低代碼平臺公司抗風險能力弱,一旦倒閉,數據、時間損失極大。
3)產品開放性。選擇低代碼平臺是一個長期的事,勢必會有個性化需求,若平臺對二次開發不友好,API不夠開放,自家程序員無能為力,企業會面臨尷尬的處境。
4)產品生態。如果低代碼平臺生態能力強,可以吸引到ISV,甚至獨立開發者,意味著企業未來的個性化需求不僅可實現,而且成本較低。
5)產品性價比。低代碼平臺本身功能多樣性、價格等可能是最后考量的因素,對企業來說,選擇、使用所花費的時間成本可能比花的錢更重要。對大企業來說,需要考慮的因素更多,如多端適配、多租戶權限體系、運維可擴展性等。
08.
低代碼平臺競爭策略
筆者對低代碼的未來樂觀,但對很多做低代碼的公司持悲觀態度,尤其資本力量不足的小公司。小公司缺資源、缺技術,不敢犯錯,產品規劃又容易屈服于客戶,生存和成長都不容易。阿里有釘釘的客戶群體,騰訊有企業微信的殺器,其他互聯網巨頭背后也都有足夠的人力、財力支撐,小平臺該如何競爭?筆者姑且臆測3種競爭策略。
杰弗里·摩爾在《跨越鴻溝》中提到產品諾曼底登陸策略,既先牢牢占據一小塊市場和用戶,然后逐步積累優勢。做通用平臺無法跟巨頭競爭,應該規避劣勢積累優勢,在起步階段,先垂直深耕一個領域,逐步完善產品,讓產品更匹配客戶的業務、審美、交互等,對比巨頭形成差異化優勢,待成熟之后開始拓展服務領域。
雖說把低代碼僅當工具略顯低端,但如果能借開源聚集足夠多的開發者人氣也能形成一定的競爭力。借助開源促成活躍的開發者社區,形成類似Python的強大類庫或AppStore的市場。簡單需求讓客戶通過工具本身設置快速實現,中復雜需求讓客戶通過插件配置化實現,高復雜需求讓客戶可以快速找到開發者定制實現。平臺提供插件市場和開發者定制市場,讓客戶、開發者和自身三方得利。以此,低端打高端,農村包圍城市。
而當下很多低代碼平臺對小微企業云資源免費的策略,筆者并不看好。這并不是好的雙贏策略,一方面增加了平臺本身的成本;另一方面,在乎這點錢的客戶本身付費能力、存活率都不高,陪他們玩吃力不討好。況且,客戶的選擇成本遠遠大于金錢成本。不如,直接開源,客戶想在自己服務器上玩就讓他玩好了,但平臺本身也提供優惠的甚至限期免費的云資源,以此吸引客戶。
最后,關于架構,盡量解耦,低代碼不只是適用于流程類場景,如表單自主設計、列表頁自主設計、工作臺、數據可視化等均可以成為獨立的服務,以此為開發者提供足夠的選擇空間。
小公司的低代碼平臺談產品規劃有些奢侈,先拿下客戶項目,一方面可以活下來,另外能跟隨客戶一同進化。尤其是行業大客戶,雖然有時候他們的需求有些個性化,但這些個性化需求背后可能隱藏著行業痛點。通過行業深耕,打造“行業基礎應用+低代碼能力”以形成行業競爭力,而后逐步向企業上下游探索。
特別聲明:
文章來源:產品曉說(pmxiaosi)
作者:李曉杰,10年IT,7年B端大客戶產品經理,分享產品和讀書思考。
原文鏈接:https://mp.weixin.qq.com/s/DOqQeKhWILkahTvyjLihAA
RPA中國推薦閱讀,如有侵權,請聯系刪除
繼續閱讀:流程自動化 RPA
未經允許不得轉載:RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > 深入看透低代碼——阿里、騰訊等巨頭火拼的下個風口
熱門信息
閱讀 (14728)
1 2023第三屆中國RPA+AI開發者大賽圓滿收官&獲獎名單公示閱讀 (13753)
2 《Market Insight:中國RPA市場發展洞察(2022)》報告正式發布 | RPA中國閱讀 (13055)
3 「RPA中國杯 · 第五屆RPA極客挑戰賽」成功舉辦及獲獎名單公示閱讀 (12964)
4 與科技共贏,與產業共進,第四屆ISIG中國產業智能大會成功召開閱讀 (11567)
5 《2022年中國流程挖掘行業研究報告》正式發布 | RPA中國