前言

我在阿里的6年

回顾我在阿里的6年，从经历来说，是先负责支付宝，继而负责淘宝，最终负责整个阿里集团的数据工作。实际上，这个过程同样也是我对数据应用的一个历程：第一阶段用数据，第二阶段养数据，第三阶段从看数据到用数据。

我在支付宝

加入支付宝之前，业内都认可我是一个比较懂得用数据去设计、优化、迭代产品的首席产品官。彼时我在支付宝，大胆地把产品与数据分析部门结合，积累了不少经验。

● 数据产品化，这个理念随我加入支付宝

说起加入支付宝，其实有些偶然。当时，支付宝邀请我去分享如何用数据做产品。分享会之后，我去了华星大厦的一个会议室，里面坐着Lucy（彭蕾，时任支付宝CEO）、Eric（井贤栋，时任蚂蚁金融COO）。在那个会议室里，他们问了我几个如何能用好数据的问题。当时，我反问了Lucy一个问题：“你每天大概会看多少数据？”

“大概几十个吧。”

“不对，你不应该一天看几十个数据那么多，我觉得你应该只看几个数据就够了。”

或许，他们已经不记得我提出的这个问题了，但是我却记得非常清楚。因为在支付宝的两年里，这是我做数据产品时一直遵循的原则。

正式加入支付宝后，我面对的第一件事情就是着手组建数据分析师团队。2010年的支付宝，公司大部分业务团队对数据团队都不太满意，而且高层对数据能产生的价值也没有太多认识。而数据负责人的调职，也导致了支付宝的数据分析和数据技术部门被分开管理。

面对数据分析和数据技术团队的目标不一致，加上业务部门对为什么要使用数据及如何用好数据充满疑问，甚至有人认为数据分析仅仅是门面功夫，所以技术团队有时候会跟我的团队“对着干”，因为两个团队的老板不是同一个人，他们也没有义务一定要支持我，所以甚至有时候会撇开我们直接跟业务部门对接。

但是最后，我坚持的数据分析产品化路线最终得到了双方的认同，技术团队甚至还主动过来问我：“我们怎么合作比较好？”所以那时，双方的关系从“对着干”变成了“我们会全力支持你”。

终于有一天，Lucy走进我办公室跟我说：“你知道吗？你们做的产品让我觉得很爽，我很喜欢这个产品。”而当我在支付宝的第二个产品“地动仪”出来时，她对我说：“这就是我梦寐以求的数据产品。”

同事和老板对结果的支持，让我肯定自己在支付宝走的这条路是对的。如果让我总结这其中的精髓，我的秘诀就是：数据分析也要讲求用户体验。

简单来说就是，别说是数据产品，哪怕一个小小的数据报告，我们都必须要知道以下5个问题：

● 这是什么问题？

● 这是谁的问题？

● 这个问题现在必须马上解决吗？

● 这个问题我们能解决吗？

● 我们有足够的数据来解决吗？

当我“苛刻”地提出“把月度经营报告当成产品来做，目的是让这份报告像iPhone一样好用”的要求时，整个团队都傻了：报告怎么能像产品一样呢？！那么，为什么数据报告不可以做到行云流水，让人看起来很爽呢？

所以，我是这么要求的：首先，报告的前3页一定要吸引人，让人有欲望继续看下去；其次，当别人看到一个数据，心里在猜测数据背后的各种原因时，我的下一页报告就要解答他心中的疑问。

因此，如果要用产品管理的理念来运行分析团队的话，必须要问“问题是什么”，并以此作为切入点。接着，解决用户的问题，得到用户的信任，然后就可以做更多的好产品。这是一套做产品的理念，因为产品需要不断迭代，并非一劳永逸。

那么，我怎么评估报告是否获得成功呢？简单来说，如果一个月度经营报告仅仅5分钟就被pass掉了，那它肯定是不成功的。

