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

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

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

*並未經過科學證實

角色及其輸出

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

• 識別專案的利益相關者，並搞清他們需要什麼。這些人會問“我們要回答的商業問題是什麼？”

• 設定並傳達工作目標、範圍和時間，落實到每個相關人員。

• 管理專案所依賴的資源，發現交付過程中的障礙。

• 確保專案如實交付、達成目標（例如，資料確實回答了對業務至關重要的問題）。

• 確保每個相關人員，從工程師到產品經理，同步工作並理解要交付什麼。這個部分比較重要，因為人們通常低估或高度資料的作用。

對專案領導者的建議：

• 如果你專注於那些可以直接為產品或業務帶來改變的問題，你的分析專案會得到最及時的反饋。例如：新的宣傳活動帶來的顧客是否轉化為付費使用者了（是否該繼續在這個宣傳渠道上繼續投資）？或者，我們準備取消這個功能，你能否檢視一下是否有付費使用者在使用這個服務？

• 保證專案的規模儘可能小。一開始，只跟蹤對於業務重要的少數幾個關鍵行為，這樣就能夠快速回答最緊迫的商業問題（如，使用這個此功能的使用者留存度如何？）及時的，有用的分析結果會讓你所在的機構著迷，他們很快會提出更多你在下一輪要回答的問題。換句話說，分析工作應該是敏捷的，隨著每次迭代更加深入。如果分析專案的規模太大（如，需要花費工程師兩週時間），那你可能冒著拖延其他緊急專案的風險。

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

對資料分析者的建議：

• 花點時間讓曾經使用過相同工具的人看看你的資料模型。例如，如果你在使用Keen，就跟使用過Keen的開發者聊聊。也可以讓分析服務提供者和你一起審閱你的資料模型。不管你在使用什麼工具，都會有些事情需要取捨，解決方案總有些部分不會按照預期工作。節省些時間，跟有過相同經歷的人談談你的計劃吧。

• 建立資料模型時，使用客戶和業務領域的習慣用語，而不是應用開發者的習慣用語。例如，不要去追蹤“階段變化”，客戶和你公司裡的其他人無法理解它。如果能保證使用的語言是業務導向的，它會幫助你的機構/企業理解如何去查詢和使用資料。

• 保證讓至少一個人審閱你的資料模型，保證模型可被他人理解。你可能會發現有些對自己來說很直白的標籤，對其他人來說並不清晰。比如，對於機構裡的不同人員，“uuid”意味著不同的東西。

• 不要重複發明輪子（不要做無用功）。

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

對產品開發者的建議：

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

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

• 埋點成功後，在正式使用前找個人審閱一下存進來的資料。和產品的其他功能一樣，分析的實施也需要有個QA過程。埋點過程中錯誤很常見，如，把數字傳送為字串、命名不清、不正確地使用JSON的格式，或者標籤裡有錯別字。

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

對分析者的建議：

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

• 分享分析的結果時，需要寫明你從資料中得到的結論，以及根據分析結果應該採取什麼業務行動（如，上個版本釋出後我們的轉化率下降了，所以應該改回去）。其他人可能不僅沒有正確解讀資料所需的上下文，他們也很可能不像你那樣感覺資料很迷人，且沒時間去試圖理解其意義。

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

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

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

• Email寄送週報

• 內部網站的一個頁面

• 在面向使用者的app中

• 用Google表格公開發布

• 推送到slack頻道

• 在某個面板上展示

• 推送到salesforce

對報告製作者的建議：

• 確保報告的使用者能理解資料才能讓你的工作產生最大價值。一個辦法是，不斷問他們“當你看到轉化率5.2%時，這對你來說意味著什麼？你會認為它是怎麼計算出來的？”

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

• 玩得開心點！整個分析專案中最棒的部分，就是看著有人因為從結果學到了新東西而雙眼放光，而你，通常就是讓這一切發生的人。

原作者：Michelle Wetzler

翻譯： 王鵬宇