A Work Day Of A Data Scientist 2

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

目錄

    原始文章

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


    組織編制是個學問

    由於資料科學家與數據分析部門出現的時間還不長,大家的認知仍有差異,或因為每間公司核心價價、管理哲學不同,導致數據團隊可能會以各種型式存在,常見的型式有三種:獨立部門、隸屬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與需求方更像是站在同一條船上,也可能因為說出真相而造成部門內的隔闔。

    結論

    職場中難免會有爭資源、爭曝光、推工作的情形存在,當這些情形發生時,知道自己會處在什麼編制下,有多少人和自己站在同一陣線,這些都可以作為求職時的參考之一。除了預先模擬未來的工作日常外,也可以初步判斷自己的個性適不適合這個職缺。

    舉例來說,如果你不喜歡開大量的會,不喜歡處理人與人之類的事務,但眼前的職缺卻必須自己充當PM的角色,那你是否能接受?或是你不會有一個資料科學背景的主管,所有專業問題都必須自己搞定,很可能在下班還必須主動進修,這會不會是你心目中理想的工作與生活?

    這篇文章說了很多,基本假設都是數據分析可以幫助公司成長。然而,數據分析本身有擴大器的作用存在,可以擴大優點,也可以擴大損失。究竟要怎麼樣才能在資料科學的路上避免犯錯?我們下一篇文章見。



    推薦文章

    Aron

    工業設計系畢業,曾任職知名品牌行銷企劃,做點設計,寫文案也寫網站;目前擔任零售業數據分析師。最近開始研究Python量化投資和虛擬貨幣。

    facebook telegram
    Content Protection by DMCA.com

    發佈留言

    • * 表示必填欄位
    • 您填寫的電子郵件不會被公開
    • 請確認您的電子郵件正確無誤,當您的留言收到新的回覆時,我們會寄送通知信件給您

    發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *