數據職涯
導覽

這張約 4 分鐘。不要念職稱。用「一句需求怎麼被拆開」讓大家知道 Engineering Lead 的工作同時包含技術判斷、協作與交付，不會只停在管理或寫一條更大的 Pipeline。

顧問情境常需要在不完整資訊下先建立假設，再用問題、資料與小型驗證把假設修正。技術能力很重要；如果無法說明取捨，方案就很難落地。

這張約 5 分鐘。先讓大家知道我現在的角色、工作焦點、教學背景與學經歷，再用右側過往經歷讓大家看見這些能力是怎麼一路累積。

職涯路徑不要講成升職階梯，而是問題範圍逐步變大：從問題拆解、資料處理、資料流程與上線交付，走到平台架構與技術決策。詳細的五階段個人故事與心路轉折先留在後段職涯章慢慢聊，這裡先帶大家看懂工作全貌，轉入下一章的資料價值鏈。

這張約 5 分鐘。先帶大家從左到右看完整條資料路徑：一個 dashboard 上的數字，不是從畫面上突然出現，而是從真實世界的事件開始，經過來源系統、資料平台，最後才進到分析與決策。

再補充各段工作的差異：資料工程在中間承擔的是把來源的混亂整理成下游可依賴的介面；分析與模型則把資料整理成能回答問題的指標、比較和證據。這兩種工作不是分開的兩條路，而是在同一條路徑上接力。

最後收在下方三個價值：公司真正需要的不是某一個特定平台，而是把資料做得更快、更穩，讓人敢拿來做決策。可以問大家：如果你看見一個 dashboard，會想往左追問哪一段？

這張約 5 分鐘。這頁不是要說「資料變多，所以需要資料工程師」這麼簡單。真正的變化是：資料開始進入每天的營運流程，一次錯誤會沿著下游傳出去。

可以依序講四個痛點：流程需要每天穩定跑；不同部門對同一個指標有不同定義；資料量放大後，速度、回補與成本都變成工程問題；AI 讓答案產生得更快，也讓錯誤定義與過期資料更快被放大。

收尾時強調：資料職位增加，不是因為工具名稱變多，而是資料已經會影響庫存、行銷、風控與客戶服務。

這張約 6 分鐘。DA 會問期間、回補與去重規則；DS 會問特徵是否可用、歷史資料與品質是否足夠；DE 則看影響範圍、監控與如何恢復。

三個角色名稱中英對照：DA（Data Analyst 資料分析師）、DS（Data Scientist 資料科學家）、DE（Data Engineer 資料工程師）。DA 側重定義與洞察，DS 側重假設與預測證據，DE 側重管線穩定、資料契約與可追溯重跑。不同公司會有不同邊界與重疊；特別在小團隊，一人可能包辦從資料管線到報表分析。

引導學生思考：不需要急著幫自己貼標籤，而是看自己願意長期面對哪類挫折與挑戰——是面對模糊需求並勇敢下定義（DA）、是在不確定中接受假設可能被推翻（DS），還是反覆處理管線失效、重跑回補與底層維運（DE）。接下來用會員流失情境，看這些問題如何在同一個團隊裡接起來。

這張約 6 分鐘。用會員流失案例把三種工作接起來。DA 的定義會影響 DS 的標籤，DS 的需求會影響 DE 的資料契約；業務的決策成本則會反過來決定要不要做模型。

三個底部詞是交付前的最低共識：先把問題定義清楚，再確認資料與結果的限制，最後留下更新頻率、owner、失效訊號與回補方式。合作不是把工作切開，而是讓下一個人不用重新猜前面發生了什麼。

這張約 6 分鐘。這頁把 DE 的日常和架構判斷放在一起。很多時間花在上游欄位變更、資料延遲、回補、告警與下游定義不一致，不只是寫 Pipeline。

Batch、Micro-batch、Streaming 都是選項，不是職稱或能力高低。即時需求要由業務決策時點、延遲損失、重放需求、團隊維運能力與成本推導。最後收在四個交付物：資料契約、能重跑的 Pipeline、品質與血緣、文件與告警。

這張約 6 分鐘。這一頁融合了我從數學系一路走到架構工作的五個階段與心路轉折，不要把履歷逐段念過去，而是聚焦「當時遇到的問題變了什麼」與「責任如何擴張」。

那時我還不知道資料工程師這個職位，只知道自己想參與資料處理，讓結果更快出來。

進入資料導向的新創公司後，雖然掛名後端工程師，但主要接觸大數據運算框架。那時我確定了自己真正熱愛的動機：看著資料順暢流過系統，並把極大資料量在短時間內可靠處理完畢，帶來最直接的成就感。隨後正式在企業級規模以資料工程師身份面對海量處理與穩定交付。

後來，我更在意資料治理、資料定義與長期使用，逐步參與跨團隊架構設計，走到現在的 Engineering Lead 工作。

這張約 5 分鐘。這是職涯故事的核心。「升級」的感覺，來自負責的範圍一路擴大：流程、系統、團隊與決策都要看。

這張約 6 分鐘。可以用金融場景的高限制環境作為背景，但不必講公司或內部架構。重點是「標準化入口」：來源不同、限制不同，仍需要一致的落地、驗證、重試與紀錄。

這也是工程責任和資料責任的交集：DE 建路徑，DA／DS 必須知道這條路徑的延遲、範圍與限制。

這張約 6 分鐘。履歷中有 MapReduce 到 Spark 的重構經驗，但公開分享時可以不先放改善百分比，除非確認可公開。把重點放在診斷順序：量測、理解資料、改造、驗證。

這個案例可以連到數學與系統思維：演算法、資料結構、分區與執行模型會直接影響效能，不能只靠換一個產品名稱。前面談到的資料正確性、成本與失敗處理，也需要用來檢查 AI 產生的方案。接下來看看 AI 會加快哪些工作，以及我們還要做哪些判斷。

這張約 5 分鐘。承認 AI 會提高個人產出，避免用「AI 不會取代人」這種空泛句子帶過。產出速度提高後，驗證、脈絡與責任會更重要。

這張約 5 分鐘。給學生具體路徑：底層、脈絡、證據、判斷。可以示範讓 AI 產生一段 SQL，但接著問資料定義、NULL、重複、時區與效能，讓大家看到審查比生成更關鍵。

這張約 4 分鐘。這張不給無限長的學習清單。作品的價值在於可被追問：來源、假設、流程、錯誤與取捨都留下來，面試時才有可以深入討論的證據。