面临问题
入职第一天，我被告知整个产品部门只有我一个数据，从一位android开发GG手中交接到hive数据库权限的账号后，我发现自己面对的是一个看不到尽头的坑。
部门面临的问题
- PM获取数据周期非常长，即使是一个join的sql取数都需要一周排期，这对于“项目上线后第二天就要看到数据“领导贯彻的思想严重背驰
- PM拿到数据后不敢用，因为bi获取周期长，PM会利用私人关系从二线运营拿数据临时应急，但发现同样的维度不同部门拿到的结果不一致，大家用的数据表也不完全相同，pm在中间成为夹心饼干，用也不是不用也不是，后来宁愿拍脑袋下决定。
基于上述的问题，当时的七级领导商量着要在前台放一个数据，同时要贴近业务能解决问题的人进来，于是机缘巧合，我在寻找靠谱甲方，觉得平台不错领导挺好，就上了船了。
进来之后领导语重心长对我表示了希望：能不能将数据获取时间缩短，比如说三小时，百度和google的数据时间我记得没那么长(领导之前是从google和百度出身)。虽然我也有自己的想法，但拿个数据都要等一个周，那别的就玩不下去了，于是爽快答应。但之后发现这个远比想象的要难。
自己遇到的问题
- 组织架构问题：我以产品经理的身份进入，带我的mentor也是一位资深的产品GG，交接给我数据库账号的GG是android开发，于是我惊奇地发现，整个部门(包括mentor)都是向我提需求的人!而我和bi部门是跨部门沟通!本来产品部门的需求就很多，他们已经做不过来，现在又来一个啥也不懂的"PM"问东问西，换做是我也不会给出好脸色。
- 数据问题：这里具体解释一下我将当时的处境看作是黑洞的原因。当时二线运营是sqlserver库(可以创建临时表)，bi主要用hive库，而且bi每个人用的hive库也不尽相同，有时候同样一个订单表，不同的人用的表不一样，不同表的字段什么意思，字段的编码维表是什么，怎么使用，这些错综复杂的关系至少是N的平方的复杂度。
- 数据库语言的问题：这是目前为止最容易解决的问题，因为可以自己百度解决。上一家公司主要是sqlserver，在此因为权限的问题最后统一选择hive在作为第一选择(因为可以申请创建临时表的权限)，这里面夹杂着hive/mysql/presto/sqlserver的语言转换。
解决问题
现在来看已经基本解决当时的问题，而且建立了一种动态平衡且多赢的局面。但这并不是在一开始就想好如何去做，而是心中有个信念，在合适的时间做合适的事情。就像夜晚开车从上海到北京的高速路上，车灯只能看到前方50m，但是只要开好这眼前的50m，最后一定能到目的地。而我当时的第一个50m当务之急是我要迅速建立大家对于数据的信任。
建立信任
虽然每个人都急迫想要数据，但内心并没有消除对数据的不信任，这是一种很复杂的感情。以我现在的情况，不可能两者同时满足，而且经得起验证的数据的基础上，快速响应才有意义，所以我稳扎稳打，先求质量。数据流为产品端=>我=>数据，建立PM对于我的信任，然后信任再慢慢转移到数据上。
- 交叉验证：对于所有经过我手的数据，只要是第一次跑数，都会找我熟悉的数据源交叉验证，这样我可以保证经过我手的数据经得起考验，在历次大规模数据核查中，我没有失手过，即使是和友商的数据全盘对比。同时练就出在和其他部门的数据交换中，如果遇到不一致的情况，通过sql就可以看出却别在哪里，谁的筛选条件更贴近真实。
- 量变到质变：内心的信念体现在每天sql的一遍一遍地重复地训练。当时pm采用二线运营的sql，我会把需求拿过来重跑，再换成hive重跑，有语法问题就百度，字段问题和使用哪些表，实在不会的就记下来，(关于公司级元数据字典，机票hive只有一张订单主表是有解释的，其他的都没有注释，只是用来看表结构和查找字段名)，当天下午五点钟统一找bi的pm询问。(必须有具体的字段或者表问题才好提问，而且bi童鞋时间宝贵，磨合很久好容易说每天下午5点开始留个时间来问问题)。
大概一个月的时间对很多字段掌握以后，之后都是靠自己多跑sql来多验证，3个月后差不多对新接的需求问题就比较少，再通过3个月的磨练，按照5个team平均每天2个sql来算，半年的时间 5team*2sql*180*5/7(工作日)>=1200，至少1200个sql的训练，基本上可以出山。
- 8020法则：在训练过程中，我一直相信所有的需求无非是订单和行为，肯定是有几张主表，80%的需求都会跟这几张主表有关，于是前期针对这些表死磕，字段、格式、使用场景、埋点方式等，后来经过实症，确实如预期，对于快速上手和建立自信有很大的帮助。
固化报表
在最初既不懂业务有不明白数据结构的时候，有一次去bi同事请教问题，TA问了一句”你在产品做的是什么?干脆来bi好了。“这个问题其实从我刚开始进入公司就一直问自己，当我越来越擅长理解需求，数据库拉取sql的时候，我愈加清楚，不能活在舒适圈，提醒自己”你不只是来拉sql的“。
但是PM能够及时获取数据的时候，当初对数据的好奇以及使用的方便性(我就坐在产品团队的中间位置，七级总监的旁边，拉个sql喊一声就能听见)，他们对于数据的需求也被集中释放，我被越来越多的需求所堆积，很多人也开始建议我可以招实习生或者正式员工，但是我想到自己还没有把这条路走通前带其他人进来是对别人的不负责任，而且我依然相信可以把事情搞定。
- 固化需求，建立业务报表：在常规报表存在的基础上，众多业务型很强维度很细的需求无法满足，他们的数据散落在各个角落，需要在常规报表的维度上再加一层计算会比较方便易懂，我针对5个team不同的业务属性，向bi申请建报表的权限，自己捣鼓出100多张报表，戏称为”小米+步枪“的游击队，是对正规军的有效补充，更加平易近人。其中一个新team还没有体系的报表，我们一起琢磨构建了一套，帮助他们有效地节约前期获取数据的时间，备受好评。
- 没有条件自己创造，自行搭建mysql中间库：为保证查询效率，公司的报表大多是sqlserver库存储中间表，但我们人微言轻申请不到资源(需要CTO审批购买刀片服务器)，于是自己找一台废旧台式机，在上面搭建mysql服务器(感谢android开发GG)，存放中间表数据，通过zeus平台建立调度任务ETL(在一次资源审核上我惊奇地发现我的调度任务数已经可以在公司排进前十 )，将hive数据聚合后存放到mysql，报表平台再读mysql。经过这样捣鼓，平均每天的工作量可以降低50%以上。
培训PM玩转数据
上半年基本上满足七级领导当初交给我的任务，用了三个月的时间来给出准确的数据，又用了三个月的时间来提升效率。半年多一直都是在被动地接受PM提出的需求，而此时我腾出时间，同时对产品和数据都建立初步的理解，我开始主动观察前台PM对数据的使用情况。
发现对于数据这个激光枪，他们竟然还在当烧火棍在用。通俗点说，从对互联网数据指标的理解、基础报表的正确使用、ABtest的报表的解读、如何用数据实现对产品的迭代等等，都还没有具备一个清晰的认识。虽然我不知道对上述问题的解答有没有达到专业水准，但是应用领域无权威，说上就上。
于是在2016年9月份，正值开学季，在每周二晚上7点-9点，对于内容分为四个主题，分四次讲解，由浅入深，组织《开学啦》系列分享。反响强烈，四份ppt不仅是pm也可以做bi新入职员工的前台数据培训教材。
第一次分享目的是激发PM对于数据的兴趣和基本认识。重点把不同场景下的基础数据指标说清楚，从哪里来->埋点，在哪里用->UIP报表，如何用->case by case。对于基础报表UIP部分，因为项目数据分散、基础数据与我无关等的原因被多数PM所弃用，但其实基础报表最重要的作用是告诉你什么是正常!当你知道主流程的正常数据，才会知道什么样的数据是不正常的。当其他数据于此冲突的时候以基础报表为准，当看自己的项目数据与主流程的数据做交叉验证的时候，看到自己where we are。
第二次分享目的是解决PM如何用好Abtest来迭代产品，重点是把如何利用abtest的报表数据来定位问题、实现产品的快速迭代，因为abtest不是说新项目表现不好而砍掉，而是新项目上线后如何不断改善优于旧版本，以提升kpi，所以大概率情况下会遇到定位问题的场景。其实这个分析主要是一个公式反复在用，用好TA基本上可以帮助解决80%的问题(剩下20%就需要专业的数据人员来介入)。同时对abtest的数据收集流程和常用名词作说明。(比如正交测试、AA验证)
第三次分享的目的是让pm有能力通过sql来验证脑中的idea。本次是对之前的进阶，讲了更多detail的内容，包括页面/点击/trace->行为表，订单/航段->订单表的主要字段说明，行为和订单关联的方法，sql的运行平台hive/presto/sqlserver/mysql，sql基础语法以及最重要的是每篇配上简单可直接运行的sql，pm们可以线下自己来尝试。
经过之后一两个月的边做边学，每个团队平均有两个pm可以实现2个join以内的hive运行，对于简单的订单和行为关联，诸如“起飞前两小时内访问首页的人数是多少?”可以独立完成。
第四次分享的目的是PM可以根据现有sql来制作报表。每个PM关注的项目数据各不相同，这些数据需要汇报给后台及业务部门，有些是每天都需要手工整理，重复劳动而且非常耗时。经过调研发现，这些数据可能也就是2-3个join的sql。经过简单培训，有心的PM自助来做其实也是非常简单。
经过培训及之后的项目历练，大部分pm的类似小需求都可以自助日报。而我会在报表出现问题的时候出现，而BI可以专注于成套体系的复杂报表。PM对自己的项目数据非常急迫，有一种经过简单培训便可以获取数据，不需要排期，他们是非常欢迎的;bi也被释放工作量，可以专注于复杂报表的设计制作和维护。本次讲解内容包括zeus调度hive源数据->mysql中间表->ART报表平台展现。
见证产品迭代
一年已过，真正看懂我的四张PPT的PM童鞋在产品端的数据分析可以非常有自信地拿出手来证明自己的kpi，可以和bi侃侃而谈sql取数逻辑是否符合需求，同时对于后台的业务部门的报表每天默默有序地自动发送，提升了效率，自信了人生。
那对于我来说，我当初加入的初衷，数据到底能对产品迭代产生多大作用?前台产品中数据人存在的意义在哪里?深夜回顾如下。
我司前台产品讲求快速迭代，即快速上线快速试错快速优化，如此往复以至于最终的kpi目的。这里面数据就像一个润滑油，保证飞速的车轮在飞速驰骋，在换轨道的时候保持方向清晰。这就要求数据首先要准、及时以及能用数据定位问题。而这三方面往往需要一个资深的数据人来把关。下面的说明可能与上面重叠，但为了证明价值进行复用，也说明思维的一致性。
数据准确性
尽信不如不信，对数据的信心是建立在充分怀疑的基础上的，而且非常清楚其使用场景。一个优秀的数据人不仅是自己而且可以让PM能够通过基础报表建立基本sense，同时了解sql辅助交叉验证。最后造成的转变是，从原来怀疑数据不敢用，到相信数据，再到带着怀疑的态度验证数据再用，产生质的转变。
数据及时性
在快速迭代中，今天上午觉得在某个新上的项目中某个指标维度可用，下午用sql验证一下，然后马上上报表，第二天作为新项目指标监测的一部分来辅助决策。这样的效率，如果数据人和产品分属两个不同部门，因为kpi的原因很难产生这样的协同效果。
大部分情况下，bi部门提供报表但是不提供分析，个人很难有成就感，而且很难激发主观能动性;而分析需要结合业务场景，有心的bi人员会多了解一些业务场景对报表和之后的分析提出建议，但更多的是在做一份工作，报表就变成一堆枯燥的数据。
一种方案是，简单的报表通过前台数据人提供一段sql交给PM自助建立报表，临时性复杂(语法在3个join以上或使用非常用表)的报表由前台数据人员建立报表支持，长期的复杂性的报表由bi部门建立报表并维护。前台数据是及时性支持，重时效轻维护，当数据稳定后，相关数据可下线或并入bi的基础报表中;bi部门是，常规系统的报表由bi设计并维护。
定位问题
定位问题也是不断试错的过程，需要在了解业务场景的情况下，不断提出假设、用数据验证、再提出假设的过程，直至整个项目符合预期目标。
提出假设是最考验数据人功力的一环，结合业务场景去思考问题点，然后挑出最有可能的几种来分别验证。对业务最能直接产生价值的是定位问题，数据有效和及时都只能说是基本功，而快速精准定位问题，并能用数据说服其他人这就是问题所在并能提出方案，这是综合能力的直接体现。因为这包含对数据的理解，对业务场景的理解，对人心的把握，当然如果对初级人员每次都是穷举法所有的可能性的点，勤能补拙，不断总结，会找到自己的分析style。
比如之前的婴童流程改造项目，首页点击婴童的icon之后，进入婴童的新流程。新流程上线后，整体婴童订单量占比上升同时新流程的转化率低于旧版转化率，但在整体婴童订单中从新流程下单的比例较低，于是决定把首页婴童icon的大小和颜色更加醒目，让目标人群注意到新流程，上线后婴童订单量进一步上升。在持续改进的过程中发现用于在填写页之后的转化率明显较低，经过定位发现用户在填写页回退上操作异常，单页面上所有点击数据波动不明显。这时候我们面对的问题是用户在填写页这附近遇到困惑，但现有数据无法定位出用户的困惑，于是申请资源请用户研究部门进行电话回访，发现很多有价值的信息，比如价格问题排序问题等，针对性改进后转化率有明显提升。
结尾
将这些经验分享出来有两个目的，一个是2016年事儿上练心的记录，一个是给大家展示可以达到的效果及方法，如果你觉得有效，可以自己尝试，自助者天助。
如果有觉得频率相同的人，可以一起加微信，倒不是找同聊，而是建立朋友圈(和而不同)。
【本文为51CTO专栏作者“李宁”的原创稿件，转载请通过51CTO联系作者获取授权】
