給剛入行擔任 DA 的 3 個小參考

其實一開始沒有特別規劃進金融業擔任資料分析師的工作，誤打誤撞進入後，也默默地做了超過 1 年。不會說自己很厲害，但是比起剛起步的時候，憧憬要跑很 complex 的模型，用最 frontier 的工具，做很 fancy 的簡報說服利害關係人，然後生意就會因為有了洞見（Insight）後順風順水，蒸蒸日上的 Me，應該是有變得比較務實一點！？

畢竟要熟悉組織的資料流（Data Flow），了解資料庫裡面有哪些 Table 和串接方式，就可能佔用你整個適用期。如果組織的產品線比較廣，或者部門定位偏向集中式（Centralized）的資料部門，做到一個很類似的資料需求，搞不好已經是半年後的事了。

如果時間能回到入職當下，By Day-1 我想我會多提醒自己幾個面向，或許跌的坑會比較少一點。

到目前為止，個人所屬的資料分析部門定位是偏向 support 的角色，也就是如何與業務單位有緊密的結合，進而用資料創造商業價值。創造商業價值有兩種，要不就賺更多的錢，要不就省下更多的錢（成本），包含時間成本、人力成本等。

如何賺更多的錢，如何省下更多的成本，其實資料分析這個領域，相對於行銷、銷售部門是更不容易讓人「有感」的。沒辦法令 C-level 以上有感的部門，長期就容易沒有資源，之於個人也比較沒有成就感。

最重要的是，想離開去更適合的地方也變得不太容易，畢竟沒什麼戰功；經濟不景氣的時候，大概也是海嘯第一排XD

也因此作為資料分析師，By Day-1 更需要「小針密縫」，為自己，甚至是部門累積更多的籌碼（Credit）和餘裕。以下是 3 個 從入職第一天起我認為 DA 就可以嘗試著墨的地方，也許對你也有幫助，相信可以在資料分析的旅程上走得更加順利，避免 burn-out 哈哈

專案管理 ＆ 需求文件化

第一點沒有列資料分析的技能，倒不是我認為資料分析本職學能的 SQL / 視覺化工具 / RPython 不重要，主要是因為依照組織規模的差異，以及對於資料驅動業務發展的重視與否，會導致同樣是 DA ，卻有很不一樣的工作日常。通常規模大一點的公司還會有一個人配搭 DA 談需求 ¹，這時 DA 的角色就很像 RD，純粹用 SQL 撈資料與製作報表/儀表板的 RD。

相反地，小公司或新創，或者大公司內剛起步沒多久的資料相關部門，因為分工尚未明確或人手有限，DA 也得自己跟需求方談，這時談需求是 DA，做需求也是 DA；這跟自己要下海幹的 PM 大概相去不遠了哈哈，而通常需要自己下海幹，還能如期如質交付需求的 PM 不會太多個 XD

所以我認為具備基礎的專案管理知識或思維，對 DA 是會有滿多幫助的。

依目前個人粗淺的理解，專案管理的本質，就是風險管理。

典型的專案管理是善用 WBS（Work Breakdown Structure），將一個目標拆解成多個工作包（Work Package）範疇清楚後，再條列出完成各個工作包所需的任務（Task）並分配給專案成員。為難的點是，資料需求往往難以切割，而且通常 DA 也是這個需求唯一的執行者，但至少善用上述的結構，為讓你對於需求的交付估時和需求的複雜度，不會落入莫名的樂觀或悲觀。

舉例來說，如果需求方提出基於特定管理目標的報表，列出來至少需要包含各產品線營收、毛利、所屬業務團隊獲利各自多少、MoM 成長比率（想像是 4 個工作包），就比較可以依照個人對於這幾個工作包相關的 Table 熟悉度、替代資料源的確認、跟資料工程師協調開 Table 權限的時間，一起放入估時的判斷中，也比較好尋求 Senior 成員或主管的協助判斷。

那為什麼需要需求文件化呢？

專案管理的金三角：時間、範疇、成本，交織出這個需求的品質。上述聊了那麼多，無不就是期待範疇清楚下，對於時程的掌握可以比較穩健。範疇不是不能變更，而是怕沒來由的變更或照單全收，導致彼此的不諒解。寫下來，才能做為往後調整、保護自己的依據，像是依照專案金三角的概念，去跟對方溝通：「他的期待，都有代價、都是取捨，重點就擺在他想拿什麼來交換，以及意願程度到哪」

舉例來說，一個 C-Level 高度重視的產品線想要數位轉型，用儀表板來取代給業務團隊的人工維運報表。這種需求，因為受到高度重視，時程通常是最無法退讓的，當對方跑出天馬行空的期待時，DA 可以想辦法協調先追求 initial success case，讓彼此可以對上面有個交代後，再將他的期待放到需求 2.0。另外一個可能性是，如果堅持時程和範疇都無法退讓，那就要讓對方知道那資料品質、正確性將會降低，若對方扛不起，自己多半也會縮回去了。講到這裡若還是不行，通常至少要反應給小老闆，這時也是很好觀察小老闆的時侯XD

最後一點，或許是嘗試迭代調教個人專屬的「需求文件模板」，一個資料需求/專案，要能發揮價值，最重要的是以終為始（專案管理的本質也是），有時需求方「說不請楚他要什麼，可能他只是想給某人一個交代，或者他不了解 DA 可以辦到哪些事，還有極限在哪@@

