在實(shí)際的工作中，數(shù)據(jù)科學(xué)家們不僅要學(xué)會如何實(shí)用工具，還要懂得如何與同事合作。The Yhat Blog這篇文章探討了在實(shí)際的數(shù)據(jù)建模和數(shù)據(jù)處理的過程中數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師應(yīng)該如何處理好關(guān)系順利地完成項(xiàng)目的問題。它引用“摩西十誡”的典故，提出了給數(shù)據(jù)處理者的五個“誡律”。我們一起來參考一下！

從表面上看，數(shù)據(jù)科學(xué)與工程科學(xué)就像是天作之合——數(shù)據(jù)科學(xué)家為商業(yè)問題創(chuàng)造全新的解決方案，而他們的同行工程師負(fù)責(zé)構(gòu)建網(wǎng)絡(luò)程序環(huán)境和集成來將這些“創(chuàng)造”變成現(xiàn)實(shí)。這種合作看起來是如此天衣無縫。 但事實(shí)上不幸的是，數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師之間現(xiàn)存的是一種普遍被認(rèn)為脆弱的關(guān)系。對于大多數(shù)團(tuán)隊(duì)來說，兩者之間的關(guān)系“正介于不存在和無法作用之間”。這對于大部分過于樂觀的人無疑是一記痛擊吧！

那么，為什么會產(chǎn)生這種不和諧的關(guān)系，如何能避免這種不和諧？在這篇簡短的文章中，我們將介紹五個“誡律”用于使數(shù)據(jù)科學(xué)家和工程師之間更合拍。快拿本本記下來。

1、了解你的數(shù)據(jù)

好的模型依賴于好的數(shù)據(jù)。要建立真正具有生產(chǎn)力的模型，數(shù)據(jù)科學(xué)家需要知道他們基于創(chuàng)造和存儲產(chǎn)品的數(shù)據(jù)庫是否可靠，以及數(shù)據(jù)庫更新的頻率。這些信息在項(xiàng)目開始之前就應(yīng)該被收集并且分享給工程團(tuán)隊(duì)，以避免項(xiàng)目進(jìn)程之中可能產(chǎn)生的阻礙。

在一個理想的世界里，科學(xué)家和工程師都應(yīng)該提前做好應(yīng)對即將發(fā)生的變化的準(zhǔn)備（例如，多種變量類型之間的變化），使他們能夠據(jù)此共同創(chuàng)建，測試和部署相應(yīng)的新版本。即使不能夠保證避免每一個程序中的事故，共享資源和盡早發(fā)現(xiàn)缺陷也可以使工程師們降低風(fēng)險(xiǎn)和預(yù)見解決可能出現(xiàn)問題的部分。

2、熟悉合作伙伴使用的工具

數(shù)據(jù)科學(xué)家運(yùn)用的主要編程語言是R或Python，這種語言便于數(shù)據(jù)的清潔，探索和建模。而工程師，卻需要使用多種不同的工具集來構(gòu)建可擴(kuò)展的網(wǎng)絡(luò)和移動應(yīng)用程序（例如，NET、Ruby on Rails、Node.js 或 JVM）。雖然期望一個人完全懂得使用這兩套工具是不切合實(shí)際的，但是跨過技術(shù)“藩籬”的限制對對方使用的語言和流程有一個基本的了解將大大有助于合作的開展。

將統(tǒng)計(jì)代碼手動重新編寫為另一種語言是一項(xiàng)費(fèi)時(shí)費(fèi)力又極其容易犯錯的工程，所以當(dāng)出現(xiàn)問題的擔(dān)憂增加的時(shí)候，建立良好的溝通機(jī)制（面對面和網(wǎng)絡(luò)數(shù)字化的）絕對是至關(guān)重要的。

3、了解技術(shù)的局限

當(dāng)數(shù)據(jù)科學(xué)家和工程師運(yùn)用不同的工具包工作的時(shí)候必然會遇到技術(shù)的限制。這常常使他們發(fā)狂，因?yàn)闆]有人喜歡被要求返工，或者看著自己辛勤勞作創(chuàng)造出來的產(chǎn)品不理想，甚至更糟糕，看到自己的辛勤勞動付諸東流。

