深入看透低代碼：阿里、騰訊等巨頭火拼的下個(gè)風(fēng)口（阿里的低代碼平臺(tái)）

圖片來源@視覺中國

文丨產(chǎn)品曉說（ID：pmxiaosi）

一、前言

2021開年“低代碼”接力“中臺(tái)”燃起了熊熊之火，引發(fā)了眾多業(yè)內(nèi)人士論戰(zhàn)。其中有兩種極端的觀念，一種是“低端炒作”、“無用玩具”，另外一種是“顛覆行業(yè)”、“取代碼農(nóng)”。

若說“顛覆”、“取代”，事實(shí)上，低代碼、圖形化的開發(fā)模式存在至少已有20年歷史了，又豈能在今天突然顛覆？

若說“低端”、“玩具”，事實(shí)上，國外低代碼平臺(tái)OutSystems估值超10億美元，Mendix被7億美元收購；Amazon、微軟、阿里、騰訊等國內(nèi)外IT巨頭，以及大量傳統(tǒng)軟件廠商、新興SaaS廠商紛紛押注，如此估值與勁頭，又豈能以“無意義”一言概之？

所以，先別急著下定義，我們多角度來看一看。本文將分兩篇，上篇主要從行業(yè)角度聊，偏BRD/MRD，主要話題是低代碼火爆的背景、優(yōu)勢、劣勢，主要用戶、客戶，企業(yè)選擇及行業(yè)競爭等；下篇主要從產(chǎn)品角度聊，偏PRD，主要話題是低代碼平臺(tái)技術(shù)模式、產(chǎn)品架構(gòu)、核心引擎、配套能力等。

二、低代碼火爆背景

低代碼是一種軟件開發(fā)模式，簡單“拖、拉、拽”即可快速搭建軟件。本文默認(rèn)無代碼是低代碼的一種形態(tài)，兩者具體定義此處不再贅述。

低代碼的形式是“可視化編程”，核心是“復(fù)用”。像中臺(tái)一樣，提高復(fù)用率是低代碼的關(guān)鍵。但單單“復(fù)用”不足以解釋今年低代碼平臺(tái)的火爆，低代碼突然火爆的原因是什么？

1、社會(huì)、經(jīng)濟(jì)因素

2020年的疫情沖擊不容忽視，它挑戰(zhàn)了很多企業(yè)原有的商業(yè)模式、協(xié)作模式，數(shù)字化經(jīng)濟(jì)的繁榮、信息化需求的激增，造成程序員供需失衡。

2、技術(shù)因素

云計(jì)算技術(shù)的成熟、移動(dòng)化的趨勢等，為低代碼2.0提供了技術(shù)基礎(chǔ)。萬維網(wǎng)出現(xiàn)前夕，計(jì)算機(jī)網(wǎng)絡(luò)是一座座孤島，互聯(lián)網(wǎng)打破了這些孤島。同樣，如今的信息孤島、云端孤島屢見不鮮，曾經(jīng)的低代碼作為開發(fā)工具也只是在構(gòu)建孤島。但“低代碼 云”的想象力將不止于此，如果能形成“互聯(lián)、共生的生態(tài)”，它有可能會(huì)打破當(dāng)前應(yīng)用與應(yīng)用，企業(yè)與企業(yè)，開發(fā)者與開發(fā)者之間的孤島，大大提高代碼復(fù)用率，進(jìn)而引發(fā)一次效率的飛躍。

3、環(huán)境因素

國外低代碼平臺(tái)成功商業(yè)化，國內(nèi)“互聯(lián)網(wǎng) ”、“數(shù)智化轉(zhuǎn)型”風(fēng)口等都是催化因子。

三、低代碼的劣勢

鑒于當(dāng)下不冷靜的態(tài)勢，先聊聊劣勢，潑盆冷水清醒一下。

1、能力弱

低代碼平臺(tái)本身是一個(gè)開發(fā)框架，能在平臺(tái)上造出什么很大程度依賴于框架本身的能力。在當(dāng)前階段，諸多低代碼玩家憑著BPM（業(yè)務(wù)流程管理）、BI（數(shù)據(jù)分析）等廝殺于企業(yè)協(xié)同領(lǐng)域，無怪乎很多看客視低代碼為“玩具”。

