多年以來我和數百家企業打過交道，在這個過程中，我領悟了讓資料分析專案成功的一些因素，也親眼看著很多專案失敗。
最常見的失敗原因說出來可能會讓你驚訝。並非是缺乏資料專業知識或者整合失誤，而僅僅是因為企業沒有讓「利用資料」成為任何人員的職責。太多公司花費好幾個月收集有趣的資料，然後讓它們靜靜地躺在角落裡積攢灰塵。這個現象驅使我來撰寫本文，希望它能給你靈感，讓你為下乙個分析專案增加一些結構性。 對分析的應用，本應該成為你不斷汲取的商業泉源。
如果能為下列每個角色，找到至少乙個樂於擔當的人選，我保證你專案成功率會增加一千倍！對每個角色的具體描述和建議見下文。
*並未經過科學證實角色
交付 專案領導者
專案規劃，包含工作範圍與時間
資料建構者
資料模型，查詢語句
產品開發者
實現跟蹤（埋點）
分析者提供新的業務問題
報告製作者
為業務提供報告
專案領導者
有乙個團隊成員要負責分析工作的實施交付。你可能已經知道，乙個高效的專案管理者要：
對專案領導者的建議：
資料建構者
對資料分析者的建議：
產品開發者
專案一開始，就要有至少乙個開發人員承擔埋點的工作。他們在各處加一些**，這樣每次登入、購買、上傳和其他行為的資料都能被儲存。如果事件的**有很多，比如移動應用+網頁，這個工作可能由多個開發者完成（如，乙個**開發者和乙個移動開發者）。在小一些的機構，埋點的開發者通常也扮演資料建構者。在大一些的團體中，開發者和資料建構者緊密合作，確保模型資料足夠理想，以及事物被跟蹤並以一致的格式標記（如「user.id」 = 「23cv42343jk88」 不是 「user.id」 = 「[email protected]」）。埋點是個相對直接的過程，許多分析服務有直接可用的客戶庫使得此過程簡化，不過，你的團隊依然需要決定要跟蹤什麼行為，如何命名。
對產品開發者的建議：
分析者
對分析者的建議：
報告製作者
這個角色不是必需的，但你可能會想要製作一些報告，便於整個團隊和其他利益相關者獲取。要想讓資料的實用性會大大提公升，資料應該更緊密地與業務流程相連，而不是被遺棄在資料庫裡等著有人翻閱。乙個前端開發者要能夠把query變成產品經理和其他業務人員閱讀的報告。下面是一些可能有用的例子：
對報告製作者的建議：
www.eship.com.cn），是一家專業大資料、大資料探勘、資料分析、使用者行為分析等adobe數字營銷的全球解決方案級合作夥伴，具備一流的數字營銷一體化解決方案能力。
乙個成功敏捷團隊的失敗歷程
很多人可能疑惑，很多案例都是從失敗到成功，這個怎麼反了。很多成功背後都有其原因，可能很勵志，但從失敗中我們能夠獲取更多。畢竟我們的知識大多源於失敗而非成功。故事是這樣的 括號中的是筆者的情緒表達 在很久很久以前 某公司成立了乙個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團...
開發，乙個尷尬的角色
最近測試的主管找我們開發的主管，說我們以後所有的需求，開發都要求寫自測報告，不分申請測試還是自測的，在提交測試之前一併提交給測試，讓測試看有什麼問題。從質量保證上來說，我是一百個贊同，我願意對每乙個方法寫單元測試，並對每個用例寫測試報告，我相信沒有哪個開發願意讓別人給自己找出bug，這其實是非常丟臉...
開發，乙個尷尬的角色
最近測試的主管找我們開發的主管，說我們以後所有的需求，開發都要求寫自測報告，不分申請測試還是自測的，在提交測試之前一併提交給測試，讓測試看有什麼問題。從質量保證上來說，我是一百個贊同，我願意對每乙個方法寫單元測試，並對每個用例寫測試報告，我相信沒有哪個開發願意讓別人給自己找出bug，這其實是非常丟臉...