面临的问题。入职第一天就被告知整个产品部只有我一个数据，交给了一个android开发者GG的hive数据库权限的账号。最后，我发现自己面临着一个看不到尽头的坑。部门面临的问题是PM的数据采集周期很长。即使是一个joinSQL的数据获取也需要一周的时间安排。后面不敢用数据，因为bi采集周期长，PM会利用个人关系从二线运营中获取数据临时应急，但是发现同维度不同部门获取的结果不一致，而且每个人用的数据表都不完全一样，PM在中间就成了夹心饼干，要不要用，然后宁愿拍脑袋做决定。基于以上问题，当时的七级领导商量，在前台放一个数据，同时，跟业务近的，能解决问题的人进来。所以一个偶然的机会，我想找靠谱的甲方，觉得平台不错，领导也不错，就决定Onboard。进来后，领导语重心长地向我表达了希望：能不能缩短数据获取时间，比如三个小时，我记得百度和谷歌的数据时间没那么长（领导是谷歌和之前百度）。虽然我也有自己的想法，但是要等一个星期才能拿到数据，而且我也玩不了别的，所以就爽快的答应了。但后来发现，这远比想象的要难。我遇到的问题组织结构问题：我是作为产品经理进入的，我的导师也是资深产品GG。给我数据库账号交的GG是android开发，结果我惊奇的发现整个部门（包括mentor）都是问我需求的！而且bi部门和我有跨部门的交流！本来产品部的需求很多，做不下去了。现在又来一个什么都不懂的“PM”来问席东文，换句话说，就是不给好脸色。数据问题：这里具体解释一下为什么我把当时的情况看成是黑洞。当时二线操作的是sqlserver库（可以创建临时表），而bi主要用的是hive库，而且bi每个人用的hive库都不一样。有时候同一张订单表，不同的人使用不同的表，不同的表字段是什么意思，字段的编码维表是什么，怎么用。这些错综复杂的关系至少是N的平方的复杂度。数据库语言的问题：这是目前为止最容易解决的问题，因为百度一下就可以解决。之前的公司主要是sqlserver。因为权限问题，最终选择了hive作为首选（因为可以申请创建临时表的权限），其中混杂了hive/mysql/presto/sqlserver的语言转换。解决问题现在看来，当时的问题已经基本解决，建立了动态??平衡、共赢的局面。但这不是一开始就怎么做，而是心中有一个信念，在正确的时间做正确的事。就像晚上在上海到北京的高速公路上开车，大灯只能看到前方50米，但只要你把前面的50米开过去，最终就能到达目的地。而我当时的第一个50m优先级是快速建立大家对数据的信任。建立信任虽然每个人都非常想要数据，但内心对数据的不信任感并没有消除，这是一种很复杂的感觉。以我目前的情况，不可能同时满足，在可验证的数据基础上，快速反应才有意义，所以我踏踏实实做事，质量第一。数据流向是产品端=>我=>数据，建立PM对我的信任，然后信任慢慢转移到数据上。交叉验证：所有经过我手的数据，只要是第一次运行，我都会找一个我熟悉的数据源进行交叉验证，这样我就可以保证有过的数据经过我的手经得起考验。在以往的大规模数据验证中，我从未遗漏过，即使是与其他公司的数据进行对比。同时，在与其他部门的数据交换中，如果有不一致的地方，可以通过SQL查看哪里错了，谁的过滤条件更接近真实。量变到质变：内心的信念体现在每天反复练习sql。当时pm用的是二线运行的sql。我会接受需求并重新运行它，然后用配置单元替换它并重新运行它。有语法问题就去百度，字段问题，用什么表。数据字典里面机票hive里面只有一张主订单表，里面有解释，其他的没有注释，只是看表结构，查字段名），而五点在当天下午，我向bi的pm询问。（一定要有具体的领域或者表题才能提问，bi童鞋时间宝贵，时间长了好说，每天下午5点可以留出时间提问）。一个月左右掌握了很多领域之后，就靠自己多跑sql多验证了。3个月后，对新连接的需求将会减少。经过3个月的训练，按照5个team平均每天2sql计算，半年5team*2sql*180*5/7（工作日）>=1200，最少1200sql训练，基本可以走出了山。8020法则：在培训过程中，我一直认为，所有的要求无非是命令和行为。肯定有几个主表，80%的需求都会和这些主表相关。现场，埋穴的方式等等，实病过后，确实是预料之中的，对于快速上手，树立自信很有帮助。刚开始固化报表的时候，不懂业务，不懂数据结构，有一次去找bi同事请教。TA问：“你做产品做什么？就来毕吧。这个问题其实从我刚进公司的时候就开始不断地问自己。当我更好地理解需求并从数据库中拉取SQL时，我更加意识到我不能生活在我的舒适区并提醒自己“你不只是在这里拉取SQL”。但是当PM能够及时拿到数据的时候，他们对数据和使用的方便性很好奇（我当时坐在产品组中间，七级总监旁边，听得一清二楚asqlcall），他们对数据的需求我也集中释放了，我被越来越多的需求堆砌起来。很多人也开始建议我可以招实习生或者全职员工，但是我觉得在我没有扫清这条路之前，别人带别人进来是不对的。不负责任，我仍然相信事情可以完成。固化需求，建立业务报表：在定期报表存在的基础上，很多面向业务的、窄维度的需求是无法满足的。他们的数据分散在各个角落，需要在常规报表的维度上加一层计算。比较方便，容易理解。我向BI申请了5个团队不同业务属性的报表制作权限，自己制作了100多份报表。绰号“小米+步枪”的游击队是正规军的有效补充，更加平易近人。.有一个新团队还没有系统的报告，我们一起建了一套，帮助他们有效的节省了前期获取数据的时间，受到了好评。我没有条件自己创建，自己搭建mysql中间库：为保证查询效率，公司大部分报表都存储在sqlserver库中，但是我们不能申请资源（需要CTO同意购买刀片服务器），于是我们自己找了一台用过的台式机，在上面搭建了一个mysql服务器（感谢android开发GG），存储中间表数据，通过zeus平台建立调度任务ETL（惊了发现我的调度任务数在一次资源审核中已经可以排在公司前十），聚合hive数据存入mysql，报表平台再次读取mysql。经过这样的修修补补，平均每天的工作量可以减少50%以上。在培训PM的前半段，我基本完成了七级领导交给我的任务。用了三个月给出准确数据，又用了三个月提高效率。半年多来，我一直被动接受PM的需求。这时候腾出了时间，对产品和数据有了初步的了解。我开始主动观察前台PM对数据的使用情况。结果发现，对于数据激光枪，他们还是当火棍用的。通俗地说，从互联网数据指标的理解、基础报表的正确使用、ABtest报表的解读、如何利用数据实现产品迭代等等，都还没有清晰的认识。虽然不知道以上问题的回答是否达到了专业水平，但是在应用领域没有权威，就随便说说吧。于是在2016年9月开学季，每周二晚上7:00-9:00，内容分为四个主题分四次讲解，由浅入深，组织了一系列的《开学啦》分享。反响强烈，四个ppt不仅是pm，还可以作为bi新员工的前端数据培训教材。第一次分享的目的是激发PM的兴趣和对数据的基本了解。重点理清不同场景下的基础数据指标，从哪里来->埋点，用到哪里->UIP报表，怎么用->casebycase。对于基础报告的UIP部分，被大部分PM弃用，因为项目数据零散，基础数据与我无关。但其实基础报告最重要的作用就是告诉你什么是正常的！当你知道了主进程的正常数据，才知道什么样的数据是异常的。此处其他数据有冲突时，以基本报告为准。当你看你自己的项目数据和交叉验证的主流程的数据时，你可以看到我们在哪里。第二个分享的目的是解决PM们如何用好Abtest来迭代产品。重点是如何利用ABTEST报告数据定位问题，实现产品快速迭代，因为ABTEST并不是说新项目做不好就砍掉，而是新项目上线后如何持续改进比老版本更能提升kpi，所以大概率会遇到定位有问题的场景。其实这个分析主要是一个反复使用的公式。用好TA基本上可以帮助解决80%的问题（剩下的20%需要专业的数据人员介入）。同时对abtest的数据采集过程和常用术语进行了说明。（比如正交测试，AA验证）第三次分享的目的是让PM有能力通过SQL验证自己脑子里的想法。这次是对上次的一个提前，讲了更多的细节，包括page/click/trace->behavior表，order/flightsegment->order表主字段说明，行为与订单关联的方法，sql运行平台hive/presto/sqlserver/mysql，sql的基本语法，最重要的是每篇文章都附有一个简单直接可执行的sql，PM们可以自己离线试试。经过一两个月的边做边学，每个团队平均有两个下午实现2个join以内的hive操作。对于简单的订单和行为联想，比如“出发前两小时内访问首页的人数是多少？”可以独立完成。第四次分享的目的是PM可以根据已有的SQL做报表。每个PM专注于不同的项目数据。这些数据需要上报给后台和业务部门。其中一些需要每天手动整理，重复且耗时。经过排查，发现这些数据可能是2-3个joinSQL。经过简单的培训，一个敬业的PM自己来做其实很简单。经过培训和后续的项目经验，大部分类似pm的小需求都可以做到日常自助。而我会在报表出现问题的时候出现，BI可以专注于完整系统的复杂报表。PM对自己的项目数据很急，如果不需要排期，简单培训就能拿到数据，非常欢迎；BI也解放了工作量，可以专注于复杂报表的设计、制作和维护。本次讲解内容包括zeus调度hive源数据->mysql中间表->ART报表平台展示。见证产品迭代一年过去了，真正理解了我的四个PPTPM童鞋在产品端的数据分析。我可以自信地用手展示我的kpi，我可以和bi讨论sql的抓取逻辑是否一致。同时，后台各业务部门报表每日自动无声有序发送，提高效率，让生活更有信心。对我来说，一开始加入的初衷，数据对产品迭代能起到多大的作用？前端产品中数据人存在的意义是什么？深夜点评如下。我们前端产品强调快速迭代，即快速上线、快速试错、快速优化等等，直到最终的KPI目标。这里的数据就像润滑油一样，保证快轮高速驰骋，变轨时保持方向清晰。这就要求数据首先要准确、及时，并且能够用数据来定位问题。而这三个方面往往需要资深的数据人来把关。下面的说明可能与上面的说明重叠，但被重复用于证明价值并说明思维的一致性。相信数据的准确性，总比不相信要好。对数据的信心建立在充分怀疑的基础上，对其使用场景非常清楚。一个优秀的数据人，不仅仅是他自己，还要让PM通过基础报表建立起基础感，同时理解SQL辅助交叉验证。最后的变化是，从怀疑数据不能用，到相信数据，再到用怀疑的态度验证数据再用，发生了质的变化。数据的时效性在快速迭代。今天早上感觉新项目中某个指标维度可用。下午用SQL验证了一下，然后立马上报。次日，将作为新项目指标监测的一部分，辅助决策。这样的效率，如果数据人和产品属于两个不同的部门，因为KPI的关系，很难产生这样的协同效应。在大多数情况下，商务部提供报告但不提供分析。个人很难有成就感，也很难激发主观能动性；并且分析需要结合业务场景，有兴趣的BI人员可以多了解业务场景。分析提出建议，但更多的是做工作，报告就变成了一堆枯燥的数据。一种方案是，由前端数据人员提供简单的报表，提供一段SQL给PM自己制作报表。临时的、复杂的报表（语法是3个以上join或使用非公用表）支持前端数据人员创建报表。长期复杂的报表由双向部门建立和维护。前端数据是及时支持，重时效，轻维护。数据稳定后，可将相关数据下线或纳入BI基础报表；对于商务部，常规系统的报表由商务部设计和维护。定位问题定位问题也是一个不断试错的过程。需要不断提出假设，用数据验证，了解业务场景后再提出假设，直到整个项目达到预期目标。提出假设是最考验数据从业者能力的部分。结合业务场景考虑问题点，然后挑出最有可能的分别进行验证。对业务最直接的价值是定位问题。有效及时的数据只能说是基本功，但是快速准确定位问题，用数据说服别人这是问题所在并提出解决方案的能力才是综合能力。直接反映出来因为这包括对数据的理解，对业务场景的理解，对人心的把握。当然，对于初级人员，如果每次都面面俱到，就会找到自己的分析风格。比如之前的宝贝进程改造项目，在首页点击宝贝图标后，会进入新建的宝贝进程。新流程上线后，整体婴童订单占比提升，新流程转化率低于旧版转化率。但新流程下的订单占整体母婴订单的比例偏低，所以决定改变首页宝贝图标的大小。并且颜色更加醒目，让目标人群注意到新工艺，推出后婴童订单量进一步增加。在不断改进的过程中，发现填充页面后的转化率明显偏低。定位后发现用户在填写页面返回时操作异常，单个页面所有点击数据波动不明显。这时我们面临的问题是用户在填写页面附近遇到了混淆，但是现有的数据无法定位到用户的混淆，于是我们申请了资源，让用户研究部进行了回访，发现了很多有价值的信息，例如价格问题。排序问题等经过针对性的改进，转化率有了明显的提升。最后，分享这些经验有两个目的。一个是2016年修心记录，一个是给大家展示一下可以达到的效果和方法。如果您认为它有效，您可以自己尝试一下。天助自助者。如果有同频的人，可以一起加微信，不是找老乡聊天，而是建朋友圈（和而不同）。【本文为专栏作家“李宁”原创稿件，转载请联系作者获得授权】点此阅读该作者更多好文
