【轉載】如何組建一支優秀的數據分析團隊？

http://www.36dsj.com/archives/38744

Q：數據分析人員能作什麼？

A：從紛繁的數據裏提煉出有價值的信息並給公司提供支持啊。

Q：你怎麼提煉啊？

A：寫程序採集啊，清洗啊，用必定的算法計算數據內部聯繫，根據業務作出判斷啊……

Q：若是都是用已有的算法，這些事情爲何不能用現成的流程來作呢？或者爲何不能寫成程序，讓機器本身實現呢？

A：呃…………

做爲一名數據分析師，剛入行的時候跟人聊天聊成這樣，很是常見也很是使人不爽。但咱們數據分析師是否是僅能手工操做一些算法，等着機器和算法逐步取代咱們麼？並非！

照例觀點先行：數據分析不等於數據分析算法/程序，數據分析算法/程序只是分析師手中的工具，數據分析要取得成功必須依賴人的力量，數據分析師的做用在於根據對業務的理解，合理使用分析工具，完成分析目標。

結合業務的數據分析纔是科學的，一切只看計算機輸出結果不考慮業務實際狀況的數據分析都是無（shua）用（liu）功（mang）。計算機能實現的算法也好，程序也好，只是數據分析中的一部分；如何選擇分析切入點，如何選擇數據來源，如何肯定算法，如何解讀結論，這些機器通通作不了，須要咱們數據分析師來解決。

觀點在上邊兩段裏已經充分展現了，接下來我要愉快的展（che）開（dan）觀點內容了：

數據分析一般包括幾個階段：提出/發現問題——獲取並清洗數據——建模——調整優化——輸出結論。

這是一個閉環流程，每一步都須要人工參與，程序會參與中間三步，算法在建模中會用到，而數據分析的最重要兩步，問題和結論，目前是不可能徹底交給計算機去處理的（其實我我的認爲這兩步在真正的人工智能出現前，毫不可能由計算機自動處理），所以數據分析人員最大的優點，就是「經驗」，也就是業務理解能力和數據分析經驗。

詳細解釋一下數據分析的幾個階段：

提出/發現問題階段：

大多數時候，數據分析都是爲了解決一個問題（鎖定某個產品的目標客戶，對一樣的人羣作營銷活動用A方案好仍是B方案好，等等），或者驗證一個猜測（不讓旅遊者上班高峯坐地鐵是否是會大幅度緩解擁擠現象，啤酒和尿布放一塊兒是否是真的會提高啤酒的銷售額，等等），總之須要達到一個目標。即便是探索性分析（拿着一大堆數據看看能不能找出點什麼結論），那也須要先預設一個或多個目標做爲切入點，而後在探索過程當中逐步修正。

提出和發現問題的過程，交給計算機幹不太靠譜，首先計算機不會提出問題（由於笨），其次計算機能發現的問題也必定是人已經發現了的問題（仍是由於笨），須要先有人來設定規則，而後計算機才能根據規則發現問題。而數據分析師，就是設定規則的人。

目標和規則的設定，必定要基於業務，這樣分析結果纔有用，不然會得出正確但無用的結論。舉個栗子，訂閱報紙的數據扔給計算機去分析關聯關係，看有哪些報紙能夠進行組合促銷，最後得出個光明日報和人民日報關聯繫數90%多，因此這倆報紙能夠組合起來賣，問題是這倆報紙原本就是要求黨政機關訂閱的黨報，組合起來毫無心義，該訂的仍是要訂，不訂的仍是不訂，這就是典型的正確但無用的分析結果。懂業務能讓分析師少作這種無用功，可是計算機要想懂業務就得由人來教，教還不必定能教會，教完了又不能舉一反三（報紙的關聯算法拿到電商去徹底不能用啊），這樣的計算機永遠都不如分析師懂業務。

獲取並清洗數據：

這個階段計算機參與的較多，分析師的工做是指出拿什麼數據，拿哪些字段，數據獲取到之後用哪些規則進行清洗整理。若是數據源不變，須要重複或按期進行分析時，這個階段的規則能夠固化，由計算機來自動執行，但規則仍然是由分析師來制定的。

