資料科學團隊工作經驗分享
講者簡介
Vickie Chu 講者目前在華碩電腦服務，以前曾經在趨勢科技、網訊電通以及消費者文教基金會擔任數據相關的工作，專長在數據 ETL(Extract-Transform-Load)、數據維運與資料視覺化，共累積大概8年的經驗。
講者曾在乙方公司工作，主要職責是整理購物網站的數據，某天主管請講者以「提高消費者購買轉換率」為目標，與客戶討論出優化電商網站的購物流程。
當時客戶認為業績不佳，是因為消費者在購賣前需要加入會員，導致消費者不願意購買，因此這次改版主要是在網頁上分出會員購賣與非會員購賣兩個入口。
完成流程優化後講者使用 T 檢定去驗證改版後的成效，結果發現並沒有實質提升電商業績。講者將這個結果分享給主管，主管雖然很驚艷，但是主管認為客戶不會在意這件事。
因為講者當時的公司是接案公司（乙方），主要就是照著需求方（甲方）公司給需求去執行。站在接案公司角度，當然是做越多事情賺越多錢，不會管做的事情成效如何。
因此講者就開始對「資料科學在不同公司定位」這樣的題目有興趣，也是今天講者想分享的第一個主題
資料科學團隊在不同公司內的定位
Type1：大公司 vs. 小公司
大公司
- 優點：穩定的發展機會，福利也比較好，有比較多的資源，可以選擇使用的工具就比較多，學習的技術就比較廣，也有機會跟很多專業團隊合作。例如公司買了一個雲端平台的服務，就可以跟雲端公司的工程團隊合作，學習雲端服務相關的技術或是趨勢等。
- 缺點：比較官僚，做事情需要依照流程申請，舉例要申請某個資料就必須上簽呈，這方面比較受限於制式化的流程，比較缺乏彈性，做的事情也比較不容易被老闆看見，每個人都是一棒接一棒的做事情，是公司裡的小小螺絲釘。
小公司
- 優點：較靈活的工作環境，因為團隊較小，每個人要做的事情比較多、比較雜，但相對影響力就比較高，因為扁平組織的關係，也比較容易讓老闆看見，比如說今天做了一個報告，就可以馬上跟老闆報告，與同事也比較有緊密的工作關係。
- 缺點：資源比較有限，做數據分析買個硬體機器就需要上百萬，小公司可能沒有這樣的資源。
Type2：甲方公司 vs. 乙方公司
甲方與乙方公司分別代表合作關係的不同角色，甲方是提出需求，付錢的角色；乙方是滿足甲方需求，提供服務的供應商，在這樣的合作架構下，甲方公司具有主導地位，有絕對的控制權，也可以說是做決策的人。
當數據團隊找到一個很棒的 Insight，在乙方公司就只能提給甲方說這個 Insight 很棒，但甲方公司可以針對這個 Insight 再做更深入分析、擬定策略，使用這個數據幫助甲方公司業績成長。
甲方公司因為很多服務依賴乙方提供，所以當有數據需求時，就需要依賴乙方公司回傳，這就要看乙方公司意願，有可能還需要花錢把數據購回。
乙方公司的優點在於因為可以接觸不同領域客戶，就可以接觸多元數據，利用不同專案增進技術，增加個人與公司的知名度；缺點則是專案掌控權在甲方，如果案子流標就無法繼續完成專案，也會有同行競爭的問題。
Type3：業務導向公司 vs. 產品導向公司
數據分析師的成就感來源來自：做出來的結果是否能被老闆認同，能被公司應用，並且實質幫助公司業務，這就跟公司是業務導向還是產品導向有關。
業務導向公司以業務為主，數據團隊會全力支援，舉例業務想知道這個月的業績是多少？有沒有達標？
數據團隊可能在很短的時間內，一週或是三天內要馬上產出業務報表給業務主管，讓業務主管能針對不同產品做業績 Review，這是業務導向公司比較常有的合作型態。
因為業務導向公司業務講話比較有份量，有時數據團隊分析出的結果，不見得會被業務採用，因為他們會使用經驗法則做事情，比較難用數據去說服業務改變作法。
而產品導向的公司專注在用數據優化自己的產品，比如說像 Spotify, Netflix 這些公司，會不斷地用數據分析的結果去優化演算法或是產品推薦，因此數據分析師在產品導向的公司更有機會將分析結果直接貢獻在產品的優化與業績的成長。
Photo by Tamas Pap on Unsplash
但產品導向公司的限制在於，如果只有產品方面的數據，並沒有串接客服、行銷…等數據，那就只能專注在產品數據，無法接觸到更全面的數據。
產品導向公司雖然是基於數據分析結果去優化產品，但可能會面臨市場接受度的問題，這個就需要持續分析、了解，才能知道數據優化產品的成效如何。
講者分享了三種資料科學團隊在不同組織架構下的差異：
1. Decentralized 分散式架構
每一個部門都有自己專屬的數據團隊。這種架構的缺點在於每個部門的數據是獨立的，很難統一整理給老闆，舉例來說當老闆想知道客服會收到多少比例的會員抱怨？
在分散式數據團隊架構下，客服相關的資料放在客服部資料庫，會員的資料行銷部的資料庫，要回答老闆的這個問題，就會發現數據串不起來。
如果這兩個部門沒有互相合作，沒有共通的欄位當 key，當要了解 User 各個面向的資料時就會比較困難
2. Centralized 集中式架構
數據被集中管理，各部門要使用資料時，就統一向數據部門申請，上面的例子就很容易被回答。但這樣的缺點是，各部門要取用資料時需要經過層層把關，需要提供使用數據的目的、欄位，並經由審核部門審核該申請部門是否有足夠權限可以取得數據。
3. Hybrid 混合式架構
有一個數據中心管理公司所有數據，比如說欄位、名稱等等有一致性設計。公司各個部門可以用統一標準來看待數據，當跨部門進行會議時，大家討論的數據可以在統一的基準上，而不會有數據歧異，但各部門還是有各自的團隊，針對各部門需要的業務應用來做數據分析。
資料科學團隊的組成
資料科學領域比較常聽到的3種角色分別是：Data Engineer, Data Analyst, Data Scientist, 但其實還有其他角色沒有被大家討論到，例如專案經理，主要工作職責是掌管專案進度，數據科學團隊的所有任務都是由專案經理來掌控。
比如說公司內會有行銷單位、產品單位、研發單位、客服單位等等會對數據團隊提出相關需求，這時候專案經理就是負責來掌控排序跨單位來的需求。
在研發團隊裡除了Data Engineer, Data Analyst 之外還有 DBA(Database Administrator )專門管資料庫的工程師，還有 RD 負責前端網頁開發或是 APP 開發，這兩個職位在研發團隊非常的重要。
DBA 負責所有數據的匯入，不管是公司內部跨單位的數據或是公司外第三方資料的匯入，都需要 DBA 將數據導入公司資料庫，資料工程師、分析師才會有數據能整理、分析。
Photo by Joshua Sortino on Unsplash
最後整體分析完的結果如何呈現給老闆或是 Stakeholder 看，就需要透過 RD 開發的網站或是 APP，可能是將數據成果呈現在報表網站，或在發送 EDM 網站上新增某個功能，或將分析結果應用在官網的產品排序。
最後數據成果會需要進行專案報告，專案經理的角色就需要去跟各部門說明研發團隊提供了什麼新的數據服務？可以協助各部門做哪些事？
另外講者分享，這幾年的工作經驗中，數據分析結果很多都是給高階主管看，會有機會近距離接觸高階主管，能第一時間接收到高階主管的需求，講者認為滿有趣的。
Photo by Markus Winkler on Unsplash
第二個有趣的是有機會接觸法務團隊，在一個龐大的組織內工作，通常都會有專業的法務團隊來處理公司大大小小跟法務有關的事情。
與資料最相關的法律就是 GDPR，因此跟資料安全相關的問題會由法務來把關。
舉例來說，當數據團隊要運用顧客數據進行行銷接觸時，就需要法務協助確認。
資料科學團隊對組織產生的貢獻
1. 優化既有的工作流程
在沒有資料團隊的情況下，大家已經在做的事情，但是資料團隊能協助各單做得更快、更好，講者舉例說明如何協助建立自動化報表，減少定期製作報表的人力成本。
資料團隊需要每月、每週、每季產出財務分析報表提交給主管，過去要花很多時間把數據整合成 Excel 檔再產出分析報表。
要優化既有工作流程，資料團隊就會重新跟主管確認報表需求，包含報表所需的資料類型、分析維度、需要呈現的報表內容等
接著將原本用 Excel 提供的數據做成自動化報表，還可以加上一些 Fancy 的圖示，讓報表更吸睛。
Photo by Luke Chesser on Unsplash
當主管定期要報告時，報表可以自動化產生在 Power Point 上，所以主管就可以縮減很多製作財務報表的時間，主管只需要微調自動化報表工具提供的內容，就可以提交給更上層的主管。
2. 應用分析服務
就是報表服務，有蠻多團隊透過 Outlook, Excel 這些 Microsoft的軟體來做數據收集、報告。
過去大家需要各自做一份數據資料，去互相交換比對數字正確性，再提供給主管，這個流程通常非常冗長，資料科學團隊可以整合這些流程與需求，直接做成一個自動化的報表，並且內嵌在公司內部網站或是 APP上。
3. 使用機器學習方法，建立些預測性的數據服務
資料團隊可以用網頁瀏覽、加入購物車等等的紀錄，找到購買意願較高的人群名單，提供給行銷單位做精準行銷的應用途。
數據科學工作常遇到的難題
1. 數據孤島
公司可以收集到的消費者數據可能是網頁瀏覽紀錄可能是行銷活動參與紀錄，可能是客服進線紀錄，或者產品購買記錄…等等，當公司沒有在數據裡面建立唯一識別碼，就比較難做到完整全面的分析。
2. 數據流失
數據是一直動態在更新，但如果沒有把「變動紀錄」存下來，就會對於數據流失沒有掌握度，也無法減緩數據流失。
講者分享的例子是：「是否接受 EDM」的欄位會動態更新至最新狀態，但有可能今天會員願意接受，明天不願意。
但是這個變動紀錄沒有被記錄在資料庫，當沒有記錄變動行為時，就很難知道會員在什麼時間點不願意？因為什麼原因願意？要怎麼讓不願意的會員再次願意接收行銷訊息？
Photo by Campaign Creators on Unsplash
3. 數據斷層
數據斷層的成因是因為公司將部分業務外包，在做廠商轉換時，就容易產生數據斷點。
例如公司使用外包廠商的電商平臺，當從 A 電商平台轉換到 B 電商平台時很常發生資料串接不起來。
因為各電商平台提供的服務不同，資料欄位也不同，就會產生資料斷點，或是資料欄位錯置。
資料科學工作未來展望
1. Data PM
需要協調跨部門之間的合作，而Data PM 與一般 PM 的差別在於，Data PM 對 Data 有比較深的理解，或是對 Business 有很深的理解，由這樣的人來做數據溝通就可以增加合作溝通的效率。
2. 平臺使用專家
近幾年 CDP（Customer Data Platform）數據整合平台蠻流行的，很多公司都把數據上傳到雲端平台上，熟悉這些平台如何上傳、下載、連接資料的專家可能在未來會越來越重要。
3. 特定領域專家
最近智慧醫療產業蠻常在新聞上看到，尤其現在就是 AI 很夯，越來越多人在討論這件事情，講者覺得特定領域專家對於數據科學也非常重要，例如在智慧醫療產業，收集很多醫療的數據
但數據分析師並不是醫療背景相關的人才，只能提供某些數據條件是正常、某些數據條件是異常的分析結果，但無法提供行動方案。
Photo by Irwan @blogcious on Unsplash
這就需要借助醫療領域專家來協助解讀，當數據異常時可以給出什麼行動建議，這也是未來會很重要的職務。
ChatGPT 在資料科學領域能協助哪些任務？
ChatGPT 對這個問題的回答是：資料清理、統計分析、視覺化、機器學習、預測、模型、時間序列分析等等。
因此講者使用了一個 ChatGPT Plug-in：Code interpreter，評估這個工具是否能取代傳統資料視覺化軟體
第一步：測試是否能匯入資料，答案是可以的。Code interpreter 可以直接上傳檔案，直接做資料分析
第二步：請 Code interpreter 分析建議，ChatGPT 就用文字列出了各個欄位內容，並把可以做分析的情境列出來。
第三步：ChatGPT 依照分析建議進行實作，一開始 ChatGPT 是用文字呈現，由於文字比較難閱讀，講者請 ChatGPT 直接做成圖表，還可以更改圖表顏色。
最後一步：請 ChatGPT 以 2x2 的排版產出一份報表，也很順利產出。
Photo by Luke Chesser on Unsplash
講者認為 ChatGPT 推出後，很多數據分析領域的工作或流程會被翻轉，過去要抓資料需要寫 Code，但現在可以直接透過 AI 工作來完成。
未來只需要專注在「如何解決陌生問題？」、「能夠提供哪些解決方案？」
總結
講者最後歸納了三個重點：
- 從公司定位的角度來選擇工作，大公司 vs.小公司，甲方公司 vs. 乙方公司，業務導向公司 vs. 產品導向公司，依照個人喜好做選擇
- 專注於個人學習，成為某個領域的專家，講者自己就是長期耕耘在資料視覺化領域，持續累積相關經驗。
- 持續關注產業動脈以及新技術，可以藉由參與社群、新聞等獲取新知，持續精進自己的能力。
Q&A
Q1：產品導向和業務導向公司可以舉例嗎，感覺好像有點相似
業務導向的公司比較以經驗法則為主，即使有分析數據，但不一定會被採用，舉例來說：公司每個月對外發 100 萬封 EDM 給潛在客戶，約有 10 萬人會開信，開信率是 1/10，其他寄出的信都是浪費。當數據分析師拿了曾開信的客戶去分析，建出一個模型是，只要發出 60 萬封信就可以獲得 10 萬人開信，代表用比較少的寄信成本獲得一樣的開信數量。
這樣的結果老闆會覺得很棒，但實際提供給業務單位時，業務單位還是有既定印象認為 EDM 當然是發越多人越好，如果真的依照模型減少發信，但最終開信率不如預期怎麼辦？
這就是雖然開發一個好用的工具，但要需要去說服業務單位接受並使用，會比較累一些。
Photo by Blake Wisz on Unsplash
而產品導向公司，因為是直接把數據分析結果做在產品上觀察成效。舉例：在電商網站上的產品推薦，背後利用顧客瀏覽紀錄或購買紀錄，要觀察這個推薦的成效就是直接看是否有提升業績。前者是對人溝通，後者只要對機器溝通（把模型上線），對機器溝通相對容易一些，對人的溝通會比較複雜。
Q2：How big is the data science team in your company? what kind of topics they are working on? (supply chain, R&D, procurement, marketing etc.)?
在比較大型的公司可分析的資料量上千萬、上億都有，可能一個 DB 都塞不完，需要分多個 DB 存。我自己本身是在做 CRM 相關數據，像是會員產品註冊、會員行銷活動、會員客服紀錄等等，也會接觸到 Supply Chain 相關的資料，比如說在供應鏈的資料數據整合，協助供應鏈優化庫存管理。
Photo by Jacques Dillies on Unsplash
Q3：請問有沒有遇到過來源資料正確有疑慮的問題？後來怎麼解決？
我分享一個之前在乙方公司做過的例子，我們的客戶是一個賣奶粉的公司，當媽媽申請試用包時，會要求媽媽提供小朋友預產期，我待的公司就會針對預產期做行銷訊息的推播，舉例買奶粉會再送玩具。
當時有被客戶抱怨，根據公司提供的名單發出去成效都不太好，或者可能過幾個月消費者才來真的來購買東西，客戶覺得名單有問題，後來才發現是資料工程師在資料底層串接時串錯欄位，導致給的名單是不正確的。
Photo by David Pupăză on Unsplash
發生這類事情通常就是趕快解決，因為也沒辦法針對過去的事情修改，只能當下發現的時候去做調整。
Q4：Code Interpreter 需要把數據放上外部網站，好奇一般大公司允許做這樣的事情嗎(資安考量)。 如果不允許的話，公司仍然無法導入code interpreter 而需要在公司內建數據人員來處理?
我們不會把公司內部的數據丟上 Code Interpreter，公司對於這件事情相對還是比較保守，還無法導入 Code Interpreter 這個工具，只是我個人關心這個議題的時候使用。
Q5：請問在設計資料收集方面，如何比較完善的規劃要收集的資料，避免未來才發現到重要數據沒有收集到?
這件事情很難，你只能在資料收集方面把重點的資料先收集到，比如說你要收集電商數據，基本就要有會員 ID、訂單號碼、訂單日期、訂單金額、購買產品、從哪個平台購買，這些基本的重要數據都要，你可以計算出會員從電商買多少產品？總共花了多少錢？為公司帶進多少收益？這個是最基本的東西。
Photo by Emiliano Vittoriosi on Unsplash
其他更細節的資訊，例如購買前在購物車裡放了哪些產品，這些就會是比較次要的資訊，等到需要用的時候再去找，很難在一開始的時候就做很全面很完整。
Q6：請問在公司資料目前大多會使用的技能為那些? 資料科學家有需要使用到Hive或者Spark嗎?
有一些公司會有用到但是我目前沒有接觸到這樣的技術，我覺得在資料分析比較重要的工具應該會是關聯式資料庫，就是SQL，你只要會下 SQL 就可以做很多基礎的事情。
Q7：請問資料分析師與資料科學家在華碩的分工如何？資料分析師需要會寫模型嗎？
我們會分不同的團隊，通常會有資料科學家團隊跟資料分析師團隊，還會有一個pm團隊來做溝通協調，資料分析師不需要寫模型，通常比較專注在資料的應用服務還有需求討論。
Photo by Cherrydeck on Unsplash
Q8：取用資料時主要用哪個服務 GCP, AWS or公司內部自建的warehouse。
都有，大公司裡就是各個工具都有，大家會嘗試每個工具可以做的極限是什麼，你會有很多的機會可以去摸到很多不同的工具。
Q9：請問應徵您相關職位會需要考leetcode 嗎？
我進來的比較早所以當時沒有，但我不確定現在需不需要。
Q10：也想問如何檢查資料正確性（方法or工具），以及團隊中是那個角色負責這一塊 謝謝！
通常團隊都會有 Q ，是專門檢查數據正確或是錯誤的團隊，但我目前合作的案子是由數據分析師自己來做這件事情。
檢查資料的正確性，可能要靠一些過往經驗，舉例：之前做過電商的案子，就會知道電商有哪些重要數據一定要有，當我們要更換電商廠商時，就要去 review 過往那些重要的數據新的廠商還能不能提供？所以是由數據分析師來做這件事情。
方法跟工具我覺得是比較以經驗法則為主，工具的話就是用 SQL，根據過往的一些邏輯經驗去試試看抓不抓得到想要的資料。
Q11：How did you handle the situation when the client challenge your analysis/data insights?
這件事情也蠻常發生的，我們有時候做的一些數據分析結果可能會影響到某些團隊的業績，而業績會跟考績有關聯。
假設我今天要 review 公司業務的業績，就會分不同 region、不同州或是不同國家來 review，這個數據會關聯到主管個人業績，這些 Sales head 或者是 BU Head 就會對數字斤斤計較。
Photo by Isaac Smith on Unsplash
我們就會告訴他們資料來源，通常是財務單位，他們就會去跟資料源頭要一份數據，再來比對我們報表上的數據是不是跟資料源頭的數據一樣。
當業務主管有疑問的時候，就會比對兩邊的資料，當業務主管相信我們的時候，就會使用我們這邊提供的數據
Q12：Data PM 和一般的PM 在 “技能” 上有什麼差異呢?
我認為是對資料有一定的概念，一般的 PM 可能對於加一個資料欄位或是多一個判斷準則，會認為是很簡單的事情，但是對於 RD 來說，調動一個小小的東西，可能要改很多的 Code，要去看很多不同的數據源的數據是否會被一併被改掉？需要花滿多時間去檢驗的。
我覺得 Data PM 會更需要了解自己部門的數據，知道自己部門有哪些數據可以協助其他單位做哪些事情，當其他單位提供需求時，Data PM 可以把關哪些能做，哪些不能做。
筆記手：盧姵吟 Lavina Lu
校稿：Vickie Chu、Ting Yu
👉 歡迎加入台灣資料科學社群，有豐富的新知分享以及最新活動資訊喔！
