在企業數字化轉型建設的過程中，軟件系統永遠都是企業的痛，可以說沒有一款軟件會讓企業在應用過程中感覺HI的起飛，都是又愛又恨，因為系統功能都是固定的，系統代碼的修改是受限的，但企業的業務場景卻是動態的，同時軟件開發又具有較高的技術門檻，需要專業的軟件開發團隊，對企業而言又是一筆不小的人力成本投入，因此既要在靈活的需求場景下改動系統功能，又不需要太多的技術成本投入，于是低代碼或無代碼平臺出現了，在一定程度上滿足了企業工作場景的系統開發需求，對于部分企業而言，擁有了低代碼平臺并不一定能開發出功能強大、適配業務的系統，也不會擺脫對程序員的依賴，因此在低代碼的應用上企業需要考慮以下環節的問題：

01 如何將模糊意識轉化成需求？

由于業務部門天生缺乏數字化的技術基因，因此業務部門有想法并不一定代表其有真實的需求，因此，企業需要在業務痛點及癢點之間做出判斷，不能因為公司有低代碼平臺就可以隨意將想法轉化成系統；因此需要將某個業務部門的想法進行整理、篩選、獲取價值需求點，然后根據需求進行開發方案設計；

沒有需求就要學會引導需求，有大量需求就要學會整理需求；

02 如何克服技術與業務之間的溝通障礙？

在軟件開發過程中最大的危險點就是需求模糊，項目開發邊界難以確定，業務部門有數字化需求是件好事，但最擔心的就是有需求難以表達，或者技術人員對業務了解深度不夠難以理解，同一個功能可能在業務與技術部門之間有不同的理解，在溝通上造成“雞同鴨講”的現象，因此對于業務場景的深度理解、能與業務部門實現同頻溝通是技術部門急需要提升的能力。

03 如何進行項目設計？

很多低代碼公司總是用“低代碼很簡單，拖拉拽即可實現系統搭建”這樣的話語來體現系統搭建的簡易化，同時鼓勵業務部門參與系統搭建，這種做法在一定程度上可以促進技術與業務的融合，但大部分企業所忽視的一個問題是：思維的轉換！俗話說術業有專攻，場景各不同，業務部門所缺乏的就是業務思維與軟件產品思維的轉換，因為在日常應用中業務部門感知的是軟件系統的前臺界面，所以在低代碼開發過程中業務部門就缺乏了后臺功能邏輯的設計能力，最終造成沒做低代碼前以為就是“拖拉拽”簡單的很，結果打開系統后臺滿屏的配置界面不知如何下手的尷尬局面。所以業務部門要進行從場景到產品的過渡。

04 如何進行項目管理？

很多人以為低代碼系統搭建不就是要業務部門在玩嗎，還搞什么項目管理？其實在大部分傳統企業內業務部門是難以勝任低代碼搭建場景的，因為：

1. 在傳統企業里由于人力有限，業務部門工作繁忙難以有空余時間來負責系統搭建工作；

2. 業務部門想當然的認為涉及技術的工作就應該信息部門來做，加之對陌生技術領域缺乏足夠的學習耐心，所以本能的排斥系統搭建工作；

3. 業務部門缺乏架構思維、產品思維、數據思維、數據安全意識，這就在一定程度上會讓所搭建的系統存在重大的隱患；

所以在大部分的傳統企業由于先天缺失技術基因，低代碼的搭建工作還是由信息部門來完成的，因此可能存在的問題就是：

業務部門的需求邊界如何確定？

功能如何設計并與業務部門達成一致!

業務部門誰來配合一起完成！

這些基礎工作如果不夠明確，那么可能出現的情況就是業務部門需求無限發散，功能無限堆疊，然后又全部推翻重來，最后可能就是信息部門背上一個能力不足的大鍋！

還有一種存在項目管理的情況就是企業沒有勝任低代碼開發這一技術能力的人員，需低代碼平臺公司或者第三方技術服務公司提供技術能力支持，一般情況下企業會與之簽訂勞動服務合同，即購買其低代碼系統搭建服務，按固定的人天來計算項目費用，那么在這種情況下企業更需要進行精細的項目管理，需要服務公司提供專業的工作任務書，要求其定期匯報項目進度，需協調的問題等，同時最關鍵的是項目質量，是否按業務部門的需求來進行系統搭建工作，是否滿足業務需求等。而此項目管理工作企業必須指定專人負責跟進、監督、協調，保障項目按期推進。

總之在低代碼項目的建設上，希望企業不要大意，低代碼也并非廠家宣傳的那樣“拖拉拽”即可實現所有的場景，簡單場景尚可，但復雜的分析運算場景、行業個性化場景就必須依托其平臺進行代碼的二次開發，還是要求企業必須有一定的技術實力，也就是說最好有程序員，但矛盾的場景是大部分的程序員都以源碼開發為榮，從內心里排斥低代碼，因此在低代碼與源碼的問題上企業應明確一個界限與取舍，不能既要還要，清楚的界定哪些場景用低代碼，哪些場景用源碼開發，低代碼與源碼開發二者技術如何融合發展。

最后總結一下影響低代碼項目質量的一些因素：