运维与生活
PDF拆分不堪重负的团队
两支五人团队与一支十人团队截然不同。
托马斯·A·利蒙切利。
Queue 欢迎专栏作家托马斯·利蒙切利回归！您可能还记得 Tom 从 2015 年到 2020 年的专栏“Everything Sysadmin”。他的新专栏“运维与生活”从本期开始，将从独特的个人视角关注 DevOps 和 IT 运维。
一位朋友来找我寻求建议。他的 SRE 团队士气低落。人们精疲力竭。离职率很高。离职人员经常以压力过大为由。有人担心他们补充人员无法持久。
然后托德（化名）告诉我最令人震惊的事情：团队工作过度，但他的老板却不允许他再招人。
他解释的方式让我觉得，他认为这是世界历史上第一次增加人手的请求被拒绝。我尽可能温和地告诉了他这个消息。
擦干眼泪后，我试图用我最了解的方式重新聚焦谈话。我问了一个工程师最有力的问题：“你试图解决什么问题？”
他回答说：“如何说服我的老板雇更多人！”
“是的，”我回答说，“但你试图解决什么问题？”
他思考了一下，说：“士气低落？压力过大？每个人都超负荷工作，以至于什么都做不成？”
是的！现在我们谈到点子上了。雇更多人是一种解决方案，而不是问题。通过将问题重新定义为士气和压力问题，我们打开了许多可能的解决方案的大门。
问题
通过讨论这个问题，我对团队有了很多了解。
他的团队负责管理六个系统：物理基础设施（电线、电缆和物理计算机），以及云基础设施，以及一系列运行在该基础设施之上的应用程序。
新员工入职需要几个月的时间，因为他们要学习各种系统、技术和流程、政策和程序。托德说他们尝试了不同的方法来培训人员、管理文档等等。所有这些都有帮助，但这仍然是很多需要记在脑子里的信息。
对我来说很清楚，团队压力的主要原因是负责太多截然不同的系统。团队成员并没有因为高风险、高压力的工作而感到压力，正如您可能预期的那样。停机时间并不多。然而，人们感到压力是因为他们觉得自己能力不足。六个主要的责任领域意味着，无论你在某件事上变得多么出色，总会有其他领域让你感到尴尬的无知。
简而言之，团队感到不堪重负。这会让人感到压力，导致士气低落。
托德说：“但这都在他们的脑子里！”我同意了。不堪重负是一种感觉，而不是物理问题。如果是物理问题，可以通过手术切除。
心理学家对此的术语是认知负荷：工作记忆资源的使用量。就像计算机因为同时运行太多程序而运行缓慢一样，你的大脑也会不堪重负。
当我与团队成员交谈时，我经常听到诸如“我感觉自己很蠢”或“在我上一份工作中，我是专家，但来这里一年了，我仍然不知道自己在做什么”之类的话。
这些都是非常聪明、经验丰富的工程师，但他们经常贬低自己。他们不仅仅是谦虚；他们真的觉得自己能力不足。
一位团队成员告诉我一些事情，这比任何管理理论书籍都能更好地解释这一点。他说，由于有六个职能责任领域，他从未长时间从事一项任务以精通它。在之前的工作中，他学会了一项技能，然后将这种学习应用于数百个项目。他指出，在学习一项新技能时感到能力不足是正常的，但每次他使用这项技能时，他都会“获得出色完成工作的多巴胺快感”。
在这个团队中，有六个主要责任领域，不断进行上下文切换。每一项任务都会让这位团队成员回到“感觉自己很蠢”的阶段。没有足够的重复来达到“成就感”阶段。没有人想要一份每天都让他们“感觉自己很蠢”的工作。
是的，如果他等得足够久，他会被分配一项任务，让他可以使用他早些时候学到的技能。然而，如果你不使用技能，技能就会退化，所以他会回到“感觉自己很蠢”的状态，再加上他会因为“没有做好笔记”而自责。
工程师经常说他们喜欢学习新事物，但我相信他们真正享受的是展示新知识。为了获得成就感，他们需要在学习新技能后尽快展示出来。在六个责任领域之间不断进行上下文切换意味着多巴胺快感很少。
以前并非总是如此。几年前，团队规模只有现在的一半，责任也只有现在的一半，每个人都更快乐。没有人谈论倦怠。一切都运行得更好。
我的建议很简单：将团队分成两半，让每一半承担一半的责任。
阻力与担忧
托德最初反对这个想法。既然他可以让某些人专攻，为什么要拆分团队？我指出他已经尝试过了，但没有奏效。如果没有来自不同团队的硬性界限，工程师会感到有义务了解并参与团队的所有决策。专家必须参加他们专业领域以外的会议，并承担了解所有其他职能的认知负荷。
不。为了使之奏效，他们需要来自组织边界的硬性限制。
经过一番讨论，我们决定尝试重组为两个五人团队，每个团队负责三个相关领域。这将减轻认知负荷，减少上下文切换，并增加那种重复的可能性，从而带来更多“技能展示”和更少“感觉自己很蠢”。
如何拆分团队
Team Topologies（Manuel Pais 和 Matthew Skelton 著）这本书就如何使用断裂面概念划分团队提出了建议。这是一个天然的接缝，可以很容易地将系统分成两个或多个部分。这些通常沿着业务领域、法规遵从性、变更节奏、团队位置、风险隔离、技术类型或用户角色划分。
在这种情况下，业务功能方面存在明显的天然接缝：应用程序与运行应用程序的平台。基本上，这是沿着架构层拆分团队。
拆分将有几个好处
* 更少的沟通路径。不再是 10 个人试图与 10 个人沟通，大多数沟通将在每个五人团队内部进行，每个团队的技术负责人负责桥接两个团队。
* 更容易达成共识。让五个人达成一致比让 10 个人达成一致更容易。做出决定的人会更专注于问题。这将从决策过程中排除那些不受影响或根本不在乎的人。
* 更高效的会议。邀请参加会议的人越多，会议就越难安排；有人迟到的可能性就越大；有人不专心听讲的可能性就越大，当被问及意见时需要重复信息。
* 每人会议时间更少。较小的团队意味着团队成员将被邀请参加更少的例行会议。
* 重复的可能性增加。如前所述，当我们能够学习一项任务并经常展示该技能时，我们工作得更好。这需要在工作类型中具有一定的重复性。
* 更明确的边界和职责分离。 在一个大型团队中，“大泥球”设计模式似乎更自然地出现。朋友之间违反一点分层有什么关系？另一方面，两个独立的团队被迫更加注重技术领域以及政策和流程中的边界。分成两个团队将成为技术系统（API）之间以及人际接口（约定俗成）之间明确定义的接口的强制性功能。
* 更轻松的领导责任。现在不是一个工作过度的技术负责人，而是会有两个技术负责人，每个人都有更易于管理的责任领域。
* 更多领导机会。一些人员流失是由于感觉晋升空间不足造成的。更多的团队意味着更多的机会。
共享 Oncall
托德担心的一个问题是这将如何影响随叫随到轮换。每 10 周轮到一次随叫随到很棒。团队喜欢每季度随叫随到不超过一到两周。然而，对于一个五人团队来说，团队成员每个季度可能会随叫随到四次，即 20%。这种频率不利于项目生产力。
相反，团队决定采用共享随叫随到轮换。他们将进行交叉培训。每个团队都会编写一份程序手册，其中涵盖大多数警报和问题的第一个现场任务。如果您负责另一个团队的职责而随叫随到，您将接受基本任务的培训，但可以上报给另一个团队。为了减少认知负荷，您无需记住每个任务。相反，所有警报和常见问题都记录在清单中。
您按照清单的步骤操作。如果您到达清单末尾并且警报仍在触发，您可以上报给负责团队。
清单被视为软件：如果您发现任何错误、混乱或不完整的地方，您可以提交错误报告。他们的代码审查流程（github pull requests）将用于建议更改。如果一个团队觉得他们收到的上报太多，他们可以改进文档或流程。因此，存在一个反馈循环，以确保文档和培训保持新鲜和有用。培训新成员基本上包括审查最常见的清单。
重复可能性的增加不仅有助于士气，而且还带来了一些意想不到的其他好处。例如，重复相同或相似的任务为改进流程提供了更多机会。如果您每年执行一次任务并看到如何改进任务，那么几乎没有动力进行这些改进。不值得。如果您每天必须多次执行任务，您将抽出时间来改进流程。重复导致更好、更高效的流程。
挑战与机遇
拆分团队的方法也存在许多挑战。人们必须放弃旧的责任。当您擅长某件事时，将任务交给其他人可能很困难。通才必须选择一个团队或另一个团队，并放弃他们已经发展出专业知识和舒适感的任务。
在团队层面，他们已经习惯的许多现有实践都发生了变化。会议时间表被重新制定。政策和程序发生了变化。
另一方面，也出现了意想不到的新机遇。管理两个较小的团队可能比管理一个大型团队更轻松。甚至有人讨论为每个团队聘请不同的经理。每种类型的团队可能需要不同类型的经理。例如，一个团队在具有运营管理专业知识的经理的领导下可能会做得更好，而另一个团队可能需要具有更多硬件经验的经理。
总结
该团队的士气低落和压力过大是由于成员感到责任过多而不堪重负造成的。10x10 的沟通结构使得难以达成共识，会议太多，每个人都承受着高认知负荷。通过拆分成两个团队，每个团队都可以更加敏捷，这是经理喜欢看到的，并且认知负荷更低，这是团队喜欢看到的。有更多的重复机会，这让人们可以发展技能并展示它们。总而言之，这有助于减轻压力并提高士气。
如果您的团队正在遭受士气低落和压力过大的困扰，请查看团队的认知负荷，审查其来源，并寻找将产生预期效果的实质性变化。解决方案可能不是拆分团队，但这可能正是所需要的。
托马斯·A·利蒙切利是一位国际公认的作家、演讲家和 DevOps 倡导者。他是 Stack Overflow, Inc. SRE 的技术产品经理。他曾在小型和大型公司工作过，包括谷歌、贝尔实验室/朗讯和 AT&T。他的著作包括系统管理员时间管理 (O'Reilly)、系统和网络管理实践（第 3 版）和云系统管理实践 (Pearson)。
版权所有 © 2022 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue 第 20 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
João Varajão, António Trigo - 评估 IT 项目的成功：感知与现实
本研究通过提供对 IT 项目成功的新见解，对实践、研究和教育具有重要意义。它通过报告项目成功（而不仅仅是项目管理成功）扩展了项目管理知识体系，项目成功基于几个客观标准，例如项目后期阶段客户对交付物的使用、客户雇用与项目相关的支持/维护服务、客户签订新项目以及客户向潜在客户推荐供应商。研究人员可以找到一组标准，他们可以在研究和报告 IT 项目的成功时使用这些标准，从而扩展当前对评估的看法，并有助于得出更准确的结论。
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx：真正驱动生产力的因素
开发者体验侧重于开发者的生活体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来推动业务绩效。本文提供了一个理解 DevEx 的实用框架，并提出了一个测量框架，该框架将来自开发者的反馈与他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，让他们了解要衡量什么以及在哪里集中精力以提高开发者生产力。
Jenna Butler, Catherine Yeh - 设身处地为他人着想
新冠疫情在许多方面改变了人们的工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对另一个人无效（甚至对同一个人在第二天也可能无效），我们尚未弄清楚如何准确预测什么对每个人都有效。正如您在此处描述的综合人物角色中看到的那样，有些人与世隔绝和孤独作斗争，很难与他们的团队进行社交联系，或者发现远程团队的混合工作带来的时间压力让人难以承受。另一些人则乐于接受这种新发现的工作方式，享受更多与家人共处的时间、更大的白天锻炼灵活性、更好的工作/生活平衡以及更强烈的为世界做出贡献的愿望。
Bridget Kromhout - 容器无法修复你破碎的文化（以及其他残酷的真相）
我们经常关注技术反模式，而忽略了我们社会结构内部的类似问题。剧透警告：许多看似技术性的难题的解决方案可以通过检查我们与他人的互动来找到。让我们谈谈在与那些被称为人类的讨厌生物打交道时您需要了解的五件事。
© 保留所有权利。