資料專案非 IT 專案

這段話現在是我的信件簽名檔。

2015 年炬識成立的時候以大數據為主題，當時我在業界已經累積十幾年的經驗，而且選擇我熟悉的金融業作為主要目標客戶群。我預期即使在技術面會有很多要挑戰，專案經驗上也應該是駕輕就熟。結果我錯了，錯得離譜。

我們依據之前做 IT 專案的流程與經驗就這麼做了幾年，不是很順利，我就持續強化專案流程與各項標準，結果團隊的痛苦指數不減反增。在梳理與分析累積數年的專案經驗後，我最後發現

「資料專案」與「IT 專案」是不同型態的專案。

只是客戶起專案的時候，經常會合併「資料專案」與「IT 專案」一起執行，造成了錯覺。包含當年的我在內，都以為「資料專案」是「IT 專案」的一種類型。

資料專案在團隊組成上的特殊性

其實，2018 年左右國外開始提出 Data Scientist Team Leader 職稱為 Product Manager 時，已經提示了差異。資料專案在團隊組成、專案流程與交付項目上，都與 IT 專案有不同之處。

圖片來源：筆者於 2019 年根據國外文獻自行繪製。

近幾年資料團隊架構的討論，為了應對 Domain 間的隔閡，開始出現非傳統階層式架構。

圖片來源：https://mikkeldengsoe.substack.com/p/data-team-structure-embedded-or-centralised

資料專案在專案流程上的特殊性

我們在 IT 專案應依據專案範疇明確或不明確，應選擇不同的專案方法，才能提高專案成功率。但是，資料專案幾乎不存在選擇 waterfall 的機會。因為資料專案是開發「資料產品」以提純「資料價值」，尤其是當專案範圍還包含對接資料使用者時，初期目標經常是不明確的。例如：

1. 資料規格定義模擬兩可，根本無法鎖定資料來源在哪裡
2. 資料規格定義很明確，但是想不出來有資料可以對應
3. 資料規格定義很明確，也知道有對應資料，但是出現的結果不合理：資料管線開發經常會有 3~4 層的資料處理，如果最終供應給資料使用者的「資料產品」是企業內不曾存在的「新資料」，多半要真的把資料推完後，才會知道「有用」還是「沒用」，這也是上篇提到的 Data Validation。

圖片來源：https://www.verticalmotion.ca/how-agile-keeps-projects-on-track-on-time-on-budget/

資料專案在本質上更靠近產品研發，需要引用敏捷方法與各種 Ops。

資料專案在交付上的特殊性

幾年前讓我們團隊最痛苦的地方，莫過於專案時程，所有客戶都認為程式開發完畢，驗證完成程式本身，專案就應該差不多要尾聲了，結果反而是混亂的開始。

圖片來源：筆者自行繪製。

IT 專案的資料只需要少量拿來測試，把資料專案當作 IT 專案，會導致工作項目短少，例如：

1. 取得來源資料：很多客戶都會要求我們在沒有資料的狀況下就開始開發程式，真的哭笑不得。少量測試資料對於資料專案沒有太大幫助，機器學習模型用訓練資料不到位，根本無法往下走。
2. 資料(產品)規格：並非資料管線的軟體功能，描述起來幾乎都是商業邏輯，例如提前還款計算基準日。為什麼要計較資料規格與軟體功能規格呢？因為不區分會導致利害關係人判斷錯誤，溝通疏漏，導致交付價值低落。
3. 資料(產品)驗證計畫：誰能決定新造出來的資料(產品)的資料關聯一致性、內容正確性。很多資料專案都是上線後，等業務單位看到資料才說某個結果很奇怪。

資料專案以取得「資料(原料)」為始，才進入開發，以交付「資料(產品)」為終

我想請所有資料領域的夥伴們，一起大聲疾呼！資料專案非 IT 專案！
Do the right thing，Do the thing right!

[追申]
就在寫這篇文章時，政府發布《資訊服務採購作業指引》，想解決過去資服採購常發生機關與業者彼此需求認知不同、費用不足及爭議處理欠缺專業等紛爭，讓政府與業者轉變為合作夥伴，立意甚佳。這次修正看來是著眼於總價合約，釐清甲乙方的各自義務。希望政府能注意到價值取向的資服專案，需引用敏捷方法時不應該走總價合約，應改用工料合約，兼顧效率與成本控制。
400億政府資訊服務採購變革關鍵，新版資服採購作業指引出爐