在 Day 7, 我討論如何調配 Data Team 內的成員以及開局。接著在 Day 8 跟 https://ithelp.ithome.com.tw/articles/10325616 描述我理想中的 Data Team。接著本篇我想討論 Data Team 該如何組織,在公司內才能有效地發揮。
可能第一個想到的問題會是這個,Data Team 應該要採用中央集權或地方分權呢?推薦一篇超級完整的文章,作者介紹 Data Team 如何因應公司不同階段調整多種模式 How should our company structure our data team? 👍
我回想一開始我的公司是如何架構 Data Team 的,中央集權的方式最符合當時狀況,然而接下來 Data Team 想更深入理解不同產品時,地方分權是個不錯做法,以下是我自己經歷或者有聽說過的模式:
對資料有重要需求的團隊有專屬的 Data 支援 Embedded in Important Teams
Data Team 採地方分權 Embedded Data Team
當要建立 Data Team 的時候,第一步是要架構 Data Pipeline. 所以大部分的 Data Team 都是從中央集權開始,因為資源有限,且人數也不會一下子就很多,在新創公司通常都是一人 Data Team,既然才一人也沒什麼好考慮其他模式 😆。
但當基礎建設做完,Data Team 應該要想好自身的願景跟任務。希望如何被衡量價值 (Day 9 提到)?想如何跟其他團隊合作?到底中央集權或地方分權,Data Team 應該有自己的想法,不見得是等組織調整。
沒有任何模式是完美的 😂。 每個模式都有企圖想解決的問題,以及對應要處理的挑戰。沒有一個模式可以永遠持續。 天下合久必分、分久必合。當一個模式解決了公司當時的挑戰,進到下個階段,挑戰又不一樣。
如果你有很複雜的 data stack, 可能就需要 DE 團隊來維運。如果你處理很機密或需要很嚴謹的資料,例如上市公司,那可能需要中央集權方便控管資料品質,或者好多分散的 Data Team 蒐集及處理資料源。如果你需要商業單位快速的做決策,或者希望迅速取得資料,地方分權就比較適合。
Tech savvy vs Business savvy
但你應該要知道,為什麼調整架構,為什麼現在是這樣,遇到什麼問題但也解決哪些問題。
當你加入一個 Data Team, 觀察它是如何演化到現在的組織。為什麼你的 Team 是這樣架構的?對公司或 Data Team 帶來哪些好處跟壞處?什麼時候壞處多過好處,就是再次思考架構的時候。
已經討論 3 篇有關 Data Team 的組成、架構,接下來想討論如何讓資料在你的公司發揮價值。下篇文章,我想開始談如何提升資料素養 data literacy。
對 dbt 或 data 有興趣 👋?歡迎加入 dbt community 到 #local-taipei 找我們,也有實體 Meetup 請到 dbt Taipei Meetup 報名參加