此为历史版本和 IPFS 入口查阅区,回到作品页
ARON HACK 亞倫害的
IPFS 指纹 这是什么

作品指纹

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

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

系列文章

〈資料科學家的工作日常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推掉爛案子的能力最弱,因為需求方跟你隸屬同一個部門、同一個主管,他可能會表示這是部門主管同意執行的案子。


到ARON HACK網站看完整文章〈資料科學家的工作日常2 — 求職前必須了解的公司組織編制〉

CC BY-NC-ND 2.0 授权