团队规模过大时会发生什么

如何识别问题，并利用全能型技能提高生产力

最近我一直在思考以下几个问题：

1. 什么是团队？
2. 多大算太大，多小算太小？
3. 什么才能算得上是一个任务（mission）？
4. 在 GenAI 时代，如何权衡专家和通才的优缺点？

几年前发生的一件事一直萦绕在我的脑海。有趣的是，这件事没有任何总体规划。然而，凭借一些文化因素，这个故事的发展轨迹非常有趣，它塑造了我的领导模式。从那以后，我一直倡导通过准备环境来进行持续改进，而不是成为一个对所有问题都有最终解决方案的自作聪明的人。

今天我想讲述这个故事，并总结以下几个关键点：

• 通才团队不太可能有内部依赖，这些依赖会充当瓶颈、障碍和单点故障。通才团队的生产力更高，适应能力更强。
• 交接会引入误解、延误、沟通不畅和责任分摊的风险。明确的责任需要知识、授权和责任。对于通才来说，更容易实现这一点。

但正如我们将看到的，通才也并非没有问题。

🤖🚫 注意：此内容未使用任何生成式 AI 创建。此页面仅供人类使用，不得用于机器训练，包括但不限于 LLM。（为什么？）

故事

很多年前，我是一个大型团队的一员。准确地说，有 14 名成员。

问题从第一次站立会议就开始了：我听不懂其他人说的 90% 的内容。我以为是因为我是团队的新成员，但随着时间的推移，我与其他团队成员越来越亲近，我了解到其他人也有同感。

看到有人在站立会议期间明显打哈欠或几乎睡着的情况并不少见。在站立会议的轮流发言中，至少有一些内容对一些人来说是完全不相关且无聊的。

为了缩短站立会议的时间，我们对每个人发言的时间都有限制，并配有手势来提醒发言人时间到了。

我们有 11 名工程师，仍然可以用 2-pizzas 喂饱！规模不是问题。

事实上，恰恰相反：我们时不时会听说一项任务，它从未在站立会议中出现过，也不在 backlog 中！

我们了解到这些幽灵任务是在它们接近完成时或在交付后。

这是怎么发生的？通常，来自另一个团队或组织的其他部门的人会伸出友好的 援手，因为我们有足够的带宽和优秀的工程师，他们通常会尽力帮助。

异步站立会议

后来我们改用异步站立会议。实现方式很简单：每个工作日，Slack 提醒都会弹出一个固定的消息：

1. 昨天你做了什么？
2. 今天你将要做什么？
3. 有任何障碍或者需要任何帮助吗？

每个团队成员都会写一条评论，或多或少与他们在同步（面对面）站立会议上说的内容一致。

这些评论会在一天中陆续出现，有些人经常错过。无论如何，我很少阅读所有评论，因为它们与我正在做的事情无关。

这比每天花 30 分钟（每个人不到 3 分钟）进行每日站立会议的干扰要小，而每日站立会议通常会拖到 45 分钟，有时甚至整整一个小时！

异步报告变成了名副其实的 报告。

站立会议的主要价值是就障碍进行对话，并激发合作的机会。否则，只需在 Kanban 泳道上移动问题并添加评论就足够了。这涵盖了报告部分。当需要对话时，我们错过了对话。

基于关注点的任务小组

我在一次回顾会议上提出了这些问题，EM/PM 表示他们会采取行动。

他们提出的解决方案是将团队分成两半：

• 前端“任务小组”（正如它被称呼的那样）将从事前端工作，基本上是将 Figma 设计转化为可用的 UI。
• 后端任务小组将涵盖从 API 到 CI/CD 以及配置云和运营的其余部分。

这个想法是拥有更小的团队，这些团队可以更快地行动，独立交付，并且彼此之间更相关和更紧密地联系。

我们按技术划分了团队，因为任何与工程师合作过的人都知道，他们可能对他们选择的工具非常虔诚。后端/前端似乎差异足够大，可以证明这种划分是合理的。

假设是，前端开发人员应该足够关心彼此的世界和站立会议报告。同样，后端任务小组应该对听到彼此的消息和协作有一些兴趣和共同语言。

作为奖励，既然任务小组规模更小，他们就可以回到同步站立会议并解锁这些对话。

这个想法听起来很合理，仅仅持续了 5 个工作小时！在下一次站立会议上，很明显两个任务小组之间存在依赖关系。谁会想到呢？😄

