数据科学家和工程师的“五诫”

在实际的工作中，数据科学家们不仅要学会如何实用工具，还要懂得如何与同事合作。The Yhat Blog这篇文章探讨了在实际的数据建模和数据处理的过程中数据科学家和数据工程师应该如何处理好关系顺利地完成项目的问题。它引用“摩西十诫”的典故， 提出了给数据处理者的五个“诫律”。我们一起来参考一下!

1.了解你的数据

好的模型依赖于好的数据。要建立真正具有生产力的模型，数据科学家需要知道他们基于创造和存储产品的数据库是否可靠，以及数据库更新的频率。这些信息在项目开始之前就应该被收集并且分享给工程团队，以避免项目进程之中可能产生的阻碍。

在 一个理想的世界里，科学家和工程师都应该提前做好应对即将发生的变化的准备(例如，多种变量类型之间的变化)，使他们能够据此共同创建，测试和部署相应的 新版本。即使不能够保证避免每一个程序中的事故，共享资源和尽早发现缺陷也可以使工程师们降低风险和预见解决可能出现问题的部分。

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

数 据科学家运用的主要编程语言是R或Python，这种语言便于数据的清洁，探索和建模。而工程师，却需要使用多种不同的工具集来构建可扩展的网络和移动应 用程序(例如，NET、Ruby on Rails、Node.js 或 JVM)。虽然期望一个人完全懂得使用这两套工具是不切合实际的，但是跨过技术“藩篱”的限制对对方使用的语言和流程有一个基本的了解将大大有助于合作的 开展。

将统计代码手动重新编写为另一种语言是一项费时费力又极其容易犯错的工程，所以当出现问题的担忧增加的时候，建立良好的沟通机制(面对面和网络数字化的)绝对是至关重要的。

3.了解技术的局限

当数据科学家和工程师运用不同的工具包工作的时候必然会遇到技术的限制。这常常使他们发狂，因为没有人喜欢被要求返工，或者看着自己辛勤劳作创造出来的产品不理想，甚至更糟糕，看到自己的辛勤劳动付诸东流。

一 旦你清楚了模型开发和部署所需要使用的语言(见诫条2)，就应该花时间研究一下使用这种语言做什么是可能的，什么是完全不能够实现的。然后就应该设定定期 的跨职能讨论会的时间表，科学家和工程师双方要经常沟通例如：你考虑在哪些方面做一些突破?双方在哪些地方可以做出让步?哪些又是技术完全实现不了的?有 没有其他选择?要实施需要付出多少努力?这些努力符合商业价值的考量吗?

在实际工作 中，假设你是一个数据科学家正在为一个Ruby编写的APP编写一段使用R语言的反欺诈算法，那么你应该知道的是R的GLM功能(用于构建广义线性模型的 函数)，在Ruby(或Java，对这个问题来说)中并没有相对应的本地功能。这时候就需要大家一起来一场头脑风暴来找寻出路啦。

4.互相尊重

在任何时候，一个数据科学家的工作总是需要大家共同的努力才能够完成，在这个过程中充满了产生误解的可能。那我们的建议是什么呢?就是像老话讲的，己所不欲，勿施于人。

对于数据科学家来说，你要做的就是写出便于维护和使用的高质量的代码，积极听取工程师关于重构模型和采取更好替代方法的建议，询问他们怎样才是一个现实的可实行的时间表，你还能提供哪些帮助等。

对于工程师来说，与数据科学家合作，需要明确必须的职责，并且共同商讨达成一份书面的处理问题的优先次序文件，遵循一个不断更新的和现实的路线图，并根据项目的进程不断检验、细化和落实科学的数据模型。

5.履行你的责任和义务

有人认为一个模型一旦创造出来，并且投入了实际的商业运用，无论是创造它的数据科学团队，还是实现了它的工程师们就可以自由地着手下一个大项目，不需要再管理这个项目了。这种想法是非常危险的。事实上，这只是分析的生命周期的另一阶段的开始。

因 为，数据科学家和工程师建立生产过程中的监控和管理模型的计划是非常重要的。谁将会监督模型和服务器的稳定性?如何将输入和输出数据存储和共享?升级版 本，再培训和重新测试的路线图是什么?还要为解决可能出现的问题制作一个行动计划。如果模型吞吐量增加怎么办?扩展需要花费多少时间和金钱?由此确定共同 承认的公平的前期职责划分，相应地分配团队成员的工作时间。

总结

数据科学家和数据工程师都在朝着同一个目标努力：运用代码建造程序来解决实际的商业问题。不幸的是，误解和技术效率低下常常导致人们忽略了这一目标。当我们 在工作中处理和他人的关系的时候，虽然没有万能的神奇公式，但是这五个诫律应该可以在消除数据工程师和数据科学家之间的鸿沟上产生深远的影响。