今天我来说说我对加班的看法。
我对加班的看法可以用一句话概括，就是“救急不救穷”。
作为一线员工
我只有三种情况会加班：真的有急事 / 为了以后不加班 / 新的机会点。
真的有急事儿
团队有的时候真的遇到急事儿了，那加一下班就加一下吧。
这就跟借钱的道理是一样的，你的某个朋友上班路上被车撞了，住院了要花很多钱，那你要是有闲钱的话就给人家借一点吧。就算没闲钱挤一挤也给人家借一点吧，毕竟这是要命的事情。
我之前所在的团队就遇到了一件急事儿，工信部突然推出了一个新的合规政策，凡是不符合这个合规政策的 APP 要一律下架。工信部给了一个时间点，让各个互联网公司整改。由于工信部是监管方，屁股决定脑袋，人家才不管你整改时间合理不合理呢。
抖音要是被下架了，那影响面有多大，相信不用公司高层开动员会，每一个一线员工都知道。
全团队一起疯狂加班了一个月，一个月的每个周末都没休息，最终在时间点前把问题给解决了。那段时间真的是加班加得昏天黑地，每天都在怀疑自己到底为什么还活着。
最终公司也给这个项目的每个人发了一笔奖金，无多有少算是对大家辛苦的一种认可。
这种班就可以加，毕竟确实是紧急事项。资本家要是完蛋了，打工狗也没地方去领工资去。
为了以后不加班
还有一种情况，今天的加班是为了以后不加班。
程序员应该经常遇到这种情况，想开发一个需求，打开代码一看，全是屎山。每个文件两万多行代码，加在一起只有 10 个函数，平均每个函数 两千行代码。
想在这个函数里改一个逻辑，没有人知道改动影响和范围是啥，没有文档没有单测（两千行的函数怎么可能有单测）。你抽出一块砖来会不会导致整个大楼轰然倒塌？不知道·····
很多人遇到这种情况，就会有一种破罐子破摔的心态，既然这段代码已经这么屎了，那我再增添一丝混沌似乎也不碍事。
我一般不会这么做，一旦我遇到这种情况，就会立刻开始梳理业务逻辑和代码逻辑，组织重构。要把这段代码修改到至少可以模块化运行的程度。然后在后续的过程中把单测的质量保证的工作也补上。
可是业务方很难理解，我只是让你加个字段，咋给我排了一个星期的时间？有些业务方好说话，能够理解；有些业务方确实有压力，没有办法接受。
那我也会尽自己最大的努力去优化这段代码，连续一个月周末加班去重构也不在话下。哪怕这种加班领导不给我批准，没有加班费，我也要第一时间去组织重构。
因为我心里知道，这次加班是为了以后不加班。我今天把这段代码整理好，那我后续的需求开发起来就会很快。否则每次来一个需求我要加一次班，加班的次数与需求数成正比。
因为我自己是一个研发，所以我用了写代码来举例子。但是我感觉各个角色各个行业都会有类似的情况 ，你需要负责的事情已经一团乱了，想要在一团乱的事情里做一小点改动都累死累活。此时即使加班也要立刻把事情整理出头绪来。
反过来说，正是因为前面的人没有立刻整理头绪，所以事情才拖到今天屎山的这个程度。
新的机会点
相信每一个“会工作”的人都明白，团队有问题需要解决，那真是天大的好事儿。
只要观察到团队的问题，我就会立刻行动起来，拿出我的整改方案，跟老板对齐。如果能够得到认可，就准备推进落地，年底绩效就准备吹这个了。
很多人看到团队有问题，就只会在匿名论坛抱怨；而像我这样的“卷王”看到问题，就像狼看到肉一样。这些问题对我们来说就是机会。
一个机会的出现通常只有很短暂的时间窗口，要么是某一个新技术出现了，导致原来解决不了的问题突然可以解决了；要么是这个问题本来不重要，但是外因变化导致这个问题突然变得很重要。
这种情况下，一个团队内总会有那么几个聪明人同时看到这个机会点。这时谁能率先拿出方案和 demo，谁就能占领这个问题的“生态位”。
举个小例子，团队内每个成员的某个日常工作总是写一段重复的代码。这段重复的代码分散在不同的地方，质量没有保障，也就没法儿管理。你看到这个情况，赶紧写一个框架，让大家接入到你的框架里，整体把控，提升团队效率。
你写得差不多了，然后周会上跟你的 leader 说了这个事情，你的 leader 肯定觉得很好，鼓励大家都接入你的框架。这时另外一个同学说他也做了一个类似的东西，你的 leader 肯定会问你们各自做到什么程度了，谁做得更先进，解决更多问题，那肯定就会让一线同学接入谁的框架。另外一个人之前的努力就白费了。
而且一旦别人接入了你的框架，你就对大家的某一小部分工作有主导权了，别人在一个很小的地方就得听你的。而且领导也会觉得，这个同学有主动解决问题的思路，那你的意见也会更受到重视。
这个“框架”的生态位，就被你站住了，你后面就可以慢慢迭代了，资源不足的话可以协调到更多资源。
所以这种情况，项目的成果与你的成绩直接相关，真的是要加班解决的。
什么样的情况不加班
未完待续····
