【转载】如何组建一支优秀的数据分析团队？

http://www.36dsj.com/archives/38744

Q：数据分析人员能作什么？

A：从纷繁的数据里提炼出有价值的信息并给公司提供支持啊。

Q：你怎么提炼啊？

A：写程序采集啊，清洗啊，用必定的算法计算数据内部联系，根据业务作出判断啊……

Q：若是都是用已有的算法，这些事情为何不能用现成的流程来作呢？或者为何不能写成程序，让机器本身实现呢？

A：呃…………

做为一名数据分析师，刚入行的时候跟人聊天聊成这样，很是常见也很是使人不爽。但咱们数据分析师是否是仅能手工操做一些算法，等着机器和算法逐步取代咱们么？并非！

照例观点先行：数据分析不等于数据分析算法/程序，数据分析算法/程序只是分析师手中的工具，数据分析要取得成功必须依赖人的力量，数据分析师的做用在于根据对业务的理解，合理使用分析工具，完成分析目标。

结合业务的数据分析才是科学的，一切只看计算机输出结果不考虑业务实际状况的数据分析都是无（shua）用（liu）功（mang）。计算机能实现的算法也好，程序也好，只是数据分析中的一部分；如何选择分析切入点，如何选择数据来源，如何肯定算法，如何解读结论，这些机器通通作不了，须要咱们数据分析师来解决。

观点在上边两段里已经充分展现了，接下来我要愉快的展（che）开（dan）观点内容了：

数据分析一般包括几个阶段：提出/发现问题——获取并清洗数据——建模——调整优化——输出结论。

这是一个闭环流程，每一步都须要人工参与，程序会参与中间三步，算法在建模中会用到，而数据分析的最重要两步，问题和结论，目前是不可能彻底交给计算机去处理的（其实我我的认为这两步在真正的人工智能出现前，毫不可能由计算机自动处理），所以数据分析人员最大的优点，就是“经验”，也就是业务理解能力和数据分析经验。

详细解释一下数据分析的几个阶段：

提出/发现问题阶段：

大多数时候，数据分析都是为了解决一个问题（锁定某个产品的目标客户，对一样的人群作营销活动用A方案好仍是B方案好，等等），或者验证一个猜测（不让旅游者上班高峰坐地铁是否是会大幅度缓解拥挤现象，啤酒和尿布放一块儿是否是真的会提高啤酒的销售额，等等），总之须要达到一个目标。即便是探索性分析（拿着一大堆数据看看能不能找出点什么结论），那也须要先预设一个或多个目标做为切入点，而后在探索过程当中逐步修正。

提出和发现问题的过程，交给计算机干不太靠谱，首先计算机不会提出问题（由于笨），其次计算机能发现的问题也必定是人已经发现了的问题（仍是由于笨），须要先有人来设定规则，而后计算机才能根据规则发现问题。而数据分析师，就是设定规则的人。

目标和规则的设定，必定要基于业务，这样分析结果才有用，不然会得出正确但无用的结论。举个栗子，订阅报纸的数据扔给计算机去分析关联关系，看有哪些报纸能够进行组合促销，最后得出个光明日报和人民日报关联系数90%多，因此这俩报纸能够组合起来卖，问题是这俩报纸原本就是要求党政机关订阅的党报，组合起来毫无心义，该订的仍是要订，不订的仍是不订，这就是典型的正确但无用的分析结果。懂业务能让分析师少作这种无用功，可是计算机要想懂业务就得由人来教，教还不必定能教会，教完了又不能举一反三（报纸的关联算法拿到电商去彻底不能用啊），这样的计算机永远都不如分析师懂业务。

获取并清洗数据：

这个阶段计算机参与的较多，分析师的工做是指出拿什么数据，拿哪些字段，数据获取到之后用哪些规则进行清洗整理。若是数据源不变，须要重复或按期进行分析时，这个阶段的规则能够固化，由计算机来自动执行，但规则仍然是由分析师来制定的。

建模、调整优化：

这两个阶段中，分析算法出场了，描述分析、关联分析、回归、分类、聚类、时间序列，每一个类别里都有一大堆的固定算法，分析师不能经过手算得出结论，须要借助封装好算法的分析工具（图形化的SPSS，命令行方式的R，等等），看来这一阶段计算机要超越分析师了！

等等，建模哪有这么简单，计算机解决不了的问题一大堆呢：何时用哪一个类别的算法（该作分类仍是聚类），同一类别不一样算法哪一个更适合当前状况（K-means仍是两步聚类，这是个问题），同一个算法怎么调整参数能使效果更好（到底该把用户聚成几类呢），算法输出的结果是否正常（有一部分数据出了问题致使分析结果出现误差）等等。这些问题计算机通通不知道耶，须要分析师来告诉它该作什么事。

打个比方，数据分析就是打仗，算法是机枪、大炮、坦克等等技术兵器，分析师是士兵、炮手、驾驶员（操纵者），不能由于士兵本身不能一分钟吐出几百发子弹或者炮手本身不能一会儿拆掉一个碉堡，就让机枪大炮坦克把操纵者扔下，本身上阵去打仗……就算是无人机，那也得有个拿遥控器的驾驶员蹲在办公室里操做啊……

