技術轉型與多人協作的第一次嘗試

這是組織第一次嘗試 技術轉型，同時也是首次以 多人協作開發 的模式完成內部翻修專案。
可以想像，在業界應該有不少團隊或乙方早已這樣運作，但在我們的組織環境下，這樣的機會其實相當難得。特別是我們必須同時維護不少系統（平均每人 1–2 套中小型系統），還要兼顧繁雜的行政庶務。尤其身處金融業，內部常有許多難以參透、卻又必須遵循的上線作業流程，因此能回到「大量開發練功」的場景，確實是相當難得的機會。當然，看似夢想的道路，走起來卻也格外艱辛。

技術轉型的門檻

選擇前後端分離架構，對我們來說是一個巨大的挑戰。
組織內沒有資深的前端框架開發者，即便資深同仁有豐富的 Java 或 .NET Framework 維運經驗，但在 Vue 等現代框架上，大家幾乎是從零開始。

回想初期，光是「登入與身份驗證」這個環節就花了大量時間。
SD（山姆）開始自學 Vue，從基礎語法、型別、物件概念開始，一步步搭配線上 Playground 做簡單 Lab 練習。兩週後，逐漸掌握基本概念，並嘗試與公司現有的認證服務整合，實驗前後端打通的可行性。

特別值得一提的是，Github Copilot 的輔助帶來極大幫助。不僅能清楚說明基礎概念，還能協助架構設計與生成程式碼。雖然 AI 可以提供現成解法，但前提仍是開發者必須理解背後原理，否則遇到更複雜的需求時，就無法舉一反三，往後設計更多延伸與變化。

是否回頭 MVC 的掙扎

即使成功打通了驗證通道，基礎架構也有了雛型，但網站介面仍是一片空白。
對團隊成員來說，前端框架幾乎是全新的領域，甚至連最基本的 Textbox 或 Button 元素語法，都需要查 Google 或反覆詢問 AI。

困難的地方不僅是「不會寫」，更是 不知道該怎麼開始設計。
舉例來說：

• 一個最簡單的表單輸入框，光是要研究應該用什麼套件、該怎麼綁定資料，就稍多個工作天。
• 不同人寫出來的排版方式完全不一樣，有人用 div 巢狀到天荒地老，有人卻只套一行程式碼就結束，結果畫面風格東一塊西一塊。
• 再加上「UI/UX 要大幅提升」這樣的高標準，讓人幾乎一開始就被壓得喘不過氣。

那段時間，甚至多次出現動搖詢問山姆：我們能不能回頭使用熟悉的 MVC？至少可以立刻開始開發，不用卡在怎麼畫出一顆按鈕或是一個下拉選單。

不過，為了避免把精力耗在基礎排版和元件研究上，我們後來決定購入 套版。
套版的價值不只是「節省工夫」，而是提供了 現成的設計範例與元件結構，讓我們能快速找到符合需求的版型，再進行改造。這大幅降低了摸索門檻，也幫助專案更快從「卡關在 UI」進入「聚焦在功能」的正軌。

建立範例與團隊培養

完成套版購入後，我開始參與開發，將山姆實驗的身份驗證功能整合進套版，並實作新增、修改、刪除、查詢等基本需求，逐步建立前後端專案結構與資料流規劃。

當地基完成、骨幹雛型成形後，便開始邀請更多成員加入。新成員可依照範例練習，快速模仿並上手，就像一間「樣品屋」：提供方向，降低走歪風險，也讓大家的風格不致相差過大。開發初期，我們每週召開分享討論會，不是為了嚴格追進度，而是讓不同時期加入的人能以最低學習成本跟上。

這樣的模式帶來驚人的成效：

• 平均每位成員加入 3–4 週內，就能獨立完成一個 CRUD 功能。
• 完成 CRUD 練習後，便能挑戰全新功能，甚至開發共用元件。
• 在中期（第二批成員加入後 3 週），群組中已經能直接發出「共用元件需求」，等待成員自願認領。

同時，我們還將經驗整理到 Wiki，強化知識傳承。甚至後期新進同仁在 2 天內就能參與開發並修正 Bug，顯示這套模式已具備一定的延續性與傳承性。

投入人力成本與壓力

