資料科學家的工作日常2 – 求職前必須了解的公司組織編制

系列文章

〈資料科學家的工作日常1 – 在資料和程式中挖掘商業價值〉
〈資料科學家的工作日常2 – 求職前必須了解的公司組織編制〉
〈資料科學家的工作日常3 – 建立資料團隊的文化與程式規範〉

組織編制是個學問

由於資料科學家與數據分析部門出現的時間還不長，大家的認知仍有差異，或因為每間公司核心價價、管理哲學不同，導致數據團隊可能會以各種型式存在，常見的型式有三種：獨立部門、隸屬IT（Information Technology，資訊部門）或RD（Research & Development，軟體開發）、隸屬需求方部門。

這篇文章主要討論的是In-house的數據團隊，也就是台灣俗稱的甲方，可能是品牌商、通路商、製造商；而不是顧問型、接案型的公司，也就是台灣俗稱的乙方，如廣告公司。未來有機會我們可以再談談甲方與乙方的差異。

編制A. 獨立部門

獨立部門的Data Team是我最喜歡的編制，也就是說，這個部門裡面聚集了一群資料科學家或數據分析師，有些規模較大的團隊可能還配有專案經理(Project Manager)。如果沒有PM，資料科學家與分析師可能要分飾多種角色，自己處理跨部門溝通與時程控管等工作環境。這種數據團隊主要的工作內容是協助其他部門，我喜歡將其比喻為公司底下的一間小公司，提供B2B的資料分析服務。

編制B. 隸屬IT或RD

先說一下IT與RD的差別，通常IT指的是負責系統整合、伺服器維運的部門，比較像是基礎建設，而RD則是負責軟體開發，像是App或網頁開發等。大部份公司可能都有IT，但不一定有RD。

由於以上的差異，因此，一樣都是程式設計，IT寫的程式跟RD可能不同，RD跟數據分析又可能不同。即使軟體開發工程師和資料科學家一樣都寫Python，但工作目標、使用環境可能天差地遠。也就是說，如果你的職稱是資料科學家，但隸屬於IT或RD，且主管沒有資料科學背景，那他可能不知道怎麼帶這樣一個團隊，不知道這個團隊可以做什麼，需要什麼樣的資源，也不知道這個團隊可能在什麼樣的地方犯錯。

編制C. 隸屬需求方部門

需求方部門可能是業務部門、行銷部門或是供應鏈部門。當隸屬這些部門時，你能獲得的技術支援最低，因為你可能會是這個部門內極少數擁有程式能力的人，而且需求方通常不會招募太多的分析師，一至二人算是比較常見的編制。

接下來的內容會談到幾種不同的情境，以及以上三種編制在這些情境下的優缺點。為避免大量的冗詞，以下內容會分別以編制A、編制B、編制C作陳述。

個人職涯發展性

以資料科學的技術力而言，編制A最佳，編制B次之，編制C最弱；以產業知識來說，編制A、B重廣度，編制C重深度。

在編制A、B中，你有機會跟各種不一樣的團隊合作，像是業務團隊、行銷團隊、營運團隊等，這樣的條件對於職場菜鳥更是難得，能在實戰中探索個人興趣，發展資料科學以外的第二專長。在數據團隊人多、案子也多的情況下，如果你敢爭取，會比較有機會挑案子做，在實務中往自己有興趣的方向發展，不至於做了一堆沒有成就感，或是能見度低的專案。

在編制C中，假設你隸屬於行銷部門，你可能可以深入了解行銷人員在商業上的操作方式，他們怎麼進行活動規劃，在意什麼指標，有什麼行銷手法或工具可以玩。如果你已經很確定自己的職涯方向是資料科學與行銷雙軌並行，那這對你來說會是個不錯的方向。

同溫層

人都需要隊友與同溫層，不只是為了心理層面的認同感，也包括在組職架構下、在各種小團體中，有多少人會跟你站在同一陣線，又有多少人可以你工作量爆增的時候提供支援。

