作为管理者，为什么我痛恨加班

最新推荐文章于 2025-12-03 22:59:33 发布

原创最新推荐文章于 2025-12-03 22:59:33 发布 · 1.2k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#架构

团队有个同学，每天工作时长很长，周末还不断有加班，而实际的交付价值并没有很明显。在打绩效的时候，我陷入了“功劳”和“苦劳”选择的困境，最终我还是坚持没有予以奖励。因为，苦劳不值得提倡。

在竞争白热化的互联网电商领域，“快”似乎是压倒一切的准则。为了快速响应市场、抢占先机，加班似乎成了许多技术团队无法摆脱的宿命。然而，作为团队的管理者，我始终坚信一个观点：持续的、被动的加班，不是团队拼搏的象征，而是管理失效、流程混乱和技术债繁重的危险信号。 它像一种慢性毒药，悄无声息地侵蚀着团队的效率、创造力，最终损害工程师的身心健康和公司的长期竞争力。

一个长期依赖加班来完成任务的团队，必然会陷入具体事务的泥潭而缺乏深度思考。当工程师的精力与心力被无休止的工作榨干，ta不可能写出优雅、健壮的代码，更不可能迸发出创新的火花。

为何非要加班

加班是一种结果，而非原因。简单地将问题归咎于“任务太多”或“人手不够”是不对的。通过我的经验，我将这些根源归纳为四大类：管理规划失当、技术债繁重、流程协作低效以及团队文化扭曲。

1. 管理规划失当：失控的源头

这是导致加班最直接、最普遍的原因。当源头的水龙头没有关紧，下游再怎么努力地“舀水”也是徒劳。

需求的“无底洞”与价值失焦：很多团队陷入了“功能工厂”的模式，产品方、运营方提出的需求，不经严格的价值评估和思考就照单全收。技术团队变成了需求的被动接收者，缺乏与需求方或主管讨论，更遑论向上挑战和提出更优解。结果就是，大量低价值甚至伪需求占用了宝贵的研发资源，导致工作量无序膨胀。
“拍脑袋”的排期与不合理的期望：在激烈的市场竞争压力下，项目上线时间常常由业务或市场目标倒推而来，而非基于对技术复杂度和工作量的科学评估。在向上沟通时，可能因为信息不对称或缺乏勇气，接受了不切实际的排期。这种“军令状”式的排期，最终会以牺牲代码质量和透支团队精力为代价，将压力无情地传导给一线工程师。

2. 技术债台高筑：越走越慢的“泥潭”

技术债就像信用卡的欠款，短期内似乎能解决问题，但长期的利息（维护成本）会高到让你窒息。

腐化的架构与脆弱的系统：为了应对早期业务的快速上线，许多系统在设计之初就埋下了隐患。随着业务变得复杂，系统模块之间耦合严重，“牵一发而动全身”。修改一个看似简单的功能，可能会引发一连串的回归测试和意想不到的Bug。团队的大量时间不是在开发新功能，而是在“救火”，不断地解决线上问题或者为历史问题打补丁，效率极其低下。
基础设施薄弱，自动化程度低：缺乏高效的CI/CD（持续集成/持续部署）流水线，发布一次版本需要数小时甚至半天的人工操作；自动化测试覆盖率不足，每次上线都依赖大量手动回归测试。这些工程效率上的短板，直接导致了研发流程的冗长和不稳定，占用了大量本可用于创造性工作的时间。

3. 流程协作低效：无处不在的“摩擦力”

一个项目从需求到上线，涉及产品、设计、前后端、测试等多个角色。不清晰、不顺畅的协作流程，会产生巨大的“摩擦力”。

职责边界模糊，沟通成本高昂：需求文档语焉不详，技术方案评审流于形式，API接口定义反复变更……这些问题导致工程师在开发过程中需要不断地沟通、确认，甚至返工。跨团队之间的信息壁垒，使得本应顺畅的协作，变成了充满等待和误解的“传话游戏”。
瀑布式的割裂而非敏捷的协同：虽然很多团队号称在实践“敏捷开发”，但实际上仍然是“伪敏捷”。产品、开发、测试之间是割裂的、线性的交接关系。开发在项目后期才看到完整的测试用例，测试在最后关头甚至是上线后才发现严重的设计缺陷。这种模式导致问题在流程的末端集中爆发，唯一的解决办法似乎只剩下“大家加加班，冲刺一下”，或者一群人大吵一架，然后加班解决，毕竟“开发总是有办法的”。

