Business Analyst in Data Team
Intro
為了讓大家可以了解未來的文章是從什麼角度來看資料世界,首先就來介紹一下我在 17 的角色,Business Analyst。由淺入深,下文首先我會介紹一般來說 Data team 會有的各個角色及工作職責,最後進入我的詳細工作內容。
1. Data team 當中的角色有哪些
在資料分析的領域,涵蓋許多相關的角色,Business Analyst (商業分析師)、Data Analyst (資料分析師), Data Scientist (資料科學家), Data Engineer (資料工程師), Algorithm Engineer (演算法工程師), 都還算是常聽到的名字。
然而從來沒有哪個職位是對應負責哪些事項有明確定義,在不同國家、公司、部門,都會有不同的稱呼。同樣都是 Data Analyst,在 A 公司可能負責從 Infra 到 視覺化資料;在 B 公司可能只管 ETL 一件事情。在坊間認真查找,10篇文章對 Data Analyst 有12種定義也不算稀奇。
在邁向資料大師之路,有非常多元的技能樹可以走,所有技能都是相得益彰。好比玩 RPG 遊戲一樣,初期點攻擊,體力就弱一點;點魔力,實戰就弱一點;很會寫 Code,可以建出漂亮乾淨的架構,但是建出來要符合商務需求,還是得靠分析師提供建議;一個很會用 R 的分析師,如果不了解資料基礎架構、資料結構、儲存型態,也沒辦法有效率地產出預測報告。
說到 RPG,不如就讓我用出團戰的比喻來形容我認知中的 Data team 吧!
坦 — Data Engineer
所有出戰時的基礎,團隊缺少這部分的時候,通常大怪都打不贏。初期戰隊常常由其他角色補位(技能樹比較偏的輸出角或是別隊的坦例如Backend),到了中後期,沒有坦的團隊是不會有其他輸出願意加入的。
近距輸出 — Data Analyst
可以近戰,是團隊中的主戰力,小怪來一個解一個(ad-hoc),但怪一多起來,或是多屬性、多方向,殺起來就沒效率。資深的近戰有時會轉兼坦,或是轉強力輸出。
遠距輸出 — Business Analyst
因為 Programming 能力較弱,近戰戰力不佳,但能眼觀八方、預測即將發生的戰事。並且採取長期抗戰,或是預防的方式,針對多屬性、多方向來的怪做有效率的資源分配,讓整場戰事能夠輕鬆取勝。
補師 — Data Scientist
多功能補給戰力。在辦活動的時候,最強的人就會放在「機動支援」,因為他什麼都會。真正厲害的DS,除了能夠按照自己的技能樹補位以上三位的角色,還可以自我產出、創新更適合企業的演算法、分析報告,或是預測模型。
2. Data Science team 架構及 Business Analyst 的角色
世界上 Data team 的架構大概可以分為兩種 (from Miguel Rios, Head of Consumer Data Science | Twitter)
https://www.datacouncil.ai/talks/scaling-data-scienc
- 嵌入式 - data function 實質存在每個 business functions,每個部門如 MKT 會有自己的分析師、甚至架構師。好處是可以非常專注在 domain knowledge,針對專精範圍設計架構以符合需求,且分析師能非常了解執行角色的 daily routine,對症下藥地提供資料輔助。
2. 中心式 - data function 獨立運作,各分析師可以互通有無,讓整間公司可以更全面、有系統性地運作,好處是可以降低資料定義不一致的風險、降低 infrastructure 建置的成本,也可以避免資源錯置、data 工作優先度混淆的問題。
Business Analyst 在第一種 — 嵌入式,通常都是首當其衝被放進 business function 的角色,必須非常了解每一個部門日常的工作是什麼,才能精準地點出該團隊還缺少什麼樣的資料,佐以做出正確快速的決策。除此之外,要能夠幫助公司整體成長,如果是站在高崗上喊話是不夠的,必須深入田野,知道執行單位的挑戰與困難,才是一個好的商業分析師。
在第二種 — 中心式的架構中,商業分析師有時會被放在 “BI” (Business Intelligence) 部門,有時放在 Data 部門。無論是哪一種,最終都還是會面臨一個類似 Data PM 的功用,作為 team 內第一線理解各部門提出問題的角色,並且統整歸納成與工程師合作的語言。除此之外,能夠擁有較大的空間判斷公司方向適合如何整理資料,也作為提供給自己做分析報告、預測模型的良好根基。
Business Analyst in 17
我的工作是在 17 擔任 Business Analyst,所屬在 Data Science and Analytics team — Data Analytics 之下,負責的事項包括:
1. Communicate with business functions
2. Data visualisation; decision tool
3. Data analysis report
4. Data modelling domain knowledge input
在 17,Data team 只有 2 個角色 — Data Engineer & Business Analyst,因此中間有許多模糊地帶,我們會互相幫助、學習,用制定良好的合作 SOP 來解決「這件事不知道應該屬於誰的範疇?」的問題。有點像是下圖 Netflix 在演講中曾經分享過的組織結構下半部分,如果按照上面那一大串的 Data 角色來說,我的工作內容算是 Business Analyst 加上一點點的 Data Analyst。
1. Communicate with business functions 之 來自五湖四海的資料疑難雜症
Business Analyst 密切與每一個部門合作,了解他們執行上的困難、適時給予資料協助,除了使用資料做決策、監測數據、訂定KPI目標及檢討成效,有時候還提供 Excel、Spreadsheet 公式教學、Campaign SOP 架構設計顧問等服務。
這些部門在 17 包括負責 App 產品功能設計的 Product Manager team、負責管理主播疑難雜症大小事的 Streamer team、負責管理高額付費用戶的 VIP team、負責公司品牌/社群操作/廣告的 MKT、負責節目製作的內容團隊 NMC (New Media Content),甚至業務、財務、法務、客服、工程、線上下活動、設計、CEO Office 等各單位,以及各個海外市場的相對應部門。
將商務單位的資料需求釐清後,Business Analyst 會與 Data Engineer 討論出最適合支援商務需求的 Data infrastructure、Data modelling 模式,並且持續檢討優化。最終根據商務部門的原始需求,判斷並視覺化給對方需要 Spreadsheet、Dashboard,或是只需要一條 Statement or 一封 email?
2. Data visualisation; decision tool 資料視覺化
提供給商業營運單位的「資料」,當然不可能是我們平常在處理的資料庫形式,而是一個可識讀的視覺化結果。在 17 最常使用的視覺化工具是 Google Data Studio & Google Spreadsheet。
前者是製作 Dashboard,用來做長期、帶狀性指標監測,資料下載,製作動態互動式分析報告使用;後者則是用來分享一次性資料提供,或是靜態分析報告結案呈現使用。
不論是製作一張 Dashboard,還是分享一個 Spreadsheet 檔案,除了資料正確性需要檢查,Metrics naming、layout / font / color design 都是分析師的課題,好的資料分享,才能讓營運部門減少理解的時間,立即找到決策答案。
3. Data analysis report 分析報告
一個分析問題可以粗到「昨天貼圖賣的好不好?」或是細到「昨天直播主追蹤的人當中是新註冊用戶來追蹤的人多嗎?」
所謂「分析」,其實是「問出一個好問題」,而要「如何解決一個問題」尚且須要更多的其他技能,例如統計知識、演算法、預測模型等等。
Data analysis 的精巧就在於分析師的能力是否: a.知道什麼是值得研究的好問題; b.知道什麼問題應該採用什麼技能來解決;c.知道問題的對象必須如何進行溝通取得 insight、如何分享分析結果最有效。雖然是最抽象的能力,但卻是 Business Analyst 最重要的工作。
4. Data modelling domain knowledge input
最後,我們是 Data Engineer 的謀略師,取得前線戰報後,必須讓 DE 知道如何儲存、處理資料,才能讓商務端的需求能夠順順地被解決,而不需要每一次都回過頭來求 DE 生出客製化的資料模組。
舉例來說,在 17 最重要變現模型就是「打賞」,每一筆「打賞」的詳細資料都必須詳細列出,時間、打賞者、收賞者、打賞項目、打賞點數、收賞者收入點數、等等。但有些次要的項目,或許就不必處理到如此細緻,例如:直播間留言內容,或許對於分析平台熱度、話題有所幫助,但缺少1–2則,並不會強烈影響分析結果,或是營收數字。
根據獲得的情報讓底層架構能夠隨著商務需求彈性變動,能夠釋放工程資源,不管是人力或是資料庫成本,才能將戰力花在刀口上。