資料科學家這個職業需要混合型的背景知識，要寫程式、懂統計、有商業邏輯、熟悉機器學習模型、懂上台報告的藝術，工作中需要在程式碼和商業思維中來回切換，積極進取的分析師可能還會開開讀書會、唸唸Paper，這一切特徵都顯示出數據團隊從骨子裡的混血基因，因此，讓他們物以類聚可能會是最好的管理方式，也就是編制A。

在編制B中，你可能還可以和同事聊聊技術話題，或是分享一些工程師才會懂的迷因梗。在編制C中，嗯，你可能會有點寂寞。

怎麼挑案子

獨立部門也有弱點。第一個弱點是獨立的數據部門很吃主管、Team Leader或PM的業務力與外交能力，其中外交能力包含了對公司高層及對其他部門。舉例來說，資料科學專案的成立有兩種型式，一種是由供給驅動，另一種是由需求驅動。前者像是你有很好的解決方案，主管拿去其他部門推銷這套解決方案；後者是需求方有痛點，自己沒有能力解決，因此上門求助。

在我的經驗中，以供給驅動的方式很容易失敗，就像廠商主動登門拜訪，很難在短時間內馬上進行合作，通常會先觀望與評估好一段時間。因為需求方一定有一套既定的工作流程，大家照著這套流程執行，彼此也相安無事，但數據團隊的介入勢必會有磨合期，即使長期而言會有正面影響，短期來說很可能會增加需求方的工作量，加上數據部門的解決方案如果沒有切中業務核心，這樣的解決方案很可能以失敗收場。如果失敗的案例不小心又在公司內傳開，其他部門對數據團隊敬而遠之的情況也不無可能。

相反，如果需求方有痛點並找上門，這樣的情況又可以分成好案子與爛案子。所謂的爛案子，通常指的是用SQL把資料抓出來，再用R或Python整理成一份像樣的報表，匯出，結束。這樣的案子不容易看不出數據團隊的價值，說白了，在這樣的案子中，需求方只是需要有人寫程式幫他們抓資料。如果採取績效至上導向，這樣的案子當然能推則推，這又是個考驗Team Leader外交能力的時刻。站在需求方的立場，他們可能真的沒有管道、沒有技術，或是沒有權限可以抓資料，而這份資料可能真的有助於他們提升績效，至於提升績效之後，需求方會不會將部份功能歸功於數據團隊，這又是另外一件事了。

那什麼是好案子？好案子就是需求方有痛點，他知道數據團隊能夠解決他的痛點而找上門，而且數據團隊在這個專案中也能夠彰顯自己的專業價值。其中的困難點在於，需求方要知道數據團隊可以做到什麼事，並願意提出合作需求，但一般人根本不會懂什麼預測、什麼迴歸、什麼分類與分群，他們很可能連你抓得到什麼資料都不知道，這完全仰賴數據團隊過去的戰功，以及PM毛遂自薦與縱橫捭闔的專案管理能力。

舉個例子，不論是什麼產業，庫存管理都是相當重要的課題，因為庫存等同於資金的積壓，沒有庫存又做不了生意，訂貨量夠不夠多、會不會太多，庫存周轉率夠不夠快，這都是可以被一一討論的議題。對相關單位來說，庫存管理是他的痛點，但他可能雙手一攤說，「系統上的建議訂貨數量就這樣給啊」。在這種情況下，需求方可能不知道數據團隊可以協助作庫存管理分析，或是明明知道，但修改系統的工程過於浩大，這件事又沒有非做不可的急迫性，於是就先擱著，等高層發現的時候再來著急。

在挑案子的情境中，編制A、B比較有可能推掉爛案子，但也因為不夠貼近需求方，不容易主動發掘好案子；編制C推掉爛案子的能力最弱，因為需求方跟你隸屬同一個部門、同一個主管，他可能會表示這是部門主管同意執行的案子。

部門角力

