Developer 當了一年 POS 產品後端的 Team Lead 的小記
今年八月時，台灣的小朋友拿到寶可夢卡牌世界賽的兒童組冠軍，覺得令人振奮。看了一下的小心得是，果然要打什麼牌也是要看環境：比賽前要選定牌組時，就要想像之後可能遇到的牌組。回想起今年因緣際會需要擔任 iCHEF 的 POS 產品後端團隊 Team Lead 角色（分兩組，我是其中一組的 Team Lead），接下這職務之前，也是剛好看到有一些困難、機會與挑戰，在做了一年的這個 moment，也紀錄下來同時公開分享，期待多少回饋給台灣的軟體工程與資訊服務產業；搜尋網路上與 Lead 職級與職務相關的分享，比較多偏原則、概念與建議，實際上要分享到底做了些什麼，通常會比較謹慎些，這邊太細節的部份還是稍微打了點馬賽克，歡迎來 Taipei.py 聚會私下聊。
就結果來看，今年主要做了：
- 【推動成立 SRE 團隊】並持續協助 SRE 團隊的運作（感謝 SRE 成員大瑋、前兩年主力羅芃與工程經理 Kenneth 在這邊的出力都非常的罩），包含文件系統、職級辨識與職責期待、運作流程等
＞ 身為台灣最早開始做 SaaS model 的 POS 廠商，Cloud 的系統架構與維護可以說必然是不可或缺，長年以來 Infra 相關的任務在 iCHEF 裡也沒有少過。隨著公司與 POS 產品團隊到一定規模，產業對 SRE 的認知愈加成熟，Infra 例行事項與任務的加重，加上團隊有人才有興趣，種種催生了 iCHEF 在 2023–2024 時正式成立 SRE 團隊，過程中也確實藉此團隊完成了各式各樣的任務，讓公司的運作更加順暢與穩健，增加了讓相關工作專業劃分並規劃執行的好機會。 - 【後端產品架構的資安成本與評估矩陣】公司在商業規劃的路上，需要參考 2023–2025 產品架構的資安成本 評估，而後端的系統架構與規劃又是其中較大而複雜的，即便預期在未來可能有些大幅變動的不同解法，仍在這個時間點給了一個可能參考並往前推進的矩陣評估
- 【雲市集報告與稽核】配合公司支持政府雲市集方案（三次…今年意外地多）代表公司於「引領中小微型企業數位轉型戰略攻頂計畫(臺灣雲市集)」實體審查中的技術部份進行簡報、回答資詢與補件處理
- 【Backend benchmark 後端專案工程估時方法】協助擬定公司每一年都需要規劃明年專案粗估時的參考表。軟體工程專案時程的挑戰，從 1975年出版的《人月神話》到經過快要 50 年的現在，我們應該可以超越「用感覺估」、「純看人估」的認知階段。另一方面，因為換了人就整個團隊與專案時程從零開始重新評估，可能也不是對公司比較有用或大家都認同的事
- 【AWS 上 Data Pipeline 的解決方案】從 Heroku、AWS DMS 到 Redshift 之路，也看了一下 Kafka 與 Data Lighthouse (Databricks) 到 dbt 甚至 duckdb，總算是有了個基底向前推進；也趁機複習了 AWS NLB、Target Group 與 subnet NACL 的知識
- 【AWS 專案計畫書】提供專案架構圖給廠商參考（與節省公司費用相關）
- 【正規化 Production 的手工修正流程】雖說我們也知道資料庫的正規化不總是有用的，而它就是常常有用比沒用好
- 【研究、試用與跟團隊分享 ArchiMate】（近代類似 UML 但角度更廣而更簡單、開放一點的模型語言），另外也研究了一下 Code Climate 與 GitClear
- 【RD 季度跨團隊成果分享】兩次✌️
- 【釐清 Jenkins Role-base Plugin 的功能與用法】沒想到從 iCHEF 第一篇 tech blog 到現在還在玩 Jenkins（協助資安實作）
- 【建議系統架構的 AWS EFS 解法】iCHEF 的台灣發票加值中心資格與系統擴張力再戰 n 年，也很感謝 PO 與 SRE 的團隊合作與執行力 ☁️
- 【升級 AWS RDS MySQL】⚡️整個可以另外寫一篇 blog，敬請期待
- 【升級 Python 版本的準備】處理了卡住 Python 升版的套件
- 【處理資安通報】來自各方的社交工程可以當作無所不在 🕵️
- 【第三方廠商合約討論】在前進的路上，大家也都是要賺錢的 💰🪽
- 【協助䇿略規劃】參與並反饋資料團隊的策略討論 🎯
- 【協助 24 年團隊規劃】䷤
- 【去 PyCon AU（澳洲）與 PyCon Taiwan 給了 Talk】🇦🇺 🇹🇼
- 【三場 Taipei.py】沒想到年終還是（被 Kelly 大大）催生了十二月的 台北 Python 使用者群組聚會（總是歡迎來玩）🀃
還是無法寫下一切的一切，就附張例行工作的截圖……總括：還活著😅。雖然打了馬賽克，不過可以想像一些常見的事項如例行的團隊成員 Mentorship 1-on-1，績效委員會、Team Lead 會議、營運會議等等。
而今年的職等變動，也讓我想到老說法，勝任 Senior 的時候就比較能認知到什麼比較不 Senior，勝任 Lead 的時候比較能認知到什麼比較不 Lead。想到當初畢業後不久就拿到 Lead Developer 的 title，其實離 Lead 的作為還很遠。過去也看到一些因為薪資或公司留人所給予的 title，不論是自己或別人拿到，一旦在意了，反而容易讓自己受傷而影響了表現，想通這點後自己就比較容易保持平靜；但要求別人假裝不在意、與自己無關好像又太強身為人類所難（苦笑）。
在公司這樣的組織裡，也往往不自覺地只顧自己方便，拿自己擅長的事來對比別人不擅長的事 ……公司存在的目的，就是讓形形色色的人們聚集到一處，合力完成無法靠個人力量實現的遠大目標
— 《岩田聰如是說：從天才程式設計師到遊戲公司社長，任天堂中興之主傳奇的一生》第二章．岩田先生的領導力．我們擅長做什麼
【警示：這段提到一些可能令人不舒服的負面角度 😈】常看到關於 Lead 職等的正向建議，這裡換個角度來寫一下偶發的反成長的心態。難以理解的商業邏輯沒寫 comment、不留文件、不寫測試、Code Dirty、常見的營運事務處理不留解法、文人相輕地說「我做的才好才有用，你做的才爛才沒用」、別人完成了開創性的作為後、別人先幫忙了之後才發現那樣有 credit，再來嘴炮說那我來幫忙可以做得更好，以及程式語言之間鄙視鏈的笑話，也許會讓原來的各種目的地愈來愈遠。
最後來回應開頭與標題：在陪打寶可夢卡牌時的觀察，玩到一半時所下的大決策大動作，很少單靠「憑感覺」，通常是非常認真在思索著「接下來可以如何如何」然後獲勝。今年的 1-on-1 也常常彼此鼓勵，有困難的地方常常也是可能拿到 credit 之處。期待下一個挑戰的年度與機會，希望自己能幫上更多忙，正向的刺激與反應可以多一點，負向的刺激與反應再少一點，多戰勝一點大家常見的最大敵人：自己，並持續為 POS 產業、資訊產業與軟體工程貢獻所能。
又不免不俗地地附上書單：
- 《經理人之道：技術領袖航向成長與改變的參考指南 (The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change)》
iCHEF 內有辦過讀書會，推薦給開發者要進入管理領域（例如 Lead、Tech Lead、Team Lead、Principle、CTO）的好書 - 《溫伯格的軟體工程學》一至四冊，因為巨量可以不用讀完，可以試著用主題閱讀的方式，挑與自己近期有關的部份進行
- 想更深入探索軟體工程專案的估時的話，除了古早的《人月神話》、中期的《Code Complete (2ed)》（例如說 coding 常只佔專案 20% 的時間），最近幾年有《Software Estimation Without Guessing》與中文的《軟體專案估算》看來也可以翻翻
- 《成長心態：面對逆境的突破挑戰與自我實現 Choose Growth: A Workbook for Transcending Trauma, Fear, and Self-Doubt》
有點像：什麼都有可能從中學習與成長 vs 三人行必無我師 🧑🏫