算法始终只是工具，数据分析效果如何仍是要看用工具的分析师功力如何。一个作过几十个分析项目的分析师，功力一般来讲比刚入行的分析师或者纯开发人员要深厚一些（极少数天赋异禀的不算……），选算法调参数建模型的能力更强一些，分析出来的结果也会相对靠谱一些——没错，经验在这两个阶段就是优点。

输出结论：

这一阶段计算机的工做已经基本完成了，对模型输出的数据进行解读，那彻底是分析师的天下——同一份数据给不一样的分析师，可能会得出不一样的结论，不少时候分析师并不仅仅根据数据自己得出结论，还要结合不少外界因素来修正结论。分析师的经验越丰富，拥有的有效信息量越多，得出的结论就越接近事实（之因此用接近，是由于对数据解读的准确度永远达不到100%，影响结果的因素太多了，好比一个企业销售额连续增加10年，分析师根据公司数据和市场状况判断下一年还会继续增加，结果老板出事跑路了，企业直接倒闭），而这个过程是计算机目前没办法自主进行的，商业智能系统作的再好，也须要由分析师来设定规则，告诉计算机在什么时间须要作什么。

也许随着大数据和人工智能的发展，有一天计算机能够彻底不依赖人工设定的规则（不须要肯定数据来源，不须要选择算法和模型，不须要人工干预来修正模型，等等），本身对数据进行全方位的分析，加入全部因素的影响，并输出准确度很是高的报告，只有到那时候，分析师才会失业啊。

不过，真到了那一天，恐怕不光是分析师失业的问题吧……

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

多年以来我和数百家企业打过交道，在这个过程当中，我领悟了让数据分析项目成功的一些因素，也亲眼看着不少项目失败。

最多见的失败缘由说出来可能会让你惊讶。并不是是缺少数据专业知识或者整合失误，而仅仅是由于企业没有让“利用数据”成为任何人员的职责。太多公司花费好几个月收集有趣的数据，而后让它们静静地躺在角落里积攒灰尘。这个现象驱使我来撰写本文，但愿它能给你灵感，让你为下一个分析项目增长一些结构性。 对分析的应用，本应该成为你不断汲取的商业泉源。

若是能为下列每一个角色，找到至少一个乐于担当的人选，我保证你项目成功率会增长一千倍!对每一个角色的具体描述和建议见下文。

*并未通过科学证明

角色及其输出

项目领导者

有一个团队成员要负责分析工做的实施交付。你可能已经知道，一个高效的项目管理者要：

• 识别项目的利益相关者，并搞清他们须要什么。这些人会问“咱们要回答的商业问题是什么?”
• 设定并传达工做目标、范围和时间，落实到每一个相关人员。
• 管理项目所依赖的资源，发现交付过程当中的障碍。
• 确保项目如实交付、达成目标(例如，数据确实回答了对业务相当重要的问题)。
• 确保每一个相关人员，从工程师到产品经理，同步工做并理解要交付什么。这个部分比较重要，由于人们一般低估或高度数据的做用。

对项目领导者的建议：

若是你专一于那些能够直接为产品或业务带来改变的问题，你的分析项目会获得最及时的反馈。例如：新的宣传活动带来的顾客是否转化为付费用户了(是否该继续在这个宣传渠道上继续投资)?或者，咱们准备取消这个功能，你可否查看一下是否有付费用户在使用这个服务?

保证项目的规模尽量小。一开始，只跟踪对于业务重要的少数几个关键行为，这样就可以快速回答最紧迫的商业问题(如，使用这个此功能的用户留存度如何?)及时的，有用的分析结果会让你所在的机构着迷，他们很快会提出更多你在下一轮要回答的问题。换句话说，分析工做应该是敏捷的，随着每次迭代更加深刻。若是分析项目的规模太大(如，须要花费工程师两周时间)，那你可能冒着拖延其余紧急项目的风险。

数据建构者

这个头衔听起来很炫，但它只是意味着你的团队须要有个懂技术的人建立数据模型，并理解查询语句如何工做。数据模型能够很简单，甚至像一封电子邮件，列出你要跟踪的行为和优先级。

这个模型有助于肯定和传达你的项目范围。数据建构者帮助整个团队评估哪些业务问题能够被回答，哪些不能。一般这我的没必要是数据科学博士，通常由一个app开发人员，或者懂得用电子表格创建模型的人担任。

对数据分析者的建议：

花点时间让曾经使用过相同工具的人看看你的数据模型。例如，若是你在使用Keen，就跟使用过Keen的开发者聊聊。也可让分析服务提供者和你一块儿审阅你的数据模型。无论你在使用什么工具，都会有些事情须要取舍，解决方案总有些部分不会按照预期工做。节省些时间，跟有过相同经历的人谈谈你的计划吧。

创建数据模型时，使用客户和业务领域的习惯用语，而不是应用开发者的习惯用语。例如，不要去追踪“阶段变化”，客户和你公司里的其余人没法理解它。若是能保证使用的语言是业务导向的，它会帮助你的机构/企业理解如何去查询和使用数据。

