团队已不堪重负，如何“分而治之”

一个朋友来找我征求意见。他的 SRE 团队士气低落。人们都精疲力尽了。人员流失率很高。人们离开的原因往往是压力大。有人担心他们的回填替换不会持续太久。

然后 Todd（化名）告诉我最震惊的是：这个团队超负荷工作，但他的老板却不让他雇佣更多的人。

他解释这件事的方式给我的印象是，他认为要求增加人手被拒绝，是历史上的第一次。

我温柔擦去他眼中的泪水后，试着用我所知道的最好的方式重新拉回主题。我问了一个你可以问工程师的最有力的问题：“你想解决什么问题？”

他回答道：“如何说服我的老板雇佣更多的人！”

“是的，”我回答说，“但是你想解决什么问题呢？”

他想了想，道：“士气低落？压力大？每个人都超负荷工作，却什么事也做不成？”

是的！现在我们开始进入正题了。雇佣更多的人是一种解决方案，而不是问题。通过重申这个问题是关于士气和压力的，我们就为许多可能的解决方案打开了大门。

通过讨论问题，我对这个团队有了很多了解。

他的团队负责管理六个系统：物理基础设施（电线、电缆和物理计算机），以及云基础设施，外加在该基础设施之上运行的一系列应用程序。

新员工入职需要花几个月的时间来学习各种不同系统、技术和流程、政策和程序。Todd 说，他们尝试过很多不同的方法来培训员工、管理文档等。所有这些虽然都有帮助，但仍然有很多信息需要牢记。

我很清楚，团队压力大的主要原因是要对如此多截然不同的系统负责。如你所料，团队成员并没有因为高风险的工作而感到有压力。停机的次数并不多。然而，人们感到压力很大，是因为他们觉得自己无能。六个主要的责任领域意味着，无论你在一件事上做得多么好，总会有其他未知领域让你手足无措。

简单地说，整个团队都感到不堪重负。这会给员工带来压力，导致士气低落。

Todd 说：“但这都是他们自己的想法！”我同意。不堪重负是一种感觉，而不是身体问题。如果是身体问题，可以通过手术切除。

心理学家称之为认知负荷：工作记忆资源的使用量。就像一台计算机同时运行太多程序而运行缓慢一样，你的大脑也会不堪重负。

当与团队成员交谈时，我经常听到诸如“我觉得自己很笨”或“在我的上一份工作中，我是专家，但我来这里已经一年了，仍然不知道自己在做什么。”

这些人都是非常聪明且经验丰富的工程师，但他们经常会自暴自弃。他们不仅仅是谦虚，而是真的觉得自己不够格。

一位团队成员告诉我的话，比任何一本管理理论书籍都能更好地解释这一点。他说，由于有六个职能领域的职责，他从来没有做过一项足够长的任务来掌握它。在之前的工作中，他学习了一项技能，然后将所学到的知识应用到数百个项目中。他指出，在学习一项新技能时遇到困难是很正常的，但每次他通过使用这项技能而把工作做得更好时，就会产生多巴胺刺激。

在这个有六个主要职责领域的团队中，他们要不断地进行情景切换。每一项任务都会让这个团队成员回到“感觉自己很笨”的阶段。没有足够的时长来达到“成就感”阶段。没有人想要一份每天都让他们“觉得自己很笨”的工作。

是的，如果等待时间过长，之前掌握的技能就会生疏，无限循环，总回到“感觉自己很笨”的状态，再加上因为“没有做足够好的笔记”而自责不已。

工程师们经常说他们喜欢学习新东西，但我相信他们真正喜欢的是展示新技能。为了获得成就感，他们需要在学习新技能后很快地展示出来。六个责任领域之间不断的切换意味着多巴胺的命中率很低。

几年前。团队只有一半的规模，承担了一半的工作量，每个人都很开心。没有关于倦怠的讨论。一切都很美好。

我的建议很简单：将团队一分为二，各司其职。

Todd 最初反对这个想法。如果可以让某些人专门从事某项工作，为什么要拆分团队呢？我指出他已经试过了，但没有用。没有了来自不同团队的硬边界，工程师们觉得有义务随时保持信息灵通，并参与团队的所有决策。专家们必须参加他们专业以外的会议，并承担了解所有其他功能的认知负荷。他们需要来自组织边界的硬性限制。

经过一番讨论，我们决定尝试重新分为两个五人小组，每个小组负责三个相关领域。这将减轻认知负荷，减少情景切换，并增加技术熟练度，从而收获更多的“技能展示”机会，减少“感觉自己很笨”的沮丧感。

