在 Day 7 我提到如何建構 Data team. 今天我想再深入說明我理想中的 data team.
剛成立 Data team 的時候，除了要釐清這個 Team 的目的、各自的守備範圍，討論如何協作也很重要。就像產品開發流程 PDP 一樣，是應該要制定一套規矩。雖然跟產品團隊開發產品或功能不同，但 Data team 開發的 data models, dashboards 也可以說是我們提供的 Data Products 資料產品。
雖然經常會有單次性的資料需求，但我們不只希望產出一次性的報表。資料分析師 DA 應該要跟 stakeholders 需求方多討論，理解他提出需求背後的理由、想解決的問題或想達成的理想，這其實就是 discovery 階段。接下來 DA 釐清之後，再產出可解決問題的 data product, 不一定完全依照需求方開的解法，但可以或甚至更好的解決問題。
不會只是依照需求開的 X 欄位就直接提供，我們會挖深一點，好奇的問：你為什麼需要這個資料？你想參考這些資料來做什麼決定？或這些資料可以回答你什麼問題？這些提問是為了更完整理解對方遇到的挑戰，去釐清問題，而不是一開始就跳入如何提供報表，要哪些欄位。
推薦 🔖 Benn's Thoughts on Production 好文值得一讀。
要考慮每個成員的專長：
一個有技術背景的 DA 會比較擅長思考資料架構，通常 SQL 能力也好，因此非常適合做 Delivery。反過來，如果是商業背景的 DA 可能會對商業問題比較熟悉，較容易同理需求方，因此就很適合做 Discovery.
持續學習跟提供學習環境、資源是很重要的。我們有提供 problem-solving workshops, brainstorming sessions, 以及每週 retrospectives 來練習。
Numerous problem-solving frameworks exist, 類似 8 Steps to Problem-Solving from McKinsey. 總之，不管你找哪個 framework, 不約而同都會告訴你，解決問題最重要是，不要一開始就跳下進去解法，先把問題弄清楚。
要讓資料使用者、需求方知道，我們不只是提供報表而已。
通常，資料使用者其實是想回答問題或者尋求洞察。他們對自己遇到的困難是清楚的，但只是給資料或拿到報表不一定是最好的解法，讓 data team 跟需求方討論、協作，結合兩邊的專業，通常可以有更好的解法。
🤜 Discover how others achieve this 這邊有個釐清需求的方法
我承認是滿理想的，我也還在努力中。可能因為我是 PM 而有這樣的理想，跟我理想中的 Product Team 一樣。但這樣理想的 Product Team 是存在的，雖然少數，但其實一直有大師們在推廣、提供方法以及很多人一起努力設法實踐中，這樣理想的團隊除了讓多數人都想加入，也證實確實有更好的產品。接下來的文章，我會把實踐中發現可行 👍 與不可行 👎 跟大家分享。
分享其他資料人也有類似的理想
分享我剛提到的 Product 大師
對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
iThome鐵人賽
看影片追技術