首页 存档 技术 查看内容

【超级趣文】8个设计数据项目的“简单”指导原则

2018-3-30 13:00 |来自: 互联网 293 0

摘要: 作者:DatTran 翻译:Modimand 校正:jason 大数据公社翻译团队 励志名言 灵感并不是在逻辑思考的延长线上产生,而是在破除逻辑或常识的地方才有灵感。 爱因斯坦 有许多人写过关于数据的文章,他们会提示一些技巧 ...

作者:DatTran 翻译:Modimand 校正:jason 大数据公社翻译团队


励志名言

灵感并不是在逻辑思考的延长线上产生,而是在破除逻辑或常识的地方才有灵感。

爱因斯坦



有许多人写过关于数据的文章,他们会提示一些技巧比如“利用云技术”,或者“做些实验”。但是这些文章大多含糊不清,没有多大的用处。因为你不可能仅仅依靠一些“小提示和小技巧”就能做出一个成功的数据产品。你必须有一个正确的思维方式。这些人写的内容让我很失望,所以我决定自己写一篇,这篇文章不是那些“小贴士”,“小技巧”与“规则”的堆砌,而是一些指导原则的总结。当然我不能保证你读了本文一定会成功,但是希望他们能够对你有所帮助。

我从一些和客户的会议,以及我参与过的项目工作中,总结出了以下原则。这篇文章的灵感是来自于一篇优秀文章:《十条让你的数据项目失败的路》,作者为MartinGoodson。同时也加入了一些我个人的观点,这些观点来自于我观察到的当前一些数据项目中存在的问题。(比如这里就有个例子:以策划项目的思维方式去设计产品)


1
尽可能简单,只有必要时才增加复杂性


自从去年AlphaGo打败了顶尖的围棋选手,人工智能(即深度学习)就成为了热门话题。时至今日,如果你不做人工智能,你就会显得落伍。有很多的客户来问我怎样利用人工智能来做一个好产品。然而问题在于绝大多数情况下,一个简单的模型已经足够用了,不要一味追求太复杂的功能。



2
定义最简化可实行的数据产品就尽早发布


尽早建立一个能够从头到尾走完流程的最简化可实行的数据产品并发布,数据科学的模型只有在建立过程中才能够真正产生价值,即使它并不完美。这么说是有道理的所以,为了你自己好,形成一个“API优先”的工作模式吧。许多数据科学的团队现在仍然把焦点集中在如何完善他们的模型,而疏于对需要解决的问题进行宏观地了解。如果你早点发布你的产品,你就能够对问题有更宏观全面的认识。你也知道的还有你知道吗,多收集些数据,就能够轻松有效地帮助你改进你的模型。


3
工作进行过程中敲定整个构架要实现的目标与所需投入


许多客户一开始就来问我,关于最优化所需的前期数据环境的问题。举个例子,他们还没有开始考虑自己想要解决的问题是什么,就先询问1.5TB的内存对于他们的Spark集群是否够用。我明白他们的出发点是需要这些信息来做财务预算,但是我的方法是渐进式的。我在着手解决这个问题的过程中,来逐渐明确我的需求。一言以蔽之:“情况是会变的”。



4
针对不同的问题,采取适用的工具


有比介入到一场关于“哪个工具更好”的争论中更糟糕的事情吗?这种事情很典型,比Rvs.Pythonvs.SASvs.Sparkvs.Daskvs.Flinkvs.Kafkavs.RabbitMQvs.Redisvs.Geodevs.TensorFlowvs.Theanovs.Torch等等等等……然而问题在于:没有哪个单一的工具,能够解决所有的问题。我的观点是:永远选择最合适的工具来解决问题。各种工具层出不穷,不要迷恋任何特定的一个。(尤其是SAS)



5
做真正有用的产品


有时候客户想要添加的功能完全没用处。(比如,你要分析传感器数据的话,你是不需要使用word2vec的!)所以,在你真的要投许多金钱与时间在某项功能上之前,请先做一些用户研究吧,如果这个功能根本不会影响到产品最终要达到的目标,就不要添加。

6
优先处理最有商业效果的项目


比如说,你有一个巨大的数码/数据/大数据变革的项目,就是你还有上千个项目正在同时进行,你需要聚焦在哪里呢?你必须找出最重要的那个并且验证你的判断,然后再着手建立项目所需的数据工具与报表。数据工作需要你投入大量的时间,按部就班得完成,而不是仅凭一时兴起。


7
经常时不时地评估你的模型并且改进它



俗话说,“不要修改一个正在运行的系统”。但是如果你坚持这一点,系统可能就会背离你了。我曾经有一个客户,在他们的系统运行了三年之后,发现系统生成的结果,不再能够解决他的问题了。这实际上是因为数据的结构变了。这个问题尤其会在你的代码里有“selectall”的时候出现。

因此,经常给你的模型做回测吧,你会回来感谢我的。拥有一个测试为主的开发文化也会帮助你减少这类问题。

8
沟通 协作= 万能钥匙

我最近和一个数据科学团队沟通过,他们告诉我,他们无法在企业中完成有意义的工作。因为他们的CIO喜欢“大数据”的概念,但是却把数据科学团队跟商业隔离开来。现在他们已经被隔离了两年了。我告诉他们,用“结对编程”(两个开发人员在一个工作站工作)的方式来打破不同团队之间的隔阂。在一个“平衡团队”(组织由多学科背景成员组成)中工作同样也会有所帮助。



原文连接:https://builttoadapt.io/8-**-guidelines-for-data-projects-859a1a738ffc

声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

相关分类

返回顶部