「全棧科學家」模式不適用的可能原因

leafwind

研究所涉獵資訊檢索、資料探勘與機器學習|曾在 Appier 擔任軟體工程師,有五年以上資料科學產品開發經驗|熱衷於寫科普文章、分享心得。| Telegram 聯絡我
leafwind

科學家與工程師的合作模式一直是個問題

數據科學家與業務邏輯密不可分,為了解決特定業務問題,發明、創造並針對性地解決。代表著垂直、專精。

數據工程師則是以重複、模組化為主,類似的問題提供抽象的解法,代表著橫向、泛用。

這兩種工作本質上就有一點衝突,最差的情況合作模式是毫不考慮取捨,讓科學家完全無視工程限制、讓工程師完全脫離商業邏輯,並且也沒有好的溝通管道,那麼一切就會一塌糊塗,多數公司雖然不是這麼地極端,但遇到的問題大概也跑不出這個範圍。

科學家與工程師合作模式的問題,近年廣泛地出現在全世界被探討。即使這在台灣算是相對較不蓬勃發展的行業,但有稍微接觸業界的科學家/工程師,應該都多少能理解這個問題的困境。

Stitch Fix 這間公司提出了一個適用於他們企業內部文化的解決方案,標題叫做「工程師不該撰寫 ETL」 Engineers Shouldn’t Write ETL: A Guide to Building a High Functioning Data Science Department | Stitch Fix Technology – Multithreaded

就像原文所說的「你的團隊和數據科學家們之間的關係是怎樣的」是他面試人的時候最常被應徵者問到的問題,這也代表著大家都多少因為工作模式的不順暢而感到挫折。


全棧科學家可以是一個解法嗎?


source: Becoming a Data Scientist – Curriculum via Metromap – Pragmatic Perspectives

這篇文章提出了一個論點,一言以蔽之,就是認為應該將 ETL /data pipeline 的自主權交給數據科學家,換句話說,就是成為「全棧科學家」。

我認為原文的建議是給那些「稍微能夠做出部門分工、正在成長中」的公司參考。

原因是剛起步的新創公司(研發很可能少於 20 人,甚至不到 10 人)本來就不應該、也不可能有明確的分工,更不要說是合作模式;而已經穩定的巨頭公司,當然也不需要這些工作模式的摸索。

然而從我過去的經驗(公司不到 40 人,到現在超過 300 人),這個針對成長中新創公司所建議的合作模式,要使用在我們(與台灣多數的新創),可能還有許多需要克服的地方。

我相信任何合作模式都有適用它的場景,所以並非一味否定這個解法,之所以適用於他們的組織,可能是因為他們的商業模式、投資人要求、招募、營運狀況等條件,都與我們所處的環境不一樣的緣故。

所以即使 Stitch Fix 是一間已經成功 IPO 的獨角獸,我們也未必可以照單全收,但可以做的是去思考何處適用、何處需要修正。

以下列出我認為這種「全棧科學家」模式可能會遇到的困難。


大數據問題

文中有一個很強烈的假設:你或許並沒有大數據,因此不見得需要一個專業團隊來營運數據平台提供服務,或許很多 ETL 工作可以交給數據科學家執行。

但現實中,我們自己的確遇到了大數據問題(文中用了 petabytes of data,暫且稱這樣夠大)。「大」所帶來的就是質變,原本 gigabyte 的資料可以運作的程式,在 terabyte 或許就不可行了。

但我認為這還不是最主要的問題,在大數據 5V 的定義中,大(Volume)只是其中一項而已, 其他面向會如何影響到處理的難度,因為不在這次文章的重心,容我有機會再詳細描述。

這些實務上的問題,在學校或是小公司根本碰不到,別說是給數據科學家處理,對於數據工程師來說也未必是簡單的事情,因此我認為在大數據的環境下,要交給數據科學家處理這些問題,自然就會遇到困難。

幸好這樣的公司並不多,或許你(的公司)並沒有大數據問題,但也不代表這樣的「全棧科學家」模式就真的適用,還有另一個困難的面向是業務導向問題。


業務導向問題

我們知道有一些歐美公司能專注在開發平台與框架,並用來賺錢;另外夠大的企業巨頭如 facebook / google / 阿里巴巴 / 騰訊可能也都有這樣的工作,因為他們組織已經大到,即使有一個部門專門開發平台與框架給內部使用,都是完全有商業價值的。

開發這些泛用性的工程產品並同時養活自己,聽起來是很多工程師理想的工作。