不過，這樣的技術轉型並非沒有代價。前期研究與基礎設施建置的時間非常漫長，每週報告大多只能寫「研究 XXX 功能」或「XXX 開發中」，遲遲無法交出明確的成果。直到 3 週後，功能才逐漸爆發性交付。

這與傳統委外專案相比，進度看起來顯得吃力，特別是當部門內 8 成人力投入 在同一套系統翻修時，外界很容易質疑成本效益。但正如我們所相信的，價值會遲到但不會缺席。

因為這樣的「實戰練功」，如今我們已經具備獨立開發新需求的能力。
即便是未來交由委外，我們也能對前後端分離架構與設計掌握更多細節，避免淪為「全然依賴外部」的被動角色。

回顧與展望

檢視這 30 天的紀錄，內容看似雜亂 —— 專案管理、系統架構、技術實作、團隊文化，幾乎包山包海。
差點想把系列文改名為 《全能工程師團隊的養成計畫》 😂。也正好反映了我們的真實樣貌 一條龍包到底 的工作方式。但透過這次的專案我們確實獲得了以下寶貴有難得的成果：

• 完整保留開發與維運知識。
• 建立可複製、標準化的開發架構。
• 讓成員在實戰中學習新框架，完成技術轉型。
• 大幅提升 UI/UX，帶來更好的使用體驗。

基於上述果實，也讓我們在明年確定的 2 個專案中，會再度採用相同模式進行翻修。沒有參與的同仁也躍躍欲試，甚至吸引其他單位前來詢問，我們究竟是如何辦到的。

另外就在擬稿此篇的同天一天，PM 美薇傳來好消息 —— 測試達成率 100% 全數通過 🎉。
恭喜老爺，賀喜夫人！團隊不僅準時交付功能，功能驗收也全面通過，這值得特別留下一個版面，在我們的專案流程裡，一個功能（User Story）並不是寫完程式就算完成，而是要經過層層驗收：

1. 開發自測：開發人員完成功能後，會先進行基本的內部測試，確認程式能跑得動。
2. 需求單位驗收：接著會邀請需求單位的窗口，依照事先設計好的 測試案例（Test Case） 逐一驗證功能是否符合需求。
3. 情境展開：一個功能往往不只一種使用情境，因此一個 User Story 會被拆解成多個 Test Case。
4. 多人驗證：每個 Test Case 至少需要 2 位以上需求單位的人員確認，避免只依靠單一觀點驗證。
5. 回歸測試：最後，還會挑選專案中的重要功能進行回歸測試，確保在新功能完成後，舊功能依然正常運作。

以這次專案為例：

• 共規劃了 176 個測試案例。
• 每個案例再展開驗證，最終形成 1145 個 Test Point。
• 最終結果是 —— 全數通過 ✅。

換句話說，不只是「功能能用」，而是「每一個情境都被驗證過、多方人員都確認過、舊功能也沒被破壞」，才能代表專案真正達到可上線的標準。這代表所有 User Story 均已達成標準，專案正式具備上線條件。 雖然過程中歷經各種挑戰，能走到這一步，已驗證為這次翻修專案的可行性。

感謝與結語

最後，必須感謝所有一路參與的成員。大家都是身兼數職，常常「有空就加入，忙時就抽離」，但仍然保有熱忱，在有限的時間裡學習新技術、交付功能。

更令人動容的是，有成員在分享會後，還會再回頭研究已交付的功能，討論是否需要重構，追求更好的可能性。這份精神，也是我今年參加鐵人賽、留下這些紀錄的最大動力之一。

同時，也感謝公司不同層級主管給予學習空間，願意支持我們嘗試；也感謝所有讀者（雖然大多是親友團 😂），還有一些認真閱讀並分享心得的朋友 —— 真心暖心。

這 30 天的挑戰，像是一場長跑，也像是一段團隊的集體修煉。
雖然這不是終點，但我們已經驗證了組織能走這條路，也為未來留下寶貴的養分。

最後的最後

謝謝邦邦不邦邦戰友們~我們成功了~，每天一早互相發文提醒、互相勉勵💖💖💖💖💖

今年就到這裡吧！
再見啦，下台一鞠躬 🙇‍♀️🙇‍♂️🙇‍♀️