如果是後者的話，這時需求訪談會議將扮演至關重要的角色，訪談前，請他寫一版 DA 準備好的「需求文件模板」，裡面安插著你模組化後一定會聊的問題，驅動對方去思考進而講清楚說明白。

資料分析

首先，針對資料分析的本職學能，簡單的工具勝過一切；剛入職莫名幻想要用 SQL/RPython 大展身手的我，才發現需求方只會 Excel，短期內終究你還是得給他像是 Excel 那樣的結構化資料…

很快地我也發現其實 Excel 的樞紐，和 SQL/RPython 的 group-by 能實現的事情是一樣的。說到底，Excel 是職場環境中，面對資料，那看似青銅劍，但實際上堪比屠龍刀一般的存在；如果每次都還要進到遠端環境處理，甚至還要覆核流程，倒不如 Excel 能搞定的通通用 Excel 搞定。

再者，不會每一個需求都對組織、個人有一樣的邊際價值，所以學習辨識對你本職學能有幫助的需求是重要的。如果有一個需求的商業價值高，個人技能/領域知識也會成長許多，那毫無疑問就是 Priority-1；但若商業價值不高，不過個人技能/領域知識很高，那至少想辦法保持開發進度。

好比說，嘗試比較進階的 window function 或思考如何處理 json 格式資料、嘗試 create table 建立自己專屬的中繼表或 Data Mart、嘗試建立自己的小小 ETL 排程等等；畢竟職涯很長，資料領域的分工也越來越明確，像是 DA/DS/DE，甚至還有新冒出來的 Data PM、Analytics Engineer。就算哪天不搞 Data，讓自己在工作日常中，在解決問題的同時持續成長是最划算的。

最後，如果不幸（或有幸！？）跟筆者一樣，遇到一個手上資料表都是原始資料的環境…想像資料分析的交付成果，不管是模型、報表、儀表板，都像在炒一盤菜，打開倉庫有的全都是產地新鮮直送的紅蘿蔔或原塊肉，身為 DA 就只能從去骨/刨絲開始。一來上菜的時間一定變慢，這時想辦法跟上游的 DE，甚至是 SA（System Analyst）打好關係，讓他願意跟你分享品種、紋理，也能縮短無效摸索的時間。

這也是 DA 通常處在資料流最末端，卻是資料第一線的使用者，要兼顧技術、業務的迷（血）人（汗）之處…

產業知識的累積

最後一個 Tips，可能也是決定 DA 在崗位上，甚至長期的資料職涯（Career in Data），是否能走得長遠的因素。也就是對於產業知識是否具備好奇心，以及是否有意識地繼續累積。

每個人偏好不同，有人偏好 2C 就一定也有人喜歡 2B 的生意，有時侯直接從 DA 起步，相較於從其他職能，像是業務、行銷轉來做 Data 的人，因為對業態、行話不理解，缺乏產業知識和商業思維的 DA，滿容易落於 Data-ATM 的狀況²。

最後關於人格特質，DA 的工作需要細心和耐心，個人認為如何抓大放小（像是與需求方的既有報表驗證開發結果）是一個值得學習的課題。畢竟職場是一個追求快速迭代的地方，一昧追求永遠不犯錯，不是一個可行的方式。

小結論

突然發現寫得有點多哈哈

總結來說，我認為 DA 的工作大概 = 1/3 PM + 1/3 Data ＋ 1/3 Domain Expert。這三種技能樹，彼此都有發展成核心技能 ＋ 支援技能的機會，目前為止，自認還有許多成長空間，像是：

• 管理資料需求，真的需要動態排程知識/軟體嗎？多複雜的資料需求才需要呢？
• 估計一個資料需求（人、機、料）成本的價值主要可以在哪？
• 需求訪談的技巧
• 資料 ETL 排程工具（像是 Airflow 等）和雲端服務的使用經驗
• 商業思維（畢竟人工報表轉自動化、轉儀表板，可以省下需求方許多時間（成本）沒錯，但是怎麼用資料洞見帶來更多的生意，我還沒有一個完整的經驗。

甚至以底層的職涯經營來看，身為 DA 應該要謹慎平衡 DA = 1/3 PM + 1/3 Data ＋ 1/3 Domain Expert 這個現實。在職涯的早期，應該努力把一項技能練到出類拔萃，努力強化自己的優勢，畢竟職場是一個 90 分，勝過於三個 60 分的遊戲。然後再慢慢培養支援技能。

列了許多可以學的東西很重要，更重要的是追求以終為始，持續打磨自己的天賦與熱情，讓自己的職涯，選擇可以越來越多，路可以走得更加穩健寬闊。

Keep Going~

參考資料

以下資源，也許你會覺得有興趣/有幫助。他們都對我啟發很多，真的非常感謝＝）

• 大人學＿專案管理一日特訓班
• andyrockdata＿給剛入行的數據分析師：想產生價值，在試用期要做的三件事
• 資料科學x商業分析 Snoza＿需求排序矩陣分享
• 吳沛燊＿如何以終為始地展開數據專案?
• AlphaCamp＿LinkedIn文章