开发人员倦怠——迹象、影响和预防

什么是倦怠？

倦怠是各行各业知识型员工面临的日益普遍且极具破坏性的心理健康挑战。如果不加以控制，倦怠将成为生产力、幸福感和团队成功的隐形杀手。

与其他类型的压力不同，倦怠通常是慢性的，并且与工作相关。倦怠是由未解决的持续性压力导致的，这种压力会让员工感到精疲力竭，无法充分发挥自己的潜力。世界卫生组织表示：

倦怠是一种综合症，被认为是由于未能成功管理的长期工作压力所致。”

倦怠在不同人身上表现形式不同。对许多员工而言，倦怠通常与疲倦、无助、愤世嫉俗以及绩效和动力下降等感觉相关。

世界卫生组织对倦怠的定义指出了倦怠的三个关键维度：

• 精力耗尽或精疲力竭的感觉；

• 与工作之间的心理距离不断增大，或对工作产生消极或愤世嫉俗的感觉；

• 专业效能降低。

软件工程师倦怠有多普遍？

倦怠是工程团队和技术工作者尤其普遍面临的挑战。开发人员经常在快节奏、高增长的工作环境中工作，构建关键任务软件——通常缺乏支持其工作所需的系统、流程和文化。

盖洛普最近的调查显示，大多数员工（约76%）经历过倦怠。更具体地说，28%的员工表示他们经常或总是感到倦怠。不到四分之一的员工认为自己很少或从未经历过倦怠。

在某些行业，例如游戏开发，工程师需要长时间工作，并在严格的截止日期前完成任务。他们经常需要在游戏发布前的最后时刻进行修改，这段疯狂的工作时间被称为“关键时刻”。Rockstar Games 的管理层承认，他们一直致力于营造一种倦怠和艰苦的工作文化。据《时代》杂志报道：

广受欢迎的《荒野大镖客 2》的发行商 Rockstar Games 的首席执行官去年在一次采访中夸口说，公司员工每周工作 100 个小时，以便在预定的发布日期之前完成这款游戏。

混乱的发布计划和部署挫折在软件开发领域普遍存在，令人惊讶。公司严重依赖工程师更快地交付代码并为客户提供价值，但往往缺乏 DevOps 实践来支持他们。相反，开发人员经常面临延迟、部署难题以及组织对其的恐惧和不信任，从而扰乱了团队的工作流程。

这种反复出现的组织障碍会导致长期的挫败感，并最终导致开发人员倦怠。

什么原因导致软件工程师倦怠？

倦怠通常源于组织内部问题，而非个人。许多工程团队未能充分解决倦怠的根源，因为他们专注于解决人员问题，而不是支持他们的系统，或者根本无法支持他们。

根据《Accelerate》（一份以研究为依据的打造高绩效技术团队的指南）显示，开发人员倦怠的六个主要组织风险因素是工作超负荷、缺乏控制、奖励不足、社区破裂、缺乏公平和价值观冲突。

工作超负荷源于对开发人员需要完成的工作数量或质量抱有不切实际的期望。难以实现的截止日期、不准确的项目进度预估以及规划不足，迫使开发人员付出超出身心承受能力的努力。长时间工作、在夜晚和周末加班的开发人员比那些工作与生活平衡的开发人员更容易倦怠。

然而，工作量并非导致倦怠的唯一风险因素。与普遍看法相反，即使工作量均衡的团队仍然可能经历严重的开发者倦怠。每周工作 100 小时的开发者可能会倦怠，但每周只工作 20 或 30 小时的开发者也可能倦怠。

在工作量可控但职场文化不佳的情况下，其他组织风险因素可能会导致慢性压力，并造成不愉快的工作环境。这些风险因素会扰乱个人或团队的发展流程，使工作持续且不必要地变得困难或具有挑战性。

决策过程中缺乏掌控会导致员工与组织使命脱节。当开发人员感到无法影响或参与那些影响他们自身及其工作的决策时，就会滋生不信任，并导致员工与管理者之间的疏离。