在職場生態中，幫公司賺錢的部門通常最有話語權，而數據團隊本質上是後勤支援部門，本身的結果沒有產值，必須由其他部門作出商業行動後，才能對公司達到真正的效益。結果可能是數據團隊的績效與公司業績相掛鉤，卻又不是實際執行業務的人，造成許多數據分析專案在落地前，因為其他部門未能提供支援臨時喊卡。即使專案成功了，功勞的歸屬也與編制有相當大的關係。

舉例來說，公司在雙11期間舉辦了大型促銷活動，數據團隊的任務是選出對此促銷可能有興趣的顧客，讓行銷進行廣告投放。如果這個活動達成了非常高的業績，接下來就是檢視活動成效的時刻。

在這樣的活動中，主導專案的可能會是業務或行銷部門，代表可能會由他們向高層匯報本次的業績與獲利，業務部門可能會說「因為我們的商品選得好，折扣給得夠深」；行銷部門可能會說「因為我們的文案有打到消費者，視覺設計吸引人，產品照片看起來超有質感」；數據團隊可能會說，「因為我把吸引人的商品資訊及文宣傳傳達給正確的消費者」。以上說法可能都對，卻不能稱得上是精準的結論，像是「業務部門貢獻40%的業績，行銷部門貢獻30%的業績，數據部門貢獻30%的業績」，因為這些條件很難用客觀數據量化，即使算得出來，可能也要耗費大量時間與人力，所以實際上很少有人會去仔細計算這些數字，就算你算得出來，也不一定說服得了其他人。

在這個案例中，如果你是編制C的數據團隊，部門主管在報告的時候肯定會提一下自己人的努力與成效，並以數據的力量來加強自身的可信度。相反，如果你是隸屬編制A、B的數據團隊，你們部門會不會有人受邀參與這場會議，本身就是個未知數，可能數據團隊很努力，也有很好的成效，但公司的高層卻沒機會知道。

你的數據可能會得罪人

資料驅動(Data-Driven)文化中的其中一項優勢就是將公司活動數據化，進而規模化、透明化。在未導入這個文化之前，許多的公司業務可能都是透過經驗法則運作，數據的應用是透過人工處理Excel的方式進行，這在數位轉型的過程中勢必會造成一些阻礙。

首先，經驗法則確實有用，可以快速的做出商業判斷，不像數據分析還要收集資料和做研究。然而，經驗法則可能包含了個人的主觀偏見與生活經驗，導致無法綜觀全局，或是跟不上市場的變化速度。當經驗法則與數據分析產生巨大衝突時，資料科學家們可能會收到這樣的回饋，「你確定你的分析結果是對的嗎？這和我們的認知有很大的落差」。

舉例來說，我在會議中常常聽到類似言論，「你確定30到40歲的人比較喜歡產品A嗎？我也是這個年紀的人，我就比較喜歡產品B，我覺得這次促銷應該推產品B」。這時候，我通常會選擇微笑帶過，因為數據分析通常會著眼於整體分佈，而每個人不過都只是分佈曲線中的其中一個點，你怎麼確定自己不是族群中的離群值？

其次，是資料的取得與應用方式。同樣一個Excel報表，原本同仁每天可能需要花一個小時整理，導入數據分析流程後，可能需要先花兩周的時間進行開發，開發完畢後就不需再進行人工作業，每天上班的時候就可以直接閱讀自動化的報表，更節省人力，也更精準，擴充性更高。

在以上兩種情況下，數據文化的導入都嘗試提出更好的解決辦法，卻可能也部份否定了過去的工作流程，甚至讓精簡人力變成是可能的選項之一。在這個過程中，必定會有一些學習能力較弱的人，基於保住飯碗的求生本能而產生抗拒心理，放大新方法的缺點與不成熟，變成數位轉型過程中的反對派。

在這個情境下，編制A、B用數據說出真相，有點政風處的味道；編制C與需求方更像是站在同一條船上，也可能因為說出真相而造成部門內的隔闔。