老程序员总结的四条工作经验教训,一部血泪史,推荐观看

·  阅读 7210
老程序员总结的四条工作经验教训,一部血泪史,推荐观看

想来从事互联网工作已经很多年了,已经从当初的懵懂少年逐渐退化成老油条。刚毕业的时候,真是个愣头青,什么都不懂,也什么都看不惯。整天加班忙得要死,还要忍受领导批评指责。

期间踩过很多坑,今天特意总结四条经验教训,送给年轻的程序员们。

程序员工作.jpeg

1. 不要做小需求

程序员在工作中,接需求的时候,千万不要做小需求、小优化、小迭代。你以为是偷个懒,减轻自己的工作量,其实大大加重了自己的工作量。

在你做了很多个小需求之后,你就会接触到很多业务模块的人,他们的业务、产品、运营、测试、开发、用户,有问题都会直接找你,每天都会看到钉钉未读消息99+,每个人回复一句,你这一天什么都不用干了。

你做了很多需求,每天忙的要死,领导也照样不会待见你。

“什么?这个需求,这么简单,就增加几个查询条件,你要做三天?”

“你能不能一天把这三个需求做完了?自己想办法克服一下。”

领导眼中,你干的就是打杂的活,是个人都能干,招个实习生可能干的更快,是团队的边缘人物。

升职加薪永远轮不到你,如果团队绩效需要有人背C,领导反而第一个想到是你。

多做多错,肯定会有你考虑不到的情况,伴随着肯定会出一些线上问题。

领导眼中,这小子能力也太差了,这么简单的活都能干废了,赶紧找个机会让他走吧。

程序员工作1.jpeg

2. 要做大需求

程序员接需求,就要接大需求,最好持续3个月、半年以上的,涉及团队核心功能、核心逻辑的,并且由自己作为ower开发的,没有就主动争取。

你可能会说,我能力不行,Hold不住,怎么办?

没关系,其他人没有比你强到哪里去。

做这个需求需要什么资源,你都可以跟领导申请。大需求代表可操作的空间非常大。

“这个大需求,我熟悉产品文档,做技术方案设计,用两周,没问题吧?”

“没问题,有不懂的找相应负责人,有困难直接找我。”

别人苦哈哈忙着开发上线,你在跟兄弟团队名义上沟通需求。上午工位上看不到你,下午远程会议讨论就你讲话声音最大,营造出团队就你最忙的景象。

你在做技术方案设计的时候,项目工时到底是3个月还是4个月,全看你的技术文档怎么写。一个添加按钮的功能,工时是一天还是三天,谁也不知道,因为除了你,没人了解整个项目的全貌。

作为整个财年的重点需求,团队所有需求的最高优先级,整个团队的绩效都看你的了。

你说开发资源紧张,没关系,领导都过来,亲自给你打下手,团队所有人都任你调动。

需求眼看无法按时上线的时候,所有人都要陪着你加班,按时上线后,功劳你占大头。

哪怕是最坏的情况,项目干废了,你也被毕业了。你的简历上也算有的写,总比写crud强一些吧。

所以,一定要大需求。

程序员工作2.jpeg

3. 定期同步工作进度

一周也不跟领导说上几句话,领导以为你天天在划水,实际上你每天加班到晚上8点,忙得焦头烂额,领导还不停地给你派活,这就是你没有定期跟领导同步工作进度的缘故。

定期同步工作进度有这几个作用:

  1. 让领导看到你的工作,对你心中有数,让领导有掌控全局的感觉。
  2. 遇到问题,缺少资源,领导能及时帮你协调解决。
  3. 获取领导信任,建立良好关系。

向领导汇报的模板,可以参考下面这样:

强哥,我最近开发的造火箭需求,目前进度是50%,火箭发射的不锈钢三脚架和铝合金外壳已经搭建完毕,还差发射燃料没有确定。
我建议用煤作燃料,最好用无烟煤,更环保,只是燃料组那边一直没给出具体排期,这样可能会耽误项目整体进度,要么这一期上线用玉米秸秆作燃料,你看能否协调一下这个问题?

火箭.jpeg

4. 项目结束,主动复盘

什么?复盘?听着很专业的样子,你不知道怎么复盘。

别担心,其他人也都不懂,大家都是赶鸭子上架。

复盘,一方面是给领导看的,让领导知道自己的努力过程和工作成果。另一方面是总结自己的得失,以便下次能更好的甩锅。

可以按照以下几点进行复盘:

  1. 项目的目标,以及完成情况
  2. 有哪些做的好的方面,如何继续保持?
  3. 过程中有哪些不足,原因是什么?你有没有好的解决方案?
  4. 你的反思与总结是什么?

复盘.jpeg

你觉得怎么样?欢迎点赞评论!

分类:
代码人生
标签:
收藏成功!
已添加到「」, 点击更改