保证让至少一我的审阅你的数据模型，保证模型可被他人理解。你可能会发现有些对本身来讲很直白的标签，对其余人来讲并不清晰。好比，对于机构里的不一样人员，“uuid”意味着不一样的东西。

不要重复发明轮子(不要作无用功)。

产品开发者

项目一开始，就要有至少一个开发人员承担埋点的工做。他们在各处加一些代码，这样每次登陆、购买、上传和其余行为的数据都能被保存。若是事件的来源有不少，好比移动应用+网页，这个工做可能由多个开发者完成(如，一个网站开发者和一个移动开发者)。在小一些的机构，埋点的开发者一般也扮演数据建构者。在大一些的团体中，开发者和数据建构者紧密合做，确保模型数据足够理想，以及事物被跟踪并以一致的格式标记(如“user.id” = “23cv42343jk88” 不是 “user.id” = “fran@cooldomain.com”)。埋点是个相对直接的过程，许多分析服务有直接可用的客户库使得此过程简化，不过，你的团队依然须要决定要跟踪什么行为，如何命名。

对产品开发者的建议：

确保根据对你的机构有意义的数据模型进行埋点。若是你的团队没有数据建构者，那么就扮演这个角色，在开始埋点以前规划一个模型。这会帮你理清思路，也更利于与他人沟通。

使用分开的repository，带有各自的key，针对dev, test和prod，这样就不会让生成数据和测试数据混淆。

埋点成功后，在正式使用前找我的审阅一下存进来的数据。和产品的其余功能同样，分析的实施也须要有个QA过程。埋点过程当中错误很常见，如，把数字发送为字符串、命名不清、不正确地使用JSON的格式，或者标签里有错别字。

分析者

你会收集不少有意思的数据，但若是没人利用，这些数据就不会有价值。团队里须要至少有一我的对数据背后隐藏的东西很是好奇。我把这些人称为分析者。分析者一般是个开发者、产品经理或产品团队/营销团队的某我的。这些人不只疯狂地想了解业务问题的答案，还能时时提出新问题。分析者喜欢钻研项目第一阶段收集的数据，并且有不少点子，引出下一阶段应该收集的新东西。换句话说，团队中须要有我的享受实践分析的过程。不要着急，这样的人有不少:)。技术背景对这个角色有很大帮助，这使得他们能快速理解什么样的查询语句能够获得想要的答案。
这个角色对于项目成功相当重要，若是没人从数据中理解、学习，就没法从中获得任何价值。

对分析者的建议：

分析的结果可能对你本身而言显而易见或颇有意义，但别人看来可能不是这样。这是由于你从一开始就知道要回答什么问题。你知道数据包含哪些不包含哪些。此外你写的查询语句最终生成了可视化结果或报告。要让他人理解最终获得的数字都意味者什么，那么你要分享不少上下文内容给他们。

分享分析的结果时，须要写明你从数据中获得的结论，以及根据分析结果应该采起什么业务行动(如，上个版本发布后咱们的转化率降低了，因此应该改回去)。其余人可能不只没有正确解读数据所需的上下文，他们也极可能不像你那样感受数据很迷人，且没时间去试图理解其意义。

不要用力过猛，不过，对于这个岗位来讲沟通技巧很重要。分析者大约半数的时间都用在了沟通上。解释与总结从数据中得到的结论、结果须要花点时间。若是你的分析结果不能只是静静躺在别人的收件箱里。有些你是机构里惟一意识到某个机会或问题的人，应该确保机构对机会或问题有所反应。有时你得作那个难搞的人。不要低估本身工做的价值。

若是分析工做是你经常要作又来不及作的，试着把它加入你官方的职位描述中，每周或每个月贡献固定时间在上面。不要让它干预你的其余时间。

报告制做者

这个角色不是必需的，但你可能会想要制做一些报告，便于整个团队和其余利益相关者获取。要想让数据的实用性会大大提高，数据应该更紧密地与业务流程相连，而不是被遗弃在数据库里等着有人翻阅。一个前端开发者要可以把query变成产品经理和其余业务人员阅读的报告。下面是一些可能有用的例子：

1. Email寄送周报
2. 内部网站的一个页面
3. 在面向用户的app中
4. 用Google表格公开发布
5. 推送到slack频道
6. 在某个面板上展现
7. 推送到salesforce

对报告制做者的建议：

确保报告的使用者能理解数据才能让你的工做产生最大价值。一个办法是，不断问他们“当你看到转化率5.2%时，这对你来讲意味着什么?你会认为它是怎么计算出来的?”

另外一种提升报告可读性的方式是写一份指南(如注释)，以解释数据从何而来、如何被计算。例如，数据是否包含从网站和app获取的用户，或只是来自其中一种的用户?它是否包括测试用户和公司的内部用户，或者他们已经被过滤掉了?

玩得开心点!整个分析项目中最棒的部分，就是看着有人由于从结果学到了新东西而双眼放光，而你，一般就是让这一切发生的人。