一个成功的数据分析团队：角色和职责.pdfVIP

一个成功的数据分析团队 ：角色与职责 多年以来我和数百家企业打过交道 在这个过程中 我领悟了让数据分析项目成功的一些因素 也 亲眼看着很多项目失败。 最常见的失败原因说出来可能会让你惊讶。并非是缺乏数据专业知识或者整合失误 而仅仅是因为 企业没有让“利用数据”成为任何人员的职责。太多公司花费好几个月收集有趣的数据 然后让它们静 静地躺在角落里积攒灰尘。这个现象驱使我来撰写本文 希望它能给你灵感 让你为下一个分析项 目增加一些结构性。 对分析的应用 本应该成为你不断汲取的商业泉源。 如果能为下列每个角色 找到至少一个乐于担当的人选 我保证你项目成功率会增加一千倍 ！对每 个角色的具体描述和建议见下文。 *并未经过科学证实 角色及其输出 角色 交付 项目领导者 项目规划 包含工作范围与时间 数据建构者 数据模型 查询语句 产品开发者 实现跟踪 （埋点 ） 分析者 提供新的业务问题 报告制作者 为业务提供报告 项目领导者 有一个团队成员要负责分析工作的实施交付。你可能已经知道 一个高效的项目管理者要 ： 识别项目的利益相关者 并搞清他们需要什么。这些人会问“我们要回答的商业问题是什么 ？” 设定并传达工作目标、范围和时间 落实到每个相关人员。 管理项目所依赖的资源 发现交付过程中的障碍。 确保项目如实交付、达成目标 （例如 数据确实回答了对业务至关重要的问题 ）。 确保每个相关人员 从工程师到产品经理 同步工作并理解要交付什么。这个部分比较重要 因 为人们通常低估或高度数据的作用。 对项目领导者的建议 ： 如果你专注于那些可以直接为产品或业务带来改变的问题 你的分析项目会得到最及时的反馈。 例如 ：新的宣传活动带来的顾客是否转化为付费用户了 （是否该继续在这个宣传渠道上继续投资 ） ？或者 我们准备取消这个功能 你能否查看一下是否有付费用户在使用这个服务 ？ 保证项目的规模尽可能小。一开始 只跟踪对于业务重要的少数几个关键行为 这样就能够快速 回答最紧迫的商业问题 （如 使用这个此功能的用户留存度如何 ？）及时的 有用的分析结果会让 你所在的机构着迷 他们很快会提出更多你在下一轮要回答的问题。换句话说 分析工作应该是敏 捷的 随着每次迭代更加深入。如果分析项目的规模太大 （如 需要花费工程师两周时间 ） 那你 可能冒着拖延其他紧急项目的风险。 数据建构者 这个头衔听起来很炫 但它只是意味着你的团队需要有个懂技术的人创建数据模型 并理解查询语 句如何工作。数据模型可以很简单 甚至像一封电子邮件 列出你要跟踪的行为和优先级。这个模 型有助于确定和传达你的项目范围。数据建构者帮助整个团队评估哪些业务问题可以被回答 哪些 不能。通常这个人不必是数据科学博士 一般由一个app开发人员 或者懂得用电子表格建立模型 的人担任。 对数据分析者的建议 ： 花点时间让曾经使用过相同工具的人看看你的数据模型。例如 如果你在使用Keen 就跟使用 过Keen的开发者聊聊。也可以让分析服务提供者和你一起审阅你的数据模型。不管你在使用什么 工具 都会有些事情需要取舍 解决方案总有些部分不会按照预期工作。节省些时间 跟有过相同 经历的人谈谈你的计划吧。 建立数据模型时 使用客户和业务领域的习惯用语 而不是应用开发者的习惯用语。例如 不要 去追踪“阶段变化” 客户和你公司里的其他人无法理解它。如果能保证使用的语言是业务导向的 它会帮助你的机构/企业理解如何去查询和使用数据。 保证让至少一个人审阅你的数据模型 保证模型可被他人理解。你可能会发现有些对自己来说很 直白的标签 对其他人来说并不清晰。比如 对于机构里的不同人员 “uuid”意味着不同的东西。 不要重复发明轮子 （不要做无用功 ）。 产品开发者 项目一开始 就要有至少一个开发人员承担埋点的工作。他们在各处加一些代码 这样每次登录、 购买、上传和其他行为的数据都能被保存。如果事件的来源有很多 比如移动应用+网页 这个工 作可能由多个开发者完成 （如 一个网站开发者和一个移动开发者 ）。在小一些的机构 埋点的开 发者通常也扮演数据建构者。在大一些的团体中 开发者和数据建构者紧密合作 确保模型数据足 够理想 以及事物被跟踪并以一致的格式标记 （如“user.id” = “23cv42