击溃官僚体系

马云都带人去了北欧Supercell，学习所谓的“大架构”，据此调整阿里巴巴的组织结构，以避免大公司常见的部门与部门争夺资源，不同的小组做同样的事情。

很多创业公司在团队管理上，都不愿意继续走大企业、大机关那种官僚层级的管理模式，希望能采取更分散、团队更自主的管理模式。一方面，大家的兴致更多在市场、产品上，对内部行政管理实在不愿意搞得那么重；另一方面，《失控》等理论也鼓励了大家尝试分散化的管理方式。

成长的烦恼

Hudl公司成立了几年后，到2011年1月时，产品团队大概有20人。在团队里，大家不用担心谁干得多、谁干得少，也不用担心发生重复劳动、消耗无用功的情况。虽然团队同时在几个方向上进行开发，但是有的方面，比如吸引用户、突出工作重点、提高用户注册量等，都做得不错。团队虽然执行力很强、动作很迅速，但是随着产品用户规模的扩大，我们还是做不到高效地开发出高质量的产品。

在此之后，我们的团队人荡20人慢慢增加到120人。在这个过程中我们遇到了很多管理上的阵痛，不同部门间开始互相扯皮、推诿。这些问题搞得我们焦头烂额，于是我们开始寻思着，应该改造团队的结构，真正解决这些问题。但怎么才能确保我们的团队规模和发展速度同步增长？在减少公司内部层级的同时，怎么才能保存迅速反应的能力？怎么才能让团队在产品上投入足够的关注度和精力？

为了解决这些问题，我们开始调整团队的结构。调整的基本思路就是两点：团队自主管理，同时保持高工作效率。

小分队：人人都是解决问题的特种兵

在我们产品团队，最基本的一级是小分队，小分队由5到8个人组成，具有完整的职能，小分队完全自治，自主运行。大部分小分队的主要工作是开发Hudl的某个具体功能，并按他们自己的节奏进行开发和。

小分队可以选择他们觉得最好的工作方式。比如有些小分队的成员可以选择在不同地方工作。在我们这里，有的小分队里，有4个人在4个不同的地方，剩下的人在公司办公室。大家在不同的地方，用各种协作工具组织起来，保持团队成员之间流畅的沟通。

我们也不指定产品负责人，因为我们认为团队每个人都应当对产品的功能负责，确定产品的指标，每个人都需要参与用户调研，以及其他跟产品开发相关的工作。

我们鼓励敏捷开发、快速迭代，但是我们不会对小分队提出具体的要求。如果小分队想尝试新的方式解决问题，自己去做就是了。如果这个小分队习惯这种工具，那个小分队习惯那种工具，那就各自用自己熟悉的工具。如果小分队觉得某种工具或者工作方式很好，我们鼓励他们告诉团队其他人，这样好的工作方式慢慢地会成为全团队的标准做法。

不过，将团队分割为一个个独立的小分队，也有一些问题。最常见的就是，可能出现重复劳动。两个团队很可能同时开发同样的功能，重复解决同样的技术问题，同时写差不多的代码。为了解决这个问题，我们组建了几个小分队，主要负责内部基础工具的开发，类似于为其他团队遇到的共通问题，开发一些基础设施性质的工具，让大家不用在这些问题上重复劳动。

我们的产品架构和部署，允许各个小分队自行确定产品功能的时间，从而避免各个小分队互相影响、拖延彼此的进度。

部落：为特种兵们提供火力支援

这种活力十足的小分队结构，可以把机构臃肿的大公司拉回到最初创业的状态，用内部创投的方式把创新效率提高，提升整个公司的创新能力。

我们大概已经建立了25个小分队，如果没有一定的组织协调，那么小分队的数量发展到一定程度之后，可能就会陷入混乱了。这时候我们引入了部落这个组织级别。

Hudl公司内部按照产品模块不同，划分为若干个部落，包括团队运动、个人绩点、社区、基础设施等。各个部落类似于一个独立的公司。每一个部落都围绕一个特定的目标建立起来，由多个小分队组成。比如，基础设施部落的工作目标是让人们更有效地工作，他们会组织小分队开发一些基础设施、内部开发工具和平台，为其他小分队提供工作的工具和框架。这些部落可以扩展到多个小分队，从而确保各个小分队向着共同的目标前进。

就像小分队一样，部落也是自主运行的，但是部落的工作目标与公司的总体目标需要保持协调一致。我们安排了一个产品总监和一个总经理来负责统一协调各部落内部的产品和业务发展目标。

各个部落都有自己的商业开发、市场营销、销售和客户服务职能，这些职能为部落内部的产品进行服务。我们认为，Hudl内部每个部落都是一个独立的业务公司，所以需要囊括业务的各个环节，以确保技术人员和非技术人员流畅的沟通。

行会：协调各部队

我们发现，有的员工分属不同的小组，或者还横跨多个部落，但他们正在从事的某些工作是差不多的。于是我们又建立了行会，让这些员工可以横向沟通，交换彼此的信息。比如，全公司所有的质量分析工程师每周会一起开会一到两次，所有的开发工程师也会根据需要组织在一起开会。

会议的内容可以视情况而定，有的时候是分享可以采用的新技术；有的是讨论如何加快学习和提高；有的是讨论如何改进行会的工作方式。这些讨论可以让每个人都有机会表达自己的想法，共同面对和解决问题。

我们希望这种组织结构可以解决团队规模扩大后遇到的问题。但它也有缺点。我们现在也遇到了一些问题，并且正在努力解决。比如，如何防止各个小分队之间的信息和专业知识割裂，以及如何让公司的产品团队在这种组织结构下，仍然与公司其他团队（如销售团队）保持紧密的关系。

公会：跨专业的兴趣组织

最后，我们还会组织一些公会。这些公会类似于行会，是横跨小分队和部落的松散组织。但是，行会是将相类似工作的人组织起来，而公会则更灵活，是把不同工作的人员按照兴趣组织起来，讨论该领域的新发展、交流彼此的想法。

任何人在任何时候都可以组织公会。如果你觉得需要成立一个公会，而且你觉得会有人感兴趣，你就可以成立一个。然后你会发现跟你一样对这个领域感兴趣的人。公会慢慢的也可能发展成为一个新的业务方向，形成新的小分队和部落。

这些问题解决起来并不容易。但是，我们仍然决定把这个问题丢给小分队。只有小分队和团队所有成员之间可以进行公开的交流、不停地探索如何改进工作、分享自己的知识，这些问题才可以在沟通和工作中找到解决方法。