作者 | 云昭

審校 | 千山

現(xiàn)代管理學(xué)之父德魯克，提及創(chuàng)新本質(zhì)時(shí)，說了兩點(diǎn)：一是讓昂貴的東西變得便宜，老百姓能用；二是讓高門檻東西變得低門檻，普通人可用。乍一看，低代碼挺符合這兩條的。

試想一下，如果有這樣一個(gè)神奇的工具，能讓產(chǎn)品經(jīng)理根據(jù)需求在4小時(shí)內(nèi)就“拖拽”出了一個(gè)產(chǎn)品給到客戶，那將會(huì)是怎樣一個(gè)場景。

一、低代碼：讓人找不到工作？

可如果放到一年前，低代碼這個(gè)“用戶故事”的畫風(fēng)是這樣的：

一個(gè)傳統(tǒng)行業(yè)老板整來一套低代碼開發(fā)平臺(tái)，讓某位產(chǎn)品經(jīng)理在上面填上數(shù)據(jù)庫字段。接著畫bpmn（業(yè)務(wù)流程管理）流程圖，拖拽前端組件，一個(gè)系統(tǒng)就成了，全程不用寫代碼。最后一周擼出一個(gè)項(xiàng)目來，能賺一百萬左右。

工程師們見狀紛紛準(zhǔn)備跑路了，看樣子只招實(shí)施就行。走之前還不忘來一句：低代碼，yyds！

低代碼當(dāng)時(shí)被吹噓得很膨脹：解放開發(fā)者的生產(chǎn)力，就靠它了！

然而，經(jīng)歷一年多的發(fā)展期，低代碼給許多人帶來的卻是無數(shù)個(gè)打臉?biāo)查g!從基層的“低代碼”開發(fā)工程師，到系統(tǒng)設(shè)計(jì)的架構(gòu)師，徹底淪為了一場“吐槽大會(huì)”。

• 產(chǎn)品經(jīng)理：我到底在做產(chǎn)品，還是做工具？
• 架構(gòu)師：本質(zhì)這玩意是一錘子買賣，本身無法應(yīng)對(duì)需求變化！這系統(tǒng)根本沒法擴(kuò)展！
• 開發(fā)工程師：簡單的工具還行，遇到復(fù)雜的，需要擴(kuò)展的就傻眼了。
• 低代碼工程師：天天用些低代碼封裝的東西，更像混吃等死，沒提升！

是大家對(duì)低代碼期待過高了嗎，還是低代碼本身就是個(gè)“偽需求”？

二、偽需求還是真需求？

真正的需求才是產(chǎn)品持續(xù)發(fā)展的動(dòng)力，那么低代碼的“真需求”在哪里呢，去年Gartner公布了一項(xiàng)低代碼的用例調(diào)查，排名靠前的是：表單和數(shù)據(jù)收集應(yīng)用程序，在應(yīng)用程序中協(xié)調(diào)業(yè)務(wù)流程和工作流的應(yīng)用程序，取代紙張、電子郵件或電子表格的應(yīng)用程序，為當(dāng)前本地應(yīng)用程序定制新的應(yīng)用程序UI。

視線拉回國內(nèi)，不難發(fā)現(xiàn)，低代碼現(xiàn)如今的應(yīng)用場景不外乎幾個(gè)方面：

首先，在數(shù)字化轉(zhuǎn)型場景中，低代碼在B端用戶中的聲量較高。這個(gè)工具似乎成為解決他們“最后一公里”問題必不可少的一個(gè)選項(xiàng)。傳統(tǒng)行業(yè)進(jìn)行數(shù)字化，往往缺乏技術(shù)人員的儲(chǔ)備，同時(shí)系統(tǒng)和設(shè)備也封閉陳舊，比如奶茶店、服裝店，讓他們專門招研發(fā)團(tuán)隊(duì)來搞數(shù)字化，一則招不到人，二則即便招來了也大材小用。低代碼就不一樣了，拖拖拽拽，就能快速搞定一個(gè)case，老板們當(dāng)然會(huì)點(diǎn)贊了。

其次，對(duì)于初創(chuàng)企業(yè)，人員和規(guī)模并不大，想要快速使公司運(yùn)轉(zhuǎn)，就必須快速搭建出CRM、OA、項(xiàng)目管理、進(jìn)銷存等系統(tǒng)，而這些系統(tǒng)看起來已經(jīng)很成熟，但要找到足夠的技術(shù)人員來快速交付，難度很大。這時(shí)候低代碼的用武之地就來了，只需要找到熟悉業(yè)務(wù)的非技術(shù)人員，經(jīng)過培訓(xùn)就能快速搭建出企業(yè)所需要定制的應(yīng)用。

