這篇文章在Hacker News轉載后產生很熱烈的討論，主要是從工程師的角度來看問題，討論了很多有關人員管理和團隊分工等一些很現實的問題。不是所有人都同意文中的觀點和解決方案，也有很多人寫出了自己的經歷來佐證作者的想法。爭議主要在于ETL工程師的工作價值以及不同職責間的分工問題。
“您的團隊和貴公司數據科學家之間關系如何？”我在面試數據平臺工程師時，這絕對是我聽到的最多的一個問題。這是個好問題，提問者可以有效的衡量這個新職位的好壞。我很樂于回答這個問題。不過我寧愿這個問題不出現，因為面試者往往是因為懷疑或者害怕才問的。
為什么呢？去看看硅谷鋪天蓋地的數據科學方向的招聘啟事，你可能會覺得數據科學家和工程師之間很有合作精神和創新精神，簡直就是形影不離。
然而現實很殘酷，這種狀況很少發生。在大多數公司中，數據科學家和工程師之間的合作經常是低效率的，有時甚至形同陌路。
◆ ◆ ◆一個典型的數據科學部門什么樣？
大多數公司將他們的數據科學部門分為3組：
l 數據科學家：搞統計的里面編程最好的，搞編程的里面統計最好的。也稱為“動腦的”。
l 數據工程師：搭建“管道”，為數據科學家輸送數據，從數據科學家那里獲得想法，然后執行出來。也稱為“干活的”。
l 基礎設施工程師：維護公司的Hadoop集群或者是別的大數據基礎設施。也稱為“管道工”。
數據科學家總是嫌棄數據工程師的執行效率太低，而且工作周期、路線圖和動機不協調。在數據工程師將他們第一個版本的想法放到A/B測試時，他們的第二個和三個版本的想法已經出來了。數據科學家的抱怨是完全有道理的。
數據工程師總是嫌棄數據科學家寫代碼又差又慢，從來都不考慮把這些想法投入產品中會產生多大的后續影響。還嫌棄這些“動腦的”總是提出一些不切實際的要求，最后的結果也并沒有多么好......他們的抱怨還有很多，這里就不一一贅述了，你懂的。
基礎設施工程師的情況也好不到哪里去。所有的人都往集群的磁盤上堆積數據，很快就需要清理了。平時他們沒有機會接觸上面的兩類人，對于他們如何使用這些基礎設施，以及這些人要解決的技術或業務問題并不是很了解。這讓他們在解決問題提高當前境遇時覺得自己微不足道。這時候，他們就限制大家對基礎設施的使用。這樣一來，只能讓其他人對他們更加惱火。
一個惡性循環就這樣產生了。
◆ ◆ ◆這是怎么回事？
這個循環里的所有人都知道當前的工作狀態其實不怎么樣，現階段的大規模招聘的工作內容也很可能一般。為什么不解決這個問題？為什么所有的數據科學和算法開發部門都會陷入這個惡性循環？為什么？！
我主要怪下面兩個事情
第一 你的數據根本不算大數據
最近五年里，數據處理工具和技術獲得了飛速的發展。除非你需要處理PB級別的數據，或者每天要處理千億級的事件，現階段大多數技術已經能輕松滿足你的需求了。
除非你想把現有技術級別再推進一層，一般來說你是不需要一組專業工程師在這些技術上層構建解決方案。如果你成功的招聘到了這樣的人，他們很快就會覺得無聊。如果他們感到無聊，他們絕對會很快拋棄公司投入谷歌、臉書、領英（譯者注：國內同理百度、騰訊和阿里）這類公司的懷抱。在這里，他們的專業技能才會真正被需要。如果他們做的還挺開心的，最大的可能就是他們非常平庸。水平一般的工程師最擅長的事情就是把復雜的事情搞得更復雜，制造出一團他們稱作“解決方案”的亂麻。因為越復雜的事情越需要專家。
第二 大家都想當“動腦的”
那必須的，“動腦的”聽起來才比較酷炫呀！每天你就坐在那里，想想怎么把事情做的更好，然后把自己的想法甩手給那些急迫的想把你的想法變成產品的人的手中。我敢說你在街上隨便找一個人跟他說一下這個工作情況，他都會瞬間接受的！數據科學家，尤其是剛入行的新人們，都拼命想把自己的工作變成這個美好的藍圖。
那是因為我們已經把這個想法根植于他們心中。為此，我們應該感謝已經存在了多年的大公司，他們在大數據風潮出現之前已經成立了商業智能部門......
一個傳統的商業智能部門有以下三個人設：ETL工程師，報告開發者，數據庫管理員。ETL工程師負責把數據放入數據倉庫，最能讓他們著迷的就是各種數據建模,比如Kimball的維度建模方法。報告開發者的職責就是用一個專業的工具（比如Microstrategy和現在大熱的Tableau以及Qlik）設計出展示各種數據的圖表報告，他們是專家。數據庫管理員（和其他工具管理員）的主要職責就是讓所有的工具保持運作、不出任何問題。
你可能也發現了，在這個設計中所有人都是“干活的”。在大約10年前，大數據和數據科學剛剛成為流行語時，已經有非常成熟的商業智能部門了。在這些部門里，“干活的”比較多，但“動腦的”不夠。所以就專門為“動腦的”設置了一個崗位。我們把數據科學家和商業智能部門整合在一起，保證他們有能力自由擺弄數據和直接改變公司業務。聰明的讀者你可能已經猜到了，現實并不是這樣的。這些數據科學家偶爾可以做出一些不錯甚至酷炫的東西出來，但是大多數時候，他們的工作僅僅是水平高一點兒的報告開發者。
但是數據工程師這個崗位聽起來真的好有吸引力，很多人爭相應聘。所以這既傳統又現代的數據科學部門橫空出世：數據科學家（報告開發者，“動腦的”），數據工程師（ETL工程師，“干活的”）和基礎設施工程師（數據庫管理員，“管道工”）。
咦？好像商業智能部門兜兜轉轉但是本質并沒有變，僅僅是把Hadoop集群加進去就搖身一變有了新名字。
◆ ◆ ◆現況真的有我說的那么差嗎？
這取決于你的目標是什么。如果你同意我上面的觀點，那這個運行方式已經存在了很多很多很多年，從商業智能出現的時候（對于硅谷來說簡直就是遠古時代，譯者注）。但是我堅信這個方式是非常低效的。除了做幻燈片和好看的數據面板之外，你的數據科學部門應該有更大的抱負！
最根本的問題就是這個方案假設有一大批杰出的工程師，他們迫切的想實現數據科學家的想法，而這個假設與現實情況相去甚遠。如果你認識這樣有才華的工程師，記得給我打電話哈。
在這個方案中，如果出現系統或者實現的問題，責任都在“干活的”身上。如果項目成功了，那最后功成名就的是“動腦的”。這是現階段各個角色無法調和的根本問題。
如果你想招到真正的工程師人才去做“干活的”角色，你的業務規模需要非常大才會讓這些人才獲得解決問題的快感。你需要因“大數據”的出現才造成的問題。不過請你捫心自問一下，究竟自己有沒有大數據。很不幸，你根本就沒有！
那么你只能去找一些資質平庸的工程師。他們會讓你的項目更加復雜，還記得上文的惡性循環嘛？最后的結果就是有一組數據科學家，他們只能做一些以前報告開發者做的事情，因為并沒有一個創新的、穩定的數據平臺幫他們實現想法。但是如果你的招聘啟事上側重于實現的方面，這些人絕不會來應聘的。畢竟他們是“動腦的”，又不是“干活的”！
◆ ◆ ◆一個與眾不同的的數據科學部門
與其試圖模仿知名企業的固有框架，我們更需要創新和發展新的模式！
幾年前，我就是為此加入了Stitch Fix。在Stitch Fix，我們力爭做出世界上最好的算法和分析。我們試圖用我們的成果引領商業潮流。除非你愿意大膽質疑、重新思考你認為不好的事情，否則這是一個很難的完成的目標。
看著我們的部門過去兩年的成長，我很有信心來分享一下我們在做些什么。
我們的目標是引領，而不是簡單的開發，我向你推薦一個我認為能更好地搭建數據科學部門的方法。這個方法可以更好地達到角色自治，每個人真正擁有從頭到尾的任務所有權，并為最終的投產和結果擔起責任。這個方法最適合那些擁有快速發展的商業模型（或數據模型）的公司。
下面是一個創建高效運轉、引領創新的數據科學團隊的藍圖，它是通過統領思想、APIs和代碼一起產生的，而不是被業界的變化牽著走，也不是為了試圖重新定位而被迫生硬地組合著PPT演示稿。
◆ ◆ ◆讓每個人都能做最好的自己
讓我們暫時忘掉傳統的角色，想想什么樣的動機能讓人們在每天清晨興奮地來上班。
無論是什么角色，凡人和偉人間一個重要區別是他們對于創造的渴求和創新的能力。偉人能夠發現問題并創造性地解決問題，這使他們遠離平庸。他們在一個能夠自治、擁有所有權、能夠專注的環境中表現卓越，并且他們渴求這樣一個環境。
組裝線的模式恰恰造成了截然相反的環境，等于把數據科學家的手銬在工程師身上。（事實上，“動腦的”也討厭自己要依賴“干活的”）。關鍵就是要營造一個每人都能擁有自治權、任務所有權和能夠專注的環境。
我們還要認識到，讓數據科學家和工程師慷慨激昂的工作類型是非常不同的。
數據科學家：數據科學家喜歡解決那些與業務縱向連接的問題，那些通過他們的努力能夠對組織或項目的成功產生重大影響的問題。他們致力于優化某些事情或進程或從頭開始創造一些東西。這些都是點導向問題，他們的解決方案也是點導向的。他們通常涉及到業務邏輯的重新組合，重新思考問題該如何解決，和如何創新。因此，他們需要深入了解業務的具體部分是如何操作的，并且與垂直業務部門保持高度合作關系。
數據工程師：工程師擅長于做抽象和概括的工作，并在被需要的地方找到有效的解決方案。這些問題通常是橫向性質的。當可以廣泛應用的時候，它們是最有影響力的。他們需要很好的、全面的了解業務是如何運作的，但是解決方案的抽象性質意味著他們不需要對業務邏輯有太深的了解，也不需要與業務部門深度合作，或是深入理解業務的縱向市場。
◆ ◆ ◆“動腦的”“干活的”混血
在數據領域中，工程師們常常擔心，無論你的職位描述是什么，你其實是想偷偷地招聘一個ETL工程師。
以防你還沒有意識到這一點——沒有人喜歡書寫和維護數據管道或ETL。這是業界誰都不愿意干的。ETL工程師就是平庸的代名詞，這實在不是什么值得驚訝的事兒。
工程師不應該做ETL。這就不應該是一個專門的角色。沒有什么比寫代碼、維護、修改和支持ETL來產生一些自己永遠不會用到的數據更消耗人的精神了。
相反的，應該給人們工作從終端到終端的所有權（自治權）。對于數據科學家來說，這意味著對ETL的所有權。這也意味著數據分析和數據科學產出的所有權。數據科學家努力的最好結果的消費者應該是機器，而不是人。不是一份報告、數據面板或PPT，它應該是某種算法或API，被整合到工程棧 ——從根本上改變企業的運作。自治權是指數據科學家擁有該代碼。從開始寫代碼到最后投入使用。他們應該能夠不需要工程師的許可就可以進行研發和調配，并負責到底：產品的性能，延遲和SLA要求等等。
這使得縱向責任和焦點直截放到數據科學家的手中。但是，數據科學家通常不是訓練有素或者高度熟練的軟件工程師。你頂多可以說他們是”水平尚可”。所以，你會認為他們會造成很大的混亂。
這就是為什么ETL和API/算法投產開發通常被流水線式地移交了工程師。但是，所有這些任務本質上是縱向（點）定向。在數據領域才華橫溢的工程師幾乎都是專注于橫向應用的。
所以，那么在這個新的、橫向的世界中一個工程師的作用是什么呢？概括起來，工程師們必須能部署平臺、服務、概念和框架，使數據科學家來能夠自由的構想、開發和實現他們的想法（如工具、框架、或用于構建、安排、執行ETL的服務）。我喜歡用樂高積木的角度去思考它。工程師設計新的樂高積木塊，數據科學家用創造性的方式來組合積木，創建新的數據科學產品。這談何容易，但是：
工程師的工作本質上是水平方向的。這使他們能夠專注于構建廣泛應用于跨多個數據科學問題的技術。這最大限度地發揮了工程輸出的杠桿作用。這很棒，因為在你的數據科學部門里數據科學家可能比工程師多很多。
工程師們專注于自己最擅長的：抽象、概括、創造高效的、可升級的解決方案。
工程師可自主操作，不受他人影響。從工程團隊以這種方式部署的生產應該像“魔術”一樣。對于數據科學家來說，事情就應該是“水到渠成”的，因為他們的需求能夠被預料到，他們所使用的的平臺、服務和框架都被妥善的照顧著。
為了使這些可以順利進行，大部分時間里工程師需要預測到數據科學家的需求。他們應提前制定多個步驟。
對于才華橫溢、創造力非凡的工程師和數據科學家來說，這樣太有趣了。
◆ ◆ ◆ 所有的工作都由科學家來做嗎？完全不是這樣的。如果有這樣的事情話，工程師的角色比標準模型中角色更具有挑戰性，要求也更高。數據科學家也是一樣的。我們并不是為了效率來優化組織，只是為了優化自治權。這能夠明確想法的所有權和傳遞責任。
這些角色對于那些擁有企業家精神的人吸引力是巨大的。它使快速運轉成為可能，消除了那些達成不必要共識的需要，并為破壞性創新打開一扇大門。但它的確是以專業化和效率作為代價的。
然而，我們并不是期望數據科學家突然成為優秀的工程師。也不希望工程師完全不了解業務邏輯和垂直舉措（vertical initiatives）。實際上，合作是這個模型取得成功所必須的。工程師們需要建立防線，來防止數據工程師掉進陷阱，產生一些不能擴展的、不可靠的解決方案。
在沒有得出解決方案的框架前，工程師要與科學家合作來開創解決方案。而不是甩手不管。工程方面的挑戰是建立自服務組件，例如數據科學家可以自主的重復業務邏輯和算法，將他們的想法應用到業務中。有了最初的的解決方案后，誰擁有什么就很清楚了。工程師擁有他們建立的基礎結構，數據科學家擁有業務邏輯和算法實施方案。這就不需要重復任何緊密耦合。
◆ ◆ ◆一個有挑戰性的合作方式
此時，你可能會懷疑是否能夠實現這種合作方式。然而，我認為值得冒險。以下是可能會妨礙進步的幾個方面，需要注意：
人們是不愿意改變的。人們總是傾向于重新創造一個他們原本熟悉的工作環境。這就會對恢復“動腦的”-“干活兒的”（Thinker-Doer）模型產生壓力。新雇員需要快速熟悉新結構。
當項目遇到困難時更要保持警惕，例如，API斷裂或者算法產生了不好的結果。
人們在這些情況下表現非常敏感。他們會堅持工程師們應該承擔責任。但是，他們是在強調表面現象而不是問題。工程師們應該建立更好的平臺支持、可視化、概念（abstractions）和彈性（resilience）。并且，他們應該意識到工程師們也會犯錯——沒有人不犯錯。
平臺工程師先于數據科學團隊考慮問題是非常必要的。你需要非常機警的平臺工程師，他們憑直覺就能決定將來什么地方需要什么服務、框架和技能。沒有從科學家到工程師的傳送過程，意味著工程師們沒有對科學家們提出的要求作出及時的反應。
記住，工程師們是在創造樂高積木，數據科學家團隊是在組裝他們。如果數據科學家團隊不需要糾正積木而只是組裝，他們就會一直努力直至創造出解決方案。他們會通過組裝錯誤的積木（把方塊放到一個圓洞里），或者創造他們自己的積木來解決問題。一般他們會陷入混亂（Big Mess）。原因是一旦被創造出來就很難被撤銷。
◆ ◆ ◆不要害怕低效
讓數據科學家擁有更多權限，其中一個后果就是他們可能無法像工程師一樣寫出有效的代碼或解決方案。我們為了速度和自主權犧牲了技術效能。意識到這是一個深思熟慮后的權衡，這很重要。
然而，很明顯，從終端到終端的所有權（自治權）效率較低。數據科學家是他們的解決方案的實施領域里的專家。因此，他們很容易在技術成本、支持成本與要求之間做出權衡。
例如，他們可以決定在特定位置取樣，在適當的位置使用合適的方法，并做出增加某些特征的決策，即使這個決策花費了高昂的開發成本，卻只產生了微不足道的業務影響。這在科學家和工程師的裝配線式合作模型中基本不可能發生（如果他們非要這樣做，通常需要無數輪談判）。
總的來說，我們希望允許數據科學家擁有自主權和創新產生的結果能夠彌補因缺少技術專業性而帶來的低效。
◆ ◆ ◆未來
我并不認為我們已經發現了構建數據科學部門最好的架構，也不認為對于你的組織來說這是最好的架構。但是，我認為這對于Stitch Fix（作者JEFF MAGNUSSON所在公司）來說這是一個更好的解決方案。
我真誠的希望分享我們的做法能夠鼓勵那些非傳統架構的部門也進行這樣的嘗試，鼓勵數據科學部門的負責人不受拘束的思考，鼓起勇氣去挑戰傳統，告訴那些對傳統角色非常失望的工程師和數據科學家，有不同類型的工作環境等待著他們的加。
京公網安備 11010502049343號