關於如何打造高效的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)
舉例：為解決拿到資料須跨多個單位費時費力，沒辦法跟上BU端需求的節奏，在天下集團Data team我們自己打造自己所需要的Data lake，採取將資料集中與資料應用(精煉 & 呈現)分離的設計，讓Data team可依序應用端需要自主完成code版控、設定自動化排程與建置分析用tables的作業，實踐追求穩定與彈性間的平衡。
事實證明empower Data team使其具備自主性，是之所以可以更快的節奏回應商業需要，且又能不斷scale-up產出的關鍵安排。
然而光僅是技術上的提升並不能解決數據工作面臨的挑戰：現實是BU端的思考往往很淺碟「只要跟Data沾上邊的事」全部都是Data team的事，但真的如此嗎？
這就須意識到數據工作先天具有跨域的性質，因此不同單位間過於破碎化的合作方式(而不是思考如何一起打好群架) 必然會無效率，例子像是 :
- 再怎麼精準的推薦演算都無法彌補 UI/UX用戶體驗不佳的問題，也無法解決因對品牌信任不足造成用戶call-to-action低落的問題
- 數據團隊無法獨自解決數據品質問題：流程不佳必然導致專案品質不佳(像是沒有問對問題、介面不良導致容易填錯資訊)，而專案品質不良所衍伸出來的數據專案與數據品質就不可能會好(像是用多種埋碼去定義同個測量標的，造成後面應用上的混亂)
因此，數據並非萬靈丹，有其能與不能。然而經驗卻告訴我們「萬靈丹思想」充斥在各處。因此數據工作若要能順利，就必須同時引領轉型並改革mindset。
數據工作要能順利，關鍵在有邏輯的貫徹 3個P : Purpose、People、Process
所謂Purpose指的是對準什麼目標? 為何這件事情重要?我們應該要在乎? 從Data team的觀點，我們認為這可以對應到四種不同類型的目標 :
- Growth 協助成長，像是推動Business metric、優化用戶旅程、AAARRR
- Feature 協助迭代、優化既有產品體驗、解決既有用戶的痛點
- Scale-up 確保穩定與規模化，將數據服務的觸角做放大與延伸
- 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)，而議題與球是完全不同的。
最後，People是指要怎麼設定職能與人設才能把事情做好?
我認為比起微管理，更能發揮高效的方法便是相信成員並empower他們可以自主做自己的決定。實務上也證實，最佳的答案往往源自於啟發團隊，而不是告訴他們要做什麼。
因此我認為是Team leader的責任要把3Ps設定好，打造可讓成員發展的空間，且當團隊卡關時，去確定這三件事之間的邏輯與運作是順暢的。
在這個概念下，Team leader的角色類似團隊的「總工程師」：如果說若工程師處理的是給電腦讀的程式代碼，那麼leader處理的是由人構成的系統，而 3Ps 定義了leader的程式語言。
因為數據工作帶有跨域的本質，是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為例，透過過往諸多的數據專案的經驗，我們歸納出幾個常見的分析套路，像是 :
- 從閱覽特定文章主題的受眾出發，去找會看的下一個文章主題是什麼?
- 從閱覽特定文章主題的受眾出發，去找他們最可能會買什麼產品?
- 從已經購買特定產品的受眾出發，去找他們下一個可能買的產品是什麼?
實證結果證實，超過半數以上的分析情境幾乎可以用上述套路以某種排列組合得到，因此打造一個可供內容、行銷、會員運營人員可以 self-service的工具就成為可能。
一些曾啟發我們的參考材料，或許對你也會有幫助
- Julie, Z. (2019)The Making of a Manager: What to Do When Everyone Looks to You.
- Colin, B. & Bill, C. (2021) Working Backwards: Insights, Stories, and Secrets from Inside Amazon.
- Kim S. (2019) Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity.
- Brian B. (2014) The First Step To Building A Growth Machine. https://brianbalfour.com/essays/growth-process-first-tactics-second
- Adam F. & Keya P. The Growing Specialization of Product Management. https://www.reforge.com/blog/product-specializations