【工作感悟】老程序员总结的四条工作经验教训
文章目录
- 前言
- 1. 不要做小需求
- 2. 要做大需求
- 3. 定期同步工作进度
- 4. 项目结束,主动复盘
- 总结
前言
想来从事互联网工作已经很多年了,已经从当初的懵懂少年逐渐退化成老油条。刚毕业的时候,真是个愣头青,什么都不懂,也什么都看不惯。整天加班忙得要死,还要忍受领导批评指责。
期间踩过很多坑,今天特意总结四条经验教训,送给年轻的程序员们。
1. 不要做小需求
程序员在工作中,接需求的时候,千万不要做小需求、小优化、小迭代。
你以为是偷个懒,减轻自己的工作量,其实大大加重了自己的工作量。
在你做了很多个小需求之后,你就会接触到很多业务模块的人,他们的业务、产品、运营、测试、开发、用户,有问题都会直接找你,每天都会看到钉钉未读消息99+,每个人回复一句,你这一天什么都不用干了。
你做了很多需求,每天忙的要死,领导也照样不会待见你。
“什么?这个需求,这么简单,就增加几个查询条件,你要做三天?”
“你能不能一天把这三个需求做完了?自己想办法克服一下。”
领导眼中,你干的就是打杂的活,是个人都能干,招个实习生可能干的更快,是团队的边缘人物。
升职加薪永远轮不到你,如果团队绩效需要有人背C,领导反而第一个想到是你。
多做多错
,肯定会有你考虑不到的情况,伴随着肯定会出一些线上问题。
领导眼中,这小子能力也太差了,这么简单的活都能干废了,赶紧找个机会让他走吧。
2. 要做大需求
程序员接需求,就要接大需求
,最好持续3个月、半年以上的,涉及团队核心功能、核心逻辑的,并且由自己作为ower开发的,没有就主动争取。
你可能会说,我能力不行,Hold不住,怎么办?
没关系,其他人没有比你强到哪里去。
做这个需求需要什么资源,你都可以跟领导申请。大需求代表可操作的空间非常大。
“这个大需求,我熟悉产品文档,做技术方案设计,用两周,没问题吧?”
“没问题,有不懂的找相应负责人,有困难直接找我。”
别人苦哈哈忙着开发上线,你在跟兄弟团队名义上沟通需求。上午工位上看不到你,下午远程会议讨论就你讲话声音最大,营造出团队就你最忙的景象。
你在做技术方案设计的时候,项目工时到底是3个月还是4个月,全看你的技术文档怎么写。一个添加按钮的功能,工时是一天还是三天,谁也不知道,因为除了你,没人了解整个项目的全貌。
作为整个财年的重点需求,团队所有需求的最高优先级,整个团队的绩效都看你的了。
你说开发资源紧张,没关系,领导都过来,亲自给你打下手,团队所有人都任你调动。
需求眼看无法按时上线的时候,所有人都要陪着你加班,按时上线后,功劳你占大头。
哪怕是最坏的情况,项目干废了,你也被毕业了。你的简历上也算有的写,总比写crud强一些吧。
所以,一定要大需求。
3. 定期同步工作进度
一周也不跟领导说上几句话,领导以为你天天在划水,实际上你每天加班到晚上8点,忙得焦头烂额,领导还不停地给你派活,这就是你没有定期跟领导同步工作进度的缘故。
定期同步工作进度有这几个作用:
- 让领导看到你的工作,对你心中有数,让领导有掌控全局的感觉。
- 遇到问题,缺少资源,领导能及时帮你协调解决。
- 获取领导信任,建立良好关系。
向领导汇报的模板,可以参考下面这样:
强哥,我最近开发的造火箭需求,目前进度是50%,火箭发射的不锈钢三脚架和铝合金外壳已经搭建完毕,还差发射燃料没有确定。
我建议用煤作燃料,最好用无烟煤,更环保,只是燃料组那边一直没给出具体排期,这样可能会耽误项目整体进度,要么这一期上线用玉米秸秆作燃料,你看能否协调一下这个问题?
4. 项目结束,主动复盘
什么?复盘?听着很专业的样子,你不知道怎么复盘。
别担心,其他人也都不懂,大家都是赶鸭子上架。
复盘,一方面是给领导看的,让领导知道自己的努力过程和工作成果。另一方面是总结自己的得失,以便下次能更好的甩锅。
可以按照以下几点进行复盘:
- 项目的目标,以及完成情况
- 有哪些做的好的方面,如何继续保持?
- 过程中有哪些不足,原因是什么?你有没有好的解决方案?
- 你的反思与总结是什么?
总结
你觉得怎么样?欢迎点赞评论!