为什么很难改变开发者团队的现状

大公司的故事

欢迎来到 BigCo Inc!

这是你第一天当软件工程师,并且很高兴开始自己的第一个任务。当新同事 Bill 向你展示代码库时,你会时不时注意 Bill 回复手机通知的频率。“你需要休息一下等会再继续吗?”,你问。“不,这种情况很常见,别担心,我已经习惯了——这些都没有那么重要。” 你会感到困惑,但是,虽然电话振动不断在办公桌上嘎嘎作响,但你还是让 Bill 向你展示 BigCo 代码库的内部工作原理。

一年后,你正走向 C 楼,比尔正在那里举办他的告别派对,这时你感觉到口袋一阵阵熟悉的振动。“为什么比尔突然辞职了?他从来没有真正抱怨过任何事情”,你一边想一边心不在焉地将手机静音。这劳累的一周过去了,终于可以回去好好睡一觉了。

当你仍在这家公司工作时,你会听到一群新入职的工程师在结束迎新会的路上兴奋地交谈。

这个小例子解释了习得性无助这一概念:

我们放弃逃避痛苦情况的这一系列行为,是因为我们的大脑在不断被提醒将这种情况设定为无能为力的事情。

在这种情况下,BigCo 的文化已经使不分白天黑夜随叫随到的现象正常化 。虽然对于外部人员来说这是很明显的问题并且急需解决,但内部人员已经放弃了这个想法。他们是被动的,他们甚至可能会自发地解释为什么不能随心所欲做任何事情:“一直都是这样”或“这就是我们确保网站始终运行的方式”。但有一天,他们放弃了。

虽然这个例子侧重于开发人员的经历,但习得性无助也给工程经理带来了一个自相矛盾的挑战:在这种情况下,经理应该深切关注团队的幸福感、参与度和最终的保留率, 但习得性无助的现象却并没有显现出来 他们的报告不会告诉经理随叫随到的体验很糟糕——他们甚至可能一开始会拒绝任何改善这种情况的尝试,因为解决问题会感觉 不自在。

开发者团队中习得性无助是怎样形成的

在我们讨论如何防止它之前,让我们看看习得性无助是如何在开发团队中产生的。

主要有2种模式:

模式 1:与过程相关的习得性无助

在这种情况下,团队需要遵循外部强加或内部强加但没有人能确切记住具体原因的流程。具体示例如下:

  • 工程师需要遵循一个很长的部署清单,或者让他们的部署得到多个委员会(例如安全委员会和 API 标准委员会)的批准。很快,工程师开始自我审查创新想法或告诉其他工程师他们的新功能是否会通过委员会的检查。
  • 假设每个人的工作量都和他们一样多,一位终身工程师正在为团队承担大量的代码审查工作。其他工程师开始抱怨这位工程师对代码审查的速度不快。

模式 2:与复杂性相关的习得性无助

在另一种情况下,无能为力的根源是单一的规模和/或复杂性。没有人真正了解系统的紧急行为。例如:

  • 现有工具是一种温水煮青蛙 的情况。这可能是一个涉及许多手动步骤的发布系统,当代码库是其当前大小的 1/10 时,这个手动系统便开始工作,现在需要维护整个发布团队。矛盾的是,这个团队可能没有时间寻找更新、自动化程度更高的系统。
  • 特别糟糕的技术负债案例,其中一个子系统或一个公共库已经固定。分配到这些组件的工程师逐渐降低解决技术债务的野心,阻止新人解决债务的尝试,并最终要求重新分配到其他地方。
  • 在较大的公司中,经理们只会向他们的团队提出自上而下的要求和压力,而不会停下来了解请求背后的商业原因。在这种情况下,经理放弃了保护团队的注意力免受各种官僚压力的影响。

会导致什么后果?

故事通常是这样的:

  1. 员工加入
  2. 员工面临着习得性无助的第一个来源。
  3. 另一个员工或他们的经理 他们这是这家公司的正常 情况
  4. …许多季度过去了,这种情况会反复重演
  5. 员工辞职,留下目瞪口呆的经理

总之,我们可以把这种辞职 称为千刀万剐 ,这让经理们感到意外。

