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

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

 

 

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

首先，连续的超时工作会让人脑力体力均透支，从而水准大降。以我为例，每次在熬夜加班打持久战的时候，越到后期我越经常犯低级错误，这些失误会制造出一大堆麻烦，甚至破坏线上正常运行的功能。即使不犯错误，在工作上也更容易钻牛角尖，毫不察觉得在错误的思路上越走越远。

其次，“透支模式”会让人产生职业倦怠，这种倦怠有时候是永久性的。启动了“透支模式”的人如果不能适时的得到休息和调整，长时间高强度的工作压力会使人失去对专业的热情和兴趣。如果在企业中长期这样管理操作，再优秀再任劳任怨的员工也会辞职。

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

“透支模式”会彻底扼杀工作热情。“透支模式”意味着整个团队的工作节奏已经超出他们所能承受的范围。就像只给汽车加能跑六十公里的油，但是非要跑七十公里远一样，一次两次勉强可以到达，长期以往，总有你蹲在路边等救援的一天（编注：“60公里的油跑70公里”这比喻不合适）。要是还不吸取教训，你就等着次次抛锚吧。

“透支模式”使员工的可靠性降低。设想一个人没日没夜的工作，每时每刻都得不到休息，管理者还怎么好意思因为“迟到”，“不回邮件”，“不写单元测试”，“引进bug“，”产生技术债务“等等等等的事情责备他。当然谁也不希望自己的团队里出现这些错误，所以请杜绝“透支模式”，使团队的可靠性得到保证。

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

综上所述，使用“透支模式”在某些不太需要脑力劳动的行业可能是个好主意，但是从来不是在软件行业中。

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

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

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

“透支模式”是这个行业的通病，不知道从什么时候开始，我们潜移默化地推崇着加班文化。一言蔽之，这是一种能为人带来巨大成就感的工作模式，甚至会让人上瘾。试想如果没有你撸胳膊挽袖子大干一个通宵，工作将不能按时完成，产品可能无法按时上线，但是由于你的牺牲和努力，像英雄那般的力挽狂澜，项目得到了“拯救”或起码大幅度的加快了项目进度。这种无与伦比的成就感是无论如何不可能在日常工作中得到的。

或者说，“透支模式”最让人欲罢不能的是，你能真正看到团队的凝聚力。每当这种时候，全体组员精力高度集中，保持持续沟通，齐心协力通力合作，很快就能突破最大的难题使工作得以顺利完成。撇开其余不谈，仅全体均精力集中一项就能使团队的整体能力提升一个档次。作为组员，在这样一个高效的团队中工作是十分激动和兴奋的。但是我们都知道，这样的兴奋比较难（虽然不是完全不可能）持久。所以偶尔还是需要开启一下全组的”透支模式“，让大家回炉一下这种“给力”的感觉。

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

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

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

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

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

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

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

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

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

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