这段时间，996.icu项目长期霸占了github趋势榜，引起了各方人士的注意。
有不少行业翘楚站出来发声，有措辞委婉激励员工奋斗的，也有言辞激烈实力劝退的。
然而，仔细想想却发现，人们似乎一直在讨论该不该加班的问题，
却没有冷静分析加班的原因是什么。
为什么我们有这么多的事情，却还剩下了如此少的时间？
这种状况是怎样造成的？
1. 工期倒排
绝大多数软件项目会花费比预期更长时间才能完成，
首要原因我认为是，一开始就产生了不合理的预期。
工程师评估要一个月做完，但是交付时间早已定死，必须在一周内上线。
这样做只会有三种可能的结果，
要么满目疮痍的上线一个半成品，要么项目延期，要么加班。
所以，并不是说项目管理者不尊重软件规律。
而是说，在一定限度之内，加班确实能让项目尽早的保质保量上线。
超出了限度，再加班也是无济于事了。
一线工程师们可能会跳出来反对，加班会导致效率低下，时间紧迫会导致疏漏更多。
但从项目管理者角度来看，这不是他的事情，是工程师自己的问题。
经验表明，短期的冲刺型加班，对项目快速上线确实是有效的。
至于是否给加班费，工程师在项目开始前是否已经满负荷运转，不同的企业会有不同。
其合理性不在我们的讨论范围之内。
这里只是说，对于工期倒排的项目，加班是最容易想到的一个办法。
2. 需求紊乱
我们知道，需求是不可能不变更的，因为软件要解决的问题是一个发展中的问题。
所以关于需求，我们应该考虑如何管理，如何控制它。
产生需求紊乱的原因是多方面的，
但我认为主要原因在于，需求的合作方并不属于同一个利益共同体。
我们来梳理一个完整需求的来龙去脉，
需求一般来自于市场，总结自产品经理，交由工程师实现，研发资源由项目经理调配。
这涉及到三方面的利益。
（1）交付标准的制定者：产品经理
（2）实现方案的制定者：工程师
（3）资源投入的制定者：项目经理
每一方如果只考虑自己，就会打起来。
通常项目经理一般是团队负责人，行政级别较高，所以更难被挑战。
因此，人们看到的都是产品经理和工程师之间的感情纠葛了。
在资源投入（人力+时间）确定的情况下，
频繁的改动交付标准，必定会产生额外的工作量。
这些额外的工作量，只能靠加班来解决了。
因此，一流团队会考虑三方利益的折中，三流团队只会盲目的加班，碰碰运气。
这个需求很简单，具体实现我不管 —— 明天上线
3. 团队文化
我加入过不同的软件团队，有些团队确实有加班文化，主管不走没人敢走。
除了想在主管面前好好表现自己之外，我还想到了一些其他的原因。
首先，事情是做不完的，如果愿意的话，工作任务总能排到明年。
那么员工们该怎么解释明明每天下班很早，还在说自己没时间。
因此，形式主义的加班就形成了，我很忙，忙到没时间接更多的任务了。
这是一种不明智的选择，除非管理者能意识到这一点。
无穷无尽的开发任务，会让工程师失去信心，
提前做完的工作应该给予奖励，而不是接踵而来的更多任务。
其次，比团队其他成员更早的下班，似乎意味着更不尽责，
但是更晚的回去，同样也不能意味着更尽责，除非主管能明确讲明这一点。
拼时间总是不合理的，大家的关注点应该放在成效上，
关注遇到了哪些问题需要协调哪些资源来解决，
怎样让每个任务更无阻碍的完成。
最后，不乏有一些管理者只有下属在身边时才会安心，
这样看起来更像一个团队，而不是一盘散沙。
对于紧急情况的处理，能立刻把人叫齐，比联系不到人要好太多了。
所以，他们不在意下属在下班时间做什么，只要在办公室就行。
类似促使加班的团队文化，还有很多，不能一一列举了。
文化是很重要的一个管理风格因素，和软件无关。
结语
加班的原因是多种多样的，加班的目的也各不相同，
可能是项目因素，可能是工程因素，也可能是管理因素，等等。
所以，消除996并不是简单的抵制就完事了。
996反映出了一些当前软件行业的更深层次的问题，
从各大公司实际执行的工作方式来看，加班对解决上述问题应该是有效的，
所以才会被执行下去。
管理者和企业主不会坐视低效无产出不管的，
只能说加班确实对效率有影响，但同时也能创造更大的利润。
在没有更好的办法出现之前，这个局面还是不会改善的，损失了太多人的利益。