4. 团队文化扭曲：被动加班的“温床”

错误的文化导向，会形成一种强大的气场，让身处其中的每个人都身不由己。

“表演型”加班与内卷文化：在一些团队里，下班时间的长短被错误地等同于努力程度和贡献度。领导不走，员工不敢走；同事都在，自己不好意思走。这种“表演给领导看”的加班文化，制造了一种“谁不加班谁就不努力”的虚假繁荣，员工们耗费了时间，却没有产生实际的价值，形成了典型的“表演”。
对问题容忍，缺乏复盘改进：项目结束后，团队立刻投身下一个项目，对于过程中暴露出的问题（无论是技术、流程还是协作上的）缺乏系统性的复盘和跟进。结果就是，同样的“坑”反复地踩，同样的错误反复地犯，团队的能力水平在低效的循环中停滞不前。

怎么破

1. 治本于源：重塑管理与规划模式

推行“价值驱动”的需求管理机制：
- 建立需求价值评估模型：联合产品、业务部门，建立一套清晰的需求评估标准，确保每一个进入研发流程的需求都是经过深思熟虑、能带来明确价值的，而且要明确这是临时方案还是长期方案，避免加班付出的人力付之东流。
- 技术深度参与前期决策：要求技术负责人从需求萌芽阶段就介入讨论，从技术可行性、实现成本、长期影响等角度提供专业意见，将问题扼杀在摇篮里。
- 赋予团队“挑战权”：在文化上，鼓励工程师对需求的合理性提出疑问，营造“我们共同为产品最终成功负责”的氛围，而不是简单地执行命令。
倡导“科学务实”的排期与预期管理：
- 基于数据进行排期：引入故事点、团队速率等敏捷估算工具，基于团队历史数据进行项目排期。对于全新的、不确定性高的项目，要预留充足的缓冲区间。
- 透明化沟通风险：作为开发者，尤其是PM、管理者，要主动、透明地向上级和需求方同步项目风险和真实进度，用数据和事实去争取更合理的排期，以此来实现预期管理。

2. 强健筋骨：系统化偿还技术债与提升工程效率

将“偿还技术债”制度化、常态化：
- 设立固定的“重构预算”：在每个迭代周期中，明确划拨出20%的研发资源，专门用于代码重构、架构优化、老旧系统升级等工作。让还债成为计划内的工作，而不是遥遥无期的“以后再说”。
- 建立技术债看板：将识别出的技术债进行记录、分类和优先级排序，使其成为一个透明的、可管理的对象，并纳入团队的研发规划中。
大力投资“工程效率”：
- 打造自动化“高速公路”：投入资源建设和完善CI/CD、自动化测试、一键部署、监控告警等基础设施。目标是让“提交代码”到“安全上线”的过程尽可能地自动化、快速和可靠。这些前期投入，将在未来的无数个日夜中，为团队节约下宝贵的时间。

我刚进入现在公司的时候，每次发布都要SRE逐个手动去Jenkins里面操作。对于一个复杂的电商系统，一百多人的团队，几百个应用，每次发布都靠「一个运维手工」去点击，可想而知这效能得多低，经常是一个运维身后排着长长的队伍等着发布。然后，我第一时间引入自动的CI/CD工具，才解决了这种单线程的低效发布。

3. 文化重塑：激励高效而非耗时

建立“成果导向”的绩效文化：
- 管理者以身作则：作为管理者，要带头准时下班，用行动破除“时长崇拜”。
- 改革绩效评估标准：在绩效评估中，明确强调商业价值、代码的可维护性、技术方案的深度、对团队的贡献等，而不是工作时长。公开表彰那些能够高效完成工作、并帮助团队提升效率的员工。
坚持“复盘驱动”的持续改进文化：
- 坚持复盘：复盘会是有难度的，看起来要花费时间，但是这正是触发团队思考的机会。将项目复盘会坚持下去，复盘会必须遵循“对事不对人”的原则，营造安全的讨论氛围。
- 追踪改进项的落地：复盘的关键在于行动。必须指定明确的负责人和截止日期来跟进复盘中产生的改进项，并在下一次复盘时进行回顾，形成“发现问题-分析原因-制定措施-验证效果”的闭环。