如何在创新业务做数据？一些对数据岗的价值思考

腾讯灯塔小明

发布于 2022-09-02 11:05:49

4200

发布于 2022-09-02 11:05:49

文章被收录于专栏：敏捷分析

以下文章来源于腾讯大讲堂，作者xugui

丨导语丨

中大厂围绕数据建设的话题一直层出不穷。随着业务的快速发展，业务同学对数据的需求也越来越多且越来越复杂，但数据的产出却往往不尽人意，这究竟是哪些因素所导致的？而数据同学，在面对海量需求时，又如何能有个人成长？本文中，笔者将结合个人经历及思考进行观点分享，核心基于两方面：价值和主动。

笔者按：

各位好，我是一名从产品，转数据分析师，又转数据产品的产品策划。在过去的工作时间里，也经历过了美妆电商，某漫画APP，还有六脉创造营的各创新业务（水印相机，QQ扩列，QQ自习室，手机QQ相机等）。在这些宝贵的过程中，我不断进行实践—踩坑—学习—解决问题—收获，逐渐从一个数据的消费者，过渡为一个数据整体价值的建设者。

在这些业务中，我承担了从0到1数据体系建设的主要工作。在某漫画APP初期，我独自战斗，后来也伴随着数据岗成员的持续加入以及完整的数据团队建设而一起成长。在后来的腾讯团队里，我还面临着无专业数据岗的问题，所以在对腾讯PCG各大部门的数据现状进行了充分调研后，我制定并实施了一套符合创新业务的数据建设方法。

如何以最小可行来建设创新业务数据体系？

首先，什么是最小可行？

MVP（minimum viable product，最小化可行产品）概念最早由埃里克·莱斯提出，刊载于哈佛商业评论，并有出版物《精益创业》。

具体到数据体系上就是，数据前期能用就可以，不需要一步到位做成一个完整的体系才去用。那数据体系在创新业务中为什么可以是最小可行，而不是大而全？

创新业务在对数据体系建设的影响上有不限于以下几点：

功能迭代频繁

这意味着对数据的需求频率高、改动多、出错率大，数据需求朝令夕改的情况时有发生。

更关注用户行为

在客户端日志与服务端业务表中，日志更为重要，如果是业务表则会相对少一些（这一点还是要看业务类型），所以对于用户行为数据的建设显得尤为重要。

增长策略在创新业务前期尤为重要

增长方法的实施中，需要格外关注用户生命周期以及增长措施，数据的专业性和复杂性也会因此有一定的提升。

综上，以某业务举例，21年为达成xx万的目标，针对不同生命周期的用户划分为新/老/回流/预流失三种类型进行用户运营，那么我在业务的数据仓库建设的思路中，就会是按照实际的用户增长运营步骤来实施：

但是在创新业务初期，想做到最小可行也并不容易。对于初创期的产品以及刚搭建的数据分析团队而言，一方面是爆炸式增长的数据分析需求，一方面是上报和分析流程不规范、数据产品欠缺等问题，矛盾尤其突出。按照“先扛住后优化”的原则，为了快速顶住需求，分析同学需要做大量繁琐、重复的工作。

综上，为什么选择最小可行？还是要认识到数据需要在快速验证产品可行性时能够起到关键的支撑作用，扛住了再优化！

在创新业务中面临的数据问题

我以经历过的某漫画APP以及六脉创造营（水印相机，QQ自习室，QQ相机）来展开。首先在这类新业务的初期，要为了快速验证产品价值及可行性，在数据建设的优先级就会排后，并且初期的数据量累计不足，难以通过数据探索式地分析出价值极强的信息来推进业务。

和成熟期的产品相比，这样的过程往往是产出投入比并不高。这就好比在AB实验中常说的，实验可以让我们在发展阶段，了解到如何准确高效地爬到山顶，而不能让我们的业务爬到更高的一座山。

我们面临的问题具体表现如下：

重视程度不够

以18年底上线的某漫画APP为例。19年初，我以唯一的数据产品岗进入产品部门，入职后接踵而来的是各种数据需求，不乏常规的取数报表以及分析，但是在研究了现有的数据体系后，要能准确快速地给出数据及分析报告并不容易，因为在整个数据链路中，存在着或大或小的问题，可以总结为：

