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