iT邦幫忙

2021 iThome 鐵人賽

DAY 20
0
AI & Data

資料產品開發與專案管理系列 第 20

[Day 20] 資料產品與 DataOps 價值

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

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

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

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

https://ithelp.ithome.com.tw/upload/images/20210920/201411404LnwtfgE7V.png

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

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

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

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

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

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

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

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

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

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

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

References

https://dataopsmanifesto.org/en/


上一篇
[Day 19] 資料產品的管理-資料治理初探
下一篇
[Day 21] 資料產品與 DataOps 原則
系列文
資料產品開發與專案管理30

尚未有邦友留言

立即登入留言