但同時(shí)也應(yīng)該看到，一方面，即使“玩具”也能為許多企業(yè)信息化轉(zhuǎn)型提供很大助力；另一方面，已經(jīng)有玩家開始向APP、游戲甚至更高的層面探索，承載核心業(yè)務(wù)、復(fù)雜應(yīng)用、多變的C端未來可期。

2、靈活性低

雖然很多低代碼平臺(tái)標(biāo)榜自身靈活性強(qiáng)、解決企業(yè)個(gè)性化需求，但其前提是在框架能力范圍內(nèi)。如果個(gè)性化需求剛好不在框架能力范圍內(nèi)，二次開發(fā)實(shí)現(xiàn)成本、時(shí)間都不容小覷。若企業(yè)所選的低代碼平臺(tái)剛好又不夠開放，對平臺(tái)支持和升級(jí)的強(qiáng)依賴性會(huì)讓企業(yè)有苦難言，這便是所謂“鎖定”。

但同時(shí)靈活性高，又可能造成易用性下降，靈活性與易用性的平衡對低代碼平臺(tái)來說是個(gè)挑戰(zhàn)。

3、開發(fā)者不友好

很多低代碼平臺(tái)框架對開發(fā)者是黑盒，這給開發(fā)者帶來兩大問題，一是活難干，二是沒前途。

1）活難干是在開發(fā)時(shí)一旦遇到Bug、性能等問題，由于不清楚內(nèi)部實(shí)現(xiàn)邏輯，問題排查無從下手，代碼調(diào)試要反復(fù)切換界面，只能浪費(fèi)時(shí)間干瞪眼等平臺(tái)支持時(shí)。

2）沒前途是專業(yè)程序員高度依賴低代碼平臺(tái)，而疏于Coding會(huì)造成能力蛻化，這長期來看意味著失業(yè)和放棄未來。

專業(yè)開發(fā)者是低代碼生態(tài)中極重要的參與者，如何讓專業(yè)開發(fā)者自愿入局對低代碼平臺(tái)來說也是個(gè)挑戰(zhàn)。

4、業(yè)務(wù)方觀念扭轉(zhuǎn)難

普通業(yè)務(wù)人員是低代碼平臺(tái)關(guān)鍵用戶，但讓業(yè)務(wù)部門把低代碼平臺(tái)用起來，至少要跨過3個(gè)門檻：技術(shù)門檻、心理門檻、動(dòng)機(jī)門檻。

1）技術(shù)門檻，稍有技術(shù)含量、需要一定學(xué)習(xí)成本，就可以攔下很多人；

2）心理門檻，很多人會(huì)出于畏懼新事物和學(xué)習(xí)而拒絕接受；

3）動(dòng)機(jī)門檻，以往業(yè)務(wù)方動(dòng)下嘴就能拿到軟件，現(xiàn)在讓他動(dòng)手自己干？很多人的懶惰是赤裸裸的現(xiàn)實(shí)。

這3個(gè)門檻并非不可跨越，但卻需要耗費(fèi)心思。

1）跨越技術(shù)門檻，可以采用無代碼，但需要平衡靈活性的妥協(xié)；

2）跨越心理門檻，需要產(chǎn)品講好故事、做好交互設(shè)計(jì)，調(diào)整如“BPMN圖、ER圖、外鍵、函數(shù)、腳本”等專業(yè)詞匯，盡量避免觸發(fā)用戶畏懼心態(tài)；

3）跨越動(dòng)機(jī)門檻，需要找到足夠痛的場景，通過行業(yè)模板、業(yè)務(wù)模板、交互設(shè)計(jì)等打造足夠簡單的操作方式。

5、應(yīng)用治理、平臺(tái)性能等

