大家好，我是一哥，有些读者做了几年数仓，感觉自己就是在做平台、写SQL，提数，对数……。看着身边的产品经理走向了领导岗位，数据分析师走向了领导岗位，而自己还是在“苦逼”的开发、提数……

今天就给大家分享一下，数据人的出路究竟在哪里？

本文主要从以下几个部分讲述：

1. 初级工程师的困惑
   

2. 技术 or 业务

3. 破局之路

01

初级工程师的困惑

曾经有读者后台联系我，咨询一些问题。有一个读者问过这样一个问题：

我一看头像是个认真学习的读者（妹子），立马就精神了，赶紧组织语言，打个草稿，准备一些怎么教教她。

其实收到收到这条消息，我真的很喜欢。首先，作为一个刚毕业的同学，能有这种居安思危的想法，已经超越了很大一部分职场人。其次，我其实和这位同学有着相似的经历，很愿意去分享一些自己的想法。

02技术 or 业务

首先，其实除了很少岗位不需要懂业务外，大部分公司的技术岗位都需要懂业务的，随着大数据平台的逐步成熟，有了平台开发这样一个岗位，他们主需要关注平台的功能，不需要关注具体的业务逻辑，所以大数据平台开发人员存在着和业务脱节的问题。另一部分数据工程师也在崛起，他们在平台上没日没夜的和数据打交道，对接需求，提数，对数，发邮件……

作为开发人员我们经常嘲笑产品经理只懂业务，不懂技术。

to young to simple

现在我可以明确的告诉你，只懂技术，不懂业务，在绝大数公司中是很难成为核心骨干的。要知道，技术永远都是服务于业务的，特别是在商业公司中（好像都是商业公司，哪有纯技术公司）。这也是刚毕业学生和资深工程师的区别，工作5年后，绝大多数工程师都会成为某一领域的业务专家，能够把业务和技术灵活的结合起来，解决企业实际的问题，以及在看到一些技术问题时候，会通过业务的变通来解决问题。

那么在实际工作中，我们如何平衡技术和业务的关系呢？

记住一句话：撸代码的时候别忘了思考！

我曾经有一个同事，开发了一个XX分析应用系统，但是当业务人员问他这个数据怎么来的时候，他完全搞不明白，只是一句话，这个需要问产品经理。问产品经理固然没错，但作为系统核心开发人员，也要清楚的知道自己每个接口开发的逻辑以及服务的业务。我们总是嘲笑产品经理不懂技术，那么产品是不是也会把开发当做撸代码的机器呢？

即使是作为平台底层的开发工程师，大部分时间都是对读写进行优化，但是读写的场景你都不了解，怎么去优化呢？只是苦苦的升级技术？增加内存？上固态硬盘？你需要去了解访问高峰时在什么时候，哪些场景下读高并发？哪些场景写高并发？那个复杂的查询SQL是在什么业务场景下触发的？这些都是作为开发工程师需要了解的，也许你花了很多时间和资源去解决的一个慢查询，只需要通过业务角度的一个转换就可以去解决掉了。

记得一哥之前做数据开发的时候，某天领导给我们布置了一个跟数据“完全不相干”的任务，让我去看业务系统的设计文档。现在想起来，真是感谢领导给自己指了一条明路啊。后来团队来了一位高级工程师，进公司的一个月内，把公司的各个业务系统都熟悉了一遍，收集的一些资料都是我们干了两年都没有接触到。通过领导安排的这件事，我后来也养成了一个习惯，进入一家新公司后，首先是通过各种资源，获取公司目前开发的业务系统知识文档，熟悉公司在干什么，公司的重点业务是什么。

当然，这样说着很轻松，其实要在干好自己本职工作之外，再思考学习，你也许就需要加班。提到加班，很多人已经反感至极，but me too！但是初期都会有这样一个阶段，每个办公室都会有那么一两个人走的比较晚，后来你发现慢慢的这几个人要么走了，要不成为了你的领导。

03

破局之路

所以，如果你做数据工作，现在就赶紧去了解业务吧，也许还不晚~。其实作为懂技术的我们是很有优势的，特别是现在有一个岗位—数据产品经理。我一直认为传统的产品经理是很难成为数据产品经理的，为什么？这个就要从数据产品本身的特性来决定了。

数据产品一般分为三种类型：数据平台、策略产品、数据可视化产品。

从上图可以看出除了普通的产品设计能力外，数据产品还需要有报表设计能力，甚至要有数据服务API设计能力或者算法分析能力，这些都是我们做数据的技术人员所擅长的。那么也许我们再稍微熟悉一下公司的业务、产品，研发人员也可以很快成长为数据产品经理。

所以，现在我想给开头的那位读者说：趁现在，了解一下公司的业务吧，多去和业务聊聊，和数据分析的同事聊聊，和产品聊聊，不要迷茫，据不完全统计，数据产品经理这个岗位现在需求量很大！

end

历史好文推荐

1. 数据人如何提高核心竞争力

2. 数据人上班划水都聊什么？

3. 数据分析新人如何面对繁杂且突然的数据需求

4. 数仓治理：数据地图长什么样？