我在支付宝，几乎每一个月度报告都会让管理层讨论三四个小时，一份数据报告居然会成为管理层讨论焦点，每次都会有很多高层管理者关注我讲什么，这时我就知道自己肯定成功了。

当然，我也同时会提醒分析师们，千万别以为靠一份报告就可以解决所有事情，你一定要让业务部门认为这份业务报告是大家一起探索的，这是我管理团队的一个基本理念。

● 用产品化理念管理数据团队，这是推进的秘诀

总的来说，数据产品化的理念最终得到了Lucy及其他高层管理者，以及团队和同事们的认可。那么针对这个理念，我是如何在团队内一步步推动的呢？

首先，我让团队做好基础服务——“白米饭”。为什么叫白米饭？因为对人来说，如果“饭”不够就会出大问题。对于公司来说，如果数据基础服务满足不了我们的用户，那么他们就会跳起来，那时候再高大上的报告也没用。所以，我要求分析团队一定要跟业务部门达成一致，知道什么东西如果我们不提供给他们，结果会很严重。

但是，长期做“白米饭”的分析部门是没有前途的。所以其次，我抽出团队一部分人成立了“突击队”。每当我听到管理层对数据的需求时，就会把信息带到团队，让团队成立两三支“突击队”，让管理层用到有用的、合适的以及具有带探索性的内容。把自己最精锐的部队放在“突击队”里，这个决定非常重要。

但是值得注意的事，“突击队”有一个前提，必须要有人能接触到最高管理层的信息通道，否则无法得到高层的信息。而这个角色就是我，我接触最高管理团队，并且把信息输送给“突击队”。

基于“白米饭”和“突击队”，最后一步，我们开始沉淀数据分析的框架。为什么数据分析框架如此重要？因为它是数据产品的养分。我用建立数据产品为目标的理念来运营一个数据团队，所以数据分析框架才是给到数据产品养分的关键点。

在支付宝时，基于Lucy和Eric给我的支持，数据产品都是自上而下推行。我先做了“观星台”，这是一个高管的数据仪表盘工具；然后做了“地动仪”，一个给中层管理看的数据产品，接着还有客服360等。

所有这些数据产品，都是从数据分析框中提炼出来的。把分析的理念和框架变成数据产品，本质上是一个数据泛化的过程。这个过程非常重要，因为数据报告的需求会越来越多，如果没有泛化数据给使用数据的人，分析团队将永远被冗杂和重复的工作所困。

在这期间，我们也做过一个改变。因为“观星台”和“地动仪”还是传统的分析工具，只不过让你有更好的“眼睛”看到更好的数据，用我一直强调的理念来讲，这属于描述性的报告，用于描述一个公司今天做的怎么样。但由于我们有了分析框架，可能稍微会带一点诊断性。所以，这种产品主要是描述性产品，偶尔会做一些诊断，但还未达到探索预测的状态。

在这个看法的基础上我有了个新想法，想法的灵感源于Facebook。当时Facebook已经积极地开展探索性的数据产品，可视化及交互功能已经非常灵活。探索和静态报告的区别在于，用户可以选择自己的角度灵活地去看数据，真正做到“逛”数据。

因此，我们创造了一个产品叫“黄金策”。“黄金策”可以让用户很轻松地在3秒钟之内就看到不同标签下用户购物行为的异同。比如，30～35岁的上海女性，有一张信用卡和多张信用卡的两种不同群体，看她们的购买行为有什么不一样。或者，看广东和上海的女性在购物表现上有什么不一样。用户可以非常轻松地比较不同用户群的购物表现。所以，我认为好的数据产品应该是可以激发用户灵感的。

在做“黄金策”这个产品的过程中，我深有感触的是：数据行业的人会很容易让技术制约产品的发展。当时我提出做“黄金策”时，大部分技术工程师都断言，3秒钟出结果是不可能的。因为以前类似的灵活配置的报告，一般都不能做到即时查询，如果要快速产出的话只能找分析师。即便如此，也可能因为资源排期等原因等待很久。

