中國軟件行業協會在《2020中國低代碼開發平臺十大發展趨勢》中提到2021年市場對于應用開發的需求將五倍于IT公司的產能。為填補這一產量缺口，低代碼除了幫助現有IT技術人員提升工作效率之外，還能帶來更低的學習門檻，讓業務人員具備一定的軟件開發能力，進一步擴充軟件開發力量，加速信息化建設。

一、什么是業務開發者？

在低代碼技術被命名之前，國際知名的研究機構們就提出了“業務開發者/平民開發者”的概念。這兩個概念與專業開發者對應，專指那些向業務部門匯報但開發能力來輔助業務發展的員工。這些人和向IT部門報告的專業開發者不同，他們的主要工作職責是業務發展，軟件開發只是一個輔助性工作，通常不會有相關的考核指標，得到的資源也較為有限。在傳統的編碼開發時代，業務開發者較為少見，有能力從事輔助性軟件開發的業務人員主要集中在數據分析師、軟件公司的程序員（程序員的主要工作是開發軟件產品或對外交付軟件項目，而不是輔助性的軟件工具）等具備編程能力的人群。而低代碼技術的出現，讓更多的業務人員可以成為業務開發者，比如構建訂單管理應用的銷售主管、人事檔案系統的HR、庫存盤點APP的庫管人員等。

整體而言，業務開發者具備以下特征：

• 具備技能：通常沒有計算機相關的教育背景，部分掌握Excel等辦公軟件的常用功能

• 考核指標：能否完成業務目標是核心指標，通常不包含信息化建設相關內容

• 學習意愿：不得不參與軟件開發，通常沒有主動學習IT相關技術的動力和投入

二、低代碼對業務開發者的價值

與幫助IT技術人員提升軟件開發效率不同，低代碼對于大多數業務開發者而言，是解決了“能不能開發軟件”的問題。這就意味著，業務人員可以根據自身的應用場景，快速構建起對應的軟件應用，減少了與IT部門協調確認的溝通成本，在IT部門資源緊缺的背景下，盡快掃清信息化死角。

業務開發者構建的應用主要有以下幾類，除數據報表應用的業務邏輯復雜度較高而且通常需要與第三方系統集成，對業務開發者有較高的學習能力要求外，其他應用場景相對簡單，更適合業務開發者使用低代碼構建。

三、業務開發者面臨的管理和技術挑戰

從理論上講，業務人員從事軟件開發確實有很高的價值，可以有效降低企業在信息化的投入，并盡快見到成效。然而，從管理到技術，業務開發者和IT技術人員都存在較大的差異，需要面臨更大的挑戰。從研究機構的數據上看，業務開發者的學習門檻和應用場景深度廣度的矛盾已經成為了很多企業實施低代碼技術失敗的主要原因。所以，在引入低代碼技術，讓業務開發者承擔企業信息化建設之前，企業仍然需要做好預期管理和組織管理優化，循序漸進。

3.1 軟件質量：“短平快”優先于可維護性

相比于有明確發展規劃和專項預算保障的IT部門，業務部門對信息化的要求通常與當前面臨的問題緊密相關。有需要解決的問題，而且IT部門無法及時解決時，業務團隊才會臨時做出預算，為自己開發軟件。

向業務部門匯報的業務開發者在軟件開發上的投入更加碎片化，峰值雖然較高，但不可持續。而且，隨著軟件應用走上正軌，業務部門大概率會在第一時間將后續的維護工作移交給IT部門，即從業務開發者交接給IT技術人員。如果在較短的時間周期內，業務開發者沒有按照預期完成軟件的開發和交付，業務部門就失去了將其留在自己團隊的最大理由。該項目則很可能直接擱淺或移交給IT團隊，進入開發隊列。而對于業務開發者而言，項目已經失敗了。

所以，大多數業務開發者會更關注如何以最快的速度將應用開發完成并投入使用，實現“能用”的基礎目標，而不是將精力投入到軟件質量和可維護性等方面。“短平快”成為業務開發者構建應用的關鍵詞，而這很可能互對軟件的可維護性埋下不可忽視的隱患。相比之下，需要長期維護信息系統的IT部門中，IT技術人員則必須將質量與可維護性（包含功能擴展、數據一致性、系統集成等）放在重要的地位，否則就是給自己和其他團隊成員“挖坑”，難以持續發展。

3.2 學習偏好：對學習投入更加敏感

不可否認，業務開發者在技術能力上可能會比IT技術人員者稍微弱一些，但這更像是業務開發者運行模式的結果，而不是原因。

為了進一步達到“短平快”的目標，應對不可持續的軟件開發工作，業務開發者通常對學習投入更加敏感。除非通過當前崗位之外的工作熟練掌握了某些軟件開發技能，業務開發者在學習軟件開發技術中投入的每一分鐘，都會拖慢項目交付的速度，擴大項目失敗的風險。這是很多業務開發者最不愿意看到的情況。

