<div id="n091y"></div>
<sup id="n091y"></sup>

    <dl id="n091y"><ins id="n091y"></ins></dl>

    <div id="n091y"><ol id="n091y"></ol></div>

    <em id="n091y"></em>
    <div id="n091y"><ol id="n091y"><mark id="n091y"></mark></ol></div>

    <sup id="n091y"><ol id="n091y"><small id="n091y"></small></ol></sup>

      追求數據團隊的多樣性,就好比大數據的多維度那么重要!

      大數據金融

      2018/11/05   編號:1512568

      已收錄案例1674篇

      訂閱

      IT部門一般是企業的后端部門,而數據團隊(很多企業叫BI團隊)則是IT的下游,可謂后端的后端,數據團隊做報表取數是本分,但如果你想在業務上有點直接貢獻則非常困難,比如數據團隊好不容易研發了一個模型,但發現要推廣到全公司則是困難重重。

      為什么?

      企業對于數據團隊一般有兩個方面的訴求,第一個,做好報表取數等數據支撐,維持公司的正常運作,比如KPI,財務報表,營銷取數等等,第二個,以數據來驅動公司業務的增長,這個使命在進入大數據時代后變得非常迫切。

      但這兩種職能,對于團隊結構的要求是完全不同的,因為前者的訴求是穩定,后者則是創新,我們總是希望一只數據團隊在做好報表取數的基礎上,能夠去做點數據創新,也叫所謂的亮點,從而能更好的體現出自己的價值。

      但你會發現,亮點永遠只是亮點,你的數據創新驅動不了公司的業務發展,一方面報表取數就像無底洞一樣耗盡了團隊的精力,資源總是不夠用,另一方面,業務部門似乎也對你的數據創新不敢興趣,廠家更是不給力,好不容易搞了個模型還曇花一現......

      沒有貶低任何工作的意思,報表取數是很專業的工作,非常強調穩定與標準化,公司需要這類特定的人才,但既然做了報表取數,就不要讓他身兼數職去搞什么建模創新。

      針對數據創新,比較好的組織形式其實是在業務部門直接設立數據組織,這樣溝通成本最低,但由于業務人員的存量包袱往往太重(新創企業或部門例外),創新性會不足,而且數據驅動業務這種思想在國內并沒成勢,改變也不是一天兩天的事情。

      最靠譜的就是IT部門自己設立數據創新團隊,大數據紅火的這幾年,很多公司的大數據團隊也起來了,但如果只是簡單的從原有BI團隊劃幾個人組成新團隊,那就是換湯不換藥,基本沒戲。

      筆者經歷了BI大發展時期,也有幸進入了大數據時代,更有幸還在干數據的活,因此可以做一些比較,自己的判斷是這樣:一堆只有取數或報表經歷的人是很難碰撞出火花的,即使補充了數據建模師也無濟于事,因為數據創新是個復雜問題,缺乏多樣性的數據團隊要獲得突破很難。

      下面舉兩個案例, 第一個是關于算法應用的 :

      團隊的建模師一直致力于解決定位的精度問題,優化數據和算法是其強項,但發現如果讓他們單獨去前端找驗證的場景,或者推銷他們的成果,往往半天都沒個回音,進展非常慢。

      筆者后來下了個決心,把做位置產品,商務支持和建模師三個人組成了團隊,發現效果是顯著的,他們在非常短的時間內就研發出了驗證精度的工具,同時把算法成果應用到了實際的產品中,并且幫助商務解決了幾個實際應用中的問題。

      但一般企業不具備這個條件,這三個人分屬三個組織,怎么搞?

      第二個是關于數據產品提升的 :

      筆者在《直擊傳統商業五大痛點,如何打造一個爆款的商圈洞察產品》中提到我們研發了一款商圈雷達產品,原來的產品開發模式基本是產品經理主導一切,合作伙伴照著做就行了,至于要選擇哪些數據,產品經理往往是根據客戶要求到標簽庫找就行了,有就有,沒有就沒有,最多再調研一下。

      但數據產品的核心競爭力其實是差異化的數據,產品團隊其實需要有較為資深的數據模型人員參與,你才能知道數據的深淺,哪些數據可用,哪些數據不可用,哪些標簽可優化,哪些標簽要放棄,還要諸如數據的呈現方式等等。

      數據產品團隊只有配備了專職的數據模型人員才能確保基本的質量,一款數據產品如果僅僅僅經歷了功能的迭代,而沒有數據的迭代,這種數據產品很難有生命力,花哨的界面客戶看多了也就這樣,數據產品一定要回歸到數據本身。

      筆者也在反思傳統BI團隊的應用推廣困境,雖然有機制和流程上的問題,但如果從自身找原因,可能是傳統BI團隊缺乏一定的多樣性,你不大可能讓一個純粹搞數據的人去做推廣,因為運營真的是一個非常專業的活,你得找到適合的各類人才,但大多時候,我們沒有,只能硬著頭皮上。

      你們不是搞建模的嗎?誰會為一支數據團隊配備運營人員呢?然后我們一天到晚找業務人員,說運營是你們的事啊,但事情沒搞大之前,Who care?這個溝通成本真是太高了。

      因此,大數據團隊要有點突破,有機會就扁平化到底吧,商務的,數據的,產品的,每天你看我,我看你就可以了,他們自然有機會演化出一些好東西。

      最后有人也許會問,憑什么你說得是對的?

      正好最近看了一本講多樣性的書,叫 《多樣性紅利》 ,作者是密西根大學政治學教授斯科特·佩奇,其不僅講了多樣性的好處,還說了多樣性要發揮作用的前提條件等等,人家都研究了好多年了。

      追求數據團隊的多樣性,就好比大數據的多維度那么重要!

      佩奇給“多樣性的好處”,找到了堅實的數據基礎。佩奇提出, 多樣性有兩個好處:一個是解決問題,一個是做預測,一個多樣性的團隊特別適合解決復雜的問題,和對復雜的事物做出準確預測。

      佩奇的理論可以用兩個數學公式概括:

      (1)群體能力=平均個人能力+多樣性

      (2)多樣性>能力

      這可不是兩個觀念上的公式,它們背后有嚴格的數學推導,如果你知道怎么計算統計學上的“方差”的話,用最簡單的語言說,多樣性的好處就是,三個臭皮匠,好過一個諸葛亮。

      很多公司搞開放的辦公區域,就是希望不同部門的員工能夠經常碰撞在一起,時不時來個頭腦風暴,但你也許會再問,既然多樣性群體智慧這么有效,那為什么不把事情都交給群體?

      比如中國足球每次輸球,論壇上都有很多“懂球帝”一致認為主教練的排兵布陣有問題,既然如此,中國足協為何不干脆把決定出場名單的權力交給廣大球迷呢?筆者經歷也告訴我,大多時候頭腦風暴沒啥卵用。

      為什么?

      佩奇又說了,要產生多樣性紅利,你的問題必須滿足四個條件。

      第一, 這個問題必須得足夠難 ,如果一個人能解決的事兒,強行搞多樣性就是浪費人力。

      第二, 群體中每個人,都必須有一定的能力 ,你一個專業的問題分析會讓個不理解背景的新人參加,其實是浪費他的時間。

      第三, 群體中每個人都有跟別人不一樣的視角和解決問題的方法 ,比如建模的人和產品的人正是擁有不同的思維模式和技能,兩者組合才能有多樣性效益,讓一堆建模的人討論模型推廣的事情,往往沒戲,這其實是最本質的一條。

      第四, 群體的規模必須足夠大 ,這倒不盡然。

      話說回來,數據團隊專注于建模其實沒錯,以前搞天盾反欺詐,由于業務人員急的很,運營的事情完全不用操心,因此團隊只要專注于提升模型準確率和覆蓋率就可以了。

      但如果自己要搞點創新,特別是人家開始還不太理解, 比如大數據就有這個特點, 這個事情的推進就會變得異常艱難,需要你的團隊有多樣性的能力,從建模、優化、推廣、變現到運營,不一而足。

      很不幸,數據創新大多數時候就是這個狀態。

      最后,每周我將會挑1-2本我讀過的書或文章進行推薦,優先大數據、人工智能類,歡迎選讀!

      作者:傅一平 (微信號:fuyipingmnb)


      好書或文章推薦(每周我會挑選出1-2本好看的書或文章進行推薦)

      《洞見數據價值:大數據挖掘要案紀實》 畢馬威中國大數據團隊的書,比較偏實戰,不少大數據應用案例,大數據的概念解釋得不錯,實戰中比如基于聚類選擇變量的一些做法值得借鑒

      《斯多葛派哲學的安心之法》 這篇文章來自萬維鋼·精英日課第一季, 斯多葛控制二分法 :”在生活中,有些事情是你能夠控制的,有些事情你是控制不了的,而你應該只關注你能控制的東西。” 比如你去參加面試,你只能控制自己,不要把希望寄托在外部目標上,否則你就會有各種焦慮不安的情緒。



      相關推薦

      本文從信息價值維度、IT價值鏈維度等幾個方面對大數據標準進行了梳理。

      新新金融 大數據金融 2018/12/06

      據知情人士透露,最近大數據行業,有大量從業者被警方帶走調查。 ...

      新新金融 大數據金融 2018/11/12

      一、大數據和人工智能 大數據是伴隨著信息數據爆炸式增長和網絡計算技...

      新新金融 大數據金融 2018/10/29

      已收錄創新知識

      75,160

      知識分類

      打開微信“掃一掃”,打開網頁后點擊屏幕右上角分享按鈕
      今日3d试机号和开机号
      <div id="n091y"></div>
      <sup id="n091y"></sup>

        <dl id="n091y"><ins id="n091y"></ins></dl>

        <div id="n091y"><ol id="n091y"></ol></div>

        <em id="n091y"></em>
        <div id="n091y"><ol id="n091y"><mark id="n091y"></mark></ol></div>

        <sup id="n091y"><ol id="n091y"><small id="n091y"></small></ol></sup>

          <div id="n091y"></div>
          <sup id="n091y"></sup>

            <dl id="n091y"><ins id="n091y"></ins></dl>

            <div id="n091y"><ol id="n091y"></ol></div>

            <em id="n091y"></em>
            <div id="n091y"><ol id="n091y"><mark id="n091y"></mark></ol></div>

            <sup id="n091y"><ol id="n091y"><small id="n091y"></small></ol></sup>