大数据文摘▲入职第一年我都做了些什么?,从全栈工程师到数据科学家( 三 )


如何展示成果?
还有一个进展不顺利的地方是我做的一些展示 。 从开发人员到数据科学家的一个变化是 , 我做演示的场合变多 。 展示的内容各种各样 , 有面向技术人员的demo演示 , 有面向业务相关人员的项目报告 , 再到与公司内部其他部门讨论项目工作 , 甚至向公司外部的第三方合作方展示工作 。
对于这些人我觉得我没有做好的一点是我没有根据受众来调整自己的展示方法 。 有些展示我做得还不错 , 比如对开发人员的技术演示我觉得我做得还不错 。 因为我跟技术人员拥有差不多的背景所以说技术的内容彼此也听得懂 , 交流起来会更容易一些 。 其他类型的演示更难一些 , 不幸地是很多时候我在展示的时候才意识听众对我讲的内容不是很在意 。
我的受众分为四类 , 从展示的难易程度来分如下:从最简单的(最左边)开始 , 到最难的(最右边):开发人员 , 业务方 , 其他部门以及外部人员 。
我还可以将最左边的那些受众标记为最技术性的 , 将右边的那些受众标记为更“销售型”的 , 当从左向右移动时 , 两者之间会有一个过渡 。 我发现针对左边受众的展示是最容易准备的——他们对我正在使用的技术或所从事的业务领域有深刻的了解 。
针对外部人员的演示是最难的 , 因为他们往往相关知识最少 。 过去 , 我与这些听众进行交流的时候会直接进入到技术细节 , 就像我和左边听众交流时一样 , 但是结果很不好 , 因为他们不一定具有任何数据科学或机器学习的背景 , 所以我谈论许多概念对他们没有多大意义 , 他们不知道我在说什么 。 对这些受众来说 , 如果我花点时间介绍一下我正在做的工作以及更多的背景知识 , 效果会更好 。 甚至对某些受众来说 , 向他们介绍机器学习的概念 , 为什么我们要使用它以及它的好处 。 有时候 , 对我来说 , 不过多讨论技术细节反而是好事 , 给他们一些大概的框架概念就好 。
在反思了这一点之后 , 我现在在准备演示材料时 , 会更多地考虑我的目标受众 。 具体来说 , 我会考虑听众可能知道或不知道的内容 , 以及需要向他们呈现的内容 , 以帮助我准备需要讨论的内容和专业程度 。 这样他们就可以更好地理解我正在谈论什么= , 并从演示中得到一些收获 。 为此 , 在准备演示文稿时我为自己准备了一些有用的问题 , 如下:
听众对于数据科学领域了解多少?听众对于我试图解决的问题了解多少?听众知道我在使用的技术吗?听众对于我采用的技术细节或者结果感兴趣吗?计划
与做程序员时相比 , 做数据数据家的工作计划更有挑战 。 作为开发人员 , 工作相对比较直接 , 所以也更好估算和排期 。 你通常知道你要实现的目标以及如何实现 。 当我还是一名开发人员的时候 , 我使用敏捷开发工具 。
因此 , 工作内容可以先评估、计划 , 然后排好优先级就开始做 。 在敏捷的方法论指导下 , 如果工作没什么意义 , 或者你不清楚如何做 , 你就不会把它排进工作计划 。 因为无法评估 , 因为未知 , 你要等到所有不明确的地方明确后才开展工作 。
数据科学的工作并不像这样简单 , 对于给定的问题你不会总是提前知道什么会起作用 。 也不会总是知道哪种类型的模型最准确 。 类似这样的情况与刚才提出的观点出现矛盾 , 当你是开发人员时 , 只有问题明确后 , 你才会把他们放入你的工作列表中 。 作为数据科学家 , 未知是你工作的一部分 , 因为你的工作就是要回答这些问题 。 或者你正在处理的问题可能会随着项目进展而改变 。 因此 , 有时候你提前做的几周计划可能很快要重新考虑 。
在计划方面 , 我喜欢将开发工作视为线性的——你知道自己在做什么以及如何做 。 数据科学工作我觉得是分叉树 , 可能需要试不同的道路 , 可能会碰到死胡同 。
数据科学家做短期工作计划还是可行的 , 比如你正在训练和测试的模型之类的——接下来一两周的工作 , 但是 , 长期计划很难做 。 你不可能总是提前知道什么会起作用 , 什么不会 。 所以我们才要进行实验和测试 , 这是数据科学家工作的核心价值 。