我並不清楚地球另一端的產業生態,但至少在台灣(甚至亞洲),並沒有很多新創公司能夠專心於開發平台與框架,或者說,因為市場上對業務導向的產品需求,仍然遠大於技術平台與框架,若要專心開發平台與框架,就無法作為產品養活多數公司。

很多問題都是這樣被延伸出來的。

極為快速的業務需求迭代

原作者認為,將 ETL / data pipeline 的自主權交給數據科學家之後,數據科學家得以更快速地解決商業需求,數據工程師也能夠專心構建更泛用的平台。

同時,數據工程師必須要能夠預見將來的需求,這也使得他們的工作將更具有挑戰性。

聽起來很完美,然而實際上的商業需求往往是很難預見的。

在以前賣套裝軟體的時代,開發一套軟體可能是以季、甚至年為生命週期在計算;現在我們提供軟體服務,要求的可能是一個月、一週,甚至一天內就要做出符合客戶需求的功能。

當然,一天就要的需求可能很小,但這個小小的業務需求,有可能不適用於現有的架構,再加上大數據問題可能會將難度提高不只一個級別,帶來的混亂也就相對不確定。

在這樣的條件下,數據工程師未必能夠預測出未來的需求,並事先將「積木」構建好讓科學家所使用。

於是又會回到一開始的惡性循環:科學家覺得他們的需求太慢被滿足、工程師忙於一直建水管與資料庫、管理基礎建設的部門則覺得被塞滿的 cluster 機器與硬碟空間越來越無法管理。

註:Stitch Fix 或許沒有這樣的問題,因為他們比較像是 B2C 的商業模式。相較於 B2B,不容易出現一個大客戶就主導(甚至常常顛三倒四)產品走向的問題;但他們同時也要承受 B2C 所帶來的風險,比如沒有大客戶的直接要求,就得「猜」得到顧客需要怎樣的產品,猜不中的下場,輕則 pivot,重則解散公司。


營運效率問題(犧牲的不只是程式效率,還有品質)

文中提到這個「全棧科學家」模式,是用「效率」換來「速度」與「自治性」,但這個失去的效率,在某些情況下可能是過度低估的。

比如他提到「他們可能無法生產出和專業工程師一樣專業且高效率的程式與方案」,這的確是個問題,但至少在我的經驗中「程式的低效率」卻還不是最棘手的問題。

如果只是程式的效率差了一點,或許可以用錢去買更多機器彌補,但品質與穩定性就不一定能花錢消災(即使可以,也通常不是線性的增加)

數據科學家的專業並不是建構穩定的工程系統與對外服務,而即使數據科學家有能力做出高品質的服務,他們沒有心力(通常也不應該)去把工程做好(因為那可能需要數倍的心力)

而不穩定的服務,在沒有大量的數據工程師,或是基礎建設工程師去扛起實作的前提下,則需要數倍的營運人力、輪班工程師,或是更多的一線客服去扛起這些壓力。

即使能維持住這樣的系統,往往也只是暫時的,有兩個原因會讓這樣的狀態很快崩解:

營運資金壓力

這樣的人力支出很可能會帶給公司不小的營運壓力,只有少數資金充裕(有富爸爸)的新創公司願意付起這樣的成本。

再加上近年 AI 難以營利的泡沫不斷被證實,金主也慢慢體認到這樣的「當代顯學」並非如他們所想像那麼地好賺,因此對於變現、營利的要求也越來越高。

畢竟在創業的當下,未來能不能賺錢還不確定,但是在尚未營利之前,投入一線營運人力所需要的成本,卻是紮紮實實的消耗了。

人力流失問題

如果你希望找到聰明有自主性的員工,不穩定的服務與品質,所產生的問題與無力感,必定會把他們逼走。

反之如果公司只是想要平庸的員工,也得確保這些任務都單純到可以被平庸的人所執行,而這跟快速迭代的業務,本質上就是完全衝突的事情。


小結

白吃的午餐不存在

在我的經驗中,現今的許多商業模式都要求速食、快速落地,因此許多業務、營運比例吃重的公司,在根本上就跟這個解法是衝突的。

世界上並沒有白吃的午餐,也沒有一個神奇的模式可以完美地解決「快速將業務落地」的問題,我們只是在各種權衡考量當中做取捨罷了。


「偷渡」工作背後所代表的本質