最后，對(duì)于大中型互聯(lián)網(wǎng)企業(yè)而言，同樣也有低代碼發(fā)揮的地方。這也是部分開發(fā)者最為擔(dān)心的地方：低代碼搶走了原本屬于自己的需求。其實(shí)，就現(xiàn)狀來看，真大可不必。

眾所周知，需求在產(chǎn)品經(jīng)理有重要和緊急之分，現(xiàn)在來看交給低代碼來實(shí)現(xiàn)的，往往是那些“緊急且不重要”、甚至“不重要不緊急”的需求，為什么還需要交給研發(fā)來排期呢？交給低代碼工具不就好了么？

再者，低代碼對(duì)于開發(fā)復(fù)雜系統(tǒng)而言，難登大雅之堂。一來內(nèi)部是個(gè)黑盒子，僅擴(kuò)展就成問題，二來低代碼的顆粒度遠(yuǎn)沒有高到可以讓CTO們大筆一揮，架構(gòu)圖里哪個(gè)系統(tǒng)要用低代碼來實(shí)現(xiàn)，因?yàn)榉€(wěn)定性不能保證。

因此，專業(yè)的事情交給專業(yè)的工具辦，低代碼不是來搶活的，而是給技術(shù)人騰出時(shí)間和精力對(duì)付更具創(chuàng)新力的事情。

三、低代碼只是開發(fā)者的可選項(xiàng)

在軟工圣經(jīng)《人月神話》一書中，作者Brooks指出了軟件發(fā)展的一個(gè)僵局：在落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后。

為了更快完成項(xiàng)目，開發(fā)團(tuán)隊(duì)會(huì)發(fā)展的極其龐大，以致于所有的時(shí)間都花費(fèi)在溝通和變更決策上，反而讓項(xiàng)目結(jié)束變得遙遙無期。

那么低代碼會(huì)不會(huì)成為打破這一僵局的工具呢？當(dāng)然是。

如果說在業(yè)務(wù)需求層面上溝通難以達(dá)成一致，那就交給甲方爸爸來自己搭建吧。

把相關(guān)的代碼模塊化封裝之后，甩給真實(shí)業(yè)務(wù)場景中人員自己來拼裝應(yīng)用，既達(dá)到了快速響應(yīng)業(yè)務(wù)需求、適應(yīng)變化的目的，同時(shí)給業(yè)務(wù)人員更大的自由度，省去與開發(fā)人員的溝通時(shí)間，同時(shí)讓應(yīng)用更貼近場景。

所以，同樣一個(gè)“人月”，專業(yè)的開發(fā)工程師和低代碼搭建工程師所發(fā)揮的作用是大有不同的。

其次，開發(fā)人員也需要低代碼工具來持續(xù)創(chuàng)新。

的確，專業(yè)的開發(fā)人員，技能非常強(qiáng)大。但它們也很稀少。如果公司想繼續(xù)提高效率，低代碼工具是必須的。

專業(yè)開發(fā)人員面臨的環(huán)境往往是這樣的：碎片化的數(shù)據(jù)和流程，積壓許久的遺留系統(tǒng)，臃腫的工作環(huán)境，他們無法利用新興技術(shù)去保持敏捷，同時(shí)還能保證無風(fēng)險(xiǎn)。

利用單一云基礎(chǔ)的低代碼工具可以使開發(fā)人員能夠加快他們交付的創(chuàng)新步伐。

此外，低代碼使開發(fā)者甚至沒有技術(shù)技能的人更容易進(jìn)行軟件開發(fā)。而且由于低代碼開發(fā)平臺(tái)的存在，會(huì)使專業(yè)開發(fā)人員和非開發(fā)人員之間的協(xié)作成為“融合團(tuán)隊(duì)”。

目前這方面做的不錯(cuò)的是國外的低代碼獨(dú)角獸Mendix，專門面向?qū)I(yè)的開發(fā)者做低代碼工具。

四、低代碼：帶有欺騙性的神話？

Brooks曾用很戲謔的筆觸描述道：用“人月”來衡量一項(xiàng)工作的規(guī)模，是一個(gè)危險(xiǎn)和帶有欺騙性的神話。

同樣地，用“代碼多少”來衡量一項(xiàng)工具的作用，也是一個(gè)帶有欺騙性的神話。

匠人都是以工具出名的。低代碼的火熱，勢必也會(huì)造就一批低代碼大牛。但這并不代表低代碼的價(jià)值亞于專業(yè)開發(fā)。

低代碼能否受歡迎取決于市場上各位干系者的接受度。