当时只有一个人站出来说“我可以帮你搞定3秒钟”，这个人就是蒋杰（现任腾讯数据中心总经理）。于是很自然地，我就跟蒋杰一起合作了这个项目，并且成了好朋友。后来，蒋杰很出色地帮我完成了这个项目。所以，我觉得做技术的人不应该让当前的技术和思维限制未来的新产品。

就用户体验来说，用户之所以不用我们的产品，其中一个很重要的原因是，没有人愿意耗时太久等一个报告，因为当报告出来之后，他的问题可能早已经解决了。试想，我们拍下脑袋决定只需两分钟，但等一个报告要两个星期，而且报告的结果还不一定能帮上他，你说他会选拍脑袋还是等报告？所以，这也是我们产品人的理念：到底怎样才能解决用户的问题？这也是产品人和数据人不一样的地方。

● 让用户喜欢数据，就会让团队喜欢自己

除了以上这些有关数据的工作外，那时我还做了另外一件事。我启动了一个项目叫“西湖品学”，每年请公司外的数据牛人来分享经验，这是数据人的一场盛会，当时很受欢迎。我做“西湖品学”有两个原因：首先，我认为人们不使用数据不是他真的不想使用；其次，没有人推广使用数据的好处。

那时，我常在支付宝说一个比喻：“我右手用得好好的，你突然让我用左手，那你就要告诉我用左手的好处，不然我无法改变我的习惯。”

用数据的习惯也是一样，当他知道数据好用的时候，就肯定会用。所以，每一年的“西湖品学”，我都请外面很多人来讲数据到底有什么好处，让公司内部的数据人知道数据应用的商业场景是怎样的，从而激起更多人对数据的渴望和期待。“西湖品学”就是这样一个全新的尝试。

在数据分析人员中，我们大部分分析员都被戏称为“表哥”“表弟”（因为他们每天都要做很多表）。但是，每天仅仅做表的人会有幸福感吗？每天做这么多表，也不知道别人怎么用，没有结果肯定就没有幸福感可言。而“西湖品学”让他们知道，他们的责任在哪里、怎样跟业务对接，他们不仅仅是“表哥”“表弟”。所以我的目的就是，不让他们抱怨自己的才华被埋没了，而让他们知道自己努力的价值所在。

当我的分析师看到管理层很激烈地讨论他们做出的报告时，我能看见他们脸上的笑容：“不枉我们两个星期不眠不休地把这个报告做出来。”其实，大多数据人都不怕辛苦，怕的就是做出来的东西没人看。

总的来说，我对分析师们要求有些不同。我要求他们对商业有一定理解，这个本身就是我在这本书中提到的“混、通、晒”——混在商业场景中，把数据与商业场景打通，将数据产品当成载体，把这个东西晒出来，让更多人使用。当你看到你的用户不能没有你，当你看到你的用户满意的时候，你自然就会感到兴奋，整个闭环就会让人感觉很兴奋。

总结起来，数据产品化的理念是我在支付宝对整个数据分析部门的顶层设计，我一直用这个理念去运行一个部门，决定资源如何配置。怎样让我的数据使用者喜欢用我的产品，取悦我们用户的办法就是帮他解决问题。

然后就是让数据更泛化。我们必须宣传数据的好处，要教育我们的用户如何使用数据。我们不能假定用户最终会知道数据的好处，而是要一边宣传理念，一边教授技巧，让用户知道怎么用数据、怎么用好数据，知道数据的价值。

最后一点就是：让我们部门的员工喜欢自己，喜欢自己的工作。

我在支付宝的成功，也离不开我的坚持。首先我得益于自己坚持的整个顶层设计的理念，我的老板Lucy和Eric也十分支持我，给我机会，对我很支持和包容；最后就是我有很棒的下属，能够把我的理念付诸实践。

