會議通知已經寫清楚：「本會議將討論模型訓練所需之資料需求，請參考附件會議相關資料，邀請相關單位參加。」

會議一開始，PM問：「我們先確認會議資料中的提到的 Table 的窗口，請問 Table A 的議題我要請教誰呢？」

現場有人回：「資料是在信貸部門，但哪個系統或欄位比較關鍵我不太確定是哪個部門負責。」

PM問：「請問信貸部門今天有代表參加會議嗎？」

一陣沈默….

🏗 為什麼資料專案會議總是人數眾多？

在資料專案中，所需資訊往往橫跨多個部門：交易系統、風控資料、業務操作紀錄、法遵規範、資安限制……每個部門掌握的資料片段都是不可或缺的。資料專案的本質，就是一場跨越部門邊界的大工程。

以前面的例子，某專案需要產出資料提供給模型做訓練，可能會牽涉（包含但不限於）

• 交易系統：業務發生的時間、地點與金額。
• 風控資料：過往的風險評級、延滯紀錄等。
• 法遵規範：哪些資料可以揭露、哪些需要加密。
• 資安限制：資料傳輸與儲存的技術規範。

💥 需求處理方的盲點與需求單位的內部複雜性

作為需求處理方，他們能清楚描述「需要什麼資料」，例如：用戶的年齡、信用分數、近六個月的交易筆數。

然而，無法完全掌握需求單位內部複雜的資訊分工：

• 「用戶年齡」可能來自 A 系統，由行銷部門負責維護。
• 「信用分數」則儲存在 B 資料庫，歸風控部門管轄。
• 「交易筆數」是從 C 系統的交易部門那邊撈取，且需要經過資料治理部門的特殊處理。

會議附件雖然寫清楚了 Table 名稱，但需求處理方並不知道這些 Table 實際對應到需求單位內哪一位「窗口」或「負責人」。

而專案成功的關鍵就在於，需求單位必須找到對應的窗口來參與會議，才能讓需求處理方順利取得正確資料，但這並不是一件容易的事！

🧠 資料專案的「超前部署」

當需求單位內部無法在第一時間確定哪個部門或哪位同事是最精準的資料提供者時，這就形成了一個困境：

• 如果漏邀了關鍵人物，會議將浪費時間，討論無法推進。
• 如果只邀了「猜測可能相關」的人，現場一旦遇到知識斷層，就會出現前面提到的「一陣沈默」。

為了避免專案延宕在「尋人」和「補會」的循環中，需求處理方採取的戰略性做法，就是寧可「超邀」也不要「漏邀」。

雖然這會導致會議人數眾多，但這確保了：

• 當我們討論到 A 系統的欄位疑問時，A 系統的專家就在現場；
• 當我們觸及到法規限制時，法遵部門的代表可以立即提供答案。

這不是需求單位內部不清楚，而是資料專案所涵蓋的資訊廣度與複雜度太高，導致所需的知識必須多方匯聚。

「下次看到資料專案會議通知上滿滿的參與名單時，別只覺得人多浪費時間——這是需求處理方為了在一次會議中，迅速而完整地取得跨部門資訊所採取的策略。」