目前市場的反饋就是：老板們看了必須上，使用者試了試不想用。

就以國內(nèi)為例，11月份，不少巨頭紛紛秀起了低代碼的肌肉：

11月3日，阿里云云棲大會(huì)上，阿里巴巴集團(tuán)副總裁、釘釘總裁葉軍宣布：釘釘上的低代碼應(yīng)用數(shù)已經(jīng)突破500萬，低代碼開發(fā)者數(shù)量超過380萬。

11月13日，騰訊升級(jí)了“微搭”，目前已服務(wù)開發(fā)者數(shù)300萬，新增小程序使用率70%；

11月18日，華為AppCube全線產(chǎn)品全面升級(jí)，側(cè)重在低代碼、零代碼、數(shù)據(jù)看板三個(gè)方面進(jìn)行了升級(jí)優(yōu)化。

數(shù)字背后可以看到，雖然飽受爭議，但低代碼的使用者的確在猛漲。

五、低代碼怎樣干有前途

低代碼平臺(tái)的用戶反饋并不那么樂觀，正如文章開頭所描述的不同崗位的使用感受那樣：意見很大。低代碼這個(gè)“盲盒”拆的好，是高效，拆的不好那就是不能用。

根據(jù)TechRepublic的一項(xiàng)調(diào)查，受訪者希望低代碼平臺(tái)能夠提高生產(chǎn)力（15%）、縮短應(yīng)用程序開發(fā)時(shí)間（14%）和自動(dòng)化手動(dòng)流程（12%）。技術(shù)和非技術(shù)團(tuán)隊(duì)可以通過實(shí)施以下一些建議，共同努力實(shí)現(xiàn)這些期望。這里給一些使用建議。

1.創(chuàng)建一組平民開發(fā)者

我們將平臺(tái)開發(fā)者視為不以coding為生的人：產(chǎn)品經(jīng)理、流程專家、商業(yè)分析師、設(shè)計(jì)師和MBA項(xiàng)目畢業(yè)生等等。這些都是來自不同背景的聰明人，他們有著不同的視角來解決問題并找到解決方案。此外，這些人也是熟悉業(yè)務(wù)的人，他們與解決方案有緊密的聯(lián)系。

因?yàn)榉羌夹g(shù)性的隊(duì)友可能是開發(fā)生態(tài)系統(tǒng)的新手，他們需要接受培訓(xùn)，以了解各種可能性以及如何最好地實(shí)施他們的最新想法。通過學(xué)習(xí)，沒有經(jīng)驗(yàn)的建設(shè)者可以獲得了進(jìn)入一個(gè)新領(lǐng)域的信心。

所以，公司需要為采用低代碼解決方案制定明確的激勵(lì)措施。這意味著要清楚低代碼的好處和結(jié)果。為什么要鼓勵(lì)平民開發(fā)者不斷學(xué)習(xí)和嘗試新工具？哪些潛在的結(jié)果會(huì)讓工作中的生活變得更好？

此外，還需要提高整個(gè)公司對(duì)低代碼所帶來的的潛在機(jī)會(huì)的認(rèn)識(shí)。老板必須確保向員工提供學(xué)習(xí)和開發(fā)資源，從而為進(jìn)一步提升解決問題的能力敞開大門。

2.關(guān)注具有戰(zhàn)略意義的關(guān)鍵低代碼項(xiàng)目

許多業(yè)務(wù)團(tuán)隊(duì)通常被激勵(lì)參加低代碼項(xiàng)目。他們希望提供新的產(chǎn)品和解決方案，并更快地將想法推向市場，又或者是需要為客戶創(chuàng)造更強(qiáng)大、更緊密、更定制化的體驗(yàn)。他們感到痛苦的是，在手動(dòng)重復(fù)輸入相同的信息和其他低效的模擬活動(dòng)上浪費(fèi)太多時(shí)間。

實(shí)際情況中，許多低代碼工程師都是業(yè)務(wù)方面的熟手，并且愿意學(xué)習(xí)可視化編程，可以為他們的日常工作創(chuàng)建簡單的用例。

在開始時(shí)，這些用戶還沒有考慮到自動(dòng)化或應(yīng)用程序開發(fā)的確切用例。為了找到想法，他們可以探索日常業(yè)務(wù)活動(dòng)中的已知痛點(diǎn)和特定行業(yè)的需求，也可以從預(yù)先構(gòu)建的內(nèi)容市場開始，看看一些常用的解決方案。一旦他們有了一個(gè)想法列表，就應(yīng)該有一個(gè)基于預(yù)測的業(yè)務(wù)影響的戰(zhàn)略優(yōu)先級(jí)排序過程。