取数难与查数慢
关键事件口径不统一
文档建设薄弱，数据知识获取效率低
埋点上报丢失率较高

而以上问题，我认为是大多数的数据从业者都会面临的，这些问题并不是招1-2个数据岗位就能解决的问题，而是要从上至下认识到数据建设的重要性后，带着与数据平台方共建的思路来开展工作。

无专业数据开发/挖掘hc

数据开发岗位往往会在业务成熟到一定程度后才会有配备，包括数据挖掘、离线or实时工具的这类T族岗位基本要在数据有一定规模后才会有。所以对于创新业务的数据同学来说，懂得数据全链路的知识相当重要，从采集到入库到清洗到最后的展示及分析，每个环节都缺一不可，因此想分工做到效率提升，并不是一件easy的事情。

极度依赖数据平台/中台能力

基于以上两点，也会引发在面对一些复杂需求时，我们只能依赖数据中台/数据平台的能力，没有办法尝试一些具有个性化、适配度更好的工具与能力的问题。因此大部分的工作内容要局限在平台侧，这样会导致数据同学工作开展的效率会受到一定的影响。

当遇到链路问题后，解决速度的时间上限取决于各个中台/平台的反馈速度及解决方法是什么。当整个数据链路涉及到的平台或者工具繁多，没有一个统一的解决方案时，就会导致我们在选择上出现多种方案，在不了解平台的情况下，无法最快做出合理的选择。

这些情况我认为是正常且需要面对的，因为创新业务前期重点还是前文提到的，需快速验证产品可行性及是否真的可以给用户带来价值，所以我也理解在数据上投入不足是存在且合理的。

数据同学在业务团队中怎么发挥自己的价值？

为什么要强调在业务团队中？因为数据岗的分类方法有很多，我的分类简单说就是「平台型」or「业务线」，这两类所面对的问题是不太一样的，而本文则会更关注在业务线数据同学的价值问题。

内在价值

我认为在数据产品岗位上的内在价值体现则是：基于自身对数据全貌的洞察能够推动业务发展

专业的数据化判断（不管是数据挖掘，还是业务分析）
设计可实施的业务策略（AB实验等）
需求背景大方向的思考与深入

外在价值

在数据产品岗位上的外在价值体现是：提升数据的使用价值和效率

取数（仅SQL）
报表（仅制作）
埋点
数据链路

外在价值是他人对我们的普通期待，也是实现内在价值的基础。

而内在价值则是个人成长不可或缺的东西，它一定是核心，我们更应该关注内在价值。

当我们数据同学认识到自己的职业发展存在一定瓶颈时，思考一下，我们在日常工作中，是更关注了内还是外？

瓶颈原因

那为什么大部分数据从业者，会迷失在外在价值中？数据这个岗位既要有基本的技术能力又要有业务思维，这就会导致非常容易陷入取数、报表、无深入的分析这样的循环，而为了业务方能更高效的看到数据，则会投入更多精力在数据层面的一些细枝末节中，包括不限于埋点排查、SQL写法、调度依赖、平台使用、日常波动归因。

这样会导致精力很难深度地投入在业务上，大家对于数据推进业务的这样一个事情可以达成共识，但是实际操作下来，最终自己却还是给别人做了嫁衣。

当然这也有公司 or BG层面在数据建设上投入的便利性的问题，根据和行家沟通，现在已经在做部分的中台收敛数据职责回去，实现统一与效率，能解放业务部门的数据同学的部分劳动力。

数据同学的个人价值如何突破？

我觉得核心还是在于我们对于价值本身的思考，这个价值涉及到项目自身、工作流程、用户感知等诸多价值判断，当我们能够在众多项目中，识别出有极大内在价值的时候，也是我们破局的第一步。

在项目取舍上，我的个人观点是，识别与选择并不冲突，也互不干扰，核心还是在于对事情的内核的判断与深度思考，具体到怎么做，我认为不限于以下几个方面：

合理评估需求优先级

数据从业者接众多的需求是必不可少的，而需求紧急级与重要度的分类方法是一个相对成熟的优先级处理框架了，所以具体在此不做赘述。

但是即使方法论是成熟的，我们在遇到N个需求时，是否真的可以从容排期，而不是根据个人偏好，难易程度来做？