记得当我晋升到副总裁，成了当时阿里巴巴数据领域职位最高的人的时候，Lucy曾经说：“在中国，品觉是数一数二的分析师。”这句话当然是对我个人的偏爱，但如果她指的是电商平台数一数二的最好的分析师，我觉得能勉强接受。

每每回想起我在支付宝的两年，甚至离开支付宝到了淘宝之后很久，公司内外依然有很多人对我说支付宝的数据分析团队是最棒的。每当遇到这样的赞美，我都觉得非常欣慰。所以，那段经历让我感觉非常幸福。

我在淘宝

有一天，Lucy把我叫过去说：“现在淘宝很需要你，淘宝的数据体系需要你去整理。”那是2012年年底，也是我在支付宝的黄金时代，就这样我来到了淘宝，开始了我在阿里后4年的时期。

淘宝前两年的经历非常丰富，每每想起来都像过去了10年，我的白发基本上也都是在这段时间长出来的。

● 一样的开始，不一样的数据分析框架

从支付宝来到淘宝，意味着我要重新打一仗。由于我已经在支付宝打了一场胜仗，所以可以照搬很多顶层设计到淘宝使用。但我也不能完全照搬，因为淘宝使用的顶层设计有些跟支付宝一样，有些却完全不一样。

淘宝跟支付宝其相比其实要复杂很多，淘宝本身是个自下而上的组织，是个极其复杂的生态圈。有趣的是，当我来到淘宝时，居然面对的情况恍如回到了入职支付宝时的情形：团队的人差不多都走光了，我感觉就像踏上了一块杳无人烟的新大陆——分析师只剩下几个人，而且我被告知这几个人还会陆续离开。

面对这一切，我做了一个今天想起来仍然感觉很勇敢的决定：我说我不会带支付宝的一兵一卒过来。所以说，我是在支付宝建了一个完整的团队，然后在淘宝又重新组建了一支全新的团队。这段经历其实让我很痛苦，但也是极为珍贵的人生经历。和支付宝时代面对的团队不一样的是，我需要同时管理分析及技术团队，所以在淘宝不用经历支付宝前期那段业务分析和数据技术目标不一致的痛苦。

当时，淘宝的数据技术团队很乱，而且是累积多年的乱，所以要整理淘宝的数据体系，只用顶层设计和数据产品的方法来做，肯定是行不通的。

但还好此时我已经有很多经验，加上当时的总裁三丰跟我的感情非常好，比起我在支付宝时，其实办事更容易。比如在支付宝我还不能直接问Lucy到底你要什么，但在淘宝我可以随时到三丰办公室问他要什么，在支付宝我只是一步步尝试满足Lucy的需求，而在淘宝我有管理层的绝对支持。所以，我遇到的问题都是来自内部，没有外在问题。

在淘宝的分析团队中，我也同样分别推出了“白米饭”“突击队”和分析框架。不一样的是，我们很难给淘宝定KPI去说达到某个程度就是做得好。如果你说这样就好了，你会发现另一个指标可能就不好了。

也正因如此，当我们要建数据产品的时候，我犯了一个错误，我想用一个自上而下的方法去做，最终发现这在淘宝行不通。尽管得益于我在eBay的经验，对淘宝这样的双边市场比较熟悉，但后来我依然觉得淘宝的生态圈非常复杂，其分析框架和支付宝非常不一样。

当我发现自上而下的方法不行之后，我就逐步去做更多能发现问题的数据产品，总体来说还是：坚持数据泛化的方向。在阿里淘系这样自下而上的组织来说，因为权力已经下放给每个“小二”。泛化一个产品相对来说比较容易，每个“小二”需要数据帮他们做决策的时候，如果让他们每个人都用数据产品，这相比在支付宝时期其实更容易。反而因为数据非常零散，我们要决定到底如何做好一个数据产品，知道如何化繁为简更重要，因为虽然有资源，但是要用资源的人也很多。