建模、調整優化：

這兩個階段中，分析算法出場了，描述分析、關聯分析、迴歸、分類、聚類、時間序列，每一個類別裏都有一大堆的固定算法，分析師不能經過手算得出結論，須要藉助封裝好算法的分析工具（圖形化的SPSS，命令行方式的R，等等），看來這一階段計算機要超越分析師了！

等等，建模哪有這麼簡單，計算機解決不了的問題一大堆呢：何時用哪一個類別的算法（該作分類仍是聚類），同一類別不一樣算法哪一個更適合當前狀況（K-means仍是兩步聚類，這是個問題），同一個算法怎麼調整參數能使效果更好（到底該把用戶聚成幾類呢），算法輸出的結果是否正常（有一部分數據出了問題致使分析結果出現誤差）等等。這些問題計算機通通不知道耶，須要分析師來告訴它該作什麼事。

打個比方，數據分析就是打仗，算法是機槍、大炮、坦克等等技術兵器，分析師是士兵、炮手、駕駛員（操縱者），不能由於士兵本身不能一分鐘吐出幾百發子彈或者炮手本身不能一會兒拆掉一個碉堡，就讓機槍大炮坦克把操縱者扔下，本身上陣去打仗……就算是無人機，那也得有個拿遙控器的駕駛員蹲在辦公室裏操做啊……

算法始終只是工具，數據分析效果如何仍是要看用工具的分析師功力如何。一個作過幾十個分析項目的分析師，功力一般來講比剛入行的分析師或者純開發人員要深厚一些（極少數天賦異稟的不算……），選算法調參數建模型的能力更強一些，分析出來的結果也會相對靠譜一些——沒錯，經驗在這兩個階段就是優點。

輸出結論：

這一階段計算機的工做已經基本完成了，對模型輸出的數據進行解讀，那徹底是分析師的天下——同一份數據給不一樣的分析師，可能會得出不一樣的結論，不少時候分析師並不僅僅根據數據自己得出結論，還要結合不少外界因素來修正結論。分析師的經驗越豐富，擁有的有效信息量越多，得出的結論就越接近事實（之因此用接近，是由於對數據解讀的準確度永遠達不到100%，影響結果的因素太多了，好比一個企業銷售額連續增加10年，分析師根據公司數據和市場狀況判斷下一年還會繼續增加，結果老闆出事跑路了，企業直接倒閉），而這個過程是計算機目前沒辦法自主進行的，商業智能系統作的再好，也須要由分析師來設定規則，告訴計算機在什麼時間須要作什麼。

也許隨着大數據和人工智能的發展，有一天計算機能夠徹底不依賴人工設定的規則（不須要肯定數據來源，不須要選擇算法和模型，不須要人工干預來修正模型，等等），本身對數據進行全方位的分析，加入全部因素的影響，並輸出準確度很是高的報告，只有到那時候，分析師纔會失業啊。

不過，真到了那一天，恐怕不光是分析師失業的問題吧……

一個成功的數據分析團隊：角色與職責

多年以來我和數百家企業打過交道，在這個過程當中，我領悟了讓數據分析項目成功的一些因素，也親眼看着不少項目失敗。

最多見的失敗緣由說出來可能會讓你驚訝。並不是是缺少數據專業知識或者整合失誤，而僅僅是由於企業沒有讓「利用數據」成爲任何人員的職責。太多公司花費好幾個月收集有趣的數據，而後讓它們靜靜地躺在角落裏積攢灰塵。這個現象驅使我來撰寫本文，但願它能給你靈感，讓你爲下一個分析項目增長一些結構性。 對分析的應用，本應該成爲你不斷汲取的商業泉源。

若是能爲下列每一個角色，找到至少一個樂於擔當的人選，我保證你項目成功率會增長一千倍!對每一個角色的具體描述和建議見下文。

*並未通過科學證明

角色及其輸出

項目領導者

