資料科學家的工作日常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推掉爛案子的能力最弱，因為需求方跟你隸屬同一個部門、同一個主管，他可能會表示這是部門主管同意執行的案子。
到ARON HACK網站看完整文章〈資料科學家的工作日常2 — 求職前必須了解的公司組織編制〉