[[174647]]

前言

在很多互聯網公司的算法相關部門(例如搜索、推薦、廣告)里，都有“做算法的”和“做工程的”兩個工種。這個看似天經地義的分工方式是否就是***的方式?這似乎還是存在一些爭議的。

這篇文章闡述了一種當前較為普遍合作模式下的問題，譯者覺得說得很在點上。更寶貴的是，作者同時也提出了一種可能會更好的合作模式，能夠解決這些問題。

需要提前說明的一點，文中的“數據科學家”可理解為我們常說的偏算法的工程師，而文中的“工程師”或者“數據工程師”可理解為我們常說的偏工程或者偏架構的工程師。

正文開始

“你的團隊和數據科學家們[1]之間的關系是怎樣的”?毫無疑問，這是我作為面試官，面試數據平臺工程師[2]時最常被問到的一個問題。這在面試過程中是一個很正常的問題，屬于求職者評估新機會的必要流程。而我也經常很樂于回答這個問題。但是我希望我不需要回答，因為這個問題的背后，折射出的是懷疑和恐懼。

為什么呢?如果你閱讀一下硅谷科技公司里數據科學與算法開發部門的招聘啟事，你或許會相信數據科學家和工程師之間的關系是高度協作、有機并且富有創造性的。

但是，行業里的真實情況卻并非如此。大多數場景下，這兩者的關系其實是介于“不存在”[3]和“高度功能失調”之間的。

一個典型的數據科學部門

大多數公司將他們的數據科學部門劃分為三個組：

數據科學家：這些家伙就是那些“工程比統計學家好&統計比工程師好”的人。也就是所謂的“思考者”。

數據工程師：這些人構建數據通道，將數據“喂”到數據科學家“嘴里”，然后從數據科學家手里拿到idea并且實現它們。也就是所謂的“執行者”(Doer)。

架構工程師：這些人維護Hadoop集群以及其他大數據平臺架構。也就是所謂的“水管工”[4]。

數據科學家們經常不爽的是，工程師們實現算法的速度太慢，以及他們之間的工作流程，路線圖以及動機總是同步不到位。當他們想法的版本1進入ABTest的時候，版本2和版本3早就已經排好隊了。他們的失望和不爽是非常可以理解的。

數據工程師們經常不爽的是，數據科學家們給出的代碼總是效率低下，代碼丑陋，幾乎從不考慮可維護性和工程化問題，而且會提出一些不現實的功能需求，結果是破壞了工程實現方案，但也沒有得到什么好處。這種問題繼續下去還有很多，但是相信你已經懂了問題在哪里。

而架構工程師們對他們都不爽，因為他們總是將集群上塞滿任務，將硬盤里塞滿數據。而且他們常常與數據科學家和工程師們都離得比較遠，這意味著他們從來不知道集群是在什么場景下被如何使用的，也不知道集群被用來解決什么業務或技術問題。這讓他們在很難擺脫當前不爽的境地。所以，他們的應對方法就是對集群做更嚴格的限制，這樣做的結果，就是其他人都開始對他們感到不爽。

這顯然是個惡性循環。

哪里錯了?

我們都知道這樣做是不對的，那我們為什么不解決這樣的問題呢?為什么每個數據科學和算法開發部門似乎都會滑落到這樣“功能失調”的模型中?

我將這其中的癥結歸于兩件事情，在這里用一些觀察來做出闡述。

你或許并沒有“大數據”

數據處理的工具和技術在過去五年間發生了巨大的進步。除非你要處理幾個P級別的數據，或者每天需要消費千億級的事件，那么大多數技術現在都可以輕松擴容到你所需要的規模。

除非你有試探這些技術的極限的需求，你或許并不需要一只高度專業的專業工程師團隊來在其基礎上構建解決方案。如果你雇傭了這些人，他們會感到無聊。如果他們感到無聊，他們就會離你而去，去到他們的專業技能更能發揮作用的地方，例如Google，Facebook等等。如果他們不感到無聊，那么他們的技能很可能非常平庸。平庸的工程師最擅長的事情，就是構建巨大無比、過于復雜、難以使用的垃圾，然后稱之為“解決方案”。而垃圾往往需要更多的維護工作。

每個人都想做“思考者”

因為這聽起來更酷!你可以整天坐在那里，思考做事情更好的方式，然后把你的思考結果甩給那些急于將它們工程化的工程師們。大街上每個人都會喜歡這個職位的!數據科學家們，尤其是那些剛剛工作、對行業了解不多的，對這樣的職位尤其喜歡。

