1. 角色定位 (Role Positioning)
您是 H2U 的技術守門員。您直接對公司CTO 匯報,負責讓產品在技術細節上做對、做好、持續進化。您需要貢獻您的專長在技術選型,工程品質,產品的技術債和識別創新機會。初期您會高度 hands-on——自己 review code、自己做架構決策、自己解最難的問題。隨著團隊成熟和您建立的工程文化落地,逐步把重心移往技術管理和人才培養。
2. 團隊結構 (Team Structure)
CTO 下設兩條獨立的技術線:
本職位(Product Tech Lead) — 帶領 5+ 位工程師,專注將 eXamine、eXpert、pano 三個 SaaS 產品做完、做好、持續迭代。擁有保護產品 Roadmap 的權力——Enterprise 專案要借人或改動主線程式碼,需經 CTO 核可,由您提供影響評估。
SA Delivery Lead(已規劃 / 另行招募) — 負責 Enterprise 客戶案件全程(售前→交付→驗收)。交付過程中發現的產品缺口,會走正式流程提交給您評估排程。
兩條線的互動模式:
SA 在客戶端發現產品功能缺口或部署障礙 → 提交正式的 Product Change Request您評估技術影響和工作量 → 決定排入 roadmap 的優先序(或說明為什麼不做)需要借調您的工程師去支援 enterprise 交付時 → CTO 決策,您提供產能影響評估您的團隊不直接面對客戶,但您需要理解客戶場景才能做出正確的技術決策
3. 公司與產品背景
公司:H2U 永悅健康,台灣數位健康第一品牌,2025 年獲英國金融時報全球五百大高速成長企業。您主要負責的企業面向產品:H2U eXpert:企業職場健康照護系統,服務超過 400 間企業。目前運行在較舊的技術棧上(包含 JDK 8 和 AngularJS 等 legacy 元件),已規劃進行系統現代化——涵蓋 JDK 升級(8→21)、前後端分離架構改造、以及前端框架的現代化重寫。這不是一次性的「升版」,而是在持續服務 200 萬用戶的同時,逐步完成的架構轉型工程H2U pano:AI 驅動的個人健康管理平台,串聯健檢前中後全流程。公司的策略重心,仍在積極開發中。現況:eXpert 與 pano 為 Cloud-Native SaaS 架構,但部分功能仍在開發中,尚未達到完整產品狀態。公司同時在推動 on-prem 部署能力(由 SA/Delivery Lead 負責客戶端),產品端需要逐步提升「雲地皆可部署」的模組化程度。公司其他產品線(不在您的直接守備範圍,但需了解生態系全貌):早安健康(健康媒體)、運動筆記(運動社群)。4. 主要職責 (Key Responsibilities)
A. 技術選型與架構決策
主導技術選型決策——框架、語言、資料庫、基礎設施、第三方服務的選擇與演進,對 CTO 負責。制定跨產品的技術標準與共用元件策略,避免三個產品各自為政、重複造輪子。評估並引入新技術時,以「解決實際痛點」為標準,不追新、不為技術而技術。主導重大架構決策(如:微服務拆分、資料庫選型、快取策略、API 設計規範),產出 Architecture Decision Record(ADR)留下決策脈絡。規劃產品的「雲地可部署性」技術路線——configuration externalization、環境無關的 build pipeline、離線授權機制等,配合公司 on-prem 策略。
B. 工程品質把關
建立並落實程式碼品質標準:code review 流程、coding convention、測試覆蓋率目標。設計並推動測試策略——單元測試、整合測試、E2E 測試的分層配置,確保每一層都有合理的投資。建立 CI/CD pipeline,確保每次部署都是可靠的、可回滾的。導入工程品質的可視化:build 成功率、測試覆蓋率、bug 趨勢、技術債追蹤。讓品質有數據、不靠感覺。親自 review 關鍵模組的程式碼,尤其是涉及資料安全、效能瓶頸、架構變更的部分。處理 production incident 時擔任技術指揮,事後主導 post-mortem 並推動改善。
C. 從一線反饋推動產品技術革新
建立「一線反饋 → 技術改善」的正式通道:客服 / 業務回報的使用者痛點SA/Delivery Lead 在客戶端發現的產品缺口工程團隊自己發現的技術債和效能問題使用數據(監控、分析)揭示的隱性問題將這些反饋分類、排序,轉化為具體的技術改善項目,排入產品 roadmap。與產品經理(PM)協作,確保技術驅動的改善和功能需求之間有合理的資源分配。主動識別「不是使用者會反映、但技術上必須處理」的問題——效能退化、安全漏洞、架構瓶頸、即將到期的依賴套件。定期(每季或每半年)產出技術健康度報告,讓 CTO 掌握產品的技術狀態。
D. 產品完善與交付
推動三個產品(特別是 pano)走向功能完整。與 PM 對齊 roadmap,確保工程團隊的產出和業務目標一致。管理 sprint 節奏和工程產出品質,確保每個 sprint 交付的是「可用的功能」,不是「寫完但沒測的 code」。處理跨產品的技術依賴——當 eXamine 的改動會影響 pano 時,確保有人在看全局。當 SA/Delivery Lead 提交 Product Change Request 時,評估技術影響和工作量,決定排程或提出替代方案。
E. 與 Enterprise 案件的跨線協作
這一塊是您的職責中最需要紀律的部分。 您的排程決策會直接影響客戶合約能不能履行。
Product Dependency Request 回覆:
當 SA 提交 Product Dependency Request(「客戶需要 X 功能,預計何時可以 release?」),您需要在約定的時間內回覆明確結論——可以排、什麼時候排、或者為什麼不排。SA 在等您的回覆才能完成 deal assessment 並提交 CTO 做 go/no-go 決策,延遲回覆等於卡住整個 enterprise pipeline。
Release 承諾的合約連帶責任:
當您確認某個功能的 release 日期後,SA 可能會將該日期寫進客戶合約作為 milestone 依賴。這意味著您的排程決策不只是內部的優先序調整——它會變成合約承諾。您需要意識到這個連帶影響,在給出 release 日期時留有合理 buffer,並在出現延遲風險時立即預警 SA 和 CTO,而不是等到 miss 了才說。
Enterprise 案件的 Critical Bug 處理:
SA 在客戶端部署或 UAT 過程中發現的 product bug,如果會影響客戶驗收或合約 milestone,需要有快速處理通道,不能等一般 sprint 排程。與 CTO 和 SA 共同定義「enterprise critical bug」的分級標準和回應時間承諾。
定期跨線同步:
每週參與與 SA 的 Pipeline Sync(30 分鐘):同步 product release 狀態、回覆新的 Dependency Request、預警可能延遲的功能。每月參與 CTO 主持的 Commitment Review:檢視所有進行中 enterprise 案件的 product 依賴狀態,校準資源分配。
F. 團隊建設與工程文化
帶領 5+ 位工程師,初期以技術指導為主(code review、pair programming、設計討論),後期逐步加入人員管理(1:1、績效、招募、career development)。建立工程團隊的文化基調:技術決策透明(用 ADR 而非口頭)、鼓勵提問和挑戰、容許失敗但要求 post-mortem、重視可維護性而非炫技。識別團隊的技術能力缺口,制定培訓計畫或招募計畫。建立 on-call 和 incident response 機制。
7 years of experience required