「全棧科學家」模式不適用的可能原因
科學家與工程師的合作模式一直是個問題
數據科學家與業務邏輯密不可分，為了解決特定業務問題，發明、創造並針對性地解決。代表著垂直、專精。
數據工程師則是以重複、模組化為主，類似的問題提供抽象的解法，代表著橫向、泛用。
這兩種工作本質上就有一點衝突，最差的情況合作模式是毫不考慮取捨，讓科學家完全無視工程限制、讓工程師完全脫離商業邏輯，並且也沒有好的溝通管道，那麼一切就會一塌糊塗，多數公司雖然不是這麼地極端，但遇到的問題大概也跑不出這個範圍。
科學家與工程師合作模式的問題，近年廣泛地出現在全世界被探討。即使這在台灣算是相對較不蓬勃發展的行業，但有稍微接觸業界的科學家/工程師，應該都多少能理解這個問題的困境。
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 找我一起交流喔！