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

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