關於如何打造高效的Data Team

學習與試誤,並試圖從不可能的地方長出可能

(原文於 天下雜誌|數位科技 Blog 刊登)

在天下雜誌群數位創新部 數據中心 (簡稱天下集團Data team),我們不斷在思考一個命題 : 要如何在一個過去僅聚焦在華文市場且有著40年歷史的傳產媒體裡,打造出一支現代化高效的數據團隊?

這篇文紀錄我在這一路上實驗出來的框架與心得,並提供一個overview。

若你是數據從業者(Data analyst、Data scientist、Data PM)想發展自己的職涯、打造自己的數據團隊,或許這篇文對你會有幫助。

數據團隊要高效,每位成員最理想的角色定位是 33% PM + 33% IT + 33% Data

不知道你是否曾困擾於數據散落在各部門難以取得? 或sprint的節奏跟不上BU端的速度? 又或者需求端只把你當撈資料與做dashboard的工具人,但其實你是可以提出更好決策建議的?

這些問題的產生是因為角色的設定不佳。

透過實踐發現:數據團隊其實IT單位與業務單位間的隱藏橋樑,是公司數據變現的關鍵。為了能發揮這樣的職能,Data team團隊成員就必須以三個三分之一來設定自己:即 33%的PM + 33%的IT + 33%的Data。

具體而言,統計建模等數據分析工作僅佔日常的33%,更多的是如何把既有的研究成果scale-up成可維運迭代的Data pipeline (33% IT),以及收斂聚焦跟溝通高價值命題的能力 (33% PM)

Data team是IT與Business Unit間的橋樑:左手解構需求、右手整合生產系統,是透過研發與prototyping將數據變現的核心角色

舉例:為解決拿到資料須跨多個單位費時費力,沒辦法跟上BU端需求的節奏,在天下集團Data team我們自己打造自己所需要的Data lake,採取將資料集中與資料應用(精煉 & 呈現)分離的設計,讓Data team可依序應用端需要自主完成code版控、設定自動化排程與建置分析用tables的作業,實踐追求穩定與彈性間的平衡。

事實證明empower Data team使其具備自主性,是之所以可以更快的節奏回應商業需要,且又能不斷scale-up產出的關鍵安排。

「集中-精煉-呈現」三部曲:將散落在公司各處的資料源做集中著重的是穩定傳輸,至於後續pipeline的版控/排程/精練/呈現則需要配合應用端的需要保持彈性與高速迭代

然而光僅是技術上的提升並不能解決數據工作面臨的挑戰:現實是BU端的思考往往很淺碟「只要跟Data沾上邊的事」全部都是Data team的事,但真的如此嗎?

這就須意識到數據工作先天具有跨域的性質,因此不同單位間過於破碎化的合作方式(而不是思考如何一起打好群架) 必然會無效率,例子像是 :

  1. 再怎麼精準的推薦演算都無法彌補 UI/UX用戶體驗不佳的問題,也無法解決因對品牌信任不足造成用戶call-to-action低落的問題
  2. 數據團隊無法獨自解決數據品質問題:流程不佳必然導致專案品質不佳(像是沒有問對問題、介面不良導致容易填錯資訊),而專案品質不良所衍伸出來的數據專案與數據品質就不可能會好(像是用多種埋碼去定義同個測量標的,造成後面應用上的混亂)

因此,數據並非萬靈丹,有其能與不能。然而經驗卻告訴我們「萬靈丹思想」充斥在各處。因此數據工作若要能順利,就必須同時引領轉型並改革mindset。

世界是複雜的,看似萬靈丹的東西,其行銷話術的成分恐怕居多,且往往是不可靠的。真正該聚焦的是去問轉折點的前後做了什麼,這些才是轉折點發生的背後原因。
數據工作要能順利,關鍵在有邏輯的貫徹 3個P : Purpose、People、Process

所謂Purpose指的是對準什麼目標? 為何這件事情重要?我們應該要在乎? 從Data team的觀點,我們認為這可以對應到四種不同類型的目標 :

  1. Growth 協助成長,像是推動Business metric、優化用戶旅程、AAARRR
  2. Feature 協助迭代、優化既有產品體驗、解決既有用戶的痛點
  3. Scale-up 確保穩定與規模化,將數據服務的觸角做放大與延伸
  4. Expansion 既有市場已飽和,找尋新的痛點與新的成長空間,擴張市場

當數據需求能對準這四種目標的任一種,數據團隊就能扮演好數據變現的關鍵職能。反之,若沒辦法對準,則會流於瞎忙。

因此,為了避免虛耗 :

作為Data team,就必須重視並堅持辯證的文化
Henry Ford的名言 : 如果我當年去問顧客他們想要什麼,他們肯定會告訴我:「一匹更快的馬」。 (If I had asked people what they wanted, they would have said faster horses)

