美公司改採「無程式碼」(No-code)服務，為何工作量不減反增？
「Low-code」常被譯為「低程式碼」，是一種軟體開發方法，可讓團隊以「最低的編碼需求」來開發數位解決方案，號稱業務使用者可自行利用基本邏輯，來迅速解決實際業務問題。但是其實「No-code」、「Low-code」在引進公司時常會面臨「錯誤的期待」而導致水土不服，舉例來說「你不應該期待自己牽了一台機車後卻能在高速公路上跑贏汽車」，如果你的目標是高速公路，或許你一開始就該選擇汽車......
文／RUBY 大叔
上週我一位在美國工作的朋友Jason，偶然間讀了我之前寫的文章「No-code 結合 AI 很無敵？公司想引進先評估這 3 點」，立刻 LINE 我，表示他正在經歷公司引進 No-Code、Low-Code（無程式碼、低程式碼）技術帶來的新挑戰，Jason 跟我分享的內容實在太「切身之痛」，感謝他同意讓我把事件分享出來，希望正在考慮引進 No-Code 的公司高層長官們先看看這篇。
Jason 跟我一樣是全端工程師，目前在美國一家規模千人的上市公司工作，他們公司 3 年多前開始採用討論度很高的 Low-Code 服務，公司多項產品皆有完整導入該服務，原先長官希望引進後，工程師可透過該服務串接、整合資料，減少工作量，達到事半功倍，公司還可順便合併部門、裁減人力，節省管理資源。
Jason 說，這個服務也在公司運行了一段時間，並不是一開始行不通就放棄，過去工程師自己寫程式可自己維修跟控管，但全面採用 Low-Code 後，由於是第三方服務，在沒有那麼客製化、那麼貼合公司業務的情況下，使用上多處受限，Jason 說，他們最後甚至放棄使用該服務，另外專門寫了一個工具取代 Low-Code 串接零散的資料，這使原本的工作量沒有減輕反而被開啟了困難模式（淚目）。
其實做採購決策的高層長官們並非第一線操作的工程師，很難感受到使用上的困境， Low-Code 優點在於使用方便，單向需求可以處理得很好，串到 BI 介面（Business Intelligence，商業智慧介面）很合適，但若要做數據管理、行銷、策略檢視，邏輯上就完全不同，無法直接使用。
聽完 Jason 的經歷，我問他會不會就此討厭 Low-Code 服務？Jason 覺得，它仍是好服務，只是被用在錯誤的場景，任何工具都有其合適的使用場景，不要挑戰它的極限，如果你想上高速公路，該買的是汽車，不是機車，汽車肯定是更合適的選擇，並非買了機車，對它投以錯誤的期待，還期盼它能載很多貨。
別把工具用到極限，否則會提高自己風險
當一家公司決定採用 Low-Code 工具，最想改變的事情是什麼？Jason 分享他的心得，他認為目標別設太大，先聚焦在一個「問題點」上改善，確認問題的產品層級、規模大小等，有時參考同業服務時，一看產品規模維護人員至少 20 人以上，但自家公司人力只有 5 人，產值不同，不會因為採取某個 Low-Code 工具就達到同層級的成效。
從技術趨勢面來看，公司採用 Low-Code 所帶來的挑戰跟問題，實際上都是嘗試轉型的一部分，但無論如何，它的存在並非是取代工程師，而是幫助他們處理大量瑣碎或耗時的工作，在不同場景上各司其職，做彼此擅長的事。
感謝 Jason 跨國連線分享，我很喜歡他提到的一個重點：「切莫把一個工具用到極限，因為這樣就是在提高自己的風險。」其實很多時候，我們真的都在挑戰一個東西的極限，記得之前曾看過一個 80 歲日本爺爺發揮職人精神挑戰了 Excel 的極限，繪出一幅山水畫，真是深感佩服，但在工作上，更多時候講求效率及時間成本，使用專業軟體會更符合使用需求，減少整體的風險！
（原文標題：美國千人公司採「無程式碼」服務，為何工作量不減反增？）
提升職場工作術？還有這些觀點供您參考
- ChatGPT怎麼用？有哪些指令能更精準獲得想要的答案？
- 「生成式AI」將成新寵兒？公司導入前請先想好3件事：你是真的需要，還是跟風？
- ３種性質工作最不易被AI取代！技職人一身武藝比文憑更吃香
- 2024年最新！盤點「數據／資料工程師」12個必備技能、推薦職缺、證照進修
★ 追蹤【104職場力】粉絲專頁、職場更給力 ★
