御豪同学 《数据产品经理宝典》作者
京东数字科技集团高级数据产品经理
周五,晚,22点52分49秒,刚进家门。旁边是便利蜂的鸡蛋炒饼,水滴沿着盖子内侧滚落,醋包还在一边。吃吗?不!此时有更重要的事情要做。
回家路上有个陌生妹子的电话,声音甜美:“你们的系统好像挂了,找人看下吧,谢谢!”
所以“22点52分49秒”是要卖惨还是晒加班?都不!做数据系统的同学懂的,如果1个小时左右问题还没修复,系统里可能产生大量的脏数据。
所以,还挺急的。
上边的小故事,相信不只是做数据产品的同学会遇到。只要是做产品、要迭代上线,可能都遇到这种线上问题处理的情况。但是其中又有一些不一样,比如时间点,对于没有自动批量处理的系统,可能就不用特别的关注跨天的问题。
可能有不少同学会觉得“数据产品”这个职位既熟悉又陌生。我们可以就从转行开始。
01 认知的准备
不管是准备内部转行做数据产品,还是准备直接跳槽转数据产品,为了获得这样的机会,首先要表现出自己具备相关的能力和基础知识。
首先,我们先明确一下,“数据产品”到底是什么:
数据产品,是为了提高数据应用效率而产生的产品,包括平台型产品、系统功能模块、移动端 App 等多种具体形态。
这就要求准备做数据产品的你,开始关注身边的各种“效率”。这一点不管是在日常工作中,还是在求职面试中,都能体现出思维的层次和总结能力。比如,业务同学眼中,这些方面是比较重要的:
\1. 拓展业务边界
\2. 提高利润
\3. 提高效率
\4. 提升影响力
但与此同时,又要面临4个方面的挑战:
\1. 成本增加
\2. 人力增加
3 时间延长
4 其他风险
这些因素的组合,就产生了各种数据需求。
如果你觉得上面的东西太“虚”了,那么下面干货就来了!
为了用数据抽象业务,以下这些模型了解下呗:
一个用户运营方面的 “蓄水池模型”,帮你理解用户运营的底层逻辑。有了它,你不但能快速理解大牛们分享的运营方法,说不定还能自己创造出独特的模型来。不管是自身的职业发展,还是为了求职面试,这都是重要的加分项。
一个E-R图帮你理清产品中的各种角色。尤其适合B端产品,是不是已经被公司里各种结构搞晕了?那么E-R图能够以图形的方式,清晰地呈现出各种角色之间的关系,还能顺便帮你发现产品设计中的问题。
一个最普通的流程图代表了逻辑顺序,也是许多复杂产品的根本设计。把一个复杂的过程拆分为流程,再一步一步的完成,这是产品经理的一项重要能力。
一个时序图代表了时间顺序,让你能稍微具备一些技术思维了。数据产品通常都会设计多个系统之间的交互。如何能保证他们之间的配合不出问题?时序图能够帮你解决这个问题。
还有一个会计记账法,能帮你梳理产品中的资金流动。如果你的产品是涉及到资金的,那么这个方法真的太重要了。资金的流动、结算、计算利息等问题,都可以通过记账法简明清晰的表现出来。
02 业务知识的准备
如果你准备转到数据分析类的数据产品,那么你需要具备很多的业务知识。大到社会环境的变化,竞品的动作,小到分析自己产品的优势和劣势,调配自己的资源等等。如果之前做的是偏技术产品的工作,那么这部分是需要重点补充的。
当然这些也不需要我们自己真的把业务的工作全部干一遍,这也不现实。许多常见的分析模型,能够覆盖到各种业务分析场景:
\1. 需求分析的KANO;
\2. 从需求到上线的项目管理;
\3. 分析产品优势的SWOT;
\4. 分析产品生命周期的PLC模型;
\5. 分析产品组合的BCG和GE矩阵;
\6. 分析产品营销的营销的4P和4C;
\7. 分析产品竞争的五力分析模型;
\8. 分析行业和宏观环境的PEST;
通过这些模型,足以帮你了解一个产品的前世今生,能帮助大家在业务理解上“弯道超车”,快速抓住业务动作的本质。
如果你已经在做数据产品了,这些模型同样能帮助你。你是否头疼如何建立指标体系?如何抽象出关键的“北极星指标”?结合认知的准备与业务的准备,足以帮你应对90%以上的场景和问题。
除此以外,你是不是还担心,不知道业务方还会提出什么奇奇怪怪的业务需求?其实业务需求只为了满足这几个目标,我们在前面已经提到过了:
\1. 成本增加
\2. 人力增加
\3. 时间延长
\4. 其他风险
所以,如果你从一开始,就考虑了资金成本方面的、人力投入方面、处理时长方面的指标,再结合自己负责的业务补充一些个性化的指标。那么常见的业务需求,就不会逃出这些基础指标的组合了。
03 技术知识的准备
除了业务,“数据产品经理要懂技术”。这可能是让很多人最头疼的一点。
你是否也经历过这样的情况:努力学过PS、Axure、PPT的各种课程,反复看各种教学视频,老师show出的例子也都理解透彻了,但是但等到自己动手的时候,却依然画不好?
你有没有想过这是为什么呢?
这种现象就代表了工具与实战之间的“鸿沟”。对于初学者,这道“鸿沟”才是我们真正的敌人。为了填平它,我们就就需要从思考方式入手、从问题说起。
我们可以从以下几个方面,来填平这道“鸿沟”:
信息的主动反馈与被动反馈,这决定了我们可以将处理过程“分心地”交给软件处理,还是需要我们自己操心。如果类比PS,画笔的处理效果就是不需要我们操心的类型。
通用的解决方案与定制的解决方案。这决定了我们将来应对类似的需求,是否需要再次投入精力。这就像我们在Axure中设计母版、组件等通用内容一样,为的就是以后可以直接使用。
离线还是在线分析、全量还是抽样数据,既然说的是数据产品,当然离不开数据。这两的方面的决策,决定了数据产品最关心的“用户体验”,通常也决定了一些技术结构上的设计思路。
当然,既然是数据产品,数据相关的技术是一定要了解的。
Apache Flume 和Apache Kafka ,常见的数据采集过程;
Apache Hive 和Facebook Presto ,数据仓库和OLAP计算;
Apache Kylin ,OLAP中多维分析的场景;
Apache Flink 和Apache Storm ,数据处理;
Apache Spark ,则涉及了多种应用场景,包括热门的机器学习;
以上这些就是数据产品的基本框架了,是不是能帮你理清工作和跳槽的思路了呢?
发表评论 取消回复