在天下集團Data team,我們也觀察到類似的pattern : 需求端會用他對數據的有限想像試圖拼湊出他想要的東西,然後對我們提需求 (一匹更快的馬),即便其實是存在更好的解法 (一台汽車)。

因此我並不認為需求端的request作為Data team就必須照單全收,因為現實是使用者往往說不清楚他到底真正要的是什麼 (更快的移動方式)。

將議題與球做好區分,需求端只能提議題,而球是執行端開給自己的,是目前被認為最高效且合理的傳接球方式 (即Process)

從Data team的觀點,需求端的request姑且只能稱作議題(issue),須經過與數據團隊辯證拆解後才能成為真正可以追蹤與執行的球(ball),而議題與球是完全不同的。

常見的誤區就是需求方把議題當作球,要求執行方照單執行。作為Data team,就需要堅持辯證的必要性以及尊重專業分工,因此確立議題與球分立的做事原則。

最後,People是指要怎麼設定職能與人設才能把事情做好?

我認為比起微管理,更能發揮高效的方法便是相信成員並empower他們可以自主做自己的決定。實務上也證實,最佳的答案往往源自於啟發團隊,而不是告訴他們要做什麼。

因此我認為是Team leader的責任要把3Ps設定好,打造可讓成員發展的空間,且當團隊卡關時,去確定這三件事之間的邏輯與運作是順暢的。

在這個概念下,Team leader的角色類似團隊的「總工程師」:如果說若工程師處理的是給電腦讀的程式代碼,那麼leader處理的是由人構成的系統,而 3Ps 定義了leader的程式語言。

是Leader的責任去定義好3P,而乘載於3P上的專案細節則是成員當責的範圍。這樣的明確分工可以讓成員去充分發揮發展,而不是介入微管理。

因為數據工作帶有跨域的本質,是IT與業務單位間的隱藏橋樑,我認為團隊成員都要具備領導他人的能力。這要跟「管理」做一個區辨:

所謂管理(Management)是一種從外部指派的角色,就像老師、大樓管理員等,而要能把這個角色做好的前提是:必須具備領導的技能,否則無法改變人們的行為。

而所謂領導(Leadership)則是指可以帶領與影響他人的技能本身(即發揮影響力)。與管理不同的是:他無法從外部硬指派,而是必須被贏得,因此任何人都可以培養領導力,無關在什麼職位。

經驗告訴我們:贏得信任最佳的方式就是頻繁的「同步情境與對準目標」(Sync Context & Goal)

這是因為人們往往容易忽略彼此認知的差異,急著直接跳入執行,而這正是很多無效率與衝突的起源。相反的,若我們重心放在傾聽同步情境,縮短認知差距,通常解方與共識會自己跳出來。

在天下集團Data team,我們認為以各種渠道(online/offline)頻繁的同步情境、立即給予建設性的回饋,並以執行力去身體力行,是展現領導力最佳的方式。

打造成長引擎(造鐘),而不是被當作引擎(報時)。
Build a growth engine, not be the engine itself.

呼應前述BU端在思考數據需求時,往往很淺碟的事實 (只要跟Data沾上邊的事,全部都是Data team的事) 其後果就是數據人員容易成為組織成長的 bottleneck,但仔細探究,背後的痛點其實應該是 :

「我們業務單位 is running out of ideas,請數據單位幫我們想點辦法吧」

或許正確的問題應reframe成:

「如何打造一個可以源源不斷產生new ideas的數據引擎?」

以天下集團Data team為例,透過過往諸多的數據專案的經驗,我們歸納出幾個常見的分析套路,像是 :

  1. 從閱覽特定文章主題的受眾出發,去找會看的下一個文章主題是什麼?
  2. 從閱覽特定文章主題的受眾出發,去找他們最可能會買什麼產品?
  3. 從已經購買特定產品的受眾出發,去找他們下一個可能買的產品是什麼?

實證結果證實,超過半數以上的分析情境幾乎可以用上述套路以某種排列組合得到,因此打造一個可供內容、行銷、會員運營人員可以 self-service的工具就成為可能。

一些曾啟發我們的參考材料,或許對你也會有幫助

  1. Julie, Z. (2019)The Making of a Manager: What to Do When Everyone Looks to You.
  2. Colin, B. & Bill, C. (2021) Working Backwards: Insights, Stories, and Secrets from Inside Amazon.
  3. Kim S. (2019) Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity.
  4. Brian B. (2014) The First Step To Building A Growth Machine. https://brianbalfour.com/essays/growth-process-first-tactics-second
  5. Adam F. & Keya P. The Growing Specialization of Product Management. https://www.reforge.com/blog/product-specializations