這些都是我們引導的結果，而一些大公司更要為此負責，尤其是那些在大數據瘋狂之前就已經有了數據智能部門的公司。

一個傳統的數據智能部門包括三種角色：ETL工程師，報告工程師(report developer)，以及DBA。ETL工程師把數據轉移到數據倉庫中。報告工程師的主要工作是在特定工具(例如MicroStrategy)中設計報告，這些人是領域內的專家。DBA(和其他工具管理團隊)的工作就是讓這一切都流暢運行。36大數據(http://www.36dsj.com/)

這里的問題在于，ETL工程師，報告工程師還有DBA全部是執行者，所以，當十年前“大數據”和“數據科學家”這些詞匯剛剛興起的時候，這些傳統的BI部門面臨著執行者太多，而缺乏思考者的問題。所以他們制造了“思考者”這樣一個職位。我們向數據科學家許下承諾，承諾他們可以隨便折騰數據，進而改變世界。但事實上并非如此。這些數據科學家有時會創造出一些很酷并且有用的方案，但是在大多數時間里，他們做的工作并不比報告工程師高明多少。

但是這個職位聽起來很酷，而且比較容易招聘。所以就誕生了當代傳統的數據科學部門：數據科學家(以前的報告工程師，現在的“思考者”)，數據工程師(以前的ETL工程師，現在的“執行者”)，以及架構工程師(以前的DBA，現在的“水管工”)。

呵呵，看起來數據智能(BI)部門從來就沒有改變，我們只是加了個Hadoop集群然后換了個新名字。36大數據(http://www.36dsj.com/)

真的那么糟糕嗎?

這個問題取決于我們的目的是什么。如果你同意上面的觀點，那么你得承認，自從BI興起之日，很多公司使用這樣的模式使用了很多年。但是如果你希望你的數據科學團隊能夠產出PPT以外的更多成果，那么我認為這是一個非常低效率的模型。

上面的“思考者”+“執行者”模式想要成功的一個基本假設是：需要有一群出色的工程師，他們沒有自己的靈魂，只是積極地將“思考者”的想法實現落地。但是，這樣的工程師，會是出色的工程師嗎?

在這個模型中，執行者們需要為其他人思想的實現和失敗負責，而思考者則因為成功而受到獎賞。這就是團隊中爭論和嫌隙的核心。

如果你希望為數據工程師崗位招聘到有天賦的優秀人才，你需要一些更大規模的、更NB的問題來讓他們解決，好讓他們的工作中不只是毫無靈魂地實現別人的想法。你需要的是大數據催生的大規模問題，但問題是，你并沒有大數據。

所以，你只能雇到中庸的工程師。他們會制造出大量的爛攤子，進一步加重問題，讓你走上惡性循環。最終的結果，就是數據科學家并不比傳統的報告工程師厲害多少，因為他們缺乏一個創新、堅固的數據平臺支持。進一步，如果你把他們定位為報告工程師，數據科學家們就該跑路了，畢竟，他們可是“思考者”，不是“執行者”!

一種不同的數據科學部門

在這個問題上，我們不應該去一味地效仿那些大公司的做法，而是應該想辦法去革新這個模型。別再試圖去設計更快的馬了[5]……

幾年以前，當我我加入Stitch Fix也正是這個原因。在Stitch Fix，我們努力在算法和分析方面做到世界***。我們的方法是通過輸出來領導行業，而不是把結果簡單地告知(inform)[6]。所以要想達到目的，必須從心底認為當前的模式是不對的，這樣才能全身心投入地創造更好的新模式。

在見證了過去兩年中我們部門發展壯大的過程后，我有信心將這些與大家分享。既然我們的目的是通過輸出來領導，而不是告知，我希望分享一種我認為更好的數據科學部門的組織方式。這是一種完全“自治”的角色，一種從頭到尾負責到底的責任感和ownership，并且要為結果負責。這是一種更加適合快速發展和迭代的公司的做法。

讓每個人都成為***的

讓我們忘掉傳統角色的分別，來思考一下工作中真正讓人興奮的地方。

不管什么角色，普通和優秀之間***的差異之一就是對創新的渴望和能力。優秀的人能夠識別并創造性地解決普通人無法解決的問題，他們更適合，也更渴望一種自治、ownership和專注的環境。

從數據科學家到工程師的流水線完全是這種環境的反方向(事實上數據科學家們也不喜歡如此依賴“執行者”)。所以訣竅就在于為每個人都創造足夠自治、ownsership和專注的環境。

但需要注意的是，能讓數據科學家和工程師們興奮的點是完全不一樣的：

數據科學家

數據科學家們喜歡的問題是與業務緊密相關，能夠通過自己努力直接影響項目或者組織的成敗的。他們對某些事情或者流程進行優化，或者從頭創造一個東西。這些都是針對性很強的問題，所以他們的solution也會是這樣。這些solution涉及到各種商業邏輯的混合，對運行流程的深入思考，以及大量的創造性。因此，這需要對業務邏輯中某個部分的深刻理解，以及對業務過程的縱向深入參與。

工程師

工程師們擅長將問題抽象、泛化，然后找到優雅有效的解決方案。與數據科學家們感興趣的問題不同，這些問題一般都是橫向的，也就是說，他們在被廣泛應用時能夠發揮***作用。這需要對業務運轉整體流程的整體深入理解，由于這些解決方法都是高度抽象的，因此并不要求工程師對業務的某一部分有非常深入的了解和參與度。

知行合一(Hybrid Thinker-Doer)

數據工程師們最害怕的事，就是盡管你的JD寫得非常炫酷，但是你心中真正想要招的，還是ELT工程師。

如果你還沒有意識到，那我可以告訴你：沒有人喜歡簡單地編寫和維護數據管道或者ETL。這是這個行業里最燙手的山芋。因此，這個職位成為孕育平庸的溫床也就不足為奇了。

工程師不應該寫ETL。這不應該是一個專門的職位，沒有什么比編寫、修改、維護、支持一堆自己從來不用的ETL更讓人沮喪的了。

相反，應該將工作整體的端到端的所有權交給員工。對于數據科學家來說，這意味著對ETL的所有權，對分析和最終產出的所有權。數據科學家們工作的***產出應該是面向機器的，而不是面向人的。***的產出物不是PPT或者報告，而是一個算法的API，可以通過調用這些API來改變業務。自治權同時也意味著對代碼的所有權。從開始開發一直到生產上線。他們應該可以獨立部署應用，并對其性能、效果和其他支持負責。

但是數據科學家們一般來說在軟件開發方面并不是非常專業，最多算是合格。所以他們可能會在工程方面制造很多混亂。這也是為什么數據的ETL和算法的落地開發通常都會交給專業工程師來做。這些任務本質上都是垂直(縱向)聚焦的，但有天賦的工程師們最擅長的往往是應用的橫向擴展[7]。

那么在這種場景下，工程師的職責應該是什么呢?綜合來說，他們需要部署平臺、服務、框架，使得數據科學家們可以自主的快速開發、部署他們的想法。可以將這些工作類比為樂高積木：工程師們設計樂高積木塊，數據科學家們通過組裝這些積木塊來實現新的想法。這樣做的好處非常明顯：

工程師們的工作變成了完全橫向的。這讓他們可以專注于設計開發能夠橫跨多種算法應用的技術。這樣做可以將工程技術的輸出***化。

工程師們可以專注于他們最擅長的：抽象、泛化，然后構建有效的，可擴展的技術方案。

工程師們可以自主工作。這樣運作的工程團隊工作起來就像變魔術，數據科學家們所期待的所需要的東西全部是可以提前預料到的，擴展性和健壯性全部交給了平臺、服務和框架，而這些正是工程師們的工作。

為了讓這套機制能夠正常運轉，大多數時候工程師們需要能預料到數據科學家們的需求，他們需要提前提前若干步進行開發。

對于有天賦的工程師和數據科學家來說，這顯然有趣多了。

所以，所有的工作都被數據科學家們干了嗎?36大數據(http://www.36dsj.com/)

完全不是。相反，工程師們在這個系統中承擔的職責要比傳統方式中更加具有挑戰性，也更加被需要，對于數據科學家來說也是一樣。我們這套機制并不是在優化效率，而是在強調自治性。這套機制的產物是明確的自治權和對結果負責的明確責任。

這對富有創業精神的人來說是非常有吸引力的。它打開了快速開發和顛覆式創新(disruptive innovation)的大門。但它的代價是一定程度的專業度，也就是一定的效率。

我們并不期待數據科學家們忽然變成有天賦的工程師，我們同樣也不希望工程師們完全不了解業務邏輯，丟掉垂直深入的主動性。事實上，團隊合作(partnership)才是這個模型可以工作的核心。工程師們應該將自己看作“鋼鐵俠的裁縫”，他們的使命是建造出強大的鋼鐵戰衣，防止數據科學家們落入方案不可擴展或者方案不可靠的陷阱。

一條極富挑戰性的路

看到這里，你或許在懷疑這樣的機制能否真正建立起來。但是這樣做帶來的收益完全值得去冒險。下面是一些可能會阻礙這個甚至會逆轉這個過程的問題：

人們不愿意改變。人們總是傾向于重建他們習慣的環境，這會導致他們傾向于返回到傳統的思考者-執行者模型。新雇傭的人更容易習慣新的組織架構。當發生問題時應該尤其警覺，例如當API出了問題或者算法效果不好。

人們會堅持認為工程師應該為此負責，但是他們往往說的只是癥狀，而不是問題本身。工程師們應該做的是為平臺提供更好的支持、可視化、抽象以及健壯性。同時應該認識到，工程師本來就有可能破壞東西，沒人可以保證不犯錯誤，不破壞任何東西。36大數據(http://www.36dsj.com/)

平臺工程師們一定要走在數據科學家們前面。團隊里需要非常敏銳的工程師，能夠提前預料到數據科學家們需要哪些服務、框架和功能。數據科學家不再把想法交給工程師來實現的一個后果就是，工程師們不再能夠針對數據科學家的需求來做出反應，因此就需要能夠提前預判。

記住，工程師們是在建造樂高積木，而數據科學家們是在組裝積木。如果數據科學家們沒有合適的積木可用，他們就會找出其他的解決方案。他們要么會使用錯誤的積木(在圓形的洞里填一個方形的積木)，要么會自己造一個。通常來講，由于這種自己造輪子的過程缺乏系統性和全局性考慮，所以會造成一團混亂。而這種混亂一旦被創造出來就很難收拾，正所謂覆水難收。

不要懼怕效率問題

鼓勵數據科學家肩負如此廣闊任務棧的后果之一，就是他們可能無法生產出和專業工程師一樣專業高效的代碼和方案。我們是在用效率來交換速度和自治性。對這個復雜權衡的認識是非常重要的。

但與此同時，這種端到端的自治性也有一些不那么明顯的高效之處。在他們所實現的領域，數據科學家們是專家，所以他們能夠做出一些需求和技術代價之間的權衡。例如，他們可以決定在某些合適的地方使用抽樣數據，或者近似方法，他們可以決定砍掉一些實現和維護代價很高，但是收益有限的功能。這些在傳統的思考者-執行者模型中是基本不會發生的，即使發生了，也是以反復溝通談判為代價的。

綜合來說，我們希望這種自治性帶來的效率和創新會大于數據科學家“全棧開發”帶來的一些低效。

未來

我不會聲稱我們發現了組織數據科學部門的***方式，或者說這就是最適合你所在的組織的方式。但是這一定不是一種試圖建造“更快的馬”的嘗試，而且我覺得這是更加適合我們的一種方式。

我真誠地希望，通過分享我們的嘗試，能夠鼓勵其他非傳統數據科學部門做出同樣的嘗試;能夠激發正在組建新部門的負責人的靈感，讓他們能夠腦洞大開，挑戰傳統;能夠告訴被傳統組織架構所“傷害”的工程師和數據科學家們，還有其他可以工作的模式和環境存在。

參考資料：

[1] 本文中的“數據科學家”可對應到國內更常用的“算法工程師”或“算法研究院”的角色。

[2] 本文中的“工程師”、“數據工程師”或“數據平臺工程師”可對應到國內更常用的“偏工程”或“偏架構”的工程師角色。

[3] 問一下你的(數據平臺工程師)面試官，他知不知道數據科學家坐在哪里(或者反之)。如果他們不知道，你就趕緊跑吧……

[4] 因為這些人的主要工作是保證數據通道的暢通，就像管道工人一樣。

[5] 福特汽車的創始人福特曾經說過一句話：“如果(發明汽車時)去問人們想要的是什么的話，他們會說想要的是更快的馬”。比喻默守陳規，在既有框架下做改進。

[6] 這里的通知(inform)指的是在傳統的行業中，BI很多時候只是將自己分析的結果告訴、通知業務部門，但是是否采納并還是由業務部門決定，這也反映出了傳統BI部門略顯尷尬的地位。

[7] “橫向”指的是開發具有可擴展性，高可復用性的應用或者組件。