拋開項目本身，相比于IT團隊完善的職業發展道路和持續的實戰機會，業務開發者在軟件開發技術上的學習顯得更加沒有“性價比”。因為，業務能力才是業務開發者最顯著的優勢，也是其最大資本；而開發能力，還不知道什么時候才會再次用到。如何讓業務開發者也有通過學習不斷提升開發能力的機會和動力，是擺在業務開發者領導面前的難題。

3.3 風險偏好：對運維風險更加敏感

從學習投入低、更關注短期效果兩個特點，我們不難看出業務開發者構建的應用比IT技術人員的質量風險更高一些。然而，業務團隊對數據錯誤、系統可用性低、數據安全性差等系統運維風險的敏感性卻不會因為開發者不同而展現出明顯的差異。更麻煩的是，業務開發者本身處在業務團隊，一旦他們構建的應用出現問題，所有損失將由該業務團隊自行承擔。在很多中大型企業中，這種風險不容忽視。

事實上，決定風險敏感度的首要因素是該軟件的應用場景。在應用場景的類型上，企業上下對生產、銷售、投資等核心業務系統的風險敏感度更高；OA、人事等邊緣應用的敏感度更低。在數據操作能力上，負責人對僅讀取數據的數據分析應用更加放心；而對那些需要寫入數據，尤其是向核心業務系統寫入數據的ERP二開等應用，要求更加嚴格。所以，讓IT部門的技術人員專注于核心業務場景、需要寫入數據的場景，邊緣應用請相關業務團隊的業務開發者參與，是一個被廣泛接受的“最佳實踐”。

四、“業務人員做軟件”的風險與出路

2021年12月，國內知名IT媒體——T研究發布了《2021中國低代碼/零代碼全景產業研究報告》，其中重點關注了采用表單驅動技術路線，提供給業務開發者的使用的低代碼開發平臺在企業落地的挑戰，并通過走訪已經引入低代碼但效果不如預期的企業客戶，匯總了業務人員使用低代碼平臺開發軟件應用失敗的主要原因。

報告顯示，“低代碼的能力有限，無法支撐復雜業務場景”和“即使經過培訓，業務人員依然無法順暢使用低代碼平臺”兩者成為失敗原因的前兩名。結合報告的上下文，T研究揭示了在“業務人員開發軟件”的目標下，低代碼平臺的兩難問題：既不簡單易用、也不能打硬仗。

不能否認，軟件開發是一個將現實中的問題用計算機所擅長的方式重新進行梳理和呈現的過程。在軟件開發的過程中，開發者不但需要理解業務場景在現實中的運作邏輯，還需要具備必要的計算機相關知識，才能將其“翻譯成”計算機擅長的樣子。不同的應用場景中，這個翻譯的難度存在很大的差異。比如，在簡單的數據填報應用中，現實中的一張問卷可以直接對應為軟件中的一個表單，而問卷中的問題則對應了表單中的數據字段。這類應用通常也稱為“單表應用”，即便沒有受過任何編程訓練，甚至在大學中沒有學習過計算機原理，業務開發者依然可以在低代碼平臺上輕松地完成整個應用的構建。但是，對于出入庫管理這種業務邏輯稍顯復雜的場景來說，現實中的一張出庫單則需要對應成“出庫單表”、“出庫單明細表”、“商品元數據表”、“倉庫元數據表”等多個數據表，才能確保這個應用具備一定的可維護性，并保障數據的一致性。開發這個類型的應用，需要業務開發者具備一定的計算機知識，或者至少有意愿在學習數據庫相關知識上投入數小時甚至數天的時間。對于大多數企業中為業務成果負責的業務開發者來說，為了做系統而需要學習數據庫知識，這種投入顯然是不現實的。

綜上所述，企業在為業務人員引入低代碼技術時，需要清楚地認識到業務開發者所擅長的應用開發場景，正確管理對低代碼技術的預期。在平臺選擇上，建議將平臺技術能力的優先級提升到學習門檻之上，優先保障該低代碼平臺可以滿足復雜應用場景所需，避免后期因切換低代碼平臺而造成返工。在實踐上有如下建議，供有意推進業務人員開發軟件的企業信息化決策者參考：

• 推薦業務開發者構建使用頻率不高，不需要與企業核心業務系統集成的單表型應用，如數據填報和流程管理

• 如果業務開發者有意愿、有投入來學習更多計算機基礎知識，特別是數據庫相關知識，可以逐步參與到檔案管理、數據報表等稍復雜的多表應用開發

• 如果業務開發者構建的應用需要長期使用，推薦IT技術部門參與數據庫結構設計等底層關鍵技術環節的評審，降低未來的維護成本

• 如涉及到與核心業務系統集成，強烈推薦IT技術部門進行全程指導和審查，以確保業務開發者構建的應用不會影響到企業核心系統的穩定運行。

擴展閱讀

• 【技術博客】平民開發者≠技術差！真正發揮平民開發者的創造力，光有低代碼還不夠