来源:接地气的产老师
有同学问:该怎么述职比较好?
原本,数据分析师想体现工作成绩就比较难。今年大环境不好,大家的危机感都很强,因此问题一出,激起很多同学同感。根据工作内容不同,述职重点有差异,但有些基本原则可以先介绍给大家。
放平心态:平凡中找机会
首先要强调一点:并非只有做项目才能体现数据价值,也不是所有的输出都得别人听你的,才显得你厉害。特别是服务老板的工作,老板嘛,总是喜欢显得自己高瞻远瞩的,所以能做好老板的支持工作就已经是大功一件了。
反而是,刚进公司就想独立负责复杂项目,很有可能踩坑。因为数据字典整齐,业务需求明确,业务态度和善的公司比大熊猫还稀少。
你刚进门,没有清晰的工作交接,数据字典?不存在的,连理解表结构都费劲。业务懒得搭理你,还时不时嫌弃你不熟练。这时候真接个建立完善的用户画像实现精准预测一类项目,很有可能把自己做死。
所以先放平心态, 先满足基础要求再说。
基本要求:用数据说话
要坚决杜绝:卖啥的不吃啥问题。不要一张嘴就是:我每天都在跑数。到底为谁跑数?跑了多少数?跑数质量怎么样?都说不清楚,这就是自掘坟墓了。
可以把我每天都在跑数,改成:
量化工作内容:我完成了50份需求
与业务工作挂钩:
1、20份为运营常规日报/周报
2、 15份为618活动项目支持
3、10份为年中复盘专题支持
4、5份服务老板的探索性需求
体现效率/质量:
1、50份需求100%按时完成
2、提供数据正确率100%,无一返工
先别管对业务有啥贡献,起码证明自己工作数量/质量是做到位了。有了这个基础,再做扩展。有些同学会疑惑:那平时业务提需求,是不是要记录一下呀?不然咋统计工作量?
当然要记录啦!你看坐你隔壁的开发组,不但记录需求,还要开需求评审会呢,多有仪式感。你越是默默付出,大家反而越忽视你的成绩。记录方法可以参考下图所示,如果业务不愿意写,那么我们自己写起来
而且记录需求还有个好处:区分到底是你取数不准,还是业务需求不清晰。经常,业务自己提的需求不清晰,或者看到数据以后又要改口径。这种就不能算是数据分析师工作失误,而属于需求变更。写一份需求记录,能有效自证清白。
进阶要求:积累工作方法
很多工作中小细节的方法积累,会被大家忽视。比如开头同学提到的:协助领导完成测算虽然都是事前拍脑袋,但拍法也有很多种:
1、只看以前走势
2、以前走势+预计行动
3、以前走势+预计行动+季节调整
等这个测算任务整完,完全可以梳理个:业务测算模型,把之前考虑的各种做法记录下来。这样下次测算还能用。而且还能在述职的时候光明正大的写上:实现方法论迭代。
类似的:
给原本的监控报表增加了字段 → 完善了底层逻辑
活动前提数,活动后再看看效果 → 实现了业务闭环
写报告的时候发现某个点做得很好 → 寻找到关键路径
互联网黑话都给他整上呀,这不就高大上起来了吗。当然,不是事事都需要写得这么夸张。记得关注下其他人写法,如果大家都在装,那你也果断装啊,不然脱离群众呀。
高级要求:切中业务痛点
更高级的要求,则需要紧密结合业务需求。但是这是有前提的,需要和业务建立起良好的沟通关系,才好深入聊。一般刚入职没俩月,人还不熟,可以先不着急,等后边慢慢合作开了就好了。
需要强调的是:业务痛点,不见得都都是你分析下我怎么赚1个亿
1、新业务上线,缺少数据
2、数据分散在各个系统,查看麻烦
3、想做精细化运营,没法灵活筛选目标用户
4、想做业务试点,但怕考虑不周,事后被挑战
5、想说服老板支持,但不知道怎么论证更周全
这些都是真实且强烈的需求,和业务搞好关系,了解真实需求,才好攻其所必救,体现我们的价值。
看完觉得写得好的,不防打赏一元,以支持蓝海情报网揭秘更多好的项目。