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

0 評論 10957 瀏覽 273 收藏 13 分鐘

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

最常見的失敗原因說出來可能會讓你驚訝。并非是缺乏數據專業知識或者整合失誤,而僅僅是因為企業沒有讓“利用數據”成為任何人員的職責。太多公司花費好幾個月收集有趣的數據,然后讓它們靜靜地躺在角落里積攢灰塵。這個現象驅使我來撰寫本文,希望它能給你靈感,讓你為下一個分析項目增加一些結構性。?對分析的應用,本應該成為你不斷汲取的商業泉源。

如果能為下列每個角色,找到至少一個樂于擔當的人選,我保證你項目成功率會增加一千倍!對每個角色的具體描述和建議見下文。

*并未經過科學證實

角色及其輸出

角色 交付
項目領導者 項目規劃,包含工作范圍與時間
數據建構者 數據模型,查詢語句
產品開發者 實現跟蹤(埋點)
分析者 提供新的業務問題
報告制作者 為業務提供報告

項目領導者

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

  • 識別項目的利益相關者,并搞清他們需要什么。這些人會問“我們要回答的商業問題是什么?”
  • 設定并傳達工作目標、范圍和時間,落實到每個相關人員。
  • 管理項目所依賴的資源,發現交付過程中的障礙。
  • 確保項目如實交付、達成目標(例如,數據確實回答了對業務至關重要的問題)。
  • 確保每個相關人員,從工程師到產品經理,同步工作并理解要交付什么。這個部分比較重要,因為人們通常低估或高度數據的作用。

 

對項目領導者的建議:

  • 如果你專注于那些可以直接為產品或業務帶來改變的問題,你的分析項目會得到最及時的反饋。例如:新的宣傳活動帶來的顧客是否轉化為付費用戶了(是否該繼續在這個宣傳渠道上繼續投資)?或者,我們準備取消這個功能,你能否查看一下是否有付費用戶在使用這個服務?
  • 保證項目的規模盡可能小。一開始,只跟蹤對于業務重要的少數幾個關鍵行為,這樣就能夠快速回答最緊迫的商業問題(如,使用這個此功能的用戶留存度如何?)及時的,有用的分析結果會讓你所在的機構著迷,他們很快會提出更多你在下一輪要回答的問題。換句話說,分析工作應該是敏捷的,隨著每次迭代更加深入。如果分析項目的規模太大(如,需要花費工程師兩周時間),那你可能冒著拖延其他緊急項目的風險。

數據建構者

這個頭銜聽起來很炫,但它只是意味著你的團隊需要有個懂技術的人創建數據模型,并理解查詢語句如何工作。數據模型可以很簡單,甚至像一封電子郵件,列出你要跟蹤的行為和優先級。這個模型有助于確定和傳達你的項目范圍。數據建構者幫助整個團隊評估哪些業務問題可以被回答,哪些不能。通常這個人不必是數據科學博士,一般由一個app開發人員,或者懂得用電子表格建立模型的人擔任。

對數據分析者的建議:

  • 花點時間讓曾經使用過相同工具的人看看你的數據模型。例如,如果你在使用Keen,就跟使用過Keen的開發者聊聊。也可以讓分析服務提供者和你一起審閱你的數據模型。不管你在使用什么工具,都會有些事情需要取舍,解決方案總有些部分不會按照預期工作。節省些時間,跟有過相同經歷的人談談你的計劃吧。
  • 建立數據模型時,使用客戶和業務領域的習慣用語,而不是應用開發者的習慣用語。例如,不要去追蹤“階段變化”,客戶和你公司里的其他人無法理解它。如果能保證使用的語言是業務導向的,它會幫助你的機構/企業理解如何去查詢和使用數據。
  • 保證讓至少一個人審閱你的數據模型,保證模型可被他人理解。你可能會發現有些對自己來說很直白的標簽,對其他人來說并不清晰。比如,對于機構里的不同人員,“uuid”意味著不同的東西。
  • 不要重復發明輪子(不要做無用功)。

