上週我一位在美國工作的朋友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 的極限,繪出一幅山水畫,真是深感佩服,但在工作上,更多時候講求效率及時間成本,使用專業軟體會更符合使用需求,減少整體的風險!