《軟體工程師記》EP.3: 五週年

前言

今年是我成為軟體工程師的第五年，也剛好是在今年，我將踏上異地求職的旅程。雖然不確定是否能在英國順利找到理想的工作，但回顧過去這五年，作為一名軟體工程師，我學到了許多，也經歷了許多。這段旅程是奇妙也是幸運，或許正值得好好記錄下來。

五年，說長不長，說短也不短。現在回頭看當初寫的 《軟體工程師記》EP.1: 從零到一 與 《軟體工程師記》EP.2: 街口支付，總覺得那時剛踏入職場的自己成長得非常快。每天都有接觸不完的新技術與新知識，日子過得充實且有挑戰性。

求穩不求新

結束了在街口支付兩年的工作後，我加入了一間美商公司，這間公司剛好符合我當時的求職目標，不錯的待遇、有跨國合作的機會也有良好的團隊文化。但我對於新技術的追求在這三年間慢慢地消失了。

起初我以為是自己變得懶惰了，導致看到新技術的欣喜程度開始鈍化。為了找回那份熱情，我在 2024 年開始寫 前端電子報，想說透過整理趨勢與新知來保持自己的新技術敏感度。但我慢慢發現，我並不是失去了對於軟體技術的熱情，而是我開始更重視系統與框架的穩定性。

剛加入這間美商公司時，發現團隊使用的並不是 Next.js 或 Remix 這類當時正夯的 Meta Framework，而是一套自研的框架。那時候的我難免有些失望，畢竟正值 Next.js 如日中天、話題性十足，而我卻沒有機會親手接觸它。

但三年過去，我漸漸看見這套自研框架的價值。它雖然使用的技術有點老舊，開發體驗也有乏善可乘，但已能穩定支援公司各個服務項目的多種需求。無論是垂直擴展，或是進一步拆分成微前端架構，它都能夠做到。這種架構層面的彈性，讓我對於前端工程有一個新的認知。

如果真的想要學習新技術，其實不妨透過寫部落格或經營自己的 Side Project 來練習跟探索，這也是當初參加 鐵人賽 跟寫 電子報 的原因。而在工作中，更重要的往往不是使用多新的技術，而是如何寫出穩定且高效的程式碼。除非新技術或框架能夠明確帶來超越穩定性的價值，否則在團隊開發中貿然引入，反而可能增加維護成本與風險。

保持開放

起初我對後端開發還非常陌生。記得在每次會議在安排下個 Sprint 工作項目時，我總是下意識地避開後端任務，更傾向選擇自己熟悉的前端項目。每當看到需要碰後端的任務，腦海裡總會冒出一個聲音：「我不夠格，會搞砸的。」而這些聲音，其實都是我自己對自己的否定。

不久之後，公司組織經歷了幾次重整，導致有些小組雖然有後端需求，卻缺乏足夠的後端工程師。那時候的我才開始主動的去接觸這些後端的開發，有些項目剛開始研究時真的很茫然，但只要敢問跟花時間，慢慢地就會開始對它感到熟悉，儘管自己還不是後端的專家，但至少不會在像是先前一樣逃避，而只是把它當成是需要被解決的問題。

功能交付

在前一間公司，我其實從未接觸過 A/B Test。當時的開發流程相對直線，所有功能只要專案經理評估沒問題，就會直接進入開發並上線。直到加入現在這間公司後，我才開始真正接觸到 A/B Test 的流程與價值。

由於我所在的團隊是負責面向消費者的產品，因此在功能交付後，最重要的兩件事通常是：錯誤監測（Error Monitoring）與觀察 A/B Test 的表現。而後者是否成功，通常會依據專案經理在 One Pager 中定義的成功指標（Success Metrics）來判斷。

• 若功能的目標是提升 GMV，那麼就需要觀察實驗組（Treatment）在功能上線後的營收表現是否優於控制組（Control）。若表現顯著較高，就代表這個功能的發佈是正向的。
• 如果這項功能只是單純的服務遷移，A/B Test 則可以當作一個功能旗標（Feature Flag），理論上 Treatment 與 Control 的表現應該趨近一致。若其中一組表現異常且具統計顯著性，則代表事情不單純，需進一步排查。
• 若功能目標是提升某個區塊的點擊率（CTR），則需輔以其他追蹤工具進行驗證，例如在程式中埋設事件追蹤，搭配資料庫查詢，或透過第三方分析平台（如 Amplitude）觀察點擊比例與使用行為。

經過這三年的洗禮，也體會到了開發新功能時，真正困難的往往不在於開發本身，而是在功能交付後，如何有效地進行監測與驗證。

