避免讓團隊肝壞去的的故事

當你遇到需要加班才能完成專案的時候，你會加班嗎？

這是一個不想加班又努力的故事。

失敗後開始的新思考#

當初 框架升級不順的背後 升級時碰壁，因此開始思考是否有其他方式可以協助現況與未來的服務拆分，所以提出了幾個技術改善的方向，其中之一便是 CSS Framework Migration。

在沒有軟體工程管理概念下，往往容易針對同一個問題用上不同的解法，而前端的領域中特別需要注意，因為 client assets 會影響 page performance，如果沒有特別的注意就會是一個大問題。

那時候情況是這樣的——整個專案中使用三套不同的 CSS frameworks，這對前端工程師來說是一種災難。

每次看到設計稿時都要先花時間搞清楚是哪一套的元件、樣式，這樣的流程既浪費時間也增加維護成本，更不用說對效能的影響。

這算是一種我在前公司也見過的「常見」問題，過去我也是推動類似的重構專案來解決。

除了效能#

除了效能上的考量，我也發現另一個我在意的結構問題——當前的實作有些是直接依賴介面框架提供的元件，缺乏中間層，導致功能邏輯與外部介面邏輯過度耦合，讓未來要替換方案的成本就不好估算。

原先使用的幾套 CSS frameworks 在我看來都不是長遠的解法。以 toC 為主的產品，在成熟後往往都會走向客制 UI components 來降低 asset 並最佳化使用方式。

不過當時公司沒有資源這麼做，所以我退而求其次，提出了統整 frameworks 的提案，想達成三個目標：

• 正規化中間層隔離
• 降低介面討論成本
• 減少開發時不必要的決策負擔

不加班，那怎麼完成？#

這個專案方向無法說服公司額外給資源，因此只能在當時還沒正式成立的 platform team 中使用原有 50% 的人力來執行，每週還需根據專案優先順序不同而調整參與成員，對我來說是個專案管理上不小的挑戰。

但事情不止如此。

當專案進度推進到三成時，我發現大事不妙了——還需要兩季才能完成，而在這段期間內可能發生很多事，我想專案被砍也是不意外的事情。

我知道我沒辦法放棄這段時間以來的努力，我也知道每一次償還技術債都是讓專案變得更好的契機。但我不想為了達成這個目標而犧牲其他同事的時間和健康，畢竟這是我的想法，不是他們的。

因此我開始思考：

既然未來所有 frontends 都會從這個改變中受益，
那是否可以讓大家也一同參與？

與其只是被動接受最後產出的結果，不如讓大家一起投入，這樣也更容易讓標準落地並維持下去。

我與 manager R 確認產品團隊近期是否有較多空檔，並規劃了一種新的合作模式，這也後來成為 platform team 與 product team 協作的原型。

我作為 project owner，同時兼任 tech lead，負責所有的技術審查與協作流程。每週根據當前可用人力，規劃適當顆粒度的任務，並跨團隊確認下週人力調度與交付安排。

這個策略讓專案進度大幅加速，R 甚至願意調派更多同事支援，讓我們能在當季完成整個 migration。

加資源=更快？#

如果這麼順利就結案，那麼就不會有開頭我的提問了。

讓我複習一下這個問句：

如果遇到需要加班才能完成專案的時候，你會加班嗎？

當老闆給更多資源的時候，通常不是在期待好好把事情完成，而是如何更快且更完美地完成。

資源進來前幾天，R 開始頻繁關心我的專案與人力規劃，讓我壓力不小。我也完全理解他有他的壓力。但我也有些未說出口的期待：除了技術債的償還，我內心還希望這次合作能讓團隊成員在介面工程化與設計能力上獲得成長。依照當時以交付日為導向的進度規劃來看，不僅會讓大家壓力山大，也會讓我無法完成知識回饋與技術成長的初衷。

最近一次 R 詢問我的時候，我誠實地表達我需要一點時間思考，但是隔天會試著提供解法。

我重新以 project management 的角度，檢視現況與目標：這季的整併是為了讓成果在更上層的管理者視角能被看到，這是一種 functional requirement；但實際上更深層的價值，如減少決策負擔、提升一致性，其實更像是 non-functional part。

針對這個差異，我嘗試找出分階段交付的可能性。

我去看了當時使用的 framework source code，發現可以先搬移部分組件實作到專案，以暫時繞過無法即時完成的重構，把這部分留到下一季再逐步完成。

這樣可以先取得被看得到的效能增進好處，以滿足 functional requirement。
我調整了執行策略，在與 R 進行同步與人力調派確認後，在保證團隊的健康下，最終順利完成結案。（呼。）

這個專案是我第一次在這間公司獨立負責的大型專案。偶爾有空還要一起重構。

在這一路上不斷調整策略、協調資源、推進技術規劃，也與超過 13 位開發者合作。除了安排週任務與 code review，也要向老闆同步進度，確保產品團隊的人力可以穩定介入。

從效能問題走向工程文化#

回顧整個過程，這個專案不只是讓當時開發流程變得簡單的探索，也替我未來想實踐的服務拆分打下地基。

更重要的是，讓我學著重新審視每個階段背後的初衷：

我們為什麼要做這件事？
怎麼做才能讓未來的自己及團隊感謝現在的我們？

原本只想解決維護性與效能問題，卻發現光靠個體努力很難推動整體改變。
要長期做出影響，除了設計得夠好及策略要對，資源分配也要有彈性跟策略才行。

我想我是有逐漸更加接近軟體工程管理的本質。
在充滿不確定與變動的環境中，持續建立能讓團隊安心推進的穩定基礎。

這些體會，帶給我的遠超交付成果本身的肯定。
而在過程中默默儲值的 credit，也在未來成為我推動更大改變的關鍵派上用場。

當然，剛完成專案的我並不知道——
這些故事才正要開始。