現代管理學之父德魯克，提及創新本質時，說了兩點：一是讓昂貴的東西變得便宜，老百姓能用；二是讓高門檻東西變得低門檻，普通人可用。乍一看，低代碼挺符合這兩條的。

試想一下，如果有這樣一個神奇的工具，能讓產品經理根據需求在4小時內就“拖拽”出了一個產品給到客戶，那將會是怎樣一個場景。

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

可如果放到一年前，低代碼這個“用戶故事”的畫風是這樣的：

一個傳統行業老板整來一套低代碼開發平臺，讓某位產品經理在上面填上數據庫字段。接著畫bpmn（業務流程管理）流程圖，拖拽前端組件，一個系統就成了，全程不用寫代碼。最后一周擼出一個項目來，能賺一百萬左右。

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

低代碼當時被吹噓得很膨脹：解放開發者的生產力，就靠它了！

然而，經歷一年多的發展期，低代碼給許多人帶來的卻是無數個打臉瞬間!從基層的“低代碼”開發工程師，到系統設計的架構師，徹底淪為了一場“吐槽大會”。

產品經理：我到底在做產品，還是做工具？

架構師：本質這玩意是一錘子買賣，本身無法應對需求變化！這系統根本沒法擴展！

開發工程師：簡單的工具還行，遇到復雜的，需要擴展的就傻眼了。

低代碼工程師：天天用些低代碼封裝的東西，更像混吃等死，沒提升！

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

二、偽需求還是真需求？

真正的需求才是產品持續發展的動力，那么低代碼的“真需求”在哪里呢，去年Gartner公布了一項低代碼的用例調查，排名靠前的是：表單和數據收集應用程序，在應用程序中協調業務流程和工作流的應用程序，取代紙張、電子郵件或電子表格的應用程序，為當前本地應用程序定制新的應用程序UI。

視線拉回國內，不難發現，低代碼現如今的應用場景不外乎幾個方面：

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

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

最后，對于大中型互聯網企業而言，同樣也有低代碼發揮的地方。這也是部分開發者最為擔心的地方：低代碼搶走了原本屬于自己的需求。其實，就現狀來看，真大可不必。

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

再者，低代碼對于開發復雜系統而言，難登大雅之堂。一來內部是個黑盒子，僅擴展就成問題，二來低代碼的顆粒度遠沒有高到可以讓CTO們大筆一揮，架構圖里哪個系統要用低代碼來實現，因為穩定性不能保證。

因此，專業的事情交給專業的工具辦，低代碼不是來搶活的，而是給技術人騰出時間和精力對付更具創新力的事情。

三、低代碼只是開發者的可選項

在軟工圣經《人月神話》一書中，作者Brooks指出了軟件發展的一個僵局：在落后的項目中增加人手，只會使進度更加落后。

為了更快完成項目，開發團隊會發展的極其龐大，以致于所有的時間都花費在溝通和變更決策上，反而讓項目結束變得遙遙無期。

那么低代碼會不會成為打破這一僵局的工具呢？當然是。

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

把相關的代碼模塊化封裝之后，甩給真實業務場景中人員自己來拼裝應用，既達到了快速響應業務需求、適應變化的目的，同時給業務人員更大的自由度，省去與開發人員的溝通時間，同時讓應用更貼近場景。

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

其次，開發人員也需要低代碼工具來持續創新。

的確，專業的開發人員，技能非常強大。但它們也很稀少。如果公司想繼續提高效率，低代碼工具是必須的。

專業開發人員面臨的環境往往是這樣的：碎片化的數據和流程，積壓許久的遺留系統，臃腫的工作環境，他們無法利用新興技術去保持敏捷，同時還能保證無風險。

利用單一云基礎的低代碼工具可以使開發人員能夠加快他們交付的創新步伐。

此外，低代碼使開發者甚至沒有技術技能的人更容易進行軟件開發。而且由于低代碼開發平臺的存在，會使專業開發人員和非開發人員之間的協作成為“融合團隊”。

目前這方面做的不錯的是國外的低代碼獨角獸Mendix，專門面向專業的開發者做低代碼工具。

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

Brooks曾用很戲謔的筆觸描述道：用“人月”來衡量一項工作的規模，是一個危險和帶有欺騙性的神話。

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

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

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

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

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