當監測結果未如預期，我們又該如何找到問題並進行改進？這些工作不再是工程師單打獨鬥，而是需要與團隊的資料分析師、專案經理密切合作，從數據中找出線索，看使用者對於新功能的使用行為，甚至重新思考與設計功能，整個驗證與調整的流程，有時候可以比開發本身耗時數倍，但卻也正是產品是否可以為公司創照價值。

Scrum Master

Scrum Master 這個職位是我加入這間公司後才認識的。這個角色的核心任務，是協助團隊順利執行敏捷開發流程。加入公司滿一年後，我剛好有機會擔任這個職位，也是在那段時間，開始與專案經理和主管有更多的交流與協作。

從規劃每個衝刺（Sprint）的待辦事項、掌握團隊每位成員的 Bandwidth，與主管和產品經理討論下一階段的任務細節與所需資源，到將任務分配給團隊成員，乃至於衝刺結束後的回顧與調整，這些都成為我在開發以外的日常。

同時，如何讓專案的利害關係人（Stakeholders）清楚掌握團隊目前的進度，以及在遇到緊急任務時該如何合理地插入衝刺中，這些都是需要花心思設計與溝通的。

舉例來說，我會鼓勵專案負責人每週將他目前的進度同步到相關專案群組，讓主管或是專案經理能夠保持在同個頻率上。以及有突發任務時，先列出所有潛在插單的項目，釐清哪些是真正「緊急且重要」的事項，再經與主管和產品經理協調後，謹慎地安插進當期 Sprint。

透過這樣的機制，我們才能在滿足業務需求的同時，維持團隊開發節奏的穩定，避免每次 Sprint 回顧時出現「插單失控」的局面。

不過對我而言，真正挑戰的地方，並不是這些流程與規劃，而是在於「人」的層面。比起分配任務，更困難的是：如何讓每位團隊成員清楚知道接下來要負責的專案？又該如何與主管討論，是否有成員希望基於職涯發展的考量，嘗試不同類型的項目？

以「讓成員知道下一個專案是什麼」為例，挑戰常來自資訊的不透明。多數時候，專案經理未必能提前提供下下個 Sprint 的需求規劃，除了看著每個季度的 roadmap 觀落陰以外，這時我通常會採取兩種策略：

1. 增加需求預測量：主動與專案經理協調，請他們提供略多於當前 Sprint 所需的任務，讓團隊有餘裕預估未來的走向。
2. 主動創造任務：與主管共同討論團隊有哪些可改善的內部流程或技術債，當成員手中的專案做完時，在等待下個任務的過程中可以順邊優化團隊的系統。

總之 Scrum Master 這個角色其實還蠻有趣的，同時也可以加強自己的溝通技巧，在這段時間也透過這個職位學到不少。

其他想法

• 工作上的所有權 (Ownership)：

  這幾年來，我對「工作所有權」有了更深的體會。無論職級高低，盡可能成為某個專案或系統的關鍵人物（Go-to Person），是提升自己在團隊中影響力的最好方式。

• 幫助他人解決問題：

  這個過程本身也是學習的機會。很多時候，在釐清他人問題的同時，也讓我對某些知識點有了更深入的理解。這不只是協作，更是雙向成長。

• 刻意挑戰自己，做那些覺得困難的事：

  成長往往來自走出舒適圈。當你開始接觸自己不熟悉的領域，所學到的往往會遠超預期。讓自己成為一個說「我可以試試看」的 Yes Man，反而能加快學習速度，也讓自己對未知少一點恐懼，多一點好奇。

• 把專案當成自己的孩子一樣對待：

  每當負責一個新功能或專案時，盡量將它當成照顧小孩一樣，除了自測以外，也加上功能旗標（Feature Flag）以便真的出事的時候，能夠即時響應；功能上線後，也會進行實時監控，確保一切如預期運作。

總結

把這些零碎的想法寫下來，也算是為這三年的歷程做個整理。如果之後還有什麼新的體會，再慢慢補上！

看著 AI 進步的速度，有時會覺得當前軟體工程師這個職業是否會成為工業革命時的紡織工，畢竟當前的頂尖 LLM 模型在寫程式的速度上是一般人的數倍，品質不差甚至更好，而現在我們所用的頂尖模型一定是未來最差的模型 😂。如果這個假設為真，希望這一篇文章不是《軟體工程師記》的最後一集，即使未來的角色有所轉變，我仍期待自己能在 AI 時代裡，親手用 AI 打造出一個讓自己感到真正驕傲的產品。