本文为数据分析师述职报告撰写支招，从量化工作内容、积累工作方法到切中业务痛点等，提供了实用的模板和建议，助力分析师们提升报告质量，更好展现自身价值。

有同学问：半年了，该怎么准备年中述职比较好？

原本，数据分析师想体现工作成绩就比较难。

今年大环境不好，大家的危机感都很强，因此问题一出，激起很多同学同感。根据工作内容不同，述职重点有差异，但有些基本原则可以先介绍给大家。

放平心态：平凡中找机会

首先要强调一点：并非只有做项目才能体现数据价值，也不是所有的输出都得别人听你的，才显得你厉害。特别是服务老板的工作，老板嘛，总是喜欢显得自己高瞻远瞩的，所以能做好老板的支持工作就已经是大功一件了。

反而是，刚进公司就想独立负责复杂项目，很有可能踩坑。

因为数据字典整齐，业务需求明确，业务态度和善的公司比大熊猫还稀少。

你刚进门，没有清晰的工作交接，数据字典？

不存在的，连理解表结构都费劲。业务懒得搭理你，还时不时嫌弃你不熟练。

这时候真接个“建立完善的用户画像”“实现精准预测”一类项目，很有可能把自己做死。

所以先放平心态， 先满足基础要求再说。

基本要求：用数据说话

要坚决杜绝：“卖啥的不吃啥”问题。不要一张嘴就是：我每天都在跑数。到底为谁跑数？跑了多少数？跑数质量怎么样？

都说不清楚，这就是自掘坟墓了。

可以把“我每天都在跑数”，改成：

量化工作内容：我完成了50份需求

与业务工作挂钩：

1、20份为运营常规日报/周报

2、 15份为618活动项目支持

3、10份为年中复盘专题支持

4、5份服务老板的探索性需求

体现效率/质量：

1、50份需求100%按时完成

2、提供数据正确率100%，无一返工

先别管对业务有啥贡献，起码证明自己工作数量/质量是做到位了。有了这个基础，再做扩展。有些同学会疑惑：那平时业务提需求，是不是要记录一下呀？不然咋统计工作量？

当然要记录啦！你看坐你隔壁的开发组，不但记录需求，还要开需求评审会呢，多有仪式感。你越是默默付出，大家反而越忽视你的成绩。

记录方法可以参考下图所示，如果业务不愿意写，那么我们自己写起来。

而且记录需求还有个好处：区分到底是你取数不准，还是业务需求不清晰。经常，业务自己提的需求不清晰，或者看到数据以后又要改口径。这种就不能算是数据分析师工作失误，而属于需求变更。写一份需求记录，能有效自证清白。

进阶要求：积累工作方法

很多工作中小细节的方法积累，会被大家忽视。比如开头同学提到的：“协助领导完成测算”虽然都是事前拍脑袋，但拍法也有很多种：

1、只看以前走势

2、以前走势+预计行动

3、以前走势+预计行动+季节调整

等这个测算任务整完，完全可以梳理个：业务测算模型，把之前考虑的各种做法记录下来。这样下次测算还能用。而且还能在述职的时候光明正大地写上：“实现方法论迭代”。

类似的：

• 给原本的监控报表增加了字段 → “完善了底层逻辑”
• 活动前提数，活动后再看看效果 → “实现了业务闭环”
• 写报告的时候发现某个点做得很好 → “寻找到关键路径”

互联网黑话都给他整上呀，这不就高大上起来了吗。当然，不是事事都需要写得这么夸张。记得关注下其他人写法，如果大家都在装，那你也果断装啊，不然脱离群众呀。

高级要求：切中业务痛点

更高级的要求，则需要紧密结合业务需求。但是这是有前提的，需要和业务建立起良好的沟通关系，才好深入聊。一般刚入职没俩月，人还不熟，可以先不着急，等后边慢慢合作开了就好了。

需要强调的是：业务痛点，不见得都都是“你分析下我怎么赚1个亿”

1、新业务上线，缺少数据

2、数据分散在各个系统，查看麻烦

3、想做精细化运营，没法灵活筛选目标用户

4、想做业务试点，但怕考虑不周，事后被挑战

5、想说服老板支持，但不知道怎么论证更周全

这些都是真实且强烈的需求，和业务搞好关系，了解真实需求，才好“攻其所必救”，体现我们的价值。