无论如何，我们尝试了几个 sprint，直到收到下一次回顾会议的反馈。

流动任务小组

下一次迭代是让一个任务小组的人员参加另一个任务小组的站立会议，当他们觉得这与他们相关或他们有议程要分享时（例如，如果一个前端人员需要与后端人员合作来更改新功能的 API）。

两次站立会议一个接一个地进行，以方便这一点。

正如你可以想象的那样，我们中的一些人始终参加两次站立会议，而另一些人始终承担其中一个前端/后端 bucket 中的任务。

因此，花在站立会议上的总时间实际上增加了，而一些团队成员由于他们的任务性质（这是他们技术专长的函数）而彼此隔离。例如，一个人只使用我们内部的 CSS 框架，几乎不需要与后端任务小组交谈。

我们是一个瑞典团队。效率、实用主义和持续改进已融入我们的文化。我这样说不是为了吹嘘，而是为了阐述我们为何不断努力优化我们的工作，以及领导层如何支持这些实验。

我们个人并不聪明，但我们一起找到了一种通常更明智和更全面的方法。

其他解决方案

在讨论我们最终确定的解决方案之前，我想快速迭代一下我们做过的其他一些实验：

• 将团队分成两半，由共享的 EM/PM 管理： API 作为前端和后端之间的明确抽象。但是，运营（例如 CI/CD 甚至 on-call）主要落在后端团队身上。不公平。
• 创建以交付为中心的临时功能团队： 例如，在前端和后端实施 GDPR 需要来自每个专业领域的几个人。用户跟踪功能也是如此。这些临时功能团队会根据需要出现，并在任务完成后解散。问题是，当每个人都被锁定在某个功能团队中时，很难获得正确的资源。维护功能之后会非正式地占用现在忙于其他任务的资源。
• 聘请顾问来弥补带宽需求的临时高峰： 这有点荒谬，因为团队已经很大了，而且很难证明我们为何需要顾问来增加额外的带宽。高层管理人员反驳说要以更智能的方式利用可用带宽。

到目前为止，我们已经为此挣扎了一年多，虽然有些人已经接受了拥有如此庞大的团队就是这样的现实，但其他人仍然在每次回顾时提出新的想法！

与此同时，公司耗尽了资金（我们之前已经报道过这个故事），正如 Sundar Pichai 所说：

稀缺孕育清晰

解决方案：通才

最终对我们有效的方法是摘掉我们专家的帽子，成为通才：

前端、后端、QA、DevOps 等都是同一结果和影响的不同关注点。

最近的一篇文章深入探讨了为什么将一个角色分解为多个头衔是一个糟糕的想法，它会损害企业（更多瓶颈）和个人（变成只能装入特殊机器的齿轮）。

当然，对于一个一生都在 API 背后工作的人来说，学习 CSS 是一个挑战。

同样，对于一个靠在浏览器 sandbox 中移动 bit 赚钱的人来说，进行云配置的学习曲线也很陡峭。

但随着时间的推移，这并不像我们想象的那么难，因为：

1. 共享的背景和结果： 每个人都知道产品是关于什么的。我们不是从抽象和孤立的角度学习一门新学科。我们只是在学习解决同一问题的不同部分。这种背景使我们能够带来我们已经知道的东西，并好奇地学习我们不知道的东西。一旦删除了这些专家头衔，好奇心和探索的道路上几乎没有任何障碍。
2. 狭隘的需求： 我们不必学习某个特定学科中的所有知识。例如，前端开发人员不必学习所有类型的 CI/CD 产品才能提高生产力。我们有 Travis，只要我们可以忍受团队成员的知识共享会议并阅读 Travis 文档，我们就有足够的生产力，而无需依赖其他人来帮助我们进行 CI/CD，这就足够了。在最坏的情况下，我们可以向团队中更有经验的人寻求帮助，但这并不是遇到问题时的默认方法。我们有访问权限、知识和足够的授权来解除自己的障碍，随着我们学到的越来越多。
3. 动机： 在《Drive》一书中，Daniel Pink 提到了 自主 、 掌握 和 目的 作为保持团队参与的关键要素。虽然专家方法能够实现掌握，但我们通过通才模型实现了所有这 3 个要素。这是 角色与头衔 和 结果与输出 论点的关键所在。
4. 瑞典的工作文化是人人平等的，每个人都受到平等的待遇，但也被期望尽其所能地承担责任。前端开发人员不得不恳求获得云提供商管理员访问权限的日子已经一去不复返了。在新模式中，每个人都有足够的访问权限来拥有自己的交付成果。但这也意味着整个团队都需要提升到理解他们提升访问权限的含义。这创造了大量的协作和知识共享机会，这极大地推动了我的职业生涯。我从我的团队成员那里学到的关于如何维护特定产品的知识比我在硕士学位上 2 年的浅薄作业中学到的还要多。
5. 更好的所有权：在“你构建它，你拥有它”中，我们区分了完整所有权的 3 个要素： 1. 知识： 你知道问题和解决方案空间 2. 授权： 你有权做出改变，而无需请求允许或依赖治理和保姆 3. 责任： 当由于你做出的决定而导致事情变得糟糕时，你必须处理清理工作

