前言

這兩篇主要會談談「資料規格書」，以及筆者自己執行過資料專案的一些經驗分享。雖然筆者在團隊內的角色是資料工程師，但本文並不會深入討論技術細節，而是專注於專案執行與跨部門協作的關鍵。

在筆者所參與過的資料專案中，選擇使用哪個雲端倉儲平台（Data Warehouse）、資料庫系統、ETL/ELT 管線技術、架構抑或程式語言，其實並不是最棘手的部分。真正的挑戰往往在於如何與非技術單位順利溝通，而這正是資料專案成功與否的關鍵。

首先，就讓我們來聊聊什麼是「資料規格書」。

為什麼資料專案必須要有資料規格書？

資料規格書就像建築的設計藍圖，它定義了：

• 資料來源：來自哪些業務系統（Core Banking、交易系統、CRM 等）。
• 欄位定義：每個欄位的型態、格式、允許值範圍。
• 轉換邏輯：清洗、標準化、遮罩或聚合等處理方式。

與其他專案的規格文件不同，資料規格書的獨特之處在於：資料處理邏輯往往就等於業務邏輯。換句話說，它不僅是工程師的參考文件，更是業務單位可以理解、甚至必須參與的協作工具。因此，資料規格書必須要能夠同時被業務單位理解，也要作為工程師在開發管線時的規格依據。

從金融業防洗錢專案談起

幾年前，筆者曾參與某金融業的防制洗錢（AML, Anti-Money Laundering）模型專案。我的任務是負責資料管線的開發，需求是將銀行現有的交易資料，透過一連串轉換處理，產出模型訓練所需的數百個特徵欄位（Features）。

然而，在專案初期的溝通卻不太順利。原因有兩個：

1. 擁有業務邏輯的單位並非專案直接對口，使得資訊傳遞常常延遲或失真。
2. 客戶對資料專案缺乏概念，並不清楚「資料規格書」應該具備哪些要素，也不知道如何協作產出。

於是，當時的做法是：客戶直接將完整的 資料庫 schema（資料結構定義） 丟給我們，由工程師自行比對並推測欄位對應，再把可能的轉換邏輯整理成 excel 表單，於每週兩次的同步會議逐一確認。

這樣的流程不僅耗費團隊大量的時間，也非常沒有效率。每一次會議，大家都像在「拼拼圖」：我們猜測邏輯、客戶再來修正，進度因此拖延，資料規格書的完成度也一度岌岌可危。