一旦你清楚了模型開發(fā)和部署所需要使用的語言（見誡條2），就應(yīng)該花時(shí)間研究一下使用這種語言做什么是可能的，什么是完全不能夠?qū)崿F(xiàn)的。然后就應(yīng)該設(shè)定定期的跨職能討論會的時(shí)間表，科學(xué)家和工程師雙方要經(jīng)常溝通例如：你考慮在哪些方面做一些突破？雙方在哪些地方可以做出讓步？哪些又是技術(shù)完全實(shí)現(xiàn)不了的？有沒有其他選擇？要實(shí)施需要付出多少努力？這些努力符合商業(yè)價(jià)值的考量嗎？

在實(shí)際工作中，假設(shè)你是一個數(shù)據(jù)科學(xué)家正在為一個Ruby編寫的APP編寫一段使用R語言的反欺詐算法，那么你應(yīng)該知道的是R的GLM功能（用于構(gòu)建廣義線性模型的函數(shù)），在Ruby（或Java，對這個問題來說）中并沒有相對應(yīng)的本地功能。這時(shí)候就需要大家一起來一場頭腦風(fēng)暴來找尋出路啦。

4、互相尊重

在任何時(shí)候，一個數(shù)據(jù)科學(xué)家的工作總是需要大家共同的努力才能夠完成，在這個過程中充滿了產(chǎn)生誤解的可能。那我們的建議是什么呢？就是像老話講的，己所不欲，勿施于人。

對于數(shù)據(jù)科學(xué)家來說，你要做的就是寫出便于維護(hù)和使用的高質(zhì)量的代碼，積極聽取工程師關(guān)于重構(gòu)模型和采取更好替代方法的建議，詢問他們怎樣才是一個現(xiàn)實(shí)的可實(shí)行的時(shí)間表，你還能提供哪些幫助等。

對于工程師來說，與數(shù)據(jù)科學(xué)家合作，需要明確必須的職責(zé)，并且共同商討達(dá)成一份書面的處理問題的優(yōu)先次序文件，遵循一個不斷更新的和現(xiàn)實(shí)的路線圖，并根據(jù)項(xiàng)目的進(jìn)程不斷檢驗(yàn)、細(xì)化和落實(shí)科學(xué)的數(shù)據(jù)模型。

5、履行你的責(zé)任和義務(wù)

有人認(rèn)為一個模型一旦創(chuàng)造出來，并且投入了實(shí)際的商業(yè)運(yùn)用，無論是創(chuàng)造它的數(shù)據(jù)科學(xué)團(tuán)隊(duì)，還是實(shí)現(xiàn)了它的工程師們就可以自由地著手下一個大項(xiàng)目，不需要再管理這個項(xiàng)目了。這種想法是非常危險(xiǎn)的。事實(shí)上，這只是分析的生命周期的另一階段的開始。

因?yàn)?，?shù)據(jù)科學(xué)家和工程師建立生產(chǎn)過程中的監(jiān)控和管理模型的計(jì)劃是非常重要的。誰將會監(jiān)督模型和服務(wù)器的穩(wěn)定性？如何將輸入和輸出數(shù)據(jù)存儲和共享？升級版本，再培訓(xùn)和重新測試的路線圖是什么？還要為解決可能出現(xiàn)的問題制作一個行動計(jì)劃。如果模型吞吐量增加怎么辦？擴(kuò)展需要花費(fèi)多少時(shí)間和金錢？由此確定共同承認(rèn)的公平的前期職責(zé)劃分，相應(yīng)地分配團(tuán)隊(duì)成員的工作時(shí)間。

6、總結(jié)

數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師都在朝著同一個目標(biāo)努力：運(yùn)用代碼建造程序來解決實(shí)際的商業(yè)問題。不幸的是，誤解和技術(shù)效率低下常常導(dǎo)致人們忽略了這一目標(biāo)。當(dāng)我們在工作中處理和他人的關(guān)系的時(shí)候，雖然沒有萬能的神奇公式，但是這五個誡律應(yīng)該可以在消除數(shù)據(jù)工程師和數(shù)據(jù)科學(xué)家之間的鴻溝上產(chǎn)生深遠(yuǎn)的影響。

譯者：趙晨，沈浩老師門下碩士研究生

原文網(wǎng)址：http://blog.yhat.com/posts/five-commandments.html