低代碼平臺(tái)降低了應(yīng)用開發(fā)成本，如果應(yīng)用爆發(fā)式增長，出現(xiàn)大量無人或較少人使用的應(yīng)用，則對業(yè)務(wù)價(jià)值不大，卻會(huì)帶來額外的認(rèn)知、管理成本。同時(shí)，應(yīng)用數(shù)和使用人數(shù)的增長，也會(huì)給平臺(tái)性能帶來挑戰(zhàn)。另外，用戶追求個(gè)性化前端呈現(xiàn)與平臺(tái)固化的前端呈現(xiàn)也是一種需要應(yīng)對的矛盾。

總之，低代碼是個(gè)好東西，框架本身可以大大提升效率，但同時(shí)，它也存在著一些問題。莫要“成也框架，敗也框架”。

四、低代碼的優(yōu)勢

看了很多低代碼平臺(tái)的劣勢，也莫要灰心，先讓克里斯坦森為我們打打氣。他在《創(chuàng)新者的窘境》中定義了“顛覆式創(chuàng)新”，即比市場上現(xiàn)有產(chǎn)品更為便宜、更為方便的替代品，它服務(wù)于低端消費(fèi)者或新消費(fèi)群體，步步蠶食傳統(tǒng)產(chǎn)品的市場份額，最終取代傳統(tǒng)產(chǎn)品的統(tǒng)治地位。低代碼平臺(tái)是否是顛覆式創(chuàng)新，我們拭目以待。

1、降本

主要包括3方面，學(xué)習(xí)成本、開發(fā)成本和其他成本。

1）學(xué)習(xí)成本降低是普通業(yè)務(wù)人員即可操作，為IT研發(fā)資源不足的企業(yè)降低人力成本。

2）開發(fā)成本降低是對于開發(fā)者而言，可以復(fù)用既有能力，減少低價(jià)值代碼耗費(fèi)時(shí)間，同時(shí)，很多需求變更可通過配置方式實(shí)現(xiàn)，縮短了開發(fā)、運(yùn)維等時(shí)間。

3）其他成本如溝通成本、測試成本，甚至云架構(gòu)方式降低硬件成本等。

2、增效

主要包括2方面，交付效率和協(xié)作效率。

1）交付效率

• 通過配置即可滿足一批新增或變更需求，直接避免了低價(jià)值代碼開發(fā)時(shí)間，開發(fā)效率提升10倍并不夸張，同時(shí)，也意味著客戶響應(yīng)效率的極大改善，這是比開發(fā)效率更重要的事！

• 通過配置無法完全滿足的需求，雖然仍有開發(fā)工作量，但由于可以復(fù)用平臺(tái)能力，也節(jié)省了相當(dāng)一部分開發(fā)工作量，提效數(shù)據(jù)要看具體場景，但總體而言，復(fù)用帶來的效率提升不容置疑！

• 由于平臺(tái)能力復(fù)用，會(huì)大大縮短端到端交付時(shí)長，如測試時(shí)長、集成發(fā)布時(shí)長等都被大大縮短，工程效率的提升，讓低代碼有超越DevOps進(jìn)化至NoOps的可能性。

2）協(xié)作效率

• 溝通效率。一個(gè)需求交付要涉及到很多人，如業(yè)務(wù)人員、產(chǎn)品經(jīng)理、開發(fā)人員、測試人員等。而借助低代碼，很多需求可能在業(yè)務(wù)部門內(nèi)容就能實(shí)現(xiàn)了。需要溝通的人數(shù)少了，溝通效率自然就提高了。

• 天生敏捷精益。敏捷追求的核心關(guān)鍵字，如“盡早交付”、“快速反饋”、“響應(yīng)變化”等低代碼平臺(tái)生而有之，通過配置快速交付，讓程序盡早接受業(yè)務(wù)校驗(yàn)，迅速得到反饋，并及時(shí)調(diào)整。精益追求的核心關(guān)鍵字，如“價(jià)值”、“消除浪費(fèi)”、“內(nèi)建質(zhì)量”等低代碼平臺(tái)同樣生而有之，低成本快速驗(yàn)證，聚焦業(yè)務(wù)設(shè)計(jì)而非程序設(shè)計(jì)，通過業(yè)務(wù)聚焦、標(biāo)準(zhǔn)化、復(fù)用、少人化等消除不產(chǎn)生價(jià)值增值的活動(dòng)，通過平臺(tái)本身內(nèi)建質(zhì)量保障所有應(yīng)用質(zhì)量等。

