在这个行业待久了，慢慢习惯了一种很矛盾的氛围：大家一边抱怨加班，一边又默认它是正常的。

加班到底意味着什么？

在我看来，它既不是能力的证明，也不应该成为团队运转的常态。更多时候，其实是问题的结果。

这些问题通常不是发生在最后一公里的开发环节，而是更早之前就已经埋下了伏笔。需求不清、反复变更，节奏缺乏边界，优先级随时被打破，技术债长期得不到治理，这些因素叠加在一起，最后自然会以加班的形式体现出来。表面上看，是开发在多付出时间，实际上，是整个系统在向下游转移成本。

但真正让问题变得更复杂的，有时还有另一种更隐性的压力：当“别的部门都在加班”的时候，你很难独善其身。

经常会听到类似的话：

“测试都在等结果呢，你们要支撑好！”
“隔壁团队天天干到 11 点，不跟上是不是不太好看？”

慢慢地，加班就不再只是业务问题，而变成了一种“组织氛围”。哪怕你的节奏本来是健康的，也会被这种氛围一点点带偏。我都开始怀疑：是不是不加班才是不正常的？是不是早点下班反而显得不够投入？

有一个名词可以解释这一现象：群体一致性陷阱。大家并不是因为真的需要加班，而是在彼此影响中，把加班变成了一种默认选择。一旦这种共识形成，想要改变，成本就会变得非常高。

我不太认同一个简单粗暴的逻辑：只要结果出来了，加班就是值得的（诚然，去年部门的一些成果确实是加班换回来的，甚至还提前完成了）。因为这种逻辑忽略了一件更重要的事情：这个结果是如何被生产出来的。如果一个团队必须依赖持续的高强度加班，才能维持基本交付，那本质上并不是在高效运转，而是在用人力对抗系统问题。

加班之所以在很多团队里挥之不去，很大程度上是因为它太“容易”了。相比于优化流程、重构系统、建立规范、提升团队能力，这些需要投入时间和精力的长期工程，加班几乎是一个立刻见效的解法。不需要改变任何结构，只需要多投入一些时间，看起来问题就被解决了。

但这种“解决”，是有代价的，而且会被延后兑付。如果一个团队长期依赖加班来完成工作，那它透支的从来不只是员工的时间，还有未来的稳定性和可持续性。真正有韧性的团队，往往不是最拼的那一群人，而是那些在复杂环境下，依然能够保持节奏、控制边界、稳定交付的团队。

当然，我不认为一个成熟的团队应该单纯的以“减少加班”为目标，而是应该建立一种更健康的节奏感。需求有边界，版本有节奏，优先级稳定，时间可被预期。即便在某些关键时刻确实需要加班，那也应该是短期的、可解释的，并且在事后能够被复盘和优化，而不是一遍又一遍地重复。

部门里我去年的加班数据也是靠前的，但我从来不排斥加班，加班本身也不是什么大问题。但为什么加班会变成了常态化，或许值得我们进一步深思。

当我们开始不再用加班数据去评价一个团队，而是去看它是否能够在正常节奏下持续产出结果，很多事情反而会变得更清晰。

这可能才是走出加班文化的起点。