業(yè)務(wù)用戶開始的另一種方式是參與概念驗(yàn)證（POC）原型開發(fā)項(xiàng)目，以轉(zhuǎn)換更復(fù)雜的流程或活動(dòng)，該流程或活動(dòng)已經(jīng)被IT部門分配了高度的戰(zhàn)略優(yōu)先級(jí)。POC原型是業(yè)務(wù)用戶（如設(shè)計(jì)師）與開發(fā)人員同事或項(xiàng)目團(tuán)隊(duì)分享其最終產(chǎn)品愿景以驗(yàn)證需求的絕佳方式。

日常問題和請(qǐng)求是低代碼解決方案的最佳選擇。業(yè)務(wù)人員應(yīng)該被授權(quán)構(gòu)建所需的擴(kuò)展和應(yīng)用程序。在IT資源和專業(yè)開發(fā)人員短缺的情況下，低代碼工具可以讓任何人改進(jìn)自己的工作流程和自動(dòng)化手動(dòng)工作，并在生產(chǎn)解決業(yè)務(wù)問題的工作原型時(shí)最大限度地提高速度、靈活性和創(chuàng)新性。

3.通過低代碼學(xué)習(xí)資源適應(yīng)新角色

雖然低代碼工具比編程語言更容易訪問，但在開始之前需要學(xué)習(xí)，特別是對(duì)于剛接觸軟件開發(fā)的業(yè)務(wù)用戶，否則構(gòu)建的第一個(gè)自動(dòng)化和應(yīng)用程序?qū)⑹遣萋实?、不可擴(kuò)展的，甚至?xí)a(chǎn)生IT風(fēng)險(xiǎn)。

低代碼課程為缺乏經(jīng)驗(yàn)的用戶打開了一扇大門，讓他們?cè)谶M(jìn)入之前獲得基本的理解。它們涵蓋了概念性的事情，如：識(shí)別用例以及如何確定從哪里開始的優(yōu)先級(jí)，包括對(duì)軟件結(jié)構(gòu)、設(shè)計(jì)和邏輯流程的深入了解，以及在構(gòu)建工作開始之前對(duì)用戶體驗(yàn)的規(guī)劃。當(dāng)然，在構(gòu)建簡單的培訓(xùn)案例時(shí)，對(duì)能力進(jìn)行全面的實(shí)際審查，確保通過實(shí)踐經(jīng)驗(yàn)獲得產(chǎn)品知識(shí)。

因此，對(duì)低代碼技術(shù)感興趣的個(gè)人越來越多地利用學(xué)習(xí)工具和課程。這些學(xué)習(xí)計(jì)劃也會(huì)擴(kuò)大低代碼工具的使用范圍。

六、寫在最后

大流行時(shí)代，經(jīng)濟(jì)可以放緩，但企業(yè)卻從不敢放慢前進(jìn)的腳步。只不過，以前更多的是靠擴(kuò)大規(guī)模來實(shí)現(xiàn)增長的，現(xiàn)在更靠譜的。則是提升人效，或者說提高創(chuàng)新力。從這個(gè)角度層面看低代碼，無他，就是一個(gè)提高效率的工具而已。

無論如何，于使用者而言，低代碼只是一個(gè)工具，而不是取代某一群人。

在低代碼的生態(tài)里，具有計(jì)算機(jī)科學(xué)和工程背景的開發(fā)人員將繼續(xù)以代碼優(yōu)先的方式推動(dòng)創(chuàng)新。

但同時(shí)，低代碼工具可以為他們帶來效率優(yōu)勢，同時(shí)也為更多非技術(shù)員工打開了參與開發(fā)過程的大門，從而增加了協(xié)作。

同時(shí)我們也應(yīng)該看到低代碼的發(fā)展所暴露出的問題：對(duì)于人才的可持續(xù)培養(yǎng)、培訓(xùn)和激勵(lì)機(jī)制的欠缺、平民開發(fā)的氛圍。

構(gòu)建正確的低代碼工作流首先要了解工具的功能，想要讓低代碼能夠擴(kuò)展、集成，并在安全性、法規(guī)遵從性和可靠性方面運(yùn)行良好，依舊需要多方合力去推動(dòng)。

所以，平常心對(duì)待即可。就好比駕駛，你可以選擇自動(dòng)擋，也可以選擇手動(dòng)擋。但自動(dòng)擋注定是個(gè)趨勢。

參考鏈接：https://stackoverflow.blog/2022/11/15/speeding-software-innovation-with-low-code-no-code-tools/

來源： 51CTO技術(shù)棧