3、提質(zhì)

Bug界有個(gè)絕對真理，“代碼越少，Bug越少”，低代碼平臺(tái)開發(fā)應(yīng)用所需的代碼量決定了其Bug量極少，甚至，“No Code，No Bug”。

低代碼平臺(tái)與“中臺(tái)”也有類似之處，由專家級(jí)開發(fā)團(tuán)隊(duì)打造便于進(jìn)化的高質(zhì)量代碼。采用“復(fù)用”、“統(tǒng)一”的理念，降本增效、打破孤島。同樣，低代碼平臺(tái)也需要警惕“中臺(tái)陷阱”，本欲“賦能”業(yè)務(wù)，不料變成瓶頸，以至業(yè)務(wù)“無能”。

4、價(jià)值

主要包括3方面，高度貼合業(yè)務(wù)、緩解低價(jià)值需求資源困境、提升程序員價(jià)值。

1）高度貼合業(yè)務(wù)。一個(gè)好的B端產(chǎn)品不是功能牛X，而是恰好能解決客戶當(dāng)下的問題。這就需要產(chǎn)品可以適應(yīng)不同成熟度的客戶，而不是一個(gè)標(biāo)準(zhǔn)方案走天下。筆者曾持此理念幫多省、多家運(yùn)營商落地研發(fā)協(xié)同平臺(tái)，針對不同客戶成熟度給不同解決方案。傳統(tǒng)的標(biāo)準(zhǔn)化產(chǎn)品無法支持此理念，但低代碼平臺(tái)卻具備這個(gè)能力，筆者對低代碼平臺(tái)的信念之一也源于這種經(jīng)歷。

2）緩解低價(jià)值需求資源困境。IT團(tuán)隊(duì)總會(huì)面對做不完的需求，縱有人把控ROI，也難免頻繁出現(xiàn)一種怪相“業(yè)務(wù)方叫的急，上線后卻不用”，這種低價(jià)值需求對開發(fā)資源的占用是極大浪費(fèi)。對于低價(jià)值需求，先用低代碼平臺(tái)滿足基礎(chǔ)需求可以改善這種困境。另外，也需要思考一個(gè)問題，“低價(jià)值需求真的價(jià)值低嗎”，這些被判定低價(jià)值的需求很難拿到開發(fā)資源，只能永遠(yuǎn)在等排期，而低代碼平臺(tái)卻能給這些“死刑需求”生存空間，這些低價(jià)值需求有可能會(huì)是組織創(chuàng)新的一個(gè)源泉。

3）提升程序員價(jià)值。低代碼可以幫程序員減少在低級(jí)重復(fù)性工作上浪費(fèi)時(shí)間，從而可以有更多時(shí)間專注于高價(jià)值的代碼，可以更深入業(yè)務(wù)，以更匹配的方式滿足業(yè)務(wù)需求。

5、互聯(lián)網(wǎng)效應(yīng)

“低代碼平臺(tái) 云”的生態(tài)，讓程序開發(fā)這門生意，上升到了互聯(lián)網(wǎng)的層面，兼具了互聯(lián)網(wǎng)四大效應(yīng)，梅特卡夫效應(yīng)、雙邊市場效應(yīng)、規(guī)模經(jīng)濟(jì)效應(yīng)、協(xié)同效應(yīng)。這才是低代碼2.0的想象力真正所在！打破信息孤島，讓應(yīng)用與應(yīng)用、企業(yè)與企業(yè)，開發(fā)者與開發(fā)者互聯(lián)共通，給“復(fù)用率”一次質(zhì)變！

五、目標(biāo)用戶分析