《团队拓扑》一书中提供了有关如何使用断裂平面概念划分团队的建议。建立一条天然的接缝，将系统拆分为两个或多个部分。这些通常与业务领域、法规遵从性、变更节奏、团队位置、风险隔离、技术类型或用户角色有关。

这样业务功能之间就存在一条自然的接缝：应用程序与应用程序运行的平台。基本上，这是按架构层次拆分团队。

拆分有以下几个好处。

• 更少的通信路径。与 10 个人沟通不同，大多数沟通将发生在每个 5 人团队内，每个团队的技术负责人再将两者联系起来。

• 更容易达成共识。让 5 个人达成一致比让 10 个人达成一致更容易。做出决定的人会将那些不受影响或根本无关的人排除在决策过程之外。

• 更高效的会议。被邀请参加会议的人越多，日程安排就越困难；有人迟到的可能性就越大；在征求意见时，越有可能因为有人走神儿而需要重复信息。

• 更少的会议时间。更小的团队意味着团队成员被邀请参加更少的会议。

• 增加了熟练工种。如前所述，当我们能够学习一项技术并经常展示它时，工作会做得更好。这需要在工作类型上进行一定程度的重复。

• 更明确的界限和职责分离。对于一个大团队，“大泥球”的设计模式似乎更加自然。朋友之间有点分层违规算什么？两个独立的团队迫使成员注意技术领域以及政策和流程的边界，就像两个定义明确的 API 接口。

• 更轻量的领导责任。现在将有两位技术主管，而不是一位过度劳累的技术主管，每个技术主管的职责范围都更易于管理。

• 更多的领导机会。一些人员流失是因为人们认为缺乏晋升空间。更多的团队意味着更多的机会。

Todd 担心的一个问题是，如何进行值班轮换。10 周中有一周值班，感觉还是不错的。团队喜欢每个季度的值班时间不超过一两周。然而，对于五人团队，团队成员每个季度需要值班四次，即 20%。该频率不利于项目的生产力。

我的建议是，团队进行共享的值班轮换方式。他们会交叉训练。每个团队都制作一本程序手册，其中涵盖了大多数报警和问题的首次现场任务。如果你值班时需要承担其他团队的责任，你会接受基本任务培训。为了减少认知负荷，所有报警和常见问题都记录在检查清单中，你不需要记住每一项任务。你可以按照检查清单上的步骤进行操作。如果检查清单中没有相关操作，你可以将其转交到相关责任团队。

对待检查清单就像对待软件一样：如果发现了错误、令人困惑或不完整的地方，你可以提交 BUG。用代码审查流程（Github 拉取请求）来建议更改。如果团队觉得他们的升级太多的，可以改进文档或流程。这个反馈回路可以确保文档和培训持续迭代。培训新成员时也要包括审查最常见的检查清单。

增加任务重复率不仅有助于提升士气，而且还有一些意想不到的其他好处。例如，重复相同或类似的任务有助于改进流程。如果你一年只执行一次任务，就没有什么动力去做改进，因为这不值得。但如果每天都必须执行很多次任务，那么你就会抽出时间来改进流程。重复会带来更好、更高效的流程。

拆分团队的方法也存在许多挑战。人们不得不放下过去的责任。当你擅长某件事时，很难把任务交给别人。多面手必须选择其中一个团队，并放弃他们已经具备的专业技能和舒适区。

在团队层面，会议日程会被重新安排，政策和程序也发生了变化。但也出现了意想不到的新机遇。管理两个较小的团队可能比管理一个较大的团队更难。甚至有人讨论过为每个团队聘请不同的经理。每种团队可能需要不同类型的经理。例如，A 团队可能需要一个拥有运维管理专业知识的经理，而 B 团队则需要一个具有更多硬件经验的经理。

团队的低士气和高压力是团队成员感到被太多责任压垮的结果。10×10 的沟通结构很难达成共识，会议太多，每个人都承受着高认知负荷。通过拆分团队，每个团队都可以更灵活，这是经理所喜欢的，而认知负荷更低，是团队所喜欢的。有了更多的重复机会，这可以让人们提升技能并展示它们。总而言之，这有助于减轻压力并提高士气。

如果你的团队正遭受着低士气和高压力的折磨，看看团队的认知负荷，回顾它的来源，并寻找能够产生预期影响的实质性改变。解决方案可能不是拆分团队，但解决方法总是有的。

原文链接：https://queue.acm.org/detail.cfm?id=3570920

声明：本文为 InfoQ 翻译，未经许可禁止转载。