夜猫子计划半年就散：研发不是熬出来的

半年前，朋友所在的公司启动了一个代号“夜猫子”的研发计划。名字起得坦率：鼓励工程师晚上加班，周末也来，用时间换进度。半年后，计划无声无息地散了。没有庆功会，没有复盘文档，连群都悄悄解散了。朋友说，最后一个月，晚上八点后的办公室只剩三个人：一个在刷手机等打卡，一个在改白天根本没想清楚的方案，还有一个是刚来的实习生，不好意思走。

这不是孤例。过去几年，我见过太多类似的操作：把研发当体力活，以为堆人堆时间就能出活。结果往往是，项目没做成，人先散了。研发不是熬出来的，这个道理不新，但总有人不信。

一、夜猫子计划的起点：一个想当然的假设

这个计划的逻辑很简单：竞争对手六个月上线，我们三个月就得做出来。正常工作时间不够，那就延长。晚上加三小时，周末加一天，一周下来多出近三十个小时，相当于多出将近一个工作日。听起来很合理，对吧？

但这里有个隐蔽的假设：研发产出和投入时间成正比。这个假设在流水线上或许成立——多拧一小时螺丝就多拧六十个。但在研发里，它不成立。研发的本质是解决问题，而解决问题的效率取决于认知状态。一个疲惫的大脑，写出的代码可能白天两小时就能改完，晚上却要花四小时，还埋下三个新 bug。

我见过一个具体的例子。某团队为了赶一个版本，连续三周晚上加班。结果版本发布后，线上事故率是平时的两倍多。事后复盘发现，大部分问题出在晚上十点后提交的代码里——那些代码逻辑绕、注释少、边界条件没考虑。团队花了两周修 bug，比当初“省”下来的时间还多。这就是典型的负反馈：加班赶工，产出质量下降，返工又吃掉更多时间，最后只能继续加班。循环一旦形成，就很难停下来。

二、疲惫的大脑写不出好代码

有人可能会说：那我们就安排简单任务在晚上做，复杂的留到白天。听起来聪明，但实际操作中很难区分。研发任务很少是孤立的，一个看似简单的接口改动，可能牵扯到缓存策略、并发安全、历史数据兼容。你以为晚上能轻松搞定，结果一动手才发现到处是坑。而疲惫状态下，人倾向于选择最直接的路径——先让它跑起来，至于以后会不会出问题，明天再说。这种“明天再说”的债务，累积起来就是技术债。

更麻烦的是，疲劳会降低人的风险感知能力。白天你会想：这个改动会不会影响其他模块？晚上你只想：赶紧提交，回家睡觉。于是，本该写的测试跳过了，本该 review 的代码直接 merge 了。这些省略在当下看不出代价，但它们在系统里埋下隐患，等到爆发时，往往已经很难追溯。

有个做后端的朋友跟我讲过一件事。他们团队曾经为了赶一个功能，连续两周晚上加班。功能上线后看起来一切正常，直到一个月后的一次流量高峰，系统崩了。排查发现，问题出在当初加班时写的一段缓存逻辑：为了省事，缓存没有设置过期时间，平时流量小看不出来，流量一大，缓存雪崩。修复花了两天，但更贵的是信任——业务方开始怀疑团队的交付质量，后续的需求评审变得格外苛刻。这种隐形成本，加班的时候没人算得进去。

三、加班文化赶走的是最不需要赶走的人

夜猫子计划还有个副作用：它筛选出了一批“能熬”的人，却赶走了一批“能想”的人。能熬的人未必是最有创造力的，但一定是最能忍受低效的。而那些对效率敏感、对技术有追求的人，往往最先离开。因为他们清楚地知道，长期加班意味着什么：没有时间学习新东西，没有精力反思和改进，只能在低水平上重复劳动。

我观察到一个规律：一个团队开始常态化加班后，三个月内通常会走掉一两个核心成员。这些人离开时往往不会大吵大闹，只是安静地提离职，理由写“个人发展”。但私下聊天时，他们会说：我不想把时间耗在无意义的消耗上。他们的离开不会立刻让项目停摆，但会带走一些看不见的东西——对系统的深层理解、对历史坑的記憶、以及团队里那种“有问题可以问他”的安全感。新人补进来，需要时间，而加班文化下，没人有时间带新人。于是新人成长慢，老人更累，恶性循环。

更讽刺的是，很多公司一边加班，一边抱怨人才流失。他们没意识到，加班本身就是人才流失的原因之一。你要求员工用健康换进度，员工就会用脚投票。这不是矫情，是理性选择。

