团队规模问题，重现

几年前，我在另一个博客上写了一篇文章“为什么团队规模很重要”。 那篇文章早已不复存在。 我解释说，团队中的沟通路径数量不会随着团队规模的增加而线性增加。 当团队呈线性增长时，团队沟通路径会平方 。 这是计算值，其中N是团队人数：Communication Paths =（N * NN）/ 2。

• 4人，（16-4）/ 2 = 6
• 5人，（25-5）/ 2 = 10
• 6人，（36-6）/ 2 = 15
• 7人，（49-7）/ 2 = 21
• 8人，（56-8）/ 2 = 24
• 9人，（81-9）/ 2 = 36
• 10人（100-10）/ 2 = 45

这就是沟通路径的数量之所以重要的原因：我们需要能够依靠我们的团队成员来交付。 通常，这意味着我们需要了解它们的工作原理。 交流路径越多，团队可能就越难理解谁在做什么和何时做。

当团队成员配对，蜂拥而至或暴民时 ，他们就会有频繁的互连点。 通过共同努力，它们减少了必要的通信路径。 如果团队骚动，也许您可​​以拥有更大的团队。 （我敢打赌，那时您不需要更大的团队。

如果团队成员单独工作，那么每天站起来也可能会解决“谁在做什么，何时何地以及在哪里做”的问题。 而且，从事个人工作的人越多，站立的时间就越长。

现在，考虑一下团队合作得很好的团队。 他们多大？ 在我的职业生涯中，我一直在团队中以更快的吞吐量交付完成的功能。 这些团队中的每一个都是4-6人。 也许就是我。 （这些团队中的许多团队都有某种形式的经理，可以保护我们免受管理层造成的混乱。）

我已经完成了数百人的成功计划。 许多球队是4-6人。 我们的程序团队（核心和软件程序团队）接近10人。

10人或更多的问题是您有一个委员会。 委员会很少提供价值。 哦，我敢肯定，您已经看到了委员会的价值，但这需要大量的工作。 我最经常看到的是，委员会的成员没有能力做出决定或不同意整个工作的前提。

在最近的敏捷路径播客（ 关于安全性的回顾 ）中，有一个地方我对团队规模有些狂热。 播客主持人约翰提到了一个30人的团队。

我尚未有30人完成任何工作。 我参加过30人的委员会，然后离开会议室。 我参加过25-400人的计划 ，我们在较小的团队中工作并完成工作。

约翰的例子是，“我们需要一支团队来完成这一特定功能。 我们需要一个定价人员，等等。” 这是一个很好的例子，说明程序结构将如何帮助功能团队交付产品 ，而不仅仅是功能。 我还没有看到一个自组织程序，但是也许您有。

您如何才能成为一个能够在产品级别进行自我组织的组织？ 这里有几种可能性：

• 人们成为通用专家，因此他们可以为他们所在的任何团队的工作流程做出贡献。
• 团队痴迷于看到自己的工作流程，以继续产生有价值的功能。 （请考虑流动效率 。）
• 组织关注团队级别的协作和适应性，因此团队可以完成重要的工作。

这里没有关于层次的任何内容。 关于MBO并没有任何废话。 管理者改变了他们所获得的回报，这就是他们可以改变企业文化的方式。

是给所有人吗？ 可能不是。 我们都在进行中。

这是我从那集中得出的结论：开始敏捷起来。 您如何为提高工作量做出贡献？ 然后，在团队中工作：如何增加团队的吞吐量？ 如何使您的工作轻松自如 ？ 一旦知道了如何在敏捷团队中工作和工作，组织的下一步是什么？ 对于许多人来说，它是程序管理 ，只有足够的结构可以定期发布产品。

就其自身而言，我不喜欢组织。 我喜欢足够的结构，因此我知道该怎么做才能在最短的时间内提供最大的价值。 对我来说，这意味着4-6人的团队，没有等级制度。 那是我。 您的里程会有所不同。

对我来说，这就是团队规模很重要的原因。

翻译自: https://www.javacodegeeks.com/2017/04/team-size-matters-reprise.html