低代碼的終端用戶可以分為3類，完全不懂編程的業(yè)務(wù)人員、專業(yè)編程的開發(fā)人員、拉通業(yè)務(wù)與技術(shù)的運(yùn)管人員。不同的終端用戶定位，決定了低代碼平臺(tái)不同的演進(jìn)方向，其重要性不言而喻。

1、業(yè)務(wù)人員

業(yè)務(wù)人員的常見痛點(diǎn)之一是“做不對”，開發(fā)交付的軟件跟預(yù)期有偏差，低代碼平臺(tái)給了他們親手打造高度匹配業(yè)務(wù)需求應(yīng)用的機(jī)會(huì)，無需再罵IT能力弱了。此處祭出一個(gè)比喻，“低代碼將像PPT一樣普及”。PPT給了很多人表達(dá)自我的機(jī)會(huì)，然而，卻沒多少人能用好PPT，這是PPT這個(gè)工具的問題嗎？

我們（低代碼平臺(tái)）如何幫業(yè)務(wù)人員寫好PPT（用好低代碼）？提供以下4種策略。

1）培訓(xùn)。通過培訓(xùn)讓業(yè)務(wù)人員理解工具的邏輯，能解決的問題，常用的方法等。讓業(yè)務(wù)人員在遇到問題時(shí)有意愿嘗試用工具解決，培訓(xùn)方法如幫助中心、視頻教程等。

2）模板。懶得想、懶得動(dòng)、想不清這些現(xiàn)象司空見慣，教一個(gè)人快速提升PPT水平的最佳方式就是直接給他一個(gè)寫好的模板，讓他簡單改改就成。所以，很多低代碼平臺(tái)走的也是這條路線，把行業(yè)內(nèi)的最佳實(shí)踐編輯成模板，最大限度為用戶提供便利。

3）教育。這是培訓(xùn)的進(jìn)階狀態(tài)，不只是教人用PPT了，也教人寫PPT的思路。低代碼平臺(tái)深耕細(xì)分行業(yè)、細(xì)分業(yè)務(wù)領(lǐng)域，結(jié)合工具輸出專家在該領(lǐng)域的最佳成功實(shí)踐，讓用戶在使用工具時(shí)也能有業(yè)務(wù)認(rèn)知成長。另外，培訓(xùn)業(yè)務(wù)也是一項(xiàng)收入，一個(gè)護(hù)城河。

4）外包。有些人不愿意浪費(fèi)寶貴的時(shí)間自己寫PPT，此時(shí)，花點(diǎn)錢讓別人代寫也是種方法。低代碼平臺(tái)提供或與此類代搭應(yīng)用的人合作，也可以為用戶提供價(jià)值，此類人與后面要聊的“運(yùn)管人員”多有重合。

2、開發(fā)人員

開發(fā)人員的常見痛點(diǎn)是“干不完，沒前途”，時(shí)間總能被無盡的需求、Bug、變更、重構(gòu)等塞滿。然后，辛苦數(shù)年，35歲被掃地出門。純靠低代碼平臺(tái)難以滿足用戶的全部需求，而且在滿足用戶的基本需求后，個(gè)性化是必然的趨勢，“福特T型車的興衰”是歷史之鏡。想服務(wù)好客戶，必然要與專業(yè)開發(fā)人員共生。

如何打造開發(fā)人員愿意參與的低代碼共生生態(tài)？提供以下3種策略。

1）插件市場。低代碼平臺(tái)專注最通用、簡單的業(yè)務(wù)，保障平臺(tái)基礎(chǔ)的易用性。一部分具有通用性的復(fù)雜業(yè)務(wù)，通過插件的方式由用戶自主選擇，以提供一定的靈活性。采用類似AppStore的思路，引入獨(dú)立開發(fā)者開發(fā)插件，這樣既能滿足用戶的個(gè)性化需求，又能為獨(dú)立開發(fā)者提供賺錢門路。

2）開放對接。改善低代碼平臺(tái)“黑盒”屬性對開發(fā)者的不友好，為開發(fā)者做故障排查定位提供幫助。另外，平臺(tái)通過API等方式支持與第三方服務(wù)之間靈活對接，為開發(fā)者提供自由選擇的空間。