DevOps 將 Ops 的工作交給開發人員;全棧工程師將後端工作交給了前端;而這次談的全棧科學家模式,則是想讓科學家也兼作自己使用的 ETL / data pipeline。

這些聽起來比較性感的新工作,或多或少都承接(偷渡)了一些比較不性感的工作,其中當然有一些顯著的好處,像是衍生出很多方便的工具,使得:

  • 前端工程師可以做一些簡單的資料庫操作,與後端 API 開發
  • 後端工程師可以做一些簡單的機器管理、佈署與基礎建設維運
  • 數據科學家可以做一些簡單的 data pipeline / ETL

然而不管是 DevOps、全棧工程師,還是全棧科學家,其實都是在把「討人厭的繁瑣工作」偷渡給那些「比較性感的職缺」

這並不稀奇,因為所有軟體工程的工作都脫離不了「將重複的工作抽象、進而自動化」的範疇,然而作為工程師,我們都知道,只要有抽象,就一定會有抽象洩漏。

「抽象泄漏」是軟體開發時,本應隱藏實現細節的抽象化不可避免地暴露出底層細節與局限性。抽象泄露是棘手的問題,因為抽象化本來目的就是向用戶隱藏不必要公開的細節。 – 抽象泄漏 – 維基百科,自由的百科全書

這當中的微妙之處,就在於我們將很多複雜、艱深的知識,抽象成簡單好用的工具;而當需求越來越多樣、系統越來越複雜、組織越來龐大、需要溝通的時候,這些隱藏不住的細節與專業,終究還是會成長到需要處理的階段。


職缺名字越換越炫,但招募失衡的問題永遠都會存在

即使 2019 已經稍微退燒,但在現今的環境中,數據科學家仍然比其他工程師職位來得熱門。

或許數據科學家以後會消失,但不管時代怎麼變,越「性感」的職缺永遠會比那些看似枯燥的職缺來得受歡迎,這些枯燥的專業需求從來都沒有消失,只是以另一種形式(框架、平台、工具)出現而已。

好比說,現在新創幾乎很少在找 DBA(資料庫管理員),但是每個工程師都要略懂資料庫的概念,並且真正需要優化、有效率管理的時候,還是得交給有實際經驗的人才能做到,這些知識的需求沒有消失,多數時候只是變成我們的隱性技術債,存在於那些好用的框架或平台上而已。

該如何自處

講了這麼多,似乎也沒有提出一個完整、有建設性的方案,不過我還是盡量就自己有限的所知提出一些看法。同樣地也未必適用於每一間公司的狀況。

在創業早期,適度的全棧化是必然的,帶來的好處或許也多過壞處;然而隨著組織成長,很快就得區分出專業。也就是說,在業績成長、組織擴張的同時也必須要將合作模式進化。

有些公司比較晚來到這個階段、需求也相對收斂,所以可以用全棧模式延續比較久,有些公司則很早就遇到問題,這非常仰賴管理者的經驗與智慧去解決,不是一味全棧化將繁瑣工作包裝給另一個性感職缺,就能皆大歡喜的事情。

同時身為技術者,適度地將底層技術封裝成好用的積木,也是不可逆的趨勢。但問題通常也不是出在做積木本身,而是該在何時、如何爭取資源(時間、人力)做積木,以及如何避免做了積木卻只用一次、甚至沒人用的窘境。

從我的角度來看,數據工程師不應該將繁瑣的 ETL / data pipeline 全包,但也不應該完全讓數據科學家自己處理。

在數據科學家相對可掌握的資料流環境中,提供足夠的自主權、在超出數據科學家專業能力範圍的部份參與設計、提供協助甚至代為實作,類似這種較為彈性的合作模式,或許是可以考慮的方向。

聽起來非常中庸,沒有一個確切的準則,但畢竟現實就是如此混沌,硬要定出一個準則反而有點不切實際了。

另一個很重要,但礙於篇幅無法在這篇文章著墨的,就是溝通這件事情。

商業邏輯與抽象資料平台的思考模式,有著天差地遠的不同,好的溝通方式與管道可以讓這整篇文章的問題變得足夠小,反之若沒有一個好的溝通方式,一間公司的科學家與工程師絕對是雙方都會工作得很痛苦。


參考資料


歡迎加入Telegram 寫寫村或是到 Telegram 找我一起交流喔!

Subscribe “All About Data” !!

累積一定數量的文章會寄信通知,不會太多,因為我很懶

相關文章:  資料科學的職稱分類演進

您可能也會喜歡…

發佈留言

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

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料