鉴于开发人员如今承受的压力，令人震惊的是倦怠及其危险却鲜有人讨论。以下是一些需要留意的迹象。
译自 Tech Works: How to Identify and Address Burnout on Your Team，作者 Jennifer Riggins 是一位科技文化领域的讲故事者、记者、作家以及活动和播客主持人，帮助分享文化与科技碰撞的故事，并传达我们正在构建的技术的影响。
编者注: Tech Works 是 The New Stack 长期撰稿人 Jennifer Riggins 的一个月度专栏，探讨影响构建和运行这个世界所依赖的软件的人员的工作环境、管理理念、职业发展和科技工作市场。
我们都知道软件工程师非常容易出现倦怠状态，为什么我们这个行业不多讨论一下这个问题呢？
当然，很多科技活动都有关于开发人员倦怠的讲座。但考虑到开发人员面临的日益增加的压力——他们要么面临裁员的威胁，要么因为人员削减而承担更大的工作负担——令人震惊的是，他们的心理健康问题如此少被关注。
倦怠对每个人来说都是不利的: 组织、团队，尤其是个人，后果可能是严重的。例如，经历倦怠的人发生自杀念头的风险会增加五倍。
我们如何在自己和工程团队中发现倦怠的第一个迹象？我们不仅可以提高开发人员的生产力——因为快乐的开发人员是更有生产力的——而且我们可以真正拯救生命。请继续阅读，了解如何提供帮助。
虽然总体倦怠率在上升，尤其是千禧一代，但开发人员倦怠率高达 83%。
"工程师们有很高的薪酬，他们可以在家工作，还可以使用各种先进技术，"G2i 项目主管 Michelle Bakels 在 Developer Health Show 播客中对 Vercel 的 Turbo 开发者体验负责人 Anthony Shew 说。
"我们认为这是一份非常舒适的工作，"她说，"与一些工作相比，的确如此，但这并不意味着它就不难，而且非常消耗精神。在我看来，有时候编码反而是工作中最简单的部分。"
她说，除了编码之外的挑战包括:
- 确定你是否在构建正确的产品;
- 以正确的方式;
- 努力理解目标客户;
- 团队动力学;
- 跨组织沟通和协作。
贝克尔斯继续说，在所有这些背后都是科技行业的"奋斗文化心态"，存在着你想要一周工作 60 到 80 小时的期望。这与研究表明五到六个工作小时有利于组织创造力的结论形成了鲜明对比。"我们没有看到来自其他行业的优秀人士表现出这种行为。"
The New Stack 于 12 月下旬进行的 VoxPop 调查询问读者，他们一天中"表现最佳"时可以编码多长时间。最常见的答复是一半受访者说: 一天三到五个小时。
Shew 是自学成才的软件开发人员，他通过 freeCodeCamp 学习编程，同时还为圣路易斯红雀队打过 AAA 棒球。他和贝克尔斯在 Developer Health Show 上大谈了这两种高压力角色的分歧和共同点。
虽然工程师的工作可能看起来神秘，运动员的努力却是显而易见的，休息和恢复是他们工作的已知要求。发现运动员由于重复性压力而受伤的风险也更容易。
"对于开发人员来说，那种精神压力是你肉眼很难察觉的。因此很难向自己或他人证明，" Shew 说，"要认识并承认你需要花时间补充能量。"
要发现开发人员倦怠的迹象就更加困难了，特别是在远程工作的世界里。即使你以前没有遇到过，要认清自己的这些迹象也是一样困难。
"谈到工程师时，我们就没有做出这种联系，"贝克尔斯继续说。"如果你想成为最好的工程师，就要投资于自己，给自己休息的时间。给自己恢复的时间。要好好吃饭。不要每天都那么艰难。"
是的，科技行业因其福利而闻名，但除了办公室里布满灰尘的乒乓球和足球机之外，大部分额外福利都在疫情期间消失了，或者从一开始就不像看上去那样诱人。
大型科技公司最早采用了无限付费休假制度，但在实行无限付费休假政策的组织里，员工实际上的平均休假天数却更少。可以想见，在工作压力下——认知负荷不断增加——科技工作者休假的时间可能会比以往更少。
"对于倦怠和运动员受伤来说，如果你达到那个临界点，如果只持续很短的时间你就很幸运，" Shew 说。"但在这两种情况下，它们都可能结束事业。"
工程领导必须能够识别开发人员倦怠的迹象，并采取战略来预防它。
一般来说，职业倦怠和压力这种心理障碍会导致以下情况增加:
- 缺勤;
- 拖延;
- 犯错;
- 创造力降低;
- 身体和情绪耗尽。
软件开发人员不快乐的具体症状包括:
- 生产力低下;
- 代码质量低下;
- 动机降低;
- 工作退缩;
- 注意力难以集中;
- 绩效不佳;
- 流程遵从性降低;
- 打算离职。
这首次在 2017 年的一份 Association for Computing Machinery 论文中被意识到，该论文着手研究如何限制开发人员的不快乐——或引发不快乐的负面体验——反过来发现这可以限制倦怠的原因。
该论文提出了大规模混合方法调查的结果和对领导层的建议，因为虽然开发人员不快乐的 10 个原因中有 3 个与个人有关，但大多数是社会技术外部原因:
- 时间压力;
- 糟糕的代码质量和编码实践;
- 同事表现不佳;
- 单调或重复性任务;
- 代码故障原因不明;
- 决策不当;
- 对开发施加限制，如技术和程序瓶颈。
这份症状列表按频率递减排列。该论文假设引起不快乐的主要原因将与人相关，但事实上，技术和流程相关的因素更为普遍。正如我们之前所写的那样，平台工程、自动化和生成式 AI 等趋势的策略可以恰当地应用于减少开发人员面临的这些压力源。
此外，该论文认为，工程领导层应该负责教育开发人员了解这些压力触发因素:"知道可能在短期和长期内导致不快乐的原因，可以鼓励开发人员对同事更加体贴。例如，花点时间考虑一下不让他人清理自己写的糟糕代码，或许是值得的。"
研究人员还引用了一篇之前的论文，发现开发人员情绪好转与代码质量直接相关。
"在对内部团队进行调查后，我和我的合作者发现，在大型全球科技公司 Globant，当软件工程师对工作感到满意时，他们对团队中存在倦怠的感知就会降低，"研究员之一 Bianca Trickenreich 告诉 The New Stack。
2023 年，她和她的团队在 IEEE 上发表了他们关于理解和减少开发人员倦怠的模型。
该论文探讨了组织文化与倦怠之间的关系。该论文证实，一种包容性文化(建立在高度信任、无过错和信息流动之上)会驱动归属感、学习氛围和包容性。
而这三个因素反过来被发现对工作满意度至关重要。SPACE 框架之前曾证明，工作满意度下降是开发人员倦怠的主要信号。
"我们还发现，当人们在一个遵循包容性文化、有学习机会以及感受到归属感和包容性的团队中工作时，他们的满意度会提高。"
自 Trickenreich 的论文发表以来，Google 的 DevOps 研究评估团队将包容性文化列为核心 DORA 指标之一。
那么，工程领导层如何在影响文化的同时，也满足自上而下的需求呢？
"围绕着我们的投资者/股东系统通常都是为了尽可能榨取人们的生产力——这是导致倦怠的根源。因此，优秀的领导者正努力平衡这些压力与他们照顾员工的愿望，"专注于工程团队分析的公司 Multitudes 的创始人兼首席执行官 Lauren Peate 告诉 The New Stack。
"也就是说:我们可以加快构建时间，但公司不会把额外的时间还给开发人员，而是让每个人都多做一些工作。"
另外，随着预算更加紧缩、就业机会减少，科技行业在 2021 年和 2022 年对文化和包容性的拥抱事实上是表演性的。不仅仅是 Twitter/X 取消了员工资源组，Basecamp 也禁止讨论"社会政治";大型科技公司似乎都已远离公司文化这个舞台。
"看到健康和良好文化等话题在当前市场环境中被边缘化也很令人沮丧 - 这又是一个例子，说明它们经常被视为可有可无的东西，"Peate 说。
作为一名工程领导，你可能面临着较少的预算或管理层投资于文化建设的愿望。但已经证明，改善开发人员体验可以提高生产力，进而提高盈利能力。
"就像许多运动队一样，你需要给运动员创造条件，"Retireable 理财建议应用程序的首席技术官 Ian Yamey 在 Leader Chats 播客上说，他也呼应了运动比喻。
Yamey 发现工程领导可以扮演三个角色来帮助开发人员高效交付而不会倦怠:
- 教练: 设定愿景，Yamey 说，通过定义文化(如通过文档和流程来传达决策)来缓解倦怠;
- 经理: 控制时间，通过管理工作量(如通过冲刺)来缓解倦怠;
- 培训师:监控健康状况，通过持续检查(包括一对一会谈)来缓解倦怠。
当然，作为工程师出身的领导层也会想要衡量倦怠，但 DX 开发人员生产力平台的现任首席技术官 Laura Tacho 表示，这是一个挑战，因为倦怠是多方面的。
"这不一定与某人工作的时间量有关，"她在一个与 The New Stack 分享的 Twitter 主题中说。她说，倦怠发生在人们:
- 过度工作。
- 长期处于压力之下。
- 与结果脱节。
- 缺乏对如何分配时间的控制权。
倦怠是一个滞后指标，这意味着它需要时间且难以衡量。Tacho 建议你留意倦怠的前期迹象，包括:
- 缺乏专注时间;
- 优先级频繁变动;
- 在办公时间外工作;
- 没有切实结果的项目;
- 组织内部的额外负担和阻力。
对于任何这些衡量指标，你都应该使用 Jira 等自动化工具与开发人员调查和对话相结合。每家大型科技公司似乎都有自己的做法，但他们似乎都至少进行季度调查。
她说，当倦怠降低时，你可能会发现:
- 更低的流失率;
- 会议参与度更高;
- 更高的员工净推荐值(eNPS);
- 动机增强。
根据这个列表，你可以衡量以下内容:
- 流失率;
- 会议质量;
- 与会者不参与的会议频率;
- 会议中每位队友的平均发言时间;
- 体现满意度的 eNPS 分数;
- 团队提出的计划或质量。
"但最重要的是，要与你的团队讨论这个问题，"Tacho 说。"你表现出的关心会产生很大影响。"