但是,如果我们采用员工的观点,他们应该在这个过程中更早地辞职,他们留下的主要原因是他们学会了适应无助 ——而不是改善情况甚至将其稳定住。

作为个人贡献者或经理,我们还努力在公司文化中工作并建立良好的文化。习得性无助会导致人类才能的大量流失,我们应该找到与之抗衡的方法。让我们看看我们可以做些什么来检测和避免它。

你能做什么 ?

在采取行动之前,重要的是要意识到这种现象。正如我们在上面所写的,习得的无助往往很难被处于这类环境中的人发现。因此,在接下来的部分中,我们将分享如何检测出习得性无助,以及如何应对。

作为个人贡献者

检测

  • 不要怀疑你的直觉 :回到上面的 BigCo 故事,当你第一次面对这个问题时,更容易做出判断。在这种情况下,嘈杂的 oncall 页面。注意效率低下和感觉不再有用的流程,并尽早做出反应。
  • 退后一步 :稍后,确保你定期评估在贵公司的流程和文化规范背后的“为什么?”尤其要注意周围人认为“显而易见”的内容。例如,每个人都可能认为拉取请求需要超过 3 天的时间才能得到审查,请尝试问自己这是为什么。

解决办法

  • 与您的团队合作实施解决方案 :特别是你在“教”他人接受不好的情况时要更加注意这一点(Bill,在我们的故事中),或者找到改进流程的创造性方法。特别是,像回顾这样的敏捷仪式可以非常有效地提出问题并同意将它们一起解决。
  • 让经理承担责任 :领导者的主要职责之一是为他们的团队创造积极的变革。一旦你发现每个人都处于习得性无助模式的情况,请务必通知经理并持续跟进,直到问题得到解决。将问题从字面上理解为“习得性无助”情况也可能有用。

作为经理

检测

  • 定期参与团队的工作 :按照设计,经理不会参与日常活动(例如公关审查、随叫随到、体验构建系统等)。这既是一个弱点也是一个优势:它会让你与团队脱节,但另一方面,当你重新体验 IC 的生活时,它会给你一个全新的前景。例如,把自己添加到一个团队的值班轮换中,并意识到这是一种糟糕的体验。轮换的人可能已经习惯了干扰,以至于他们不再抱怨它,但是作为“新人”,你很快就会发现问题。
  • 注意行为的细微变化 :这里最有用的提示是,曾经对某个问题非常直言不讳的人停止抱怨。你不应总是将此变化解释为积极的“问题已解决”解决方案。确保你与相关人员或团队达成共识。
  • 衡量 :建立一个习得性无助的常见来源列表(高会议负载、中断的 CI、创建速度过慢、页面杂乱等),并创建一组你定期监控或获取警报的指标。进行客观的测量可以发现异常趋势,否则你会逐渐将其视为“正常”。

解决办法

  • 鼓励工程师拥有自主权 :直接并通过文化规范教导人们,他们是强大的 ,而不是无能为力的,改变和修复糟糕的情况是关键。这意味着欢迎批评并让人们能够解决问题。
  • 宣布流程破产 :并非每个流程都意味着永远存在。例如,你的工程师真的需要为他们合并的每个 PR 填写一份清单吗?你是否仍然需要工程师在 99% 的时间里只确认和静音警报的随叫随到轮换?不打破现状可能更舒服,但更去除无用的过程更有效。
  • 从小处着手,以同理心为导向 :习得性无助的一个令人惊讶的方面是人们太习惯于糟糕的情况,以至于他们最初可能会抵制你想要解决它的尝试。一开始专注于小的、战术上的胜利会有所帮助。你可能还认为这显然 存在问题,但重要的是要重新了解你的团队一直以来的感受。它将帮助你找到更有效的方法来帮助他们。

希望本文阐明了开发者团队中反复出现的问题根源,并为你提供了解决这些问题的几个关键!如果你想了解怎么操作, Okay 可以提供帮助,请点击让我们知道

原文作者 Antoine Boulanger
原文链接 https://www.okayhq.com/blog/status-quo-is-so-hard-to-change-in-engineering-teams#

推荐阅读
作者信息
AgoraTechnicalTeam
TA 暂未填写个人简介
文章
175
相关专栏
资讯
37 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和 Agora 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。