这里要指出的一点是，其实很多数据需求，核心价值并没有业务同学想的那么重要，甚至是这个数据需求本身是在不合理，或者还没想好的前提下提出的，我也经常遇到需求方说这个需求很重要很重要，实际上过了一两个月，这个需求已经被业务方忘记，或者做出来后看一眼就结束的情况。

所以我的处理方法是，作为需求的owner去思考项目本身的价值，而不是作为需求的处理人去思考。

带着思考主动深入业务

其实深入业务这一点，是大家都爱说的一句话，实践起来可难可易，主要还是在于意识问题。在业务团队中，要充分认可自己也是一名在一线的业务组员，自己做的事情就是for业务，而不是for其他组员。当面对一个KPI时，要完成这个数据，自己需要站在一个更高的维度去思考，而不是始终在等待着需求，毕竟数据同学掌握着业务数据的全貌，当我们面对一个问题时，我们是第一个可以知道这个问题背后的数据现状的人。

多为自己考虑，多做属于自己的东西

我的导师在这点上也多次和我沟通，点醒了我让我意识到，多为自己考虑尤为重要。无论是处于大厂还是去中小型公司，数据岗的工作内容不应该只是工具化和基础的呈现结果，否则当想要晋升or跳槽时，拿什么去讲？建了300个表、做了100个报表、取了1000个数、分析了多少个现状？所以在完成一个数据需求的过程中，我们应当在识别出这件事情背后的实质价值时，在行动上主动争取，在思想上持续深入。

避免工具化思维

工具化思维也是我曾犯过的错误之一，也是众多外界对于数据领域认知的误区，比如某知乎问题当中谈到如何快速成为数据分析师时，基本都是在讲excel、sql、python、机器学习、数据挖掘，甚至一些数据分析培训课程也是类似的内容，不过也可以理解，毕竟在这种文章或者培训中很难表达出业务的重要性，对于偏业务的数据同学，无论是用什么工具，excel也好，统计建模也好，都是为了最后的业务增长，只要做出了好的结果，老板真的会care你用了啥么？

避免落入能力陷阱

何为能力陷阱？这是我找一位行家小姐姐聊职业规划时知道的概念，这也是一本书，推荐大家去看看。

我们很乐于去做那些我们擅长的事，于是就会一直去做，最终就使得我们会一直擅长那些事。做得越多，就越擅长，越擅长就越愿意去做。这样的一个循环能让我们在这方面获得更多的经验，但却容易陷入能力陷阱，在其他方面无法突破。

每个人都要特别警惕这种能力陷阱，避免把大量时间花在日常琐事上。如果你想获得更多更好的发展，就要从日常琐事中解脱出来，转变到进行更多策略性思考、在日常工作外建立人际关系网络、提升影响力等能够给你持续带来价值的工作上，这样你才能在各领域获得更好的发展。

这种情况我也发生过，所以我在持续性探索和寻找解决方案，避免让自己一直在做擅长的事情。比如在埋点这件事情上，非常重要且非常基础，但是这样一件重要的工作却没有太多出彩的可能性，做得再好也没人夸你，做得不好数据出错那就得大背锅。

所以针对埋点问题，我的解决方法是形成体系化、常规化的思路去设计埋点，当存在成熟的埋点思路后，可以将每次的埋点需求交给合作伙伴进行设计，在部分重要埋点（比如DAU口径事件）上进行把关即可。

当然可以有更高维度的角度去管理埋点，比如数据上报，你“痛”了么？中提到的，但是这个方法我认为会更适合成熟业务，且不管是开发还是非开发岗希望能从根本上提升效率。

数据分析技能化，而非职能化——可能的未来趋势

最后谈一下，我对于数据岗未来发展趋势的理解，这一点也是目前众多大佬交流/公众号文章谈论的，以往大部分公司会单独设置一个数据分析岗位，来应对日常的分析工作。但是往后可能会有数据分析技能化的趋势，也就是说在数据平台/中台能力到位的情况下，产品/运营可以利用自己基础的数据能力（包括SQL、报表、自助分析）来完成日常的数据分析工作，不再会依赖我们这类SQLBoy，具体到现实就是，我之前所在的增长组，日常工作中每个人都能通过「腾讯灯塔」完整地做出简单的数据分析工作，包括不限于下钻分析，异动归因，漏斗分析，固定化报表。

*部分内容来源于公司内网，仅供参考