【www.shanpow.com--优秀作文】
一：[团队与数据]【原创】如何打造优秀的大数据团队
对于企业来说，要建设自己的大数据平台，需要的不只是技术解决方案，更重要的是组建一支优秀的数据团队。那么，数据团队有哪些成员组成？他们的工作方式是什么？采用怎样的组织架构来开展工作？
1. 数据团队成员
这里只讨论数据团队中核心成员的角色和他们的工作职责。
1）基础平台团队
主要负责搭建稳定、可靠的大数据存储和计算平台。
核心成员包括：
数据开发工程师
负责Hadoop、Spark、Hbase和Storm等系统的搭建、调优、维护和升级等工作，保证平台的稳定。
数据平台架构师
负责大数据底层平台整体架构设计、技术路线规划等工作，确保系统能支持业务不断发展过程中对数据存储和计算的高要求。
运维工程师
负责大数据平台的日常运维工作
2）数据平台团队
主要负责数据的清洗、加工、分类和管理等工作，构建企业的数据中心，为上层数据应用提供可靠的数据。
数据开发工程师
负责数据清洗、加工、分类等开发工作，并能响应数据分析师对数据提取的需求。
数据挖掘工程师
负责从数据中挖掘出有价值的数据，把这些数据录入到数据中心，为各类应用提供高质量、有深度的数据。
数据仓库架构师
负责数据仓库整体架构设计和数据业务规划工作。
3）数据分析团队
主要负责为改善产品体验设计和商业决策提供数据支持。
业务分析师
主要负责深入业务线，制定业务指标，反馈业务问题，为业务发展提供决策支持。
建模分析师
主要负责数据建模，基于业务规律和数据探索构建数据模型，提升数据利用效率和价值。
2. 数据团队的工作方式
数据团队的工作可以分成两大部分，一部分是建设数据存储和计算平台，另一部分是基于数据平台提供数据产品和数据服务。
平台的建设者包括三种人群：基础平台团队对hadoop、spark、storm等各类大数据技术都非常熟悉，负责搭建稳定、可靠的大数据存储和计算平台。数据平台团队主要负责各类业务数据进行清洗、加工、分类以及挖掘分析，然后把数据有组织地存储到数据平台当中，形成公司的数据中心，需要团队具有强大的数据建模和数据管理能力。数据产品经理团队主要是分析挖掘用户需求，构建数据产品为开发者、分析师和业务人员提供数据可视化展示。
平台的使用者也可以包括三种人群：数据分析团队通过分析挖掘数据，为改善产品体验设计和商业决策提供数据支持。运营、市场和管理层可以通过数据分析师获得有建设性的分析报告或结论，也可以直接访问数据产品获得他们感兴趣的数据，方便利用数据做决策。数据应用团队利用数据平台团队提供的数据开展推荐、个性化广告等工作。
3. 数据分析团队的组织架构
在整个大数据平台体系中的团队：基础平台、数据平台、数据应用和数据产品经理团队都可以保持独立的运作，只有数据分析团队的组织架构争议比较大。数据分析团队一方面要对业务比较敏感，另一方面又需要与数据平台技术团队有深度融合，以便能获得他们感兴趣的数据以及在数据平台上尝试实验复杂建模的可能。
从他们的工作方式可以看出，数据分析团队是衔接技术和业务的中间团队，这样的团队组织架构比较灵活多变：
1）外包
公司自身不设立数据分析部门，将数据分析业务外包给第三方公司，当前电信行业，金融行业中很多数据分析类业务都是交给外包公司完成的。
优势： 很多情况下，可以降低公司的资金成本和时间成本；许多公司内部缺乏相关的知识与管理经验，外包给专业的团队有助于公司数据价值的体现 。
劣势：一方面外包人员的流动和合作变数，对数据的保密性没有保证；另外一方面，外包团队对需求的响应会比较慢，处理的问题相对通用传统，对公司业务认知不如内部员工深入，创新较低。
2）分散式
每个产品部门独立成立数据分析团队，负责响应自己产品的数据需求，为业务发展提供决策支持。
优势：数据分析团队与开发团队、设计团队以及策划团队具有共同的目标，团队整体归属感强，绩效考核与产品发展直接挂钩，有利于业务的发展。
劣势：在业务规模比较小的情况下，数据分析师比较少，交流的空间也比较小。因为身边的同事都不是该领域的人才，无法进行学习交流，所以成长空间会比较小，分析师的流失也会比较严重，最终陷入招募新人——成长受限——离职——招募新人的恶性循环。另一方面，每个产品团队都零星地招募几个分析师，整体来看给员工的感觉是公司并不是特别重视数据化运营的文化，对数据的认同感会被削弱，不利于公司建立数据分析平台体系。
3）集中式
数据分析团队与产品团队、运营团队各自独立，团队的负责人具有直接向分管数据的副总裁或CEO直接汇报的权限，团队负责响应各业务部门的数据需求。
优势：分析团队具有充分的自主权，可以专心建设好公司级别的数据平台体系，研究数据最具有价值的那些问题，有权平衡业务短期需求和平台长期需求直接的关系。另一方面，这种自上而下建立起来组织架构，可以向全体员工传达数据在公司的重要位置，有利于建立数据化运营的文化。
劣势：产品业务团队会觉得他们对数据的掌控权比较弱，一些业务数据需求得不到快速响应，认为分析团队的反应太慢无法满足业务发展的需要。随着业务发展越来越大，产品团队会自己招募分析师来响应数据需求，逐渐替代分析团队的工作，这样势必会导致分析团队的工作被边缘化。
4）嵌入式
数据分析团队同样独立于产品团队存在，但只保留部分资深数据专家，负责招聘、培训数据分析师，然后把这些人派遣到各产品团队内部，来响应各类业务数据需求。
优势：团队的灵活性比较好，可以根据公司各业务线的发展情况合理调配人力资源，重点发展的项目投入优秀的人才，一些需要关闭的项目人才可以转移到其他项目中去。
劣势：分析师被嵌入到产品团队内部，受产品团队主管的领导，从而失去了自主权，导致沦落为二等公民。人事关系在公司数据分析团队中，却要被业务团队主管考核，但业务团队主管并不关心他们的职业发展，导致分析师的职业发展受到限制。
那么，到底采取哪一种组织架构比较合适呢？
可以根据公司数据化运营进展的深度灵活采取一种或几种方式。除了外包模式，其他组织架构我都经历过，简单来说，早期采用分散式、中期采用集中式、后期采用分散式或嵌入式以及两则并存。
早期：公司对数据体系的投入一般是比较谨慎的，因为要全面建设数据体系需要投入大量的人力和财力，公司不太可能还没有看清楚局势的情况下投入那么多资源。所以，往往都是让每个产品团队自己配置分析师，能解决日常的业务问题就行。杭研院早期的网易云阅读、印像派等项目中就是采用的这种分散的模式。
中期：随着业务的发展、公司对数据的认识有所提高并且重视程度不断加大，就开始愿意投入资源来构建公司级别的数据体系。这个阶段采用集中式有利于快速构建数据分析平台，为公司各个产品团队提供最基础的数据分析体系，能在未来应对业务的快速发展。杭研院花了两年时间完成了这个阶段的主要工作，并在网易云音乐和易信产品发展阶段起到了至关重要的作用。
后期：一旦公司级别的数据分析平台构建完成，消除了早期分散模式中分析师缺少底层平台支持的窘境，他们能够在分析平台上自助完成大量的数据分析工作。而且经历过集中式阶段的洗礼，公司上上下下对数据的认识都有了很大的提高。此时，在回到分散模式时，原先的很多弊端已基本消除，此外，采用嵌入模式也是可以的。目前杭研院在网易云音乐、网易云课堂、考拉海购等几个产品中就是分散式和嵌入式并存的架构。
总之，没有最好的组织架构，只有适合自己的组织架构。
作者介绍沈琦：网易杭州研究院商业智能部门总监、大数据技术专家自2007年毕业以来，一直在网易杭研院从事大数据技术的相关工作，现担任商业智能部门总监，负责管理杭研院和考拉两个商业智能团队，在大数据技术和部门管理方面都具有丰富的经验。商业智能部门负责网易数个亿级用户产品的数据分析工作，覆盖考拉海淘、云音乐、云课堂、云阅读和易信等众多网易明星级产品。
作者将参加WAW上海7月6号的年度大会，参与圆桌讨论《移动和万物互联时代的企业数据策略》。
二：[团队与数据]对团队数据的分析处理
昨晚因返程上海，时间受限。未能按时刊出文章内容。致歉给自己。呵呵。【再加上网络等原因，也未能在手机上直接登录公号发送内容】
此前从四个方面谈到从数据分析角度，对团队进行培训需求诊断。关于手工收集的问题，有伙伴在平台提问，这里再多说两句：
1.绝大多数业务伙伴并不习惯于在PC端使用有关统计工具，而移动端相关工具尚未有效呈现。因而大部分情况下，还是需要手工进行处理。但是，依然有前提。也就是这个团队是有可以手工统计的数据留存的。反过来，如果一个团队并没有可以用手工来进行统计的常规数据量，那么，实话说，是否需要进行什么培训需求诊断可以斟酌一下了。
2.关于提及的钉钉APP，可能大多数团队并没有去借助使用。在公司没有在移动端开发有关工具的情况下，就团队长而言，其实可以研究下类似“钉钉”这样的APP，的确能够在很大程度上，方便团队工作沟通与管理。同时，也是提高团队形象的某种方式。【跟客户们说起来，挺有科学性，层次高；跟一定水平的准增员提起来，也能吸引到人家。】
3.手工进行数据统计的主要原因，还是在于系统信息提供的差异性不够。前面跟大家提到关于拜访量的数据问题，除此以外，不是不能举出来了，而是需要根据团队特定情况，来进行处理。
比如，在团队长不太精细的情况下，如果留存有关于团队一定时期内所有新增人员的情况资料，那么，就可以也有必要做一下关于增员特点梳理的数据分析。假设一年时间里，团队新进了100位新人，半年下来，走了60人。这60人，会不会有些什么共性特点？尽管数据量不大，但也可能存在一些道道，可以琢磨。
再比如，关于参会率的分析了解。如果以更加精细的标准来对照，也许还要关注参会率高与低是否有某种走势上的规律性，以及是否与团队活动的情况有一定的相关性。晴天、雨天；热天、冷天；活动天……可能这些情况并不一定会成为是否需要培训的理由，但是，在某些时候，可能是改善某些经营管理内容的重要影响因素。
再再比如的话，还有特定产品件均保费分布、险种组合类型及程度等与手工有关的选项。
可能，您还会认为，我只是一个外部的讲师，大多数情况下，我都不是只为这一个团队服务的，如何需要做这些手工统计的工作？
其实，没有什么特别标准的答案，但是，我们经常提到的接地气的问题，在这种手工数据统计的过程当中，会得到很大程度的改善。
您说，手工一下，是否值得呢？一通胡说，请见谅。呵呵。
三：[团队与数据]想组建自己的数据科学团队？CEO们要先回答这几个问题
按要求转载自36kr
作者 | 欧开磊
数据科学为什么对很多创业公司如此重要？公司应该在什么时候在数据科学方面进行投入？应该将数据科学团队放在公司里的什么位置上？如何营造一个尊重数据科学的文化氛围？
编者按：Jeremy Stanley是日用杂货当日送达初创企业Instacart主管数据科学的副总裁，Daniel Tunkelang是前LinkedIn的数据主管。作为在数据科学领域身经百战的老将，他们在这篇文章中为那些想打造一支属于自己的数据科学团队的公司CEO们提供了一些建议，主要涵盖了这几个问题：数据科学为什么对很多创业公司如此重要？公司应该在什么时候在数据科学方面进行投入？应该将数据科学团队放在公司里的什么位置上？如何营造一个尊重数据科学的文化氛围？
你可能很难相信，“数据科学家”在2008年才开始成为一个真正意义上的职业头衔。当时，为了迎合市场对数据分析、工程学和产品这种跨学科技能人才日益增长的需求，Facebook的 Jeff Hammerbacher 和LinkedIn的 DJ Patil 率先提出了“数据科学家”这个概念。今天，市场上对数据科学家的需求极其旺盛，越来越多的公司都想更好地了解如何打造一支属于自己的数据科学家团队。
作为在数据科学领域身经百战的过来人，Jeremy Stanley和Daniel Tunkelang已经见识了不同行业的不同公司在不同发展阶段在打造数据科学家团队方面的成功和失败案例。他们发现，这里面的挑战不仅在于如何招聘顶尖的数据科学家，还包括如何最大限度地发挥他们的价值，以及如何在日趋激烈的人才竞争中留住他们。
在这篇文章中，我们为那些想打造一支属于自己的数据科学团队的公司创始人提供了一些建议。数据科学为什么对很多创业公司如此重要？公司应该在什么时候在这方面进行投入？应该将数据科学团队放在公司什么位置上？如何营造一个尊重数据科学的文化氛围？
你想实现什么样的目的？数据科学主要有两个方面的功能：一是改善用户所使用的产品；二是为公司决策提供支持，改善决策质量。
数据驱动型产品利用数据科学和工程学来持续改进产品性能，例如，提供更好的搜索结果、更个性化的推荐等等。
数据决策科学利用数据来分析业务指标，例如增长数据、用户黏性数据、盈利点和用户反馈数据等，从而为制定公司战略和关键性的业务决策服务。
两者的区别可能看起来非常显而易见，不过在打造和扩充自己的数据科学团队的过程中，记住这两者之间的区别非常重要。接下来我们就详细探讨这两点。
利用数据科学打造更好的产品
数据产品可以利用数据科学去提升产品的性能表现。他们依靠的是这样一个良性循环：产品搜集用户使用数据，这些数据成为算法素材后再反过来为用户提供更好的产品使用体验。
那么在搜集到数据之前是怎样的呢？你的产品的第一个版本必须解决数据科学称之为“冷启动”的问题，也就是说产品的初始版本必须提供足够好的体验才能够启动“数据搜集—数据驱动产品提升”这个良性循环。要想做到这一点，这就需要依靠产品经理和工程师制定足够好的解决方案。
例如，当用户打开Instacart应用的时候，这款应用会在“再次购买”栏向自动给用户展示他们最近购买过的日用杂货品。这是一个用户很喜欢的功能，不过它几乎用不到数据科学或是需要足够多的数据来支撑。只有当我们为用户推荐一些他们之前没有购买过的商品的时候，这时数据科学才能发挥它真正的作用。例如，要向A用户推荐他之前从未购买过的商品，这就需要数据科学家对所有用户的购买行为进行分析，从而确定和A用户比较类似的B用户，然后再根据B用户过去的购买行为来为A用户推荐商品。这就是数据科学利用数据创造价值、从而使用户更容易地发现他们自己可能没发现的好产品的一个案例。
为了改善产品，数据科学家必须和工程师进行持续而紧密地合作。此外，你还需要决定是产品科学家自己去落实产品改进方案还是与工程师一起去落实。这两种方法都可以，不过最好能对其进行规定，让它成为公司员工人人皆知的一个流程与规范。
使用数据科学为做出更好的决策提供支持
数据决策科学利用数据分析与可视化来为公司业务和产品决策提供支持。公司里可能谁都有可能是决策者，例如产品经理对如何制定路线图的优先级进行决策，公司高管对公司层面的战略性问题进行决策。决策科学问题涉及的范围很广，不过它们有一些共同的特点。第一，它们是公司之前尚不需要解决的一些新问题；第二，它们通常是主观性的问题，需要数据科学家在有未知变量和缺少上下文的情况下处理的问题。第三，它们通常是非常复杂的问题，问题的不同部分之间缺少明确的因果关系。与此同时，决策科学问题又是可以衡量且影响非常重大的，做出决策后能对业务产生具体而重大的影响。
上面说得听起来很像数据分析，事实上，数据分析和数据决策科学之间的差别并不是一直都非常清楚的。不管怎样，决策科学要做的事远不限于仅仅是制作报告和图表。数据科学家不应该做那些利用市场上现有的商业智能工具就能完成的工作。
在LinkedIn，公司管理团队就曾利用数据决策科学做出一个非常关键的商业决策：有关在搜索结果中其他会员资料的可见性。在之前，只有付费用户才能查看自己三度人脉网络里成员的全部资料。这种可见性规则非常复杂，LinkedIn想对其进行简化，但同时又不想影响自己的营收。其中的风险还是很大的。
最后提议的可见模型是对非付费用户每月的使用进行限制。LinkedIn的决策科学家利用用户历史行为来预测这个改变对营收和用户黏性可能会造成的影响。这个分析必须在一个模型上推断过去的行为从而在另一个完全不同的模型上预测用户未来的行为。结果证明，新的可见性规则不仅对公司业务产生了积极影响，同时也让数百万用户更加满意我们的产品，它还帮我们卸下了之前产品开发中规则过于复杂的沉重负担。有些用户抱怨新的可见性规则方面对查看资料上做出的限制，然而这部分人正是LinkedIn认为应该付费使用自己产品的用户。在数据决策科学的帮助下，这个项目非常成功。
并不是所有的决策都需要依靠数据决策科学。有些决策太无关紧要，所以不值当在数据决策科学上进行大量投入。还有一些决策可能非常重要，但缺乏需要的数据对其进行有意义地分析。在这种情况下，就需要依靠直觉和实验。
数据决策科学和数据产品需要的技能有的是类似的，很少数据科学家能在这两个方面都非常擅长。数据决策科学依靠的是业务和产品感觉、系统思维能力和优秀的沟通能力。数据产品需要的是机器学习知识和产品级别的工程技能。如果你的数据科学团队规模还很小，你可能需要找一个在这两方面都比较擅长的超级英雄。当团队规模慢慢变大后，你最好能招在这两个方面分别比较擅长的人才。
你是否应该在数据科学上进行投入？数据科学并不适合所有公司。只有当它对公司成功与否至关重要时，你才需要在数据科学上进行投入。在你决定是否投入打造一支数据科学团队之前，建议先问自己下面这四个问题：
（1）你决心利用数据科学来为制定战略决策服务或是打造数据驱动型的产品吗？
如果你还不确定是否会利用数据科学为制定战略决策服务或是打造数据驱动型的产品的话，那么建议暂时不要招聘数据科学家。
只有当你决心打造一个数据驱动型的决策文化时，数据科学才能更好地为制定战略决策服务。你可能并不是一开始就需要它，不过要招到合适的数据科学家是需要一定的时间的，让数据科学家了解你的数据和业务同样是需要一定的时间的。在你打算利用数据科学驱动决策之前，这些工作都需要提前做。
数据驱动型产品可以通过利用数据持续改善和优化产品，从而创造更多的价值并取悦更多的用户。如果你这些在你的产品路线图上，那么你应该尽早招数据科学家进来。数据科学家可以在产品设计、数据搜集和系统架构等方面做出关键性决策，这对于打造一款真正优秀的产品非常重要。
（2）你能够搜集到你需要的数据并且让数据驱动行动吗？
公司的创始工程师可以依靠很少产品和设计指导的情况下就能开发一个最小可行性产品。数据科学则需要大量的数据。推荐系统依靠监测你的产品来追踪用户行为，优化业务决策则需要依靠对关键性的活动和输出进行精密测量。
光搜集数据是远远不够的，只有数据能够真正驱动行动的时候，数据科学的价值才能显现。数据应该去推动产品的迭代完善，同时能够驱动公司的关键绩效指标（KPI）。
为了真正落实这一理念，这就需要在全公司范围内明确每款产品需要搜集什么数据，同时制定清晰的搜集和维护数据的架构和流程。这需要数据科学家、工程师和产品经理的协同配合，而所有这些又都需要管理层的支持和承诺。同样的道理，数据驱动型决策也需要公司CEO自上而下的支持和决心，确保全公司都能决心依靠数据来做决策，而不是依靠依靠职位高的人的意见进行决策。
（3）你搜集的数据里有足够多有用的信号来帮你获取有意义的见解吗？
很多人将大量数据和数据科学等同起来，然而数量并不是一切。真正的数据科学是从噪音中的数据里提取有用的数据信号。
有用的信号不光取决于数据量的大小，还取决与信号和噪音的比例。举个例子，一个广告产可能会从数十亿的广告曝光中搜集数据，然而只有少数用户与广告互动的情况下才是真正有用的数据信号。因此，通常情况下大量的数据只能产生少量有用的信号。
（4）你是否需要让数据科学成为你的核心竞争力，或是否可以将数据科学工作外包出去？
要打造一支数据科学团队是非常困难而且是需要大量资金支持的。如果通过外包就能完全满足你在数据科学方面的需求的话，那么不妨将这项工作外包出去。有人建议可以明智地利用外部的顾问来做这项工作，不过还有一个更好的建议，那就是通过利用市场上现有的产品和解决方案来获取数据、创建模型、实现自动化操作并给出关键的分析报告。它可能不是专门为你的需求量身定制的完美解决方案，不过为了能快速推进业务、同时能够让核心团队成员专注在能创造最多价值的工作上，在这方面做一点点妥协也是值得的。
你什么时候需要将数据科学作为自己的核心竞争力呢？如果数据科学正在解决对你能否成功起着至关重要作用的问题的话，这时你就不能将这项工作外包出去了。市场上现有的解决方案很多时候也非常死板不灵活。如果你的公司正在尝试利用一种独特的方法解决一个新问题的话（例如搜集全新类型的数据或是以全新的方法使用数据），这时市场上现有的解决方案可能就无法满足你的需求了。
（Jeremy Stanley在位于旧金山的Instacart总部）
那么你什么时候应该开始组建数据科学团队呢？数据科学，首先需要足够多的数据才能开展下面的工作，而大部分公司一开始并没有足够多的数据的。
在招聘数据科学主管或组建数据科学团队之前，要确保你有工作可以让他们可做。同时，你需要尽早开始搜集一些关键数据，一旦你准备好之后，数据科学团队就可以立刻施展身手、发挥作用。
如果你还没有数据，这时谁负责决定该搜集什么样的数据、何时搜集数据呢？这个决策者并不一定需要是数据科学家，但最好是能了解不同数据集的潜力且能够做数据投资策略决策的人。如果你已经知道自己将会花很多的时间和金钱在数据的获取上，这时你或许就应该做一些少量的投入去招聘你的第一个数据科学家了。
可能你现在立刻就需要数据，因为你的业务就是提供数据产品。然而你的最小可行性产品可能并不是数据驱动型产品。这时你只能将赌注压在你的直觉上，看你的直觉是否能为市场所验证。在这种情况下，过早地在数据获取和数据科学上进行投入只会浪费你宝贵的资金和时间，这些时间和金钱应该用在将最小可行性产品推向市场上。一旦你有可供数据科学家处理使用的数据后，同时也决心投入大量的产品、工程和业务资源来支持你的数据科学工作的话，这时，你就应该快速组建一支数据科学团队了。
要在公司在灌输一种重视数据的文化，越早越好。从用户获取到产品发布再到收购，所有这些重要决策都应该基于数据而非大家的意见。将数据科学引入公司的另一个好处就是它能够让大家认识到数据是公司的一级资产。
一次成功的产品发布应该是能否帮你搜集足够多的数据供学习的。如果让我们给出一个最重要的建议的话，那就是：在你验证了你的最小可行化产品（MVP）之后，这时你就应该考虑在数据科学上进行投入了。
（图中是Daniel Tunkelang）
你应该将数据科学团队放在公司里的什么位置上？你将数据科学团队放在公司里的什么位置上，这对团队以及整个公司的业务都会产生很大的营销。目前有三种方法：一个完全独立的数据科学团队，嵌入型团队，完全整合型的团队。每种方法其实都各有利弊。
（1）让数据科学团队完全独立
在数据科学团队完全独立情况下，这个团队和其它诸如工程团队是并列的。数据科学团队的负责人可能会想产品/工程副总裁、甚至是CEO直接汇报工作。
这种独立模式的优势的它有充分的自主权。这种数据科学团队可以自主决定解决它认为最有价值的那些问题。作为一个完全独立的团队存在还有另外一个象征性的优势，就是它彰显了公司是将数据视为一级资产的，这有助于公司吸引更多顶尖的数据科学人才加入。
这种独立的模式对于那些决策科学团队尤其有帮助。尽管基于数据决策的科学家是和产品团队紧密合作的，不过他们独立的身份可以帮助他们更好地做出艰难地决策，例如可以告诉产品经理他们的产品指标还不够好，所以暂时还不能发布。
这种作为一支独立团队存在的模式的弊端就是它可能会面临被边缘化的风险。随着公司里产品团队规模慢慢扩大，他们经常倾向于一切都能自给自足。虽然他们可以从与数据科学家的合作中受益，但产品团队还是不希望依靠他们自己无法彻底掌控的资源。他们想一切都能依靠自己，为此，产品团队甚至会以招聘“研究工程师”的名义招聘自己的数据科学家，这样他们什么就可以掌控了。如果产品团队拒绝和独立的数据科学团队合作的话，那么数据科学团队就面临被边缘化的风险，无法发挥应有作用。这时很多优秀的数据科学家也将离你而去。
LinkedIn最初的数据科学团队也是一个独立的团队，自主性让这个团队在LinkedIn的很多产品上都做出过关键性的贡献，从提升“你可能认识的人”的推荐质量到有效监测虚假账号等等。然而随着LinkedIn规模日益壮大，作为独立团队的数据科学团队与产品团队的有效协作变得越来越难，尤其是当产品团队后来自己招聘了具有和数据科学团队类似技能的工程师后更是如此。最终根据实际需要，LinkedIn决定不再将数据科学团队作为一个独立的团队。
（2）让数据科学团队作为一个嵌入型团队
在嵌入型模式下，数据科学团队将人招进来后，会将这些人派遣到公司不同部门和项目中去。这时虽然还有一个数据科学主管，但他/她充当的主要是招聘经理和指导员的角色。
作为一种嵌入型团队，为了确保团队成员效用，它放弃了自主权。最好的情形是，数据科学家分别加入最需要他们技能的产品团队中，帮助解决公司内存在的一系列问题。
这种嵌入型的团队模式当然也是有自己的弊端的。并不是所有数据科学家都愿意放弃自主权（事实上很多都不愿意放弃）。数据科学家的职位描述里非常看重创意和首创精神，然而作为一个嵌入角色，通常要求他们完全服从被嵌入团队的主管的领导。
还有就是，作为嵌入团队成员，这会让数据科学家感觉自己是个“二流公民”，被嵌入团队的领导会认为自己不应该对这些安插到自己团队中的数据科学家的职业发展负责，而数据科学团队主管也会认为这些人不直接归自己管理。我们发现很多公司采用的都是这种方式，其实只有当你的数据科学团队规模比较大时才适合采用这种方法。
（3）完全整合型
在完全整合型的模式里，已经没有单独的数据科学团队了。事实上，这时是由产品团队自己去招聘和管理自己需要的数据科学家。
完全整合型有利于公司内部合作。让数据科学家成为产品团队里的“一流人员”解决了独立团队和嵌入型团队的一些弊端。这时，数据科学家、软件工程师、设计师和产品经理都围绕共同的产品目前通力协作，让大家更有团队意识，有效避免团队内部出现缝隙。
然而完全整合型模式的弊端是它稀释了数据科学家的身份。每一个数据科学家都只能与所在的产品团队相关联，而没有一个集中式的数据科学团队。此外，这种模式没有嵌入型团队模式灵活，因为在完全整合型团队模式下，你更难根据每个数据科学家的兴趣和技能对他们进行灵活调动。最后，完全整合型的团队模式也给数据科学家的职业发展带来了挑战，因为每个数据科学家所在的团队的领导可能并不能客观地评估他们的价值或是奖励他们取得的成绩。
在Instacart，数据科学家就是完全被整合进产品团队的。每一个产品团队都有自己的工程师、数据科学家、设计师和产品经理，工程师和数据科学家都向技术主管汇报工作，而技术主管自己可能并不是工程师或数据科学家。这个组织结构保证了工程师和数据科学家能够紧密合作，他们可能做任何有助于实现所在团队目标的工作。而作为数据科学副总裁，Jeremy主要为数据科学家和他们的团队领导提供指导。
上面介绍的三种模式各有利弊，你必须确定哪种方法适合自己的公司情况，并且做好根据实际需要实时调整的准备。有时候最好的方法不是一个单一的模式，而是混合模式。
如何打造一个尊重和重视数据科学的公司文化随时公司规模的不断壮大，你可能需要招聘越来越多的数据科学家。这里顺带推荐Jeremy的另一篇不错的文章：《怎样才能持续聘到优秀的数据人才？》。如果你能尽早在公司内部打造一个尊重和重视数据科学的文化，这将为公司后续发展带来诸多益处。
很多公司声称自己是数据驱动的公司，他们搜集很多数据，在数据工程上也投入了很多钱，但最后还是功亏一篑。
行动胜于雄辩，只有在一个真正基于数据做决策的公司里，数据科学才能真正发挥价值。
你需要在公司内部建立这样的原则和可信度：即使是有悖于常识或是可能会造成公司内部的权利剧变，你依然会基于数据进行决策。只有这样，才能真正在公司里形成尊重数据科学的文化并让数据科学发挥最大的价值。
和其他人一样，数据科学家也希望自己的工作被认可。只要做到尊重和重视数据科学，这就会形成一种良性的反馈循环，数据科学家将会更有动力攻克一些艰难的重大问题，同时确保他们的解决方案是可以衡量的。
承认和认可数据科学家的贡献有时是非常困难的，尤其当他们被整合到其他团队中时更是如此，这就需要你的数据科学主管非常优秀而且有影响力，同时公司高层管理人员应该定期去了解和认识到数据科学家对公司业务做出的贡献。
如果数据科学家不和产品经理、工程师和设计师紧密合作的话，他们是无法开发出卓越的产品的。如果主管领导不重视和欣赏他们的见解的话，数据科学家也将无法对产品产施展影响。
在Jeremy刚开始加入Saithru担任数据主管的时候，公司内的整个工程师团队对数据科学是持一个非常中立的看法的。为了让大家重视数据科学，在前两个月，他将自己30%的时间都用在了给工程师团队设计和教授一门有关统计学习的课程。在这门课程上，他将的所有例子使用的都是Sailthru的数据，给大家讲述打造数据驱动产品的各种一处。这门课程很快改变了工程师团队对数据科学的看法。最后证明，Jeremy为了让大家认识到数据科学的重要性而花的大量时间是非常值得的。
随着时间的推移，你打造的数据科学团队的成员将有不同的技能组合、不同的背景和世界观，这时他们也将发挥越来越大的影响。最后，为了让数据科学团队能更高效地工作，数据科学家必须要被团队成员、用户和公司决策者所信任。在组建团队的过程中，要招聘那些真正认同公司价值观的人，因为他们日后将给公司造成的影响是非常巨大的，或好或坏，他们做的决策可能会塑造公司的未来。
戳阅读原文了解更多！
往期精彩文章点击图片阅读
数据清洗要了命？这有一份手把手Python攻略