3）產(chǎn)品層次。通過產(chǎn)品架構(gòu)設(shè)計(jì)讓產(chǎn)品具備層次性，即給一線業(yè)務(wù)人員、二線運(yùn)管人員、三線開發(fā)人員提供不一樣的產(chǎn)品能力。對于業(yè)務(wù)人員，采用“無代碼”，以絕對的易用性解決最急迫的業(yè)務(wù)需求；對于運(yùn)管人員，采用“無代碼 插件”，解決一部分個(gè)性化需求；對于開發(fā)人員，采用“純代碼 API”，迎合開發(fā)人員使用體驗(yàn)，明明可以幾行代碼搞定的事，就不要讓開發(fā)者蹩腳的在界面里“拖拉拽”了。

3、運(yùn)管人員

運(yùn)管人員的常見痛點(diǎn)是“等不及”，面對客戶、領(lǐng)導(dǎo)的直接壓力，恨不得擼起袖子下手干。只恨接不下開發(fā)兄弟的絕招，“You can you up,no can no BB”。此處，運(yùn)管人員泛指那些介于業(yè)務(wù)和開發(fā)之間的角色，如產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、運(yùn)營人員、咨詢師、售前等。這些中間角色既能站在業(yè)務(wù)角度思考問題，又具備一定的軟件思維和技術(shù)功底，是低代碼平臺(tái)的理想用戶。他們可能是最有意愿花時(shí)間研究產(chǎn)品使用方法的群體了，滿足他們的需求需要低代碼平臺(tái)的UI設(shè)計(jì)、產(chǎn)品交互和配置能力強(qiáng)大，以迎合不愿將就、略有挑剔的他們。

六、目標(biāo)客戶分析

低代碼的消費(fèi)客戶可以分為2類，企業(yè)和軟件廠商?？蛻羰鞘杖氲闹苯觼碓?，關(guān)乎低代碼平臺(tái)的生存。但客戶畫像這個(gè)話題很難聊，一方面它需要細(xì)化，泛泛而談沒有意義；另一方面，平臺(tái)在生存探索中，可能會(huì)不斷調(diào)整。

1、企業(yè)

企業(yè)又可按行業(yè)、規(guī)模等細(xì)分，不同類型企業(yè)需求不同，甚至審美風(fēng)格也有獨(dú)特偏好。如中小企業(yè)相對價(jià)格敏感，IT人員匱乏，能滿足需求即可，追求簡單、易用、速度，偏好整套打包方案；大中型企業(yè)通常已建成部分系統(tǒng)，可能涉及系統(tǒng)對接、二次開發(fā)等，注重安全，相對強(qiáng)勢，個(gè)性化要求多，講究產(chǎn)品專業(yè)性、先進(jìn)性等。不同類型企業(yè)，需要的方案不盡相同，有些僅需要低代碼平臺(tái)的自由流程定制能力，作為信息化能力補(bǔ)充滿足邊緣需求；有些需要在特定業(yè)務(wù)領(lǐng)域先進(jìn)價(jià)值主張，解決企業(yè)特定的問題；而有些則需要完整解決方案，并通過簡單配置作為主要協(xié)同工具。

2、軟件廠商

包括傳統(tǒng)軟件廠商和ISV，很多傳統(tǒng)軟件廠商仍在基于流程引擎幫客戶做定制開發(fā)，低代碼工具可以作為攪局者殺入這一領(lǐng)域，幫軟件廠商壓縮團(tuán)隊(duì)規(guī)模，以更低成本、更快速度完成項(xiàng)目交付。而定位ISV則需要平臺(tái)本身具有巨大的客戶量，這是巨頭們廝殺的領(lǐng)域。

七、企業(yè)如何選低代碼平臺(tái)

企業(yè)面對這個(gè)問題通常有2個(gè)選擇，選擇自建低代碼平臺(tái)，或選擇購買第三方低代碼平臺(tái)。

1、自建低代碼平臺(tái)

