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

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

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

1. 不要做小需求

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

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

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

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

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

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

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

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

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

2. 要做大需求

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

你可能会说，我能力不行，Hold不住，怎么办？

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

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

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

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

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

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

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

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

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

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

所以，一定要大需求。

3. 定期同步工作进度

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

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

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

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

强哥，我最近开发的造火箭需求，目前进度是50%，火箭发射的不锈钢三脚架和铝合金外壳已经搭建完毕，还差发射燃料没有确定。

我建议用煤作燃料，最好用无烟煤，更环保，只是燃料组那边一直没给出具体排期，这样可能会耽误项目整体进度，要么这一期上线用玉米秸秆作燃料，你看能否协调一下这个问题？

4. 项目结束，主动复盘

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

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

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

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

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

你觉得怎么样？欢迎点赞评论交流！