資料可以是資產、也可以是負債。

當組織積累了太多無用、甚至錯誤的資料時，資料不但不能提供價值，反而需要花更多力氣與時間去儲存、除錯、整理它，變成了負債。

為了讓資料能更好的被使用、更快產生出價值，一份 DataOps 宣言由此誕生。

透過第一手在組織、工具、以及產業中與資料工作的經驗，我們發現更好的方式來開發以及交付分析成果及分析工具，我們稱這種方式為 DataOps。

承襲了敏捷宣言對軟體業的目標以及影響，DataOps 宣言提出了五個重要的價值：

• 個人與互動重於流程與工具
• 可用的分析重於詳盡的文件
• 與客戶合作重於合約協商
• 實驗、迭代以及回應重於大量的前期設計
• 跨部門的營運所有權（Ownership）重於獨立的責任。

現今的資料產品和軟體開發脫不了關係，前面三則是和敏捷宣言一模一樣，就不再多做解釋，將目標放在後面兩條，這也凸顯了資料產品和一般軟體開發不同之處。

實驗、迭代以及回饋重於大量的前期設計

在做軟體開發時，很少會聽到「實驗」這個字眼，但實驗對於資料產品開發來說是不可缺少的部分。這幾天來一直在說明一個觀念，「資料產品必須由下至上逐層疊起」，這個特性讓上層的資料產品需要更長的開發以及迭代流程，同時資料產品往往又很難模擬，需要靠真實的**「上線」**才有辦法得到真實的反饋，這也是資料產品在開發中的最大風險來源。如果最後發現無法解決問題，也不太能輕易地打掉重練，因為下層的資料產品又會和其他系統牽扯、甚至被其他的資料產品所使用。

這時候「實驗、迭代、取得回饋」就變得更為重要。

理想上希望透過小規模的 POC，在不影響到其他現有產品的情況下，快速打通各層資料產品後，透過 A/B 測試或金絲雀部署上線觀察狀況。透過這樣的過程快速取得使用者反饋，看看是不是少了什麼使用者行為沒有收集到、模型的選用上是不是有更好的做法等等，會比前期設計來得重要的多。

跨部門的營運所有權（Ownership）重於獨立的責任

資料產品比其他軟體更特別的事情就在於跨部門營運了。舉個簡單的例子，如果一個電商公司依據營運功能分成業務、行銷、IT 三個部門好了，IT 會主要負責電商網站的開發和維護，業務跟行銷會跟 IT 提相關的功能需求，業務負責業績、行銷負責讓更多人來使用網站，那在這個分工下問題來了，「資料產品要歸誰管？」

業務和行銷提需求，IT 負責建立網站、設計 Table Schema，使用者透過行銷操作導入到網站，資料被蒐集下來後進入資料倉儲，接著又被行銷和業務拿去做業績報表，網站上還有自動推薦系統。可以看到資料從「需求」開始，就在各個部門、甚至使用者之間穿梭來往，每一層的資料產品也會互相影響，非常不適用傳統一刀切的分工方式。

因此資料產品會比其他業務更講求「跨部門的 Owenership」，亦即在資料產品中牽涉到的人和部門都需要對這個資料產品負責。有些公司會另外成立專職的資料團隊來處理這些資料，實務上資料團隊也需要持續跟各部門保持緊密的合作。

References

https://dataopsmanifesto.org/en/