在電信業做DS的日常- 團隊與自介
近來資料科學家、AI等buzzword喊的震天價響，但實際工作上資料科學(DS)是怎麼運作的，國內實際案例卻較為少見，我以自身在電信業大數據部門兩年的體驗，說明團隊從初步階段到穩定成長，及人員的組成，還有工作上日常運作。
系列大綱：
- 團隊與自我介紹
- 團隊在不同階段的定位
- 經典專案
自我介紹：
首先講講我自己，我的經歷比較特別，相對於我很喜歡的Blog，Brian的半路出家軟體工程師在矽谷，我應該算是半路回家，從理組轉到文組，又跑回理組的工作，不過每次面試時都會被問……
我畢業於應用外語系，類似大學的外文系，在升大三時從電子系轉過去的，在畢業之後當替代役之時，開始思考未來的職涯。文組在台灣的就業環境，相對於工科，初期薪資差距滿大的，所以我就想，文組與理組的複合背景是否有不同的選擇，剛好當時大數據非常熱門，看一下需要程式以及簡報分析結果的溝通力(雖然我很不會做PPT，汗)，數據分析是個好的切入點。
題外話，做數據分析(Data Analytics)相對於工作內容較為確定的，如軟體工程師、Data Engineer，數據分析很多時候需求/spec是相當模糊的，或是演算法工程師，偏向研發、理論推倒、數學等，讀paper有點像學術研究，數據分析更多是面向商業價值(business value)，樞紐分析表、視覺化、模型都只是工具的一種，如果用理工的思維，只想要確實的輸入輸出，像一個API，會非常痛苦，初期要一段時間才能從單向的理工思維，轉為較為多元甚至混亂的現實商業世界，才能創造出data的insight，而在文組的思維上的衝撞，至少讓我在這個初期的痛苦階段，過渡得快一點，但要有複合的思維，在現行的教育體系是比較困難的。
役畢後，就報名了資策會為期半年的Data Engineer 巨量資料分析就業養成班培訓，開啟了Data的旅程，結業後進入了台灣之星，一開始以為是成天跟model、數學、調參與程式搏鬥，沒想到PPT、需求訪談、下SQL、ETL、出報表抑或excel分析才是主軸，model只是其中的一小部分，重要的是insight，工具也不是重點，Notepad++ 用起很快速阿，Excel有更好的相容性與共同語言，有些PM Excel用起來更是快的不要不要的，資料量小真的不一定會贏。（話說就職前我根本不知道vlookup阿，只知道left join，炸
經過前主管Andy提點跟自己的體會，越來越深刻體會，mining/modeling 抑或 SQL, excel的樞紐分析表，都只是找到insight的工具，重點是貢獻出的價值(value)，而不是技術的難度。
團隊介紹：
我們大數據部門比較特別，是建在行銷(marketing)，所以更多是應用(application)導向的，第一線直接面對User，偏向Mining Team，以資料挖掘找出insight或報表自動化，少部分建模調參的工作。
相對於一般IT部門，功能或系統導向，亦或是可能做好一個project，向各單位推銷(傳教)，如果domain不足，就容易有需求不符的問題。
在marketing目前是反過來的，比較像事求人，而不是要去promote一個東西，但應用快速取得成績後，規模逐漸擴大，會產生嚴重的跨部門溝通成本，畢竟系統在不同單位，人員也不同，都會有些障礙。
不過話說回來，前期部門剛成立時，去推銷分析，建立credit的階段也是沒少走，但目前部門已經有了一定的基礎，能處理行銷內部的需求。利用資料探勘(Data Mining)的技術，以SQL處理大量資料或複雜邏輯、視覺化工具(如Tableau)，快速產出insight，協助業務單位解決問題，後續更細緻或複雜分析的大型專案，模型才會出現，主要是受限於資源與時程的配置，先求有再求好。
這裡強調一下，公司的狀況(電信業算大型企業)與團隊建置(在marketing)算是比較不同，特點如下：
- 甲方：決策建議
- 電信業：大量的真實數據，用戶、通話、網路等
- 飽和的產業：進入生命週期的後段，有大量資料用於用戶留存，以及額外的加值服務，新用獲取空間有限
- 足夠的資本：電信業資本額很大，有足夠資源投入研發
所以不一定適合大家，且建構一個data team非常燒錢，要企業的資本夠，上層中長期支持，加上初期能快速提供insight的主管，才有足夠的空間可以成形，不然以台灣中小企業的規模．不一定能承受這樣的成本及時間……
人員組成 R & R(Role and Responsibility)
- 經理(Manager)：負責團隊的規劃，初期的話甚麼都得做，必須快速讓團隊展現成效，建立credit，同時避免讓Data Team落入一個誤區，僅僅是自動化與出報表，簡單短期有效的easy work，就會變成很像小型的資料倉儲(DW)部門，可取代性會很高。
但這些事情也很重要，最直接幫助業務單位節省人力(cost down)，不過必須要有取捨(trade off)，在中長期做出團隊的差異化，提升公司長遠的效益。需要清楚的路線road map，以及在domain knowledge的支持下，做出有insight的分析，否則就會陷入一個短期資料處理(ETL)、自動化的循環。
而且會挖了很多維護(operation)的負擔，相對於一次性分析ad-hoc快速取得credit，會是比較「中長期」的重責，基礎建設之於空氣與水，所以reporting/mining 的trade off，關係到公司規模與部門定位，如果在比較大型的公司，似乎就會把reporting交給data engineer支援，data analyst/scientist負責業務分析或是較細緻的模型設計。
許多公司想做Data不容易成形，因為開疆闢土且有domain knowledge的主管難尋，且薪資上的巨大拉力，幾乎都出國了。二來是reporting的業務掛上去了，是很難中斷的，不過如果好高騖遠，只想玩模型調參，也是不行的，其他單位可能也不知道你們在幹嘛XD
2. Data Engineer：主要負責系統的建置，效能調整等，團隊的基石，在初期建置，與中長期資料增加時，效能的重要性會上升，而跨部門的溝通成本也會逐漸明朗化。想當初團隊沒有senior，大部分就是manager一個人要配置junior的工作，然後尋求IT部門的協助，從DBA建資料庫開始，後來終於有懂系統的senior進來，基本上環境就沒問題了，系統環境如果沒有長期的深入，遇到問題會很無解orz
3. Data Analyst
主要由有domain的分析人員擔任，會是團隊的價值展現與差異化所在，提出對於業務上有insight 的分析，或是下SQL串資料、資料視覺化甚至是模型建置，尤其在初期建立credit非常重要，確立路線是正確的。
而面對臨時性的需求（ad-hoc），要能冷靜的快速應對，提供正確的結果，是體現資深分析人員的要點之一，就是救火啦！緊急的重要分析，最能考驗資深人員的價值，為團隊取得信任感。
我們部門目前5個人，最多時有到7個人，目前是一位主管兼任senior分析人員，另一位比較專精於系統架構，含我三位是junior則看專案分配，但其實都會互相幫忙，以專案為主確立owner，比較不像是以職能如，Data Engineer\Analyst\Scientist的區別，小專案可能就是一個人一條龍完成。
Ref:
