還記得「No-code 技術結合 AI」有望為企業與非技術背景的人才降低資源成本的趨勢討論嗎？
本篇要接著分享，當企業正式採用 No-code 與 Low-Code 技術所面臨的「陣痛」與挑戰有可能是什麼？為將來有機會引進或使用 No-Code 技術的開發人員、公司管理層、或想挑戰的非技術背景人員作為心得參考。
上週我一位在美國工作的朋友 Jason，偶然間讀了我之前寫的文章「No-code 結合 AI 很無敵？公司想引進先評估這 3 個關鍵問題」，立刻 LINE 我，表示他正在經歷公司引進 No-Code、Low-Code（無程式碼、低程式碼）技術帶來的新挑戰，Jason 跟我分享的內容實在太「切身之痛」，感謝他同意讓我把事件分享出來，希望正在考慮引進 No-Code 的公司高層長官們先看看這篇。
Jason 跟我一樣是全端工程師，目前在美國一家規模千人的上市公司工作。他們公司 3 年多前開始採用討論度很高的 Low-Code 服務，公司多項產品皆有完整導入該 Low-Code 服務，原先長官希望引進後，工程師可透過該服務串接、整合資料減少工作量，公司還可順便合併部門、裁減人力，節省管理資源。
Jason 說，這個服務在公司運行了一段時間，並不是一開始行不通就放棄，而是施行了一段時間才喊停。原因是過去工程師自己寫程式可自己維修跟控管，但全面採用 Low-Code 後，由於是第三方服務，在沒有那麼客製化、那麼貼合公司業務的情況下，使用上多處受限。Jason 說，他們最後甚至放棄使用該服務，另外專門寫了一個工具取代 Low-Code 串接零散的資料，這使原本的工作量沒有減輕，反而被開啟了困難模式（淚目）。
做採購決策的高層長官們，並非第一線操作的工程師，很難感受到使用上的困境， Low-Code 優點在於使用方便，單向需求可以處理得很好，串到 BI 介面（Business Intelligence，商業智慧介面）很合適，但若要做數據管理、行銷、策略檢視，邏輯上就完全不同，無法直接使用。
聽完 Jason 的經歷，我問他會不會就此討厭 Low-Code 服務？他覺得，Low-Code 仍是好服務，只是被用在錯誤的場景，任何工具都有其合適的使用場景，不要挑戰它的極限。舉個例子，如果你想上高速公路，該買的是汽車而不是機車，汽車肯定是更合適的選擇。不該買了機車卻對它投以錯誤的期待，期待機車上高速公路甚至期待它能載很多貨。
別把工具用到極限，否則會提高自己風險
當一家公司決定採用 Low-Code 工具，最想改變的事情是什麼？
Jason 分享，如果要採用 Low-Code 工具解決問題，目標別設太大，先聚焦在一個「問題點」上做改善。首先確認問題的產品層級、規模大小⋯等，參考同業服務時，如果同業產品規模維護人員至少 20 人以上，但自家公司人力只有 5 人，很明顯產值上有很大不同，這不會因為採取某個 Low-Code 工具就達到同層級的成效。
從技術趨勢面來看，公司採用 Low-Code 所帶來的挑戰跟問題，實際上都是嘗試轉型的一部分，但無論如何，No-Code、Low-Code（無程式碼、低程式碼）技術的存在目的並非取代工程師，而是幫助他們處理大量瑣碎或耗時的工作，在不同場景上各司其職，做彼此擅長的事。
感謝 Jason 跨國連線分享，我很喜歡他提到的一個重點：「切莫把一個工具用到極限，因為這樣就是在提高自己的風險。」記得之前曾看過一個 80 歲日本爺爺發揮職人精神，挑戰了 Excel 的極限，繪出一幅山水畫，我雖然深感佩服，但工作上及職場情境講求效率及時間成本，使用專業軟體會更符合使用需求，減少整體的風險！
延伸閱讀