有一個團隊成員要負責分析工做的實施交付。你可能已經知道，一個高效的項目管理者要：

• 識別項目的利益相關者，並搞清他們須要什麼。這些人會問「咱們要回答的商業問題是什麼?」
• 設定並傳達工做目標、範圍和時間，落實到每一個相關人員。
• 管理項目所依賴的資源，發現交付過程當中的障礙。
• 確保項目如實交付、達成目標(例如，數據確實回答了對業務相當重要的問題)。
• 確保每一個相關人員，從工程師到產品經理，同步工做並理解要交付什麼。這個部分比較重要，由於人們一般低估或高度數據的做用。

對項目領導者的建議：

若是你專一於那些能夠直接爲產品或業務帶來改變的問題，你的分析項目會獲得最及時的反饋。例如：新的宣傳活動帶來的顧客是否轉化爲付費用戶了(是否該繼續在這個宣傳渠道上繼續投資)?或者，咱們準備取消這個功能，你可否查看一下是否有付費用戶在使用這個服務?

保證項目的規模儘量小。一開始，只跟蹤對於業務重要的少數幾個關鍵行爲，這樣就可以快速回答最緊迫的商業問題(如，使用這個此功能的用戶留存度如何?)及時的，有用的分析結果會讓你所在的機構着迷，他們很快會提出更多你在下一輪要回答的問題。換句話說，分析工做應該是敏捷的，隨着每次迭代更加深刻。若是分析項目的規模太大(如，須要花費工程師兩週時間)，那你可能冒着拖延其餘緊急項目的風險。

數據建構者

這個頭銜聽起來很炫，但它只是意味着你的團隊須要有個懂技術的人建立數據模型，並理解查詢語句如何工做。數據模型能夠很簡單，甚至像一封電子郵件，列出你要跟蹤的行爲和優先級。

這個模型有助於肯定和傳達你的項目範圍。數據建構者幫助整個團隊評估哪些業務問題能夠被回答，哪些不能。一般這我的沒必要是數據科學博士，通常由一個app開發人員，或者懂得用電子表格創建模型的人擔任。

對數據分析者的建議：

花點時間讓曾經使用過相同工具的人看看你的數據模型。例如，若是你在使用Keen，就跟使用過Keen的開發者聊聊。也可讓分析服務提供者和你一塊兒審閱你的數據模型。無論你在使用什麼工具，都會有些事情須要取捨，解決方案總有些部分不會按照預期工做。節省些時間，跟有過相同經歷的人談談你的計劃吧。

創建數據模型時，使用客戶和業務領域的習慣用語，而不是應用開發者的習慣用語。例如，不要去追蹤「階段變化」，客戶和你公司裏的其餘人沒法理解它。若是能保證使用的語言是業務導向的，它會幫助你的機構/企業理解如何去查詢和使用數據。

保證讓至少一我的審閱你的數據模型，保證模型可被他人理解。你可能會發現有些對本身來講很直白的標籤，對其餘人來講並不清晰。好比，對於機構裏的不一樣人員，「uuid」意味着不一樣的東西。

不要重複發明輪子(不要作無用功)。

產品開發者

項目一開始，就要有至少一個開發人員承擔埋點的工做。他們在各處加一些代碼，這樣每次登陸、購買、上傳和其餘行爲的數據都能被保存。若是事件的來源有不少，好比移動應用+網頁，這個工做可能由多個開發者完成(如，一個網站開發者和一個移動開發者)。在小一些的機構，埋點的開發者一般也扮演數據建構者。在大一些的團體中，開發者和數據建構者緊密合做，確保模型數據足夠理想，以及事物被跟蹤並以一致的格式標記(如「user.id」 = 「23cv42343jk88」 不是 「user.id」 = 「fran@cooldomain.com」)。埋點是個相對直接的過程，許多分析服務有直接可用的客戶庫使得此過程簡化，不過，你的團隊依然須要決定要跟蹤什麼行爲，如何命名。

對產品開發者的建議：