新模型建立了明确的所有权，从而实现了更快的交付、更高的质量和总体上更便宜的运营。

这是一个天才的总体规划吗？我不这么认为。资金耗尽了，稀缺孕育了清晰。我们唯一做对的事情是进行开放对话、实验、从这些实验中学习并不断优化我们的工作流程。

公司是否发展壮大并利用这种成功作为新的“Spotify 模型”?

当然没有！😄

没有通用的最佳实践，只有适合的实践。 你应该看看什么适合你的设置，这受到你正在构建的产品类型、你拥有的可用人才、可用预算和大量其他因素的严重影响。

我非常小心，不要将发生在我们身上的事情作为解决所有问题的全球真理来规定。事实上，让我们深入挖掘一下这种工作方式的一些副作用。

副作用

所有的药物都有副作用！这个解决方案也不例外。以下是我们在执行该解决方案 12 个月后出现的一些意想不到的副作用：

1. 一些专家辞职了。 部分原因是冒险进入“另一边”对他们的职业生涯没有太大的意义。令人惊讶的是，我们无需填补这些空缺就能应付。我的理论是，专家的工作并非每天 8 小时都需要。这创造了大量的空闲时间来学习新事物或在获得报酬的同时休息！通才模型最大程度地提高了资源利用率（很抱歉将人称为“资源”，但我从系统工程中借用了这个术语，希望它在下一个项目中更有意义）。高利用率使一些资源变得过于“热门”，无法以可持续的方式进行。正如我们所知，成为通才并不是每个人的菜。这远早于 GenAI 时代。GenAI 可以帮助学习新概念和帮助解决问题。即使有了 GenAI，如果没有适当的摄入控制，这条路线也很容易导致疲劳。幸运的是，我们有 30 天的假期（瑞典的事实标准）和专门的开发时间（可以用来磨练斧头的付费时间百分比），但倦怠的风险仍然非常真实。就我个人而言，我不得不使用一些假期来退后一步、反思并实施个人策略，以使工作量对我来说是可持续的。但是这个解决方案中没有任何东西可以促进这一点。事实上，它的设置是为了最大限度地提高生产力和效率。
2. 我们没有我们想要的那么深入。 前端开发人员在给定的日子里使用 3 种语言：JavaScript、CSS、HTML。通常，人们使用其他编译成这些语言的语言：TypeScript、SASS、JSX/TSX。然后是测试框架、SSR（服务器端渲染）、图标库、字体等。这个关注点足够大，可以让某人忙上好几年。再加上 CI/CD、Kubernetes、Istio 和 on-call 职责，你就得到了一项令人精疲力竭的工作。当然，资源利用率很高，每个人都可以完成很多工作，但这也意味着更多的上下文切换和更少的深入工具箱的机会。

我想 1 和 2 是同一枚硬币的两面。但是，考虑到加速增长、更好的利用率和总体自主性，如果我处于类似情况下，我会再次选择此解决方案。YMMV。

你是否有类似的设置经验？你会在这篇文章中添加什么，使其对可能遇到这篇文章的其他人更有用？

如果你觉得这篇文章有见地，请在你的圈子和社交媒体上分享它，以激励其他人。

总结

糟糕的站立会议仅仅是一种症状。T 根本原因是缺乏兴趣和理解。

专家团队没有共同的语言和共享的目标，因此很难进行对每个人都有意义的站立会议。

另一方面，通才团队有共同的语言和兴趣来填补知识空白。

无论什么对你有效，文化的一个关键要素是愿意尝试和不断改进。即使你的最终状态可能与本文中的故事不同，这一部分也是不容谈判的。