关于在淘宝所做的数据产品我这里不再一一赘述，值得一提的是，我们当时做了一个非常重要的决定，就是移动终端。那时候，很多淘宝的消费者都开始使用智能手机，我就决定我们一定要做移动版的阿里数据App。淘数据这个PC产品在我来淘宝之前已经存在，只是一直不温不火，不是没人去使用，而是产品的用户体验不好。因此，当我们用移动版取代PC版之后，发现很多高管及中层管理一下子变成了午夜常客，我就知道自己的决定是对的。

此外还有一件事就是数据服务，当时需求也已经显现出来。因为我们这个部门承担的责任不仅是数据分析，还有数据底层的搭建。虽然我的业务分析团队当时只服务淘宝，但是数据技术团队要服务天猫、淘宝、聚划算等多个业务部门。这需要我们在数据服务上分几个层面去做：一是除淘宝之外的天猫、聚划算事业部的数据产品我们也帮他们做了；二是我只建数据中间层，别的部门可以用我们的数据中间层来建他们的数据产品；三是提供数据服务，我用早期的数据服务方式把数据输出给其他部门使用。这就是我在淘宝的前半部分时间的情况，上半身（分析师）是淘宝，下半身（数据底层）是集团。

● 建立数据公共层，是阿里大数据的开始

进入阿里集团的这几年里，大部分业务部门的分析师都归我管理，同时数据平台和技术底层也都在我这边，所以我的业务就演变成了集团数据技术及产品部，内部叫DT。

回想淘宝期间，我一直觉得如果我能早一点整合数据底层团队，收获会更大。整合数据要花的力气往往跟数据的离散、不规范、各自为政很有关系。有时白纸一张重新开始，比起消耗大量时间在处理老问题更简单得多。

而对于我们整个DT部门，这时候有两个新的使命：一是做对外的数据产品，即生意参谋，同时也逐步把集团中其他对外数据产品例如数据魔方及量子报告等综合到生意参谋上；二是建立数据公共层，数据公共层是结合了集团各业务群的共享资源而成的数据服务，希望可以成为内部的DaaS模型。

数据公共层的起缘是因为当时集团各个部门建了很多自己的数据“烟囱”，重复建设严重，导致数据的存储、加工等资源严重浪费。怎么把各个“烟囱”中的数据分为专有和公有，并且把公有的数据放在数据公共层，这是我在这段时间内耗费精力最多的事情。在我眼里，这个数据公共层也是我认为在大数据中最重要的东西，我也在其中学到了很多经验。

前面提到的那些应用，我们都可以称之为“数据”，而这时才是“大数据”。“大数据”的意义就在连结，数据公共层就是跨业务群的精华，让所有人能把其他人的数据冗余利用起来，这时“大数据”才算做了起来。

我这么说，不是说我们以前没有数据共享，而是从前都是零散和没有计划地分享及同步数据，有点小打小闹。到了正式建立数据公共层的时候，才有人去整合全集团的所有数据，把它当成一个数据资产共建来看待，所以数据公共层后来就被CEO定义为公司唯一的数据资产的收集与加工的部门。

● “混、通、晒”和“存、管、用”，帮我打通数据闭环

在我淘宝的几年生涯里，一个非常重要的项目让我永远难忘。

有一年，马云让我们把聚划算自动化，在我眼里其实这就等同于商业版的无人驾驶技术——因为，要把聚划算这个部门的品类规划、选品、定价等流程自动化，让机器决定什么产品哪天上聚划算。它要求整个链条中的决策都要自动化，而没有人参与其中，这对我们数据的收集、加工、提炼等整个链条的能力都提出了非常大的考验。

而且，这个项目也是真正实验如何在业务运营中使数据技术成为主干的一步，数据能力、算法要完全融入到业务流程当中，每个环节中的数据回流等成为闭环的一部分。

