[[174647]]

前言

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

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

需要提前說明的一點，文中的“數(shù)據(jù)科學(xué)家”可理解為我們常說的偏算法的工程師，而文中的“工程師”或者“數(shù)據(jù)工程師”可理解為我們常說的偏工程或者偏架構(gòu)的工程師。

正文開始

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

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

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

一個典型的數(shù)據(jù)科學(xué)部門

大多數(shù)公司將他們的數(shù)據(jù)科學(xué)部門劃分為三個組：

數(shù)據(jù)科學(xué)家：這些家伙就是那些“工程比統(tǒng)計學(xué)家好&統(tǒng)計比工程師好”的人。也就是所謂的“思考者”。

數(shù)據(jù)工程師：這些人構(gòu)建數(shù)據(jù)通道，將數(shù)據(jù)“喂”到數(shù)據(jù)科學(xué)家“嘴里”，然后從數(shù)據(jù)科學(xué)家手里拿到idea并且實現(xiàn)它們。也就是所謂的“執(zhí)行者”(Doer)。

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

數(shù)據(jù)科學(xué)家們經(jīng)常不爽的是，工程師們實現(xiàn)算法的速度太慢，以及他們之間的工作流程，路線圖以及動機總是同步不到位。當他們想法的版本1進入ABTest的時候，版本2和版本3早就已經(jīng)排好隊了。他們的失望和不爽是非?？梢岳斫獾摹?/p>

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

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

這顯然是個惡性循環(huán)。

哪里錯了?

我們都知道這樣做是不對的，那我們?yōu)槭裁床唤鉀Q這樣的問題呢?為什么每個數(shù)據(jù)科學(xué)和算法開發(fā)部門似乎都會滑落到這樣“功能失調(diào)”的模型中?

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

你或許并沒有“大數(shù)據(jù)”

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

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

每個人都想做“思考者”

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

這些都是我們引導(dǎo)的結(jié)果，而一些大公司更要為此負責(zé)，尤其是那些在大數(shù)據(jù)瘋狂之前就已經(jīng)有了數(shù)據(jù)智能部門的公司。

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

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

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

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

真的那么糟糕嗎?

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

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

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

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

所以，你只能雇到中庸的工程師。他們會制造出大量的爛攤子，進一步加重問題，讓你走上惡性循環(huán)。最終的結(jié)果，就是數(shù)據(jù)科學(xué)家并不比傳統(tǒng)的報告工程師厲害多少，因為他們?nèi)狈σ粋€創(chuàng)新、堅固的數(shù)據(jù)平臺支持。進一步，如果你把他們定位為報告工程師，數(shù)據(jù)科學(xué)家們就該跑路了，畢竟，他們可是“思考者”，不是“執(zhí)行者”!

一種不同的數(shù)據(jù)科學(xué)部門

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

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

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

讓每個人都成為***的

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

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

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

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

數(shù)據(jù)科學(xué)家

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

工程師

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

知行合一(Hybrid Thinker-Doer)

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

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

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

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

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

那么在這種場景下，工程師的職責(zé)應(yīng)該是什么呢?綜合來說，他們需要部署平臺、服務(wù)、框架，使得數(shù)據(jù)科學(xué)家們可以自主的快速開發(fā)、部署他們的想法?？梢詫⑦@些工作類比為樂高積木：工程師們設(shè)計樂高積木塊，數(shù)據(jù)科學(xué)家們通過組裝這些積木塊來實現(xiàn)新的想法。這樣做的好處非常明顯：

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

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

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

為了讓這套機制能夠正常運轉(zhuǎn)，大多數(shù)時候工程師們需要能預(yù)料到數(shù)據(jù)科學(xué)家們的需求，他們需要提前提前若干步進行開發(fā)。

對于有天賦的工程師和數(shù)據(jù)科學(xué)家來說，這顯然有趣多了。

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

完全不是。相反，工程師們在這個系統(tǒng)中承擔(dān)的職責(zé)要比傳統(tǒng)方式中更加具有挑戰(zhàn)性，也更加被需要，對于數(shù)據(jù)科學(xué)家來說也是一樣。我們這套機制并不是在優(yōu)化效率，而是在強調(diào)自治性。這套機制的產(chǎn)物是明確的自治權(quán)和對結(jié)果負責(zé)的明確責(zé)任。

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

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

一條極富挑戰(zhàn)性的路

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

人們不愿意改變。人們總是傾向于重建他們習(xí)慣的環(huán)境，這會導(dǎo)致他們傾向于返回到傳統(tǒng)的思考者-執(zhí)行者模型。新雇傭的人更容易習(xí)慣新的組織架構(gòu)。當發(fā)生問題時應(yīng)該尤其警覺，例如當API出了問題或者算法效果不好。

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

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

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

不要懼怕效率問題

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

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

綜合來說，我們希望這種自治性帶來的效率和創(chuàng)新會大于數(shù)據(jù)科學(xué)家“全棧開發(fā)”帶來的一些低效。

未來

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

我真誠地希望，通過分享我們的嘗試，能夠鼓勵其他非傳統(tǒng)數(shù)據(jù)科學(xué)部門做出同樣的嘗試;能夠激發(fā)正在組建新部門的負責(zé)人的靈感，讓他們能夠腦洞大開，挑戰(zhàn)傳統(tǒng);能夠告訴被傳統(tǒng)組織架構(gòu)所“傷害”的工程師和數(shù)據(jù)科學(xué)家們，還有其他可以工作的模式和環(huán)境存在。

參考資料：

[1] 本文中的“數(shù)據(jù)科學(xué)家”可對應(yīng)到國內(nèi)更常用的“算法工程師”或“算法研究院”的角色。

[2] 本文中的“工程師”、“數(shù)據(jù)工程師”或“數(shù)據(jù)平臺工程師”可對應(yīng)到國內(nèi)更常用的“偏工程”或“偏架構(gòu)”的工程師角色。

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

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

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

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

[7] “橫向”指的是開發(fā)具有可擴展性，高可復(fù)用性的應(yīng)用或者組件。