[[150060]]

身為一名七年的數據從業者，對一些專業概念尚不能準確的描述。比如什么是大數據？我雖然從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個統計腳本，共有兩個工程師負責開發維護，新需求處理不過來，已有任務總是出問題。于是經理才痛下決心，安排我們去做一個系統來解決這一問題。

回過頭來看數據驅動

前面我們看了幾個不那么數據驅動的例子，接下來我們看看數據驅動應該是什么樣子的。數據驅動的理想狀態應該是人人都是數據分析師，每個參與業務的人能夠直接和數據打交道，有了問題，可以直接從數據中要結論，并且數據的獲取，不依賴于第三者，不像前面提到的有那么一個中間人老王。為了達到這一點，有許多的工作要做，比如數據源要采集全，數據模型要化繁為簡，強大的分析工具等，這是一個系統工程。