11月3日，阿里云云棲大會上，阿里巴巴集團副總裁、釘釘總裁葉軍宣布：釘釘上的低代碼應用數已經突破500萬，低代碼開發者數量超過380萬。

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

11月18日，華為AppCube全線產品全面升級，側重在低代碼、零代碼、數據看板三個方面進行了升級優化。

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

五、低代碼怎樣干有前途

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

根據TechRepublic的一項調查，受訪者希望低代碼平臺能夠提高生產力（15%）、縮短應用程序開發時間（14%）和自動化手動流程（12%）。技術和非技術團隊可以通過實施以下一些建議，共同努力實現這些期望。這里給一些使用建議。

1.創建一組平民開發者

我們將平臺開發者視為不以coding為生的人：產品經理、流程專家、商業分析師、設計師和MBA項目畢業生等等。這些都是來自不同背景的聰明人，他們有著不同的視角來解決問題并找到解決方案。此外，這些人也是熟悉業務的人，他們與解決方案有緊密的聯系。

因為非技術性的隊友可能是開發生態系統的新手，他們需要接受培訓，以了解各種可能性以及如何最好地實施他們的最新想法。通過學習，沒有經驗的建設者可以獲得了進入一個新領域的信心。

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

此外，還需要提高整個公司對低代碼所帶來的的潛在機會的認識。老板必須確保向員工提供學習和開發資源，從而為進一步提升解決問題的能力敞開大門。

2.關注具有戰略意義的關鍵低代碼項目?

許多業務團隊通常被激勵參加低代碼項目。他們希望提供新的產品和解決方案，并更快地將想法推向市場，又或者是需要為客戶創造更強大、更緊密、更定制化的體驗。他們感到痛苦的是，在手動重復輸入相同的信息和其他低效的模擬活動上浪費太多時間。

實際情況中，許多低代碼工程師都是業務方面的熟手，并且愿意學習可視化編程，可以為他們的日常工作創建簡單的用例。

在開始時，這些用戶還沒有考慮到自動化或應用程序開發的確切用例。為了找到想法，他們可以探索日常業務活動中的已知痛點和特定行業的需求，也可以從預先構建的內容市場開始，看看一些常用的解決方案。一旦他們有了一個想法列表，就應該有一個基于預測的業務影響的戰略優先級排序過程。

業務用戶開始的另一種方式是參與概念驗證（POC）原型開發項目，以轉換更復雜的流程或活動，該流程或活動已經被IT部門分配了高度的戰略優先級。POC原型是業務用戶（如設計師）與開發人員同事或項目團隊分享其最終產品愿景以驗證需求的絕佳方式。

日常問題和請求是低代碼解決方案的最佳選擇。業務人員應該被授權構建所需的擴展和應用程序。在IT資源和專業開發人員短缺的情況下，低代碼工具可以讓任何人改進自己的工作流程和自動化手動工作，并在生產解決業務問題的工作原型時最大限度地提高速度、靈活性和創新性。

3.通過低代碼學習資源適應新角色

雖然低代碼工具比編程語言更容易訪問，但在開始之前需要學習，特別是對于剛接觸軟件開發的業務用戶，否則構建的第一個自動化和應用程序將是草率的、不可擴展的，甚至會產生IT風險。

低代碼課程為缺乏經驗的用戶打開了一扇大門，讓他們在進入之前獲得基本的理解。它們涵蓋了概念性的事情，如：識別用例以及如何確定從哪里開始的優先級，包括對軟件結構、設計和邏輯流程的深入了解，以及在構建工作開始之前對用戶體驗的規劃。當然，在構建簡單的培訓案例時，對能力進行全面的實際審查，確保通過實踐經驗獲得產品知識。

因此，對低代碼技術感興趣的個人越來越多地利用學習工具和課程。這些學習計劃也會擴大低代碼工具的使用范圍。

六、寫在最后

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

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

在低代碼的生態里，具有計算機科學和工程背景的開發人員將繼續以代碼優先的方式推動創新。

但同時，低代碼工具可以為他們帶來效率優勢，同時也為更多非技術員工打開了參與開發過程的大門，從而增加了協作。

同時我們也應該看到低代碼的發展所暴露出的問題：對于人才的可持續培養、培訓和激勵機制的欠缺、平民開發的氛圍。

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

所以，平常心對待即可。就好比駕駛，你可以選擇自動擋，也可以選擇手動擋。但自動擋注定是個趨勢。

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