例如，开发人员有时被迫使用他们认为无效的工具。从变更审批委员会到代码审查，再到数据请求，开发人员可能会受制于整个堆栈中缓慢的工作流程。在某些组织中，开发和运营部门可能会在没有彼此意见的情况下就团队实践做出决策，从而造成组织紧张。

社区的崩溃也会导致缺乏支持、竞争异常激烈、压力重重的工作环境。此外，骚扰和欺凌会让开发者感到孤立和恐惧。缺乏社区支持或公正的反馈，开发者必须应对额外的压力，从而降低他们的生活质量。

缺乏公平（决策缺乏公平）和奖励不足（缺乏积极的强化和反馈）也会让开发人员感到无法控制自己的工作和结果。

依赖指责而非组织学习的文化会导致公平和认可的缺失。组织有时不去解决系统底层的缺陷，反而将诸如代码缺陷、变更失败或错过截止日期等工程难题归咎于开发人员，并羞辱他们。

最后，价值观冲突会导致组织、团队和个人价值观不匹配，从而造成长期压力。例如，一位重视个人隐私的广告追踪软件开发人员，可能会因为个人价值观与公司使命之间持续不断的拉锯战而精疲力竭。

开发人员倦怠的代价是什么？

斯坦福大学的研究人员估计，职业倦怠每年导致近 1900 亿美元的医疗保健费用，并导致超过 120,000 人死亡。

除了医疗保健成本外，倦怠还会导致生产力下降、病假增加、昂贵的残疾以及人员流失。据估计，职场压力每年给美国经济造成超过5000亿美元的损失。研究人员认为，每年因压力和倦怠而损失的工作日接近5.5亿个。

对于工程团队而言，开发人员倦怠会导致交付速度变慢、代码质量下降、项目成果不佳以及人员流失率上升。从长远来看，倦怠还会抑制创新、创造力和组织学习。

管理人员如何发现开发人员倦怠的迹象？

重要的是要理解，人们对倦怠的反应各不相同。员工可能同时出现几种症状，也可能一次只出现一两种。有些员工主要出现精神症状，而另一些员工则经历生理和身体上的变化。

还要记住的是，倦怠并非一种二元状态。相反，员工会根据不断变化的环境和工作量，沿着“倦怠梯度”上下波动。

倦怠的心理和情绪症状包括：

• 疲倦或精疲力竭：您感觉情绪过于疲惫，无法全身心投入工作或与同事相处。

• 愤世嫉俗或消极：您认为自己的角色越来越紧张和令人沮丧。

• 疏离感和疏离感：你感觉与同事和公司使命疏远。你对工作感到“麻木”。

• 绩效或生产力下降：您无法按时有效地完成任务。您的工作质量明显下降。

身体症状也很常见。经历倦怠的开发人员可能会发现自己比平时更加​​疲惫不堪，还可能出现失眠。他们还可能经常头痛、食欲不振、胃肠道问题或头晕。

您能通过指标和数据源检测倦怠吗？

通过更仔细地观察他们的 DevOps 指标，团队可以发现倦怠、开发人员沮丧和部署痛苦的早期迹象。

团队应该留意那些表明他们的工作不必要地具有挑战性或难以完成的迹象。他们应该留意那些表明他们的工程系统（即组织工作流程和流程）在为开发人员提供快速反馈、避免延误和避免繁琐工作方面效率低下的迹象。

较长的交付周期、较低的交付频率以及较低的代码量都可能导致开发过程中出现摩擦。在这种情况下，工程师可能会遇到阻碍和瓶颈，从而扰乱他们的开发流程。

在2014年的DevOps企业峰会上，Blackboard前首席架构师David Ashman回忆起他的工程团队如何因技术债务的不断增加而变得缺乏敏捷性和停滞不前。Ashman的警示信号是代码提交数量的显著变化。

[代码库] 增长速度如此之快，以至于它正在变成一个庞大的产品，具有如此多的复杂性，如此多的难以克服的债务，以至于我们在开发和运营中都遇到了问题，发布时出现重大故障，开发人员花费太长时间才能开发出这些产品。