產品開發者

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

對產品開發者的建議:

  • 確保根據對你的機構有意義的數據模型進行埋點。如果你的團隊沒有數據建構者,那么就扮演這個角色,在開始埋點之前規劃一個模型。這會幫你理清思路,也更利于與他人溝通。
  • 使用分開的repository,帶有各自的key,針對dev, test和prod,這樣就不會讓生成數據和測試數據混淆。
  • 埋點成功后,在正式使用前找個人審閱一下存進來的數據。和產品的其他功能一樣,分析的實施也需要有個QA過程。埋點過程中錯誤很常見,如,把數字發送為字符串、命名不清、不正確地使用JSON的格式,或者標簽里有錯別字。

 

分析者

你會收集很多有意思的數據,但如果沒人利用,這些數據就不會有價值。團隊里需要至少有一個人對數據背后隱藏的東西非常好奇。我把這些人稱為分析者。分析者通常是個開發者、產品經理或產品團隊/營銷團隊的某個人。這些人不僅瘋狂地想了解業務問題的答案,還能時時提出新問題。分析者喜歡鉆研項目第一階段收集的數據,而且有很多點子,引出下一階段應該收集的新東西。換句話說,團隊中需要有個人享受實踐分析的過程。不要著急,這樣的人有很多:)。技術背景對這個角色有很大幫助,這使得他們能快速理解什么樣的查詢語句可以得到想要的答案。這個角色對于項目成功至關重要,如果沒人從數據中理解、學習,就無法從中得到任何價值。

對分析者的建議:

  • 分析的結果可能對你自己而言顯而易見或很有意義,但別人看來可能不是這樣。這是因為03你從一開始就知道要回答什么問題。你知道數據包含哪些不包含哪些。此外你寫的查詢語句最終生成了可視化結果或報告。要讓他人理解最終得到的數字都意味者什么,那么你要分享很多上下文內容給他們。
  • 分享分析的結果時,需要寫明你從數據中得到的結論,以及根據分析結果應該采取什么業務行動(如,上個版本發布后我們的轉化率下降了,所以應該改回去)。其他人可能不僅沒有正確解讀數據所需的上下文,他們也很可能不像你那樣感覺數據很迷人,且沒時間去試圖理解其意義。
  • 不要用力過猛,不過,對于這個崗位來說溝通技巧很重要。分析者大約半數的時間都用在了溝通上。解釋與總結從數據中獲得的結論、結果需要花點時間。如果你的分析結果不能只是靜靜躺在別人的收件箱里。有些你是機構里唯一意識到某個機會或問題的人,應該確保機構對機會或問題有所反應。有時你得做那個難搞的人。不要低估自己工作的價值。
  • 如果分析工作是你常常要做又來不及做的,試著把它加入你官方的職位描述中,每周或每月貢獻固定時間在上面。不要讓它干預你的其他時間。

報告制作者

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

  • Email寄送周報
  • 內部網站的一個頁面
  • 在面向用戶的app中
  • 用Google表格公開發布
  • 推送到slack頻道
  • 在某個面板上展示
  • 推送到salesforce

對報告制作者的建議:

  • 確保報告的使用者能理解數據才能讓你的工作產生最大價值。一個辦法是,不斷問他們“當你看到轉化率5.2%時,這對你來說意味著什么?你會認為它是怎么計算出來的?”
  • 另一種提高報告可讀性的方式是寫一份指南(如注釋),以解釋數據從何而來、如何被計算。例如,數據是否包含從網站和app獲取的用戶,或只是來自其中一種的用戶?它是否包括測試用戶和公司的內部用戶,或者他們已經被過濾掉了?
  • 玩得開心點!整個分析項目中最棒的部分,就是看著有人因為從結果學到了新東西而雙眼放光,而你,通常就是讓這一切發生的人。

來源:數據工匠

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!