拒绝透支加班，从我做起！

在IT行业中，尤其是对那些在初创公司中的员工来说，疯狂加班简直是家常便饭。我们姑且称这种工作方式为“透支模式”。

”透支模式”是指在一段特定时间内，由于项目上线压力或其他种种因素，开发人员必须要高强度超时工作的模式。程序员总是对通宵加班有种迷信，总是过度放大其效果，并且认为这是解决问题的”大杀器“。更为可悲的是，这种孤胆英雄一样的行为几乎成为程序员社区信仰的一部分，成为我们衡量彼此是否是一个合格程序员的准则，更是许多公司管理层用来压榨员工的手段和借口。

“透支模式”是否科学？答案是否定的。从一个项目经理的角度来说，让一个本身能力卓越的员工尽快变成低效得只会制造垃圾代码的机器，只需要为项目设置一个deadline，一个根本不现实也不可能完成的deadline。因为为了赶进度，该名员工除了没日没夜的加班加点外，别无选择，他只能最大限度的牺牲其他时间。换句话说就是启动“透支模式”。

为什么“透支模式”危害无穷？

首先，连续的超时工作会让人脑力体力均透支，从而水准大降。即使不犯错误，在工作上也更容易钻牛角尖，毫不察觉得在错误的思路上越走越远。

其次，“透支模式”会让人产生职业倦怠，这种倦怠有时候是永久性的。

虽然听上去很讽刺，因为启动“透支模式”的本意是完成更多的工作。但实际情况却是人们会变得越来越懒，效率越来越低。原理很简单，假设我决定这一晚上都用来解决一件事。我的大脑会把任务时长定位为一晚上，所以先休息一小时听上去也无伤大雅。但是综合来看，这一晚上的平均效率其实是被拉低的。

“透支模式”使员工的可靠性降低。设想一个人没日没夜的工作，每时每刻都得不到休息，管理者还怎么好意思因为“迟到”，“不回邮件”，“不写单元测试”，“引进bug“，”产生技术债务“等等等等的事情责备他。

频繁启动”透支模式“使管理层的威信受到质疑。其实每次收到加班通知时，程序员往往想知道“为什么？”。听上去可能有点“刻薄”，但是话糙理不糙，这种时候员工会觉得管理者只在乎任务是否完成，而根本不关心他们作为个人是不是健康是不是高兴。

“透支模式”为什么存在？

最重要的原因是–不切实际的期望。团队领导者没有很好的评估团队的工作效率以及完成项目所需的工作量。在某些最坏的情况中，项目的交付日期只是项目经理未经调研分析就一拍脑门随便定的。更为普遍的情况是，项目的交付日期是确定的，但是没有确定的需求范围。于是随着项目的开展，需求范围增大而导致交付日期变得越来越不切实际。这个时候，项目经理应该根据当下项目的进展情况对交付日期进行合理的调整。

沟通不畅以及各种不靠谱的担心。不会说“不”是众多程序员的通病。“你能这周五前做完吗？”，“嗯……可能……大概……估计……可以吧。”。从项目经理的角度出发，他们不希望把计划时间定的太长，首先因为他们担心把日期定的太远会有点“说不过去”，其次他们太明白程序员有“错过交付日期”的习惯，从而会把交付时间订的尽可能地早。因为项目时间越长，交付就会变得越越遥遥无期。“你们觉得如果这次在时间上留了余地，能就比deadline晚两天交吗？”

如何可以不用”透支模式“也完成项目？

赶不上交付进度？那就赶不上吧。让你的客户失望一次，少赚点钱，蒙受一些损失，总之项目失败就是失败了。既然你没能管理好你的团队和项目，那为什么不干脆把这些问题暴露出来呢？

细化你的目标，精细化管理。如果你把任务定的太多，完成日期又制定得太高远。那这个任务计划基本上定了也是白定，因为你并不知道这是否符合实际情况。但是我相信如果你只是计划今天下午做什么，你的计划会更准确而且更容易完成。

步步为营，了解团队的真实进度。在软件业中，不能只看书面的进度报告，必须对提交的代码进行测试确保其符合开发需求且运行正常。

制定合理的目标，明确所面对的问题。如果公司总是需要使用“透支模式”来完成目标，那说明管理者根本不了解整个团队的工作节奏和能力。这时候项目经理得说服自己要“慢下来”，开发速度没有预期中快，没关系，接受事实并积极调整。

尽管“透支模式”是一种不健康的、低效且愚蠢的做法，但是我们承认有时候它确实是唯一的解决办法。但是请记住，不到万不得已不要开启“透支模式”，尽管可以把它当成最后的杀手锏，但从长期效果来看，这是以团队的凝聚力和对管理者的信任为代价的。

我们可以杜绝“透支模式”吗？

“透支模式”的造成往往是由于规划失误、沟通不畅和领导不当。想想由此造成时间和物质上的巨大浪费，是时候停止这样的恶性循环了。

对于管理者来说，当不得不使用“透支模式”时候，请把这个当做一个个人工作上的失误，并好好反思。

对于团队里的其他人，请善加利用正常工作的时间，请做到保证沟通，集中精力，让每分钟都算数！