從革命失敗到建立團隊 一段關於資料文化的新創旅程
講者簡介
版聚回顧及重點摘要
講者八年工作經驗裡，待過 Arc & Codementor 與 Gogolook 兩間新創公司，因此今天的職涯分享會著重於從事 Data 工作，在台灣新創公司裡可能發生的事情：
- 資料角色框架 vs. 個人職涯追求
- Whoscall — 堅持的改革，與伴隨而來的失敗
- Arc & codementor — 建立理想的團隊與文化
- 總結：從職涯中學到了什麼？
資料角色框架 vs. 個人職涯追求
最近 ChaptGPT、Open AI 很紅，各種 Large Language Model（LLM）如雨後春筍般出現，但回歸到 Data 角色，講者認為還是有很多模糊性。
很多公司想找 Data 的人，但並不知道該找什麼樣的人，在新創公司又會更明顯，因為新創公司無法投入太多資源細分 Data 角色，往往會希望 Data 角色能夠扛起越多的責任越好，職責就會變得更模糊。
想要入門 Data 工作的人，一開始可能會不知道該學習什麼樣的技能，從講者簡報左下圖可看出，不管是 Data Engineer、Data Scientist、Data Analyst，基本上都跟 Software Engineer 有一定程度的重疊，而這幾個角色間的重疊程度又更大。
簡報右上圖則呈現出 Data 領域可以再細化成更多角色，還可以分成 Machine Learning Engineer、MLOps…等。
每個角色之間的重疊性仍眾說紛紜，像是 Pipeline 比較屬於 Data Engineer 負責的範疇，但目前的趨勢是 Data Analyst 也會碰到 Pipeline 甚至是 infra 相關的內容。
ML Engineer 跟 MLOps 中間有一些分隔，Ops 比較偏向 DevOps ，工作內容偏向 Retrain Model、Version Control，但 ML Engineer 好像也會做類似的事情，而 Data Engineer 跟 Data Analyst 重疊部分又衍生出 Analyst Engineer 的角色。
大家通常會覺得 Pipeline 就是把需要的資料做 ETL（Extract, Transform, Load） 或是 ELT（Extract, Load, Transform） 相關處理，所以處理 Pipeline 會被認為是 Data Engineer 的職責，但實務上，分析端的商業需求變動很快，如果每一次分析都要透過 Data Engineer 修改 Pipeline， 那就需要額外的溝通成本。
為了解決這個問題，講者公司使用 DBT（Data Build Tool）服務解決。DBT 服務主要由 Data Analyst 維護，當 Data Analyst 因應商業需求需要做什麼改變時，可以自己修改 Pipeline，就能有效率地產出分析結果，這時候 Data Analyst 就蠻像 Analyst Engineer。
這些例子只是用來說明 Data 相關職位其實不停地演進，沒有人知道未來會演進成什麼樣子？
基於講者過去的經驗，每個角色在不同公司都有不同的定位，通常剛起步時會經歷 Full-Stake Data Scientist，代表 Data Scientist 要有辦法解決整個 E2E 流程，從 Business Goal 到 Connect to Business APP，甚至做優化。
這個 E2E 流程幾乎包含上述講過的所有職位，所以講者才會說新創裡的 Data 角色通常會更模糊、更包山包海。
講者分享幾個新創裡 Data 角色的演變例子：
例1：新創裡的 Back-End Engineer 有時就是公司的 Data Engineer。新創公司一開始做出服務，有前端後端收了很多資料，老闆就會希望從資料找出更好的商業目標，因此團隊會發現資料無法被整合，必須有人來解決資料整合的問題。
另外，如果同時在 Database 裡做分析，會跟用戶使用出現資源衝突，因此需要把資料先放到 Data Warehouse，此時 Back-End Engineer 就會開始做這件事，直到一段時間後受不了，才會開始找 Data Engineer 進來開始區分職責。
例2： Back-End Engineer 跟 Data Engineer 有時候都是公司的 DevOps，就是公司沒有很明確找一個 DevOps 的角色， Back-End Engineer 跟 Data Engineer 要隨著需求，隨時去設定相關的 Infra。
例3： DA、PM、Marketer 甚至 CXO 都會自己分析數據，講者公司並沒有明確定義「分析數據」是 DA 的工作，講者公司傾向用一個 General 平台，讓公司所有角色都有辦法用最短的時間去分析數據。
通常大家對每個職位會有既定框架，認為大概可以做哪樣的事情，當你做超過那個角色範圍的事情時，大家會說可以轉換角色。
但講者認為職位跟框架是人訂出來的，實際在發展職涯的過程中，不需要被這個框架限制住，當下手上的任務，哪些技能是最重要的
保持著好奇心去學習，並把過去的經驗連起來，就能創造屬於你自己的職位。
主流認為比較好的職涯發展會是：先選定一個角色學深，再慢慢學廣，但講者一開始就是從廣開始，而這些累積不會沒有用，到某個階段，這些學習到的知識點最後還是會連起來，讓你融會貫通。
講者在職涯發展過程中，雖然面對角色定位很模糊，但講者很明確知道自己的職涯目標，在職涯發展路上就比較不會迷失。
講者的職涯目標很清楚的是：
- 想要學更多東西。如果有機會可以學到更多東西，或是跟更厲害的人學到更多東西
- 希望自己的待的公司或是自己本身對世界有更大的影響力
- 想要跟一群很棒的人一起成長
講者最後拋出可以協助職涯定錨的問題是：「你想透過資料實現什麼？」
可能是「建立一個會讓人沈浸其中的推薦系統」、「建立一個分類或分群系統」、「提出沒有人想過商業 Insight」、「了解更多未知事物的因果」，或是「跟著時代的腳步去嘗試各種可能」…等。
這個提問講者沒有明確答案，歡迎讀者可以思考後寫下自己的答案，成為自己職涯的北極星。
Whoscall — 堅持的改革，與伴隨而來的失敗
講者經歷的第一間公司 Gogolook，主要產品是一個名為 Whoscall 的 APP，可以協助使用者辨識陌生來電，Data Size > 1.6 billion，資料內容是眾多使用者的 Call Log，近年來跨足到 Fintech 領域，連接來電與金融，建立更完整的防詐體系。
講者分享在 Gogolook 裡， 4 個從失敗學習的故事跟大家分享：
1.好想做個人化離線資料庫
離線資料庫從 Whoscall 官網的 QA 中有說明，當使用者網路連線不佳，還是可以從離線資料庫去辨識來電。
當有電話打進來，網路順暢時，會連上網查來電來源，離線資料庫，就是不用連網就可以知道來電來源，連網查詢的機制在 iOS 系統有所限制，因此離線資料庫在 iOS 系統上是很重要的部分。
雖然離線資料庫有容量限制，之前是二十萬筆號碼，現在不知是否有增加，但這個做法可以盡量涵蓋每個使用者會被騷擾的電話號碼，對於辨識率有明顯的提升，因此講者認為個人化離線資料庫很重要。
熱門的號碼不見得會打給每個使用者，但如果可以分析使用者通話行為，就可以依照相似通話行為推估使用者是否會有高機率收到相同的騷擾電話，進而提升辨識率。
舉例：A 跟 B 有類似的通話行為，當 A 接到騷擾電話，我們就可以將這個號碼更新到 B 的離線資料庫裡。
在經過討論後，講者認為這件事情是有價值的，因此跟台大研究生一起思考如何實作，也達成滿多階段性成果。
講者舉了 4 組號碼的分群案例，透過 Graph Embedding 做 Random Walk 方式去得到的分群結果，如果要用人的理解去給每個群命名，左下角就是跟享樂有關的，左上角比較是營業部門，右上角是政府相關，當有不同號碼的分群後，當使用者接到某個類型電話，那高機率會接到相同類型的號碼。
即便有不錯的研究成果，但功能並沒有馬上上線，講者總結原因是：
- 該任務不屬於當下團隊重要目標
- 團隊對於這件事情能帶來多少價值的認知有落差
- 模型到產品還有一段長路要走，很多東西需要考量。而當時公司只有講者一個 Data 角色，講者身上還有其他重要的事情需要優先處理，因此這件事情就不了了之。
最後 Whoscall 還是有推出個人化離線資料庫，但跟講者當時做的內容有些差別。
2. 好想建立資料產學合作典範
講者當時的公司與台大幾位教授有產學合作，離線資料庫就是與研究生共同合作的題目。
講者認為產學合作可以讓學術研究應用到商業產品，企業提供實際商業上的題目，研究生藉由研究最新的技術，提出解法
講者需要確保研究結果可以對公司產生價值，而教授確保研界結果可以產生學術價值。
在資料領域中，學生通常懂更多也追技術追得最快，這樣的合作模式，對於資源有限的小公司非常有幫助，因爲小公司沒有資源可以讓正職員工去投入時間深入研究，所以利用產學合作，把研究的事情外包給研究生。
最後一個好處是公司員工與教授可以從不同面向去評估研究成果的價值，是個多贏的合作流程。
講者過去經歷了大概三年的產學合作也發了蠻多跟 Call Log 相關的論文，但最後這個產學合作卻沒有繼續下去，講者分享了三個原因：
- 公司當下的資源無法持續投入在產學合作，資源包含教授費用、講者的工作時間。
- 公司與團隊認為產學合作的影響力不高。
- 講者可能沒有相對能力去獲得公司內部的信任，讓內部相信產學合作可以帶來價值。
這些與第一個嘗試無法繼續推動的原因類似。
3. 好想讓研究變成公司的核心
講者認為「研究」是很重要的事情，因為單純做產品很難跟競爭對手拉開距離，但做一個研究，雖然可能失敗，只要成功就會成為產品的護城河。
講者列出了一個好的研究需要具備的條件：要能定義明確目標、建立合理實驗情境去驗證目標。
而好的研究需要有好多團隊，因此講者向公司 CXO 們，提出想組建團隊的想法，原本公司分成三個團隊，由 Consumer 團隊提供資料給其他兩個團隊，做報表與研究。
而講者的提案則是中間有個研究團隊，將三個團隊相關需求綜合考量做全盤研究，並依據重要性提供數據服務給不同團隊。
經過講者提案，公司開始找新的 Data 角色，有專門做 Infra 的人，也有一個研究部門，很多研究題目慢慢被重視， Data Team 的人也越來越多。
看起來這次提案有發揮效果，但這件事對講者而言是另一個層面的失敗，因爲公司改變了，但講者並未被納進想進入的研究團隊裡。
講者在這個嘗試裡的反思是推動好事之餘，也要把自己考慮進去。每個人都希望事情可以成功，而自己也需要成功。
因此不要做無謂的謙虛，更成熟表達自己的需求，取得大家的信任與理解，是職場上滿需要學習的一個面向。
4. 好想建立好的資料團隊
建立研究團隊的過程，講者從 Research 走到 Product ，與團隊摸著石頭過河後，訂立了以下團隊規則。
- 前期探索階段：如何以最小成本用有效率的方法去找到實驗的方向。
- 實驗階段：需要比較高的品質標準，確定可以被產品化，所以需要 Code Review、簡單的自動化流程。
- 產品化階段，從研究成果轉換成產品過程，就多了 QA 的參與。
在這個過程中，講者的重要學習是：
建立個人在團隊間的信任與仰賴，推動新的嘗試會比想像中容易。
有時候堅持做對的事情，但如果在溝通上過於武斷，或是沒有注意到團隊成員的感受，其實會影響到團隊的氣氛，連帶影響事情是否會成功。
Arc & Codementor — 建立理想的團隊與文化
Arc 跟 Codementor 其實是兩間公司，雖然做的事情不相關，但其實是在同一個生態系裡面，Arc 是遠端職涯媒合平台，主要客戶在美洲、拉丁美洲。
Codementor 是遠端學習平台，有點像是 Stack Overflow 的線上版本，使用者透過視訊詢問學習上遇到的問題，平台也會舉辦 Codementor Event，就是各種程式相關的開發活動，串連工程師從學習到求職的生態系。
在 Arc & Codementor 的職涯旅程中，講者挑選了三個面向與大家分享：
1. 從頭開始學習專業，不論軟硬
在加入新公司時，講者從過去職涯上跌過的坑，整理出幾個學習重點：
- 硬實力：就算有很多想法，還是要有硬實力去理解不同選擇的差別，提出的執行方案才更有說服力。
- 過去的知識的累積是基於解決問題去獲取，知識本身是破碎的，並不知道互相的關聯是什麼，需要加強把知識點連成線、面的能力。
- 溝通與團隊協作有關的軟實力。
講者提升硬實力跟將知識點串連的方法是「教學相長」
講者在 PTT 家教版上找到有人想學 python，因此開始當起家教，擔任家教備課的過程，可以重新去整理過去自己知道的知識，重新融會貫通變成教材，再輸出給學生。
這個教學持續兩年左右，每週上課 2 小時，但備課都是 8 個小時起跳，有時候準備 Demo 卡關的時候，還會卡好多天。如果單純換算時薪滿不划算，但站在學習的角度，其實當老師本身的學習更多。
軟實力提升方面，講者是從一個 podcast「大人學」學習很多職場人際關係、優勢策略…等。
之前講者以為這種非技術的課沒什麼用而且收費很貴，但在 Whoscall 後期就有去上課，體悟到
推動事情的方法，不是只有專注在事情上，而是要先去了解對方需求，先傾聽才能開啟互信的合作。
綜合軟實力與硬實力的提升，即便講者在 Arc & Codementor 團隊裡有各種不同 Data 角色，但因為講者過去做過很多不同職位，再加上溝通能力的補強，還是可以在團隊裡帶起良性的討論。
在 1-on-1 會議時，因為過去整理過教材、思考過各種職涯發展路徑，因此可以跟成員分享真實經驗與看法。
累積了連續兩年持續準備教材、持續學習，講者培養了「學習」這個興趣，就像健身一樣，每天進步一點，壓力不會那麼大，成就感也會慢慢堆疊出來，目前「學習」對講者來說已是一種自我提升的正向人生體驗。
2. 建立互信的團隊，成為好的領導者
講者是第一個加入 Arc & Codementor a comment 的 Data 角色，老闆也給講者足夠信任去組建團隊，以下是講者思考自己想組建什麼樣的團隊：
- 能夠暢所欲言的團隊：有話直說，不會事後抱怨，團隊成員間不會明爭暗鬥，惡性競爭求表現或是升職加薪。
- 成為亦師亦友的主管，講者希望自己能包含 6–7 成開發的工作，繼續在硬實力上成長，給予團隊成員職涯上的指引。
- 團隊成員之間緊密信任，但還是要強調公司最重要，團隊第二。公司好團隊好，個人才會跟著好，而不是個人為主，想著在這裡學會什麼之後比較好找工作。
講者認為主管幾乎可以決定團隊文化，所以主管必須要以身作則。
如果希望團隊文化是透明的，那就需要把資訊揭露給下屬。如果希望團隊互相信任，就需要傾聽所有人的想法，有道理就要採納。如果希望大家可以直接的回饋，不論正負面，都不要在後面抱怨，那就必須接受所有的反饋，然後努力去改善。
例如下屬跟講者反應講者講的某些話讓人不開心，講者的反應會是：「我知道了，下次不會再犯一樣的事情。」
當主管願意做到這件事情，以身作則，大家就會知道真的什麼事都可以講，團隊安全感會慢慢被建立起來，就可以把所有事情講出來進行理性的溝通。
身為中階主管，會收到上層主管的資訊，這時候再聽下屬的反饋時，很可能會覺得下屬只從自己的角度出發，但其實有時候下屬視角的反饋是很有道理的
所以要怎麼收進很多不同層級的想法，消化吸收後整理提供給大家，這件事情是有一定的挑戰。
最後，講者認為主管很像父母，因為主管像父母一樣有絕對的權力，但這個權力不代表可以不尊重小孩（下屬）。
當主管（父母）懂的尊重小孩（下屬）時，就會用溝通引導的方式循循善誘，提供每個人在一定範圍內自由發揮的空間。
而選擇跟努力一樣重要，做了選擇也需要努力，努力過後也需要知道哪個選擇比較好
這些都是在跟下屬 1-on-1 時需要討論的事情。
試錯比成功更關鍵，所以主管需要鼓勵下屬去犯錯，但要提醒不要一犯再犯，我們可以一直嘗試各種不同的錯誤，但在過程中需要有所學習成長，把事情做得更好。
在擔任中階主管的過程中，會面對很多上下或是平行單位的衝突需要平衡，講者借用「大人學」裡學到的 TOC 衝突圖的概念與大家分享。
很多工作或生活中的矛盾衝突，背後其實會有核心的共同的目標，但在表面上會因為各自有不同的訴求而發生爭執，所以在溝通時的第一步需要先放下自己心中的見解，先去理解為什麼對方這樣要求？這樣想？才能找到隱藏的共同目標，讓溝通更加順利。
例如 PM 跟工程師就是很常有衝突的角色，PM 想要將專案時程提早，工程師可以試著去了解，這樣的訴求背後的目標是什麼，去找到彼此的交會點，而不是停在「不可能，做不到」，就無法往下溝通。
3. 透過資料的價值提升公司的價值
在新創公司裡大家其實都是分析師，所以講者團隊做了一個 DBT（Data Build Tool） 架構，把現存資料分成三層架構，每層可以重複被使用，並加上對應的測試。講者認為這個是滿未來性的作法，會越來越被廣為使用，推薦大家可以去了解。
另外講者公司也透過 ChatGPT 的 QA 架構整合到 Slack 裡，讓分析可以更容易，例如：團隊成員可以問「我要怎麼拿到某個資料表的資訊？」或是「我需要某個資訊，在哪個資料表裡？」甚至可以請 ChatGPT 提供一個 Query 去拿到所需要的資料，分析的時候大家只需要用對話的方式進行即可。
講者公司一直有在演進的是 Hire AI，希望能將推薦做得更有效率，推薦好的開發者給用戶（徵才公司），或是推薦用戶（徵才公司）給開發者。
如何使用開發者的 Resume 資料推薦，過去比較是看開發者的技能、所在國家是否匹配，但其實還有很多描述是軟性面向的，例如希望用戶找一個 Positive、Proactive的人，這些內容可能要從開發者過去待過的公司、過去經驗統整。
而 Open AI 就可以去解讀 Resume 上的文字資訊，去計算 Job Description 跟 Resume 之間的 Consine Similarity，講者公司目前的推薦版本就驗證利用「區域」、「技能」之外的資訊，可以推薦得更精準
另外還有持續優化的是，如何抓到更多試用者的 Preference Information，後續做個人化推薦。
再來是 Customized Embedding Vector，在每個 ID 後面再掛一層 Fully Connected Layer 讓每個 Embedding 去 Fit 目前的 Training Data、如何衍生更多特徵值…等等，都是可以持續進行中的優化計畫。
總結：從職涯中學到了什麼？
- 未來還會有不同的際遇，過去其實講者很多規劃並沒有隨想像發生，因此敏捷地去調整自己的期待是很重要的。
- 講者分享了很多職涯上的失敗，遇到的各種挫折，在面對挫折當下的情緒一定很低落，但更重要的是挫折帶來的體悟，這個體悟可以產生什麼樣的行動，帶給未來什麼樣的幫助。在面對挫折當下可能很難看到學習點，但如果你一直正面去面對挫折，接受當下自己不足的地方，努力改進，在未來某個時間點會幫助到自己。
- 不要被自己的負面情緒擊垮，當接收到很多負面事情時，真的很容易想說：「算了，我可能就是這樣，我的能力就到這」，或是「別人認為我怎麼樣，那我就真的是怎樣」。每個人都有無限可能，不是說別人的話不用聽，但更多的是要多傾聽自己如何正面看待事情。失敗為成功之母不一定對，但如果能正面面對失敗，失敗才能成為成功之母。
- 「變得更強」不只是個人專業，大家可能會很憧憬在某個領域深耕很久的大大，但如果在過程中，不只個人專業有所增長，還能幫助更多人成長，幫助團隊、公司、甚至世界變得更好，這也是一個變強的 Sign。
Q&A
Q1: 想了解在 whoscall 做通話軌跡做分群的細節？
A1: 我用模糊的記憶大概拼裝一下整個流程：
- 使用 Call Log 資料，裡面分成 Incoming Call, Outoing Call，兩個人相互通話紀錄可繪製成線，綜合多人通話紀錄就會變成一張圖，類似 Facebook 社交網路的圖表，可以知道多個使用者的好友關係。
- 使用 Graph Embedding 的方法可得到多個使用者的 Eembedding Vector，使用的演算法就是 Deep Walk。
- 得到所有使用者的 EmbeddingVector 後，就可以去跑 Kmeans，得到不同通話號碼的分類。
- 最後使用類別做推薦，假設我跟 Tony 是屬於同一個類別，當我收到詐騙電話，就可以將這個電話推薦給 Tony，就可以更即時去預防新的詐騙電話。
Q2: 如果想要進新創擔任 Data Analyst 的角色，有沒有什麼技能或人格特質特別重要？
A2: 人格特質其實不分新創或是其他環境，我面試時會希望看到點：正面主動、以解決事情為導向、擁抱學習。新創公司人不多，每個人需要處理的事情很雜，團隊之間的配合是一個人要處理很多事情，所以不能有太多框架，必需要學習任何可解決當下問題的技能，有這個心態也滿重要的。
技能方面 SQL 最重要，這是個歷久不衰的語言，並且越來越重要，它是有很大的價值。
另外前面我有提到，公司或是我個人的想法都希望慢慢淡化 DA 的角色，能夠慢慢走向 AE，就是分析師也可以具備 Pipeline 相關的能力，可以使用 DBT 架構，我們公司的 DA 就掌握滿多工程師的技能， 像是管理 Pipeline、寫 API。
所以我會建議 DA 的走向一開始還是把 SQL、Python 可以做到統計相關的技能練熟，然後慢慢越走越廣。
Q3: 沒有考慮進 Research 部門最可能的原因是什麼?
A3: 其實我是想要加入 Research 部門的，但手上還有跟研究生研究的成果想要產品化，而我當時沒有明確表達加入意願，所以才沒有加入。
如果這件事情可以重來，我會很明確表達我想做的事情是什麼？去討論手上的事情可以交給誰？讓我可以比較好的轉移過去。
Q4: 在前公司的時候，你希望跟你的主管可以討論什麼職涯主題？
A4: 當時我們沒有所謂的 Data Team，直到我離開都沒有， Data 相關的人都是歸屬在 Service Team，當時主管有問我是否有興趣當團隊裡的小 Leader。
當時我比較年輕，會懷疑自己，會有「我真的可以嗎？」的想法，所以就拒絕這件事。
現在重新思考的話，我應該會積極地去爭取我內心真的想要的東西，而不是表面謙虛，但其實是自我懷疑的狀態
有時候先爭取到，然後在做的過程中就會慢慢變成自己理想的樣子。
與主管的溝通上，我會希望自己能更明確表達自己的需求，並且更成熟的去溝通。
Q5：延伸題目，你後來當主管後，希望組員在1-on-1的時候跟你討論什麼主題？或是什麼職涯的題目？
A6：我們有一個 1-on-1 的 Notion，上面有列討論的主題
- 過去 1 個月讓你感到興奮的事情？
- 過去 1 個月讓你覺得挫折的事情？
- 現在的開心指數如何？
- 你學到了什麼？
我認為 1-on-1 不是告訴你接下來工作要怎麼做，或是聽你講說你遇到了什麼樣的麻煩，這些都是平常工作遇到的當下就要去討論、解決的。
設計這幾個分享題目的目的是：知道公司的方向如何幫助成員職涯發展
如果幫助不大，我會跟成員討論需要怎麼調整，我可以怎麼讓成員跟公司的方向慢慢靠近。
如果你的主管沒有辦法支持你的職涯方向，會建議嘗試各種角度的溝通達到你想要的目的，但如果最後發現道不同不相為謀，也不是件壞事，你可以從過程中去探索自己想要的方向在哪裡。
筆記手：盧姵吟 Lavina Lu
校稿：YangChi Shen、Ting Yu
👉 歡迎加入台灣資料科學社群，有豐富的新知分享以及最新活動資訊喔！
https://www.facebook.com/groups/datasciencemeetup