在決策是否自建之前至少要考慮清楚3個(gè)問題，引入低代碼的目的是什么？比購買第三方軟件ROI更高嗎？公司是否有足夠的實(shí)力折騰？有些中型企業(yè)可能會(huì)認(rèn)為低代碼技術(shù)門檻并不高，拼裝流程引擎、表單設(shè)計(jì)器、報(bào)表設(shè)計(jì)器等即可，但事實(shí)并非如此簡單。低代碼平臺(tái)看似簡單，但建設(shè)成功率并不高。除了要面對本文所講的低代碼的劣勢，還至少會(huì)面對3個(gè)問題：

1）成本高，低代碼平臺(tái)是個(gè)持續(xù)建設(shè)的過程，對架構(gòu)師能力要求極強(qiáng)，還需要解決可能的性能瓶頸問題，而性能問題解決不易。

2）缺人才，作為一個(gè)不通用的內(nèi)部開發(fā)框架，幾乎沒有開發(fā)人員會(huì)傻到為此葬送前程，公司會(huì)因此面臨極高的開發(fā)人員離職率，頻繁的人力更換不僅成本高，而且會(huì)影響業(yè)務(wù)發(fā)展。

3）速度慢，一旦有個(gè)性化或超出平臺(tái)能力之外的需求產(chǎn)生，就需要對平臺(tái)框架進(jìn)行升級(jí)，而框架升級(jí)通常速度緩慢，此時(shí)，業(yè)務(wù)只能等待；同時(shí)，如果沒有平滑的升級(jí)策略，整個(gè)開發(fā)團(tuán)隊(duì)會(huì)反復(fù)深陷在應(yīng)用重構(gòu)之中。

2、選購低代碼平臺(tái)

選購低代碼平臺(tái)也需要謹(jǐn)慎，選平臺(tái)容易，換平臺(tái)難。不同的企業(yè)場景不同，無法推薦某家平臺(tái)絕對適合所有企業(yè)，本文僅提供5個(gè)通用因素以供參考。

1）自身需求。這是最核心的考量因素，不應(yīng)該對比產(chǎn)品的功能數(shù)量、技術(shù)亮點(diǎn)等，而應(yīng)該先明確自身的需求，尋找一個(gè)與自身需求相匹配的平臺(tái)，是需要一個(gè)全套平臺(tái)？還是需要靈活的流程自定義功能？

2）公司實(shí)力。如果低代碼平臺(tái)公司抗風(fēng)險(xiǎn)能力弱，一旦倒閉，數(shù)據(jù)、時(shí)間損失極大。

3）產(chǎn)品開放性。選擇低代碼平臺(tái)是一個(gè)長期的事，勢必會(huì)有個(gè)性化需求，若平臺(tái)對二次開發(fā)不友好，API不夠開放，自家程序員無能為力，企業(yè)會(huì)面臨尷尬的處境。

4）產(chǎn)品生態(tài)。如果低代碼平臺(tái)生態(tài)能力強(qiáng)，可以吸引到ISV，甚至獨(dú)立開發(fā)者，意味著企業(yè)未來的個(gè)性化需求不僅可實(shí)現(xiàn)，而且成本較低。

5）產(chǎn)品性價(jià)比。低代碼平臺(tái)本身功能多樣性、價(jià)格等可能是最后考量的因素，對企業(yè)來說，選擇、使用所花費(fèi)的時(shí)間成本可能比花的錢更重要。對大企業(yè)來說，需要考慮的因素更多，如多端適配、多租戶權(quán)限體系、運(yùn)維可擴(kuò)展性等。

八、低代碼平臺(tái)競爭策略

筆者對低代碼的未來樂觀，但對很多做低代碼的公司持悲觀態(tài)度，尤其資本力量不足的小公司。小公司缺資源、缺技術(shù)，不敢犯錯(cuò)，產(chǎn)品規(guī)劃又容易屈服于客戶，生存和成長都不容易。阿里有釘釘?shù)目蛻羧后w，騰訊有企業(yè)微信的殺器，其他互聯(lián)網(wǎng)巨頭背后也都有足夠的人力、財(cái)力支撐，小平臺(tái)該如何競爭？筆者姑且臆測3種競爭策略。

