埋头干活不会汇报,别说 996 就算 007 也没用!

见字如面,我是军哥!

经调研发现 80% 的程序员认为工作汇报就是形式主义,无聊至极,但是我要和你说,做好工作汇报非常重要,这直接关系到你在这家公司能否快速成长和晋升加薪,而且要告诉你一件扎心的事,就算你努力结果也很好,不会汇报绩效也不会很好。

认为只要自己努力了,996了,007了,感动自己了,拿到结果了,领导就会主动来给你加薪晋升了,这都是一厢情愿。

为什么呢?

因为领导下属 N 多人,他可能都没太了解你,信息差永远存在~

所以,学会汇报并主动汇报,在工作中尤为重要。

1、三种汇报类型

a、计划类汇报

就是你和领导说你将要干什么事,干多久,能干到什么程度等等。

b、进展类汇报

就是干的过程中,进度落后了么,有延期或质量问题么,及时汇报及时解决,让领导安心省心。

c、成果类汇报

这个最难也是领导最看重的,就是一个迭代或者项目做完之后,你要总结出你的工作给业务带来了多大价值并尽量量化,你个人的技术广度和深度有多大提升,还有你个人软性方面能力比如沟通协作和复盘总结能力有多大提升。

所以,关于汇报类型至少就这三种,汇报本身是门学问,一定要重视并学起来。

2、关于最难的「成果类汇报」的正确姿势

其实学会方法也不难,我们来深入聊聊成果类汇报,可以从以下四个维度来思考:

第一个维度是结果。

比如你是业务开发,那么你可以业务开发和技术优化两个角度去总结,并且对于业务开发项目,从业务的维度总结是自然的,例如某个业务用户日活是多少。对于技术优化方案来说,主要看技术方案给业务带来的价值是什么,例如高可用方案让业务 P1 故障从 3 次减少到 0 次。

再比如你是基础架构开发团队,结果建议从系统的性能、可用性和成本等方面进行总结;如果中间件系统已经产品化,也可以从销售量或者流量等方面进行总结。

而对于运维和测试之类的部门,结果建议从质量、效率和成本方面进行总结。

第二个维度是数据。

如“提升了开发效率”这种比较虚的描述,应该改成“开发一个功能从 10 人天提升为 2 人天”这种使用具体数据的描述。

很多人在一开始尝试的时候都会遇到一个疑问,感觉这个事情好像没办法用数据来描述啊?这个时候怎么办呢?其实大部分的情况,不是真的不能用数据来描述,而是你没有去搜集数据,没有养成用数据来说明的习惯而已。

第三个维度是技术本身。

对于程序员来说,做完一个项目之后,技术上有哪些提升、学到了什么新的技术、对哪些技术有了更深或者更全面的理解等,都可以在总结的时候系统地梳理出来。

第四个维度是自我成长和思考。

除了关注技术上的提升之外,你还需要关注个人综合能力成长,也就是软实力提升,比如对业务的理解能力、项目组织能力、沟通能力和做事方法等。

最后以业务理解能力为例,做完一个项目后,你可以从以下角度去总结:业务的适应场景是什么?目标用户是谁?目标用户有什么特点?解决了目标用户的什么问题?实际的效果又如何?

如果平时工作是低头走路,那汇报就是抬头看天,这是一个和领导直接沟通拿到即时反馈,明确和矫正目标以及速度修正自己/提升自己的重要场景,各位要多重视。

以上,供你参考~

最后,特别预告一下,我最近和几个中大厂的架构师和技术总监吃饭聊天,总结了一些他们能成长如此之快的底层思维和做事方法论,这个主题之前分享过一次,效果很好,我准备本周六晚上 21 点开直播来和你深入聊一聊。

我相信一定可以开拓你的视野,不用那么卷就可以把身边的同事拍在沙滩上,请点击「下方」预约,也欢迎带着其他问题来直播间提问,我们不见不散~

以往热文推荐:

我打工15年,自己干3年,分享你8条顶级认知!
开心!两位读者来报喜!


更多精彩,关注我公号,一起学习、成长

aea4de293d2fc373d6052e749b8bf91d.png

猜你喜欢

转载自blog.csdn.net/chengjun_java/article/details/132750094
996
007