好在这时我们的部门已经是一个具备全方位支持能力的，能够覆盖数据的准备、加工、收集、分析、整合到使用整个链条的部门了，而且我的数据科学团队也已经开始涵盖集团中很多不同业务的项目，甚至连交通这样的政府项目都有涵盖。

我这段时间的经历，我想说我很荣幸，能够用我的白头发换来亲自经历一场人机大战的故事，让我可以在过去3年中接触到这么多数据甚至整个数据链路，最终我实现了数据应用的闭环。要做好数据，我们首先要在数据使用的闭环中让数据越来越容易使用，同时在数据准备的闭环中，让制作数据的成本越来越低（见图0-1）。

闭环系统中，虚线以上用户能很简单地使用，虚线以下是让数据制作变得更快更自动化。一个是使数据产生价值，如何让多种多样多变的数据原材料很快、很灵活地重组，并且使它相对稳定，这就是做数据基础建设天天要去想的问题。如何让而使用数据变得越简单越好用，这是两个闭环。

这就是我曾提到的“存、管、用”和“混、通、晒”。“存、管、用”就是用技术而不是人工的方法去做资产或材料管理。怎样评估是不是做的好呢？得看数据有没有、细不细、全不全、稳不稳、快不快。所以，一旦把数据管理好了，我们就会很灵活很快地做出数据，并且在使用的时候产生很大的价值，到底我们提炼到的是垃圾还是黄金就取决于此。

以往用数据要“混、通、晒”，养数据要“存、管、用”，经历了支付宝和阿里集团的6年后，我觉得以上每个环节都已经出现很多创新，比如感知（sense）技术的创新让数据收集层面多姿多彩；存储的格式会更适合于数据灵活掉动；人工智能除了直接服务于产品外还可以增加数据的识别度；大家都已经意识到数据的互联互通及质量保证是DT的基础……

● 整合和配合，数据团队要学会取舍

在淘宝的几年，可以说是我在支付宝成功之后的收成期。得到领导的信任，拿到很多重要的项目，很多人都想加入我的团队，人才也不再是一个问题。

从我进来淘宝到现在，数据团队一直是急速奔跑的团队。我进淘宝时，团队仅仅7个人，如今已经发展到700多人，规模扩大了100多倍。与此同时，数据部门承载的管理层的期望也越来越高，也越来越在聚光灯下。

团队发展时，我一直比较纠结员工配合的问题，工程师和分析师的合作是数据部门的一个“死门”。因为分析师总是想把脏活给技术的人做，而技术的人觉得这是个苦差事，总是想做一些比较偏业务的事情。这两者之间常常都不满意各自所在的位置，想跳出自己的圈圈。此外，分析师也有一些配合的问题，比如决策分析和业务分析两种分析师到底该怎么区分，怎么让大家一起合作一直是个难题。

这样的配合我认为是数据和业务团队的整合。中央部门的数据团队一定要面对一个很残酷的问题：什么东西是我们该做的？什么又是当时机成熟之后要放手到业务部门的？

简单来说，就是谁做得好就应该谁来做。2014年时，我也曾想把商业分析团队放回到各个业务部门中，结果业务老大都不同意，认为我管更好，谁做得好归谁。

在很多项目中，我发现只要业务部门一旦看到数据能帮上他的忙，而且是非常重要的东西时，他们就会把应用的东西拿回去。所以中央部门不用强求，只能做小项目。在大项目中，大部分业务团队都有自己比较好的应用场景，都能更好地进行试验。所以，中央部门慢慢要形成好的数据中间层，这是关键。

中央部门很难做好应用，分析师也一样。应用和分析师都需要对业务场景非常理解才能做好。而底层的数据怎样更灵活、更快、更容易给用户使用，肯定是中央部门需要做的。

但划分不是完全绝对的，而是你中有我，我中有你。决策分析肯定最好放在中央，因为决策分析是服务整个公司的，帮助CEO来看大盘，肯定不能用业务部门的视角。