1、搶灘登陸打細(xì)分市場

杰弗里·摩爾在《跨越鴻溝》中提到產(chǎn)品諾曼底登陸策略，既先牢牢占據(jù)一小塊市場和用戶，然后逐步積累優(yōu)勢。做通用平臺(tái)無法跟巨頭競爭，應(yīng)該規(guī)避劣勢積累優(yōu)勢，在起步階段，先垂直深耕一個(gè)領(lǐng)域，逐步完善產(chǎn)品，讓產(chǎn)品更匹配客戶的業(yè)務(wù)、審美、交互等，對比巨頭形成差異化優(yōu)勢，待成熟之后開始拓展服務(wù)領(lǐng)域。

2、開源免費(fèi)打開發(fā)者生態(tài)

雖說把低代碼僅當(dāng)工具略顯低端，但如果能借開源聚集足夠多的開發(fā)者人氣也能形成一定的競爭力。借助開源促成活躍的開發(fā)者社區(qū)，形成類似Python的強(qiáng)大類庫或AppStore的市場。簡單需求讓客戶通過工具本身設(shè)置快速實(shí)現(xiàn)，中復(fù)雜需求讓客戶通過插件配置化實(shí)現(xiàn)，高復(fù)雜需求讓客戶可以快速找到開發(fā)者定制實(shí)現(xiàn)。平臺(tái)提供插件市場和開發(fā)者定制市場，讓客戶、開發(fā)者和自身三方得利。以此，低端打高端，農(nóng)村包圍城市。

而當(dāng)下很多低代碼平臺(tái)對小微企業(yè)云資源免費(fèi)的策略，筆者并不看好。這并不是好的雙贏策略，一方面增加了平臺(tái)本身的成本；另一方面，在乎這點(diǎn)錢的客戶本身付費(fèi)能力、存活率都不高，陪他們玩吃力不討好。況且，客戶的選擇成本遠(yuǎn)遠(yuǎn)大于金錢成本。不如，直接開源，客戶想在自己服務(wù)器上玩就讓他玩好了，但平臺(tái)本身也提供優(yōu)惠的甚至限期免費(fèi)的云資源，以此吸引客戶。

最后，關(guān)于架構(gòu)，盡量解耦，低代碼不只是適用于流程類場景，如表單自主設(shè)計(jì)、列表頁自主設(shè)計(jì)、工作臺(tái)、數(shù)據(jù)可視化等均可以成為獨(dú)立的服務(wù)，以此為開發(fā)者提供足夠的選擇空間。

3、深入項(xiàng)目打行業(yè)生態(tài)

小公司的低代碼平臺(tái)談產(chǎn)品規(guī)劃有些奢侈，先拿下客戶項(xiàng)目，一方面可以活下來，另外能跟隨客戶一同進(jìn)化。尤其是行業(yè)大客戶，雖然有時(shí)候他們的需求有些個(gè)性化，但這些個(gè)性化需求背后可能隱藏著行業(yè)痛點(diǎn)。通過行業(yè)深耕，打造“行業(yè)基礎(chǔ)應(yīng)用 低代碼能力”以形成行業(yè)競爭力，而后逐步向企業(yè)上下游探索。

【鈦媒體作者介紹：李曉杰；微信ID：ecdoer；微信公眾號(hào)：產(chǎn)品曉說（ID：pmxiaosi）。10年以上產(chǎn)品、項(xiàng)目管理實(shí)戰(zhàn)經(jīng)驗(yàn)，近7年服務(wù)大B端客戶運(yùn)營商（移動(dòng)、聯(lián)通），核心產(chǎn)品為企業(yè)信息化與協(xié)同，包括低代碼平臺(tái)、DevOps研發(fā)協(xié)同、項(xiàng)目及財(cái)務(wù)管理、OA協(xié)同、企業(yè)門戶、數(shù)據(jù)可視化等，希望與同路人共同探索產(chǎn)品經(jīng)理成長之路?！?/p>