在工作中把时间留给长期的重要问题

没有经验的数据分析工作者很容易成为数字的奴隶。

目前，大部分的互联网公司都会设置数据分析岗位，因为互联网公司的产品天然地有信息化和数据化的特征。

这又会带来另一个问题。

传统行业的产品出了问题，可以通过抽检产品样品直观地看到。互联网公司的产品出了问题，只能通过计算数据去推断。

这就导致了数据岗位自身也要承担数据的出口角色，业务方依赖你去计算数据体现产品现状，业务方又依赖你去分析异常发现产品问题，业务方还希望你能未雨绸缪指导产品改进。

我们从招聘上总结一些业界比较标准的数据分析师工作内容：

1. 数据埋点：有新产品或者产品有新功能上线，需要看一下产品prd，与PM和RD沟通埋点需求，因为没有埋点就无法计算。发布前后测试检查各埋点是否正确。

2. 数据仓库：根据不同的业务规划数据仓库的各个层级，设计表和字段，是日常报表的主要数据来源。数据开发后还需要检查一下逻辑是否正确。

3. 日常监控：计算口径或其他数据问题答疑，数据有问题的时候找问题修复。

4. 常规报告：日报、周报、月报。

5. 临时需求：什么都有，难度不一，如果是长期需求还需要想办法做数据产品。

6. 数据产品：利用公共工具做的数据产品，将某种常规取数或数据逻辑固定下来。

7. 专题分析报告：针对某一个专题进行全面分析，出具报告。

8. 模型研究：有空的时候会研究一下模型，研究好了就需要在数仓中准备好数据，根据算法出结果，最终产品化。

对于公司和数据工作者本人来说，都能认同6、7、8是比较有价值的工作，他们也会认为这才是数据工作者的核心产出。但一般而言数据工作者会困于1~5不能自拔。

写SQL，取数据，做报告，这就是数据分析师的日常。

一个原因是一个公司里面，分析师的配置其实是偏少的。这是为什么数据分析师往往在需求中疲于奔命。

每个业务方对业务有各种疑惑，会有从各种角度看数据的需求出来。负责接需求的分析师通常会比较被动，数量多起来就疲于奔命。

「一直在算数，什么时候才能做真正的分析呢？」

在这个状况持续一段时间后，新入门的数据分析工作者就会开始想这个问题。一个常见的提案是，采用新的工具/建设新的数仓/加一下班把数据需求都完成了，把现有的数算完，就能腾出时间来做深入的分析了。

这个想法最天真的地方就在于工作永远做不完。

就算这批数算完了，公司还没有上市呢，业务上总有需要你算数的地方。就算公司上市了，人类还没有踏出地球，哪里没有数要算呢？

遗憾的地方也就在这里，业务方也想得到真正的分析（以及升职加薪），所以他们会不断地问问题，争取更多的资源。而你作为被争取/榨取的其中一个资源，也确实没时间去给他深入地分析。

想要有价值地成长，就得把时间留给一个长期的重要问题。

大部分情况下，数据分析工作者面对的问题都是短期的。短期内的问题永远解决不完：「我有一个新的想法需要支持」，「这两天转化率下降是不是有问题」，「之前答应给我算的数算好了吗」……

长期来看，产品的活跃用户在增长吗？用户的留存率如何？产品对用户的核心价值在长期来看有没有得到增进？

每个人都知道这很重要，但不是每个人都能解决它。拥有数据、懂得使用计算工具、掌握一般人没有的模型知识的你最有可能看到解决的路。

对这些问题的钻研，会影响到你的整个职业生涯，无论你在哪家公司工作，都仍然面对着一样的商业现实。

利用短期的需求积攒业务理解，在一个长期的时间内专注一个问题。真正的成果都是无数改进的累积与坚持。

可以做的事情很多，有价值的是选择应该做的事情。

没有经验的数据分析工作者一开始最愁的问题，是能否解决接到的需求。

当你有一定的成长后，就会发现可以做的事情其实是很多的。大部分的日常需求都是可以做的事情，这时候如果习惯于以前的工作方法，没有找到一个长期的问题专注，就跳不出来了。

想一下，如果没有这个数，业务方的工作能做吗？能做就表示这个问题并不重要。

如果没有这个数，业务方的工作就做不下去了，这就得反问一句，如果一个业务会陷入这种困境，还要你来给他擦屁股，炒了这个负责人得了。

数据很重要，也没有这么重要。大部分情况下，没有数据，工作也是可以进行的。如果工作进行不下去，那是最基本的商业逻辑出了问题。逻辑出了问题，有数据也没用。

很多问题并非非你不可，效率最大化的方法是各司其职。