数据则分公有数据和专有数据，专有数据要回到离应用比较近的地方。公有数据是公司最有用的资产，在中央部门集中管理，让它成为很重要的材料以供别人使用。那么，边界怎么分？我只能说：只要大数据的情况越泛化，中央部门所需要承担的责任就越重，也越集中、越具体。

这些年来，我觉得现在阿里的数据依然没达到我理想中的蓝图，主要有两个原因：一是整个大环境还未形成，二是阿里的数据环境才刚开始，演变是循序渐进的过程。这个过程，是急不来的。

我看数据科学

在2010年年底，我就意识到有大数据的出现，所以当时就跟Lucy提出，支付宝要有一些数据科学的人才储备，但可惜的是，我虽感觉到了新时代即将来临，却未能正确地指出机器学习的趋势，所以没有大力引进。

而到了淘宝后，我是第一个在管理层力推大量招聘数据科学家的，当时还有其他高管质疑我的做法。但在当时淘宝总裁的大力支持下，我终于如愿。记得我招到第一个数据科学家后，我们每周都会在我办公室约谈，用非技术的语言聊数据科学家是做什么的，以便很快加深我对数据科学的理解。

传统的数据科学家常常是博士或博士后，研究的方向是机器学习。数据科学家的出现其实是个演变的过程，几年前企业的数据应用都是看多用少，不够直接，也很少涉及机器学习、算法等领域。

从数据科学家进来的那天开始，我就认为他们是不可缺少的，他们的工作不是今天的数据分析师和数据挖掘工程师能做得了的，虽然数据分析团队中也有数据挖掘的人，但数据科学和数据挖掘是有所分别的。

我认为合格的数据科学家应该是有产品意识的，为了解决问题会更偏重于找到问题的原因，然后寻找最好的方法来解决它。所以可以说，区别就在“科学”这两个字。

数据科学是科学不是工程，工程追求效率，科学追求真理。如果数据科学家做得太实操，就会变成一个数据挖掘工程师。如果他“飘”在空中，便没办法在企业中生存。

企业想要找到既能上天也能落地的数据科学家很难。在我眼里，一个企业如果有这样的人，就像三国时期刘备有了关羽。但可惜的是，这世上的关羽少之又少。

在这种情况下，企业应该把事情分为长中短线来看。顶层设计要比较清楚，让数据科学家能做一些比较有难度的事情，让能落地打仗的工程师去做落地的事情。这两者如果没有好好区分，他们之间就会“打架”，这样企业耗不起。此外，从企业环境来说，一个公司到底有没有科学精神，也会非常影响数据科学人才的落地。

经历过对数据科学的理解后，回想我在支付宝做的最后一个 “黄金策”，如果今天让我重新做这个产品，我不会用以前的方法，因为今天的技术和曾经的技术已经不一样了。

“黄金策”给人的感觉是可以发现很多东西，但同时能发现的东西也是有局限的。虽然有600个或800个用户变量给你自己组合，但数量还是只有600个或800个，能不能有6000个或8000个呢？从今天的技术来讲，用深度学习的方法，有些环节机器会比人做得更好。

6年来我所做的工作都是人用经验提出一个假设，然后用数据来证明哪个假设更可能。到今天为止，让数据告诉我们新的发现，而不是人的经验，还是少数情况。但数据带来的这些新发现，是人类以前的逻辑中所没有的。换句话说，数据重组了这个世界的“可能”。

这是人类为什么要花很多资源去做大数据的原因所在，因为人类的思考本身是有局限性的，如果使用集体智能，用深度学习的方法来找出人都提不出来的假设，然后通过人机协作找出未来的新世界、新智慧，这就是数据科学要走的路。

数据科学如果不是每天都在进步，每天不满于今天的状态去PK以前的理论，就不是数据科学，而是死工程。数据科学每天都在突破以前的理论，因为以前的理论只能解决某个点，以前的顶层设计只适合于以前的情况，未来的顶层设计怎么样，需要我们不断去探索，而科学就是探索。