四、研发需要的是深度时间，不是长时间

软件研发有个特点：它的核心产出是决策和设计，而不是敲键盘的时长。一个关键的架构决策，可能只需要两小时高度专注的思考，但它带来的影响远超两周的机械编码。问题是，深度思考需要连续、不被打断的时间。而加班文化恰恰破坏了这种时间：白天开会、回消息、处理杂事，晚上好不容易安静了，人已经累了。于是深度工作被挤到角落里，大家只能用碎片时间做表面功夫。

有个做算法的朋友跟我描述过他的理想工作日：上午两小时不看消息，专注推公式或读论文；下午两小时写代码验证想法；剩下的时间处理沟通和杂务。他说，这样的日子一周只要有三天，产出就比天天加班高。但现实是，他的日历被各种会议填满，晚上加班时脑子已经转不动，只能做些边角料的工作。时间花了，进展却慢。这不是他一个人的困境，是很多研发团队的常态。

管理学里有个概念叫“深度工作”，指的是在无干扰状态下专注进行职业活动，使认知能力达到极限。这种工作能创造新价值，且难以复制。与之相对的是“浮浅工作”，指对认知要求不高的事务性任务，往往在受干扰的情况下开展。加班文化盛行的团队，往往浮浅工作泛滥，深度工作稀缺。大家看起来很忙，但忙的是响应、协调、修补，而不是创造。

五、夜猫子计划的终局：无声解散

回到夜猫子计划。它解散的直接原因很简单：进度没赶上，质量还出了问题。但更深层的原因是，团队失去了信心。最初大家还抱着“拼一把”的心态，但两个月后，当发现加班并没有让事情变快，反而让 bug 变多时，士气就垮了。有人开始摸鱼，有人开始投简历，剩下的人也只是在熬时间。计划名存实亡，解散只是走个形式。

朋友说，解散那天，没有人惋惜。大家反而松了口气，终于可以正常下班了。后来，团队恢复到正常工时，用两周时间还清了加班期间欠下的技术债，又重新梳理了需求，砍掉了一些不切实际的功能。三个月后，项目反而上线了。这个结果并不意外：当人不再被疲劳拖累，效率自然回归。而那些被砍掉的功能，后来证明大部分用户根本不需要。

六、为什么“加班赶进度”的幻觉如此顽固

值得多问一句：既然加班低效的证据并不少见，为什么“加班赶进度”的念头还是反复出现？

一个原因是，进度压力往往来自外部承诺，而承诺已经做出，能动的只剩下工时。当交付日期被销售或管理层定死，团队手里最直接的杠杆就是延长工作时间。这看起来是“负责任”的表现，实际上是把决策失误的成本转嫁给执行者。另一个原因是，加班有可见性。晚上办公室亮着灯，周末群里有人回消息，这些信号容易被看见，也容易被当作“努力”的证据。相比之下，减少会议、砍需求、留出专注时间，这些真正有效的做法往往不产生戏剧性的画面，也就难以在组织里获得同等注意力。

还有一个更微妙的原因：加班提供了一种控制感。面对不确定的研发过程，管理者很难精确预测哪天能完成，但可以要求大家多待几小时。这种“至少做了点什么”的感觉，缓解了焦虑，却掩盖了真正的问题——需求是否清晰、技术方案是否可行、依赖是否就绪。用加班代替思考，是最省事的做法，也是最昂贵的做法。

七、如果非要赶进度，该动什么

当然，现实中确实有 deadline，也确实需要加速。但加速的正确方式不是延长工时，而是缩小范围、减少干扰、提高单位时间的认知质量。

具体来说，可以做的有几件事。第一，砍需求。把功能分成“必须有”和“最好有”，只做前者。很多项目延期是因为范围膨胀，而不是因为工时不够。第二，减少并行任务。让一个人同时做三个项目，切换成本会吃掉大量时间。集中精力做一件事，效率反而高。第三，保护深度时间。每天留出两小时不安排会议、不强制回消息，让工程师能连续思考。第四，缩短反馈循环。把大版本拆成小迭代，每两周有可演示的产出，问题早发现早修正，避免最后阶段集中爆发。这些做法不需要加班，但需要管理上的克制和取舍。

夜猫子计划的失败，不是因为团队不努力，而是因为努力用错了地方。研发的产出不遵循线性叠加，疲惫的团队既熬不出创新，也留不住人心。这个道理，希望下一个“夜猫子”启动之前，能有人先想起来。