身为一名七年的数据从业者，对一些专业概念尚不能准确的描述。比如什么是大数据？我虽然从2008年开始做这块的东西，但国内到了2011年的时候才兴起了这一概念。我花了三四年的时间，也不能对其有一个准确的把握。就在前天，我把我对大数据的认识拿出来和团队交流时，也产生了多处分歧，甚至有成员提议不要提“大数据”这一名词。可有客户就是被“大数据”这一概念吸引过来的，你绕开这块不讲可不行。同样，对于什么是数据驱动（Data-driven）？我依旧不能给一个准确的描述，这也许是一个新事物在发展过程中必须经历的阶段，等到尘埃落定，没有分歧的时候，也是它寿终正寝的时候。虽然无法准确定义数据驱动，但我却能通过一些对数据驱动的似是而非的认识（迷思，Myth）做一个剖析，然后再做一个总结，我们对它的认识就会更进一步了。
迷思一、KPI就是数据驱动
KPI是Key Performance Indicator的缩写，指关键绩效指标。我们在衡量目标是否达到时，最好能够有一个能够衡量总体效果的标准，这就是KPI。KPI通常是一个数字，比如今年某一企业的销售目标是5000万元，国家的GDP增长要不低于7.5%，小米手机的出货量要突破1亿。这些KPI可能是基于以往的表现评估得出的，也可能是拍脑袋的。有了KPI，组织就有了明确的目标，组织内部就按照这一目标，层层向下分解，只要每个基层完成了任务，那么组织整体的KPI就可以达到了。这种方式的好处有一堆，坏处也有一堆，咱们在这里就不论证了。咱们只讨论KPI是否是数据驱动？
KPI有一个典型特点是自上而下的，先有了一个数据，然后上下齐心协力把这个数据给坐实了。这种方式有可能是不切实际的，比如中国历史上的大跃进运动。这种方式不是先有了数据，从数据出发，再做新的决策。KPI的达成过程，是组织通过努力驱动数据的过程。正好是我们说的数据驱动相反的模式。
迷思二、有了仪表盘就是数据驱动
不管是稍大规模的传统企业，还是任何规模的互联网企业，仪表盘已经是标配了。通过仪表盘，我们可以监测到公司的总体运作情况。对于公司的创始人来说，有了仪表盘，就可以对公司总体做决策了。但对于产品、运营等具体干活的人员，这可就傻了眼了。明明昨天一个机房挂了，但流量还在涨。只看到总用户量下跌了，但仪表盘上根本看不出来原因。如果想要进一步研究问题，必须对数据进行进一步的下钻，这又超出了仪表盘的承载能力。难免对有些成员来说，这些泛泛的指标很难指导决策，不看也罢。
迷思三、有专职数据工程师跑数据就是数据驱动
工程师老王（本来写的是小张，团队的小张同学抗议，后来改成老王，团队的王姓同学说他老婆总叫他老王。。）负责处理所有跑数据的需求。运营同学相对上个月的活动效果进行一个评估，提了一个统计数据的需求。产品同学拿到了新功能上线的用户数据，发现比上线之前还降了？这一定是统计程序写的有问题。我们再来看看干活的老王，每天干着没有尽头的跑数据的工作，为了能够让自己不过早累死，就制定了一个复杂的数据需求规范，让那些想要跑数据的同学费一般功夫才能提过来，拉长周期，要是写的不合格，直接让需求提出者回去重写。老王已经尽力了，可因为需求提出者太多（在一个产品发展超过一年，就会出现这种情况，除非产品快挂了），后提的需求需要经过很长的周期才能满足，有些同学可能觉得提数据需求太麻烦，干脆还是换做拍脑袋吧。
这种模式下看似也能运转的通，但实际许多需求被压抑了，被强制串行化。
迷思四、每个需求都是一个新的脚本
在创业公司，多面手居多，有的甚至是全栈（什么技术活都能干）。产品运营同学或老板有了数据需求，某位同学可能三下五除二就搞定了。写了一个只有他一个人能看懂的脚本（脚本是一类开发效率很高但是运行效率可能较低的程序代码，比如用perl、python等编写。）。这久而久之，就出现了一堆不同的人写的不同的脚本。如果来了新人，十有八九会交给新人去维护。因为这些脚本写的时候图快，并不会做code review，甚至连跑的数据是否正确都不能保证，那代码质量可想而知。特别是如果有人专门负责写统计脚本，那干三个月还行，觉得能够学到不少的知识。干六个月的时候，就有点腻了，发现都是重复的工作。干到一年的时候，十有八九会想走人。如果小李是接手者，发现上百个脚本，看不懂，看不完，就只能骂娘了。
工程师都是乐观主义者，对于某个数据需求，总会说这很简单，给我10分钟就搞定了。而实际要把这个脚本变成可用的任务，可能要花费两天时间。许多数据需求是例行的，那么就需要管理数据源、生成的中间数据、最终结果的发送，那么想要维护好，就不是那么容易了。更何况数据源头的格式可能发生变化，那么所有的脚本可能都跑出了错误的数据。这让我想到2008年，我刚加入百度新产品部统计团队时。当时共有20台统计机器，有500~600个统计脚本，共有两个工程师负责开发维护，新需求处理不过来，已有任务总是出问题。于是经理才痛下决心，安排我们去做一个系统来解决这一问题。
回过头来看数据驱动
前面我们看了几个不那么数据驱动的例子，接下来我们看看数据驱动应该是什么样子的。数据驱动的理想状态应该是人人都是数据分析师，每个参与业务的人能够直接和数据打交道，有了问题，可以直接从数据中要结论，并且数据的获取，不依赖于第三者，不像前面提到的有那么一个中间人老王。为了达到这一点，有许多的工作要做，比如数据源要采集全，数据模型要化繁为简，强大的分析工具等，这是一个系统工程。
本文作者：桑文锋
来源：51CTO