確保根據對你的機構有意義的數據模型進行埋點。若是你的團隊沒有數據建構者，那麼就扮演這個角色，在開始埋點以前規劃一個模型。這會幫你理清思路，也更利於與他人溝通。

使用分開的repository，帶有各自的key，針對dev, test和prod，這樣就不會讓生成數據和測試數據混淆。

埋點成功後，在正式使用前找我的審閱一下存進來的數據。和產品的其餘功能同樣，分析的實施也須要有個QA過程。埋點過程當中錯誤很常見，如，把數字發送爲字符串、命名不清、不正確地使用JSON的格式，或者標籤裏有錯別字。

分析者

你會收集不少有意思的數據，但若是沒人利用，這些數據就不會有價值。團隊裏須要至少有一我的對數據背後隱藏的東西很是好奇。我把這些人稱爲分析者。分析者一般是個開發者、產品經理或產品團隊/營銷團隊的某我的。這些人不只瘋狂地想了解業務問題的答案，還能時時提出新問題。分析者喜歡鑽研項目第一階段收集的數據，並且有不少點子，引出下一階段應該收集的新東西。換句話說，團隊中須要有我的享受實踐分析的過程。不要着急，這樣的人有不少:)。技術背景對這個角色有很大幫助，這使得他們能快速理解什麼樣的查詢語句能夠獲得想要的答案。
這個角色對於項目成功相當重要，若是沒人從數據中理解、學習，就沒法從中獲得任何價值。

對分析者的建議：

分析的結果可能對你本身而言顯而易見或頗有意義，但別人看來可能不是這樣。這是由於你從一開始就知道要回答什麼問題。你知道數據包含哪些不包含哪些。此外你寫的查詢語句最終生成了可視化結果或報告。要讓他人理解最終獲得的數字都意味者什麼，那麼你要分享不少上下文內容給他們。

分享分析的結果時，須要寫明你從數據中獲得的結論，以及根據分析結果應該採起什麼業務行動(如，上個版本發佈後咱們的轉化率降低了，因此應該改回去)。其餘人可能不只沒有正確解讀數據所需的上下文，他們也極可能不像你那樣感受數據很迷人，且沒時間去試圖理解其意義。

不要用力過猛，不過，對於這個崗位來講溝通技巧很重要。分析者大約半數的時間都用在了溝通上。解釋與總結從數據中得到的結論、結果須要花點時間。若是你的分析結果不能只是靜靜躺在別人的收件箱裏。有些你是機構裏惟一意識到某個機會或問題的人，應該確保機構對機會或問題有所反應。有時你得作那個難搞的人。不要低估本身工做的價值。

若是分析工做是你經常要作又來不及作的，試着把它加入你官方的職位描述中，每週或每個月貢獻固定時間在上面。不要讓它干預你的其餘時間。

報告製做者

這個角色不是必需的，但你可能會想要製做一些報告，便於整個團隊和其餘利益相關者獲取。要想讓數據的實用性會大大提高，數據應該更緊密地與業務流程相連，而不是被遺棄在數據庫裏等着有人翻閱。一個前端開發者要可以把query變成產品經理和其餘業務人員閱讀的報告。下面是一些可能有用的例子：

1. Email寄送週報
2. 內部網站的一個頁面
3. 在面向用戶的app中
4. 用Google表格公開發布
5. 推送到slack頻道
6. 在某個面板上展現
7. 推送到salesforce

對報告製做者的建議：

確保報告的使用者能理解數據才能讓你的工做產生最大價值。一個辦法是，不斷問他們「當你看到轉化率5.2%時，這對你來講意味着什麼?你會認爲它是怎麼計算出來的?」

另外一種提升報告可讀性的方式是寫一份指南(如註釋)，以解釋數據從何而來、如何被計算。例如，數據是否包含從網站和app獲取的用戶，或只是來自其中一種的用戶?它是否包括測試用戶和公司的內部用戶，或者他們已經被過濾掉了?

玩得開心點!整個分析項目中最棒的部分，就是看着有人由於從結果學到了新東西而雙眼放光，而你，一般就是讓這一切發生的人。