这样的挑战可能会让开发人员难以实现他们的目标，与系统抗争，并可能不得不花更长的时间来克服它。

团队还应注意高工作量和混乱日程安排的迹象。长时间的会议会让开发人员无法专注于有意义的工作，并使他们的一天变得支离破碎，最终导致他们对日常工作感到不满。工作日投入的时间减少，而晚上和周末投入的时间增加，会使团队面临倦怠和工作与生活失衡的风险。

团队长时间以超过 100% 的效率运行（不间断或停机）即使是最高效的团队也会精疲力竭。代码量（以拉取请求和提交量来衡量）可以作为工作量的一个近似值。

与其他工程指标类似，背景也很重要。了解团队和个人的日常生活，才能更清楚地了解情况。没有单一的“倦怠”指标。相反，团队应该依赖几个衡量团队挫折感和痛苦的指标。

如何防止开发人员倦怠

避免倦怠需要团队减少“救火”、减少辛劳和增加负担。目标应该是减轻部署的痛苦，确保工作从代码到生产的快速流畅，并营造一种学习、心理安全和公平的文化。

首先要改进组织的 DevOps 实践。根据Accelerate的说法：

倦怠是可以预防或逆转的，而 DevOps 可以提供帮助。组织可以通过营造支持性的工作环境、确保工作有意义以及确保员工理解自身工作与战略目标之间的关联，来改善导致倦怠的因素。

对 DevOps 的投资可以增强组织的开发者体验，改善日常工作。从长远来看，更完善的 DevOps 可以最大限度地降低导致开发者倦怠的几个关键风险因素。

为了防止倦怠，团队首先应该秉持持续改进的原则。持续改进是精益方法论的核心理念，它主张通过持续的衡量、学习和实验，逐步提升组织的绩效。它营造了一种衡量和改进日常工作的文化，识别潜在的开发痛点，并确定修复的优先级。

其次，团队应该营造一个优先考虑心理安全的环境。他们应该为工程师提供必要的安全感，让他们能够进行实验并从错误中学习，而不是互相指责。当决策过程直接影响到他们的工作时，开发人员必须参与其中。

第三，团队必须重视开发者体验。这需要团队能够快速反馈，最大限度地减少挫折，并降低开发者的恐惧感。

具体来说，组织可以通过提供护栏来改善工作流程，消除部署带来的恐惧和痛苦，从而减轻慢性压力。当开发人员拥有自动化测试和环境、用于性能可视化的遥测技术、用于隔离故障的松耦合架构以及用于快速回滚的版本控制时，他们可以快速自信地更改代码。团队还可以定期处理技术债务，以避免开发停滞和恐惧。

混合工作或远程工作能帮助防止倦怠吗？

随着世界努力从办公室工作转向远程办公或混合办公，工作场所也在迅速变化。这种巨大的转变可能会改变团队识别和预防倦怠的方式。

远程工作减少了通勤时间，让员工能够更好地掌控自己的日程安排。他们受益于更大的灵活性，可以花更多时间陪伴家人朋友，或从事工作以外的活动。

远程办公还能减少干扰，让开发者有更多时间专注于有意义的工作。开发人员更少受到同事的拍肩和开放式办公室的干扰。

远程办公和混合办公模式虽然可以消除某些压力，但也可能会带来新的压力。员工可能会面临一些不熟悉的挑战，例如缺乏与同事见面的时间，以及工作与生活的界限变得不那么严格。如果没有文化上的改变来适应新的工作环境，新近远程办公的团队更容易倦怠。

转向远程办公的工程团队在过渡期间也可能会面临 DevOps 问题。他们需要应对新的需求，尤其是在硬件和团队沟通方面。

为了成功过渡，团队应该密切关注开发流程的变化，以确保他们的工具和实践在新的工作场所仍然有效。如果出现问题，他们应该采用新的工具和实践，以更好地适应异步通信和远程开发。