公司拆成自主管理的小团队，马云专程去北欧学来的管理结构
很多创业公司在团队管理上，都不愿意继续走大企业、大机关那种官僚层级的管理模式，希望能采取更分散、团队更自主管理的模式。一方面，大家的兴致更多的在市场、在产品，对内部行政管理实在不愿意搞的那么重；另一方面，《失控》等理论也鼓励了大家常识分散化的管理方式。
据说连马云都带人去北欧Supercell学习所谓的“大中台架构”，据此调整阿里巴巴的组织结构，以避免了大公司常见的部门与部门争夺资源，不同的小组做同样的事情。
本文介绍了一种将团队分散化的管理方式。他们将120人的产品团队，拆解为20多个自主管理的小团队，从而降低管理成本、提高团队协作效率。
文章来自Hudl产品团队的blog，这种团队结构是他们从Spotify那里学来的，而且有所创新。有意思的是，Supercell和Spotify都是北欧公司，组织结构的理念也很一致。
Hudl成了几年后，到2011年1月时，产品团队大概有20人左右。在团队里，大家不用担心谁干的多、谁干的少，也不用担心发生重复劳动、消耗无用功的情况。虽然团队同时在几个方向上进行开发，但是有的方面，比如吸引用户、突出工作重点、提高用户注册量方面，都还做的不错。团队虽然执行力很强、动作很迅速，但是随着产品用户规模的扩大，我们还是做不到高效地开发出高质量的产品。
在此之后，我们的团队人数从20人慢慢增加到120人，在这个过程中我们遇到了很多管理上的阵痛，工作的时候开始互相打架。没有人清楚谁应该做什么。这些问题搞的我们焦头烂额，于是我们开始寻思着，应该改造下团队的结构，真正解决这些问题：
怎么才能确保我们的发展速度和团队规模同步增长？
怎么才能让减少内部的层级？
怎么才能保存迅速反应的能力，无论是在产品规划、产品开发还是在产品发布上？
怎么才能让团队在产品上投入足够的关注度和精力？
为了解决这些问题，我们开始调整团队的结构。大概2年前，Spotify就开始采用这种团队结构。调整的基本思路就是两点：团队自主管理、保持快速度。团队调整就是用不停地、更好的实现这两个目标。
在我们产品团队，最基本的一级是小分队，小分队由5到8个人组成，具有完整的职能，小分队完全自治，自主运行。大部分小分队的主要工作是开发Hudl的某个具体功能，并按他们自己的节奏进行开发和发布。
小分队成员并不一定是要在同一个地方的人。在我们这里，有的小分队里，有四个人在四个不同的地方，剩下的人在公司办公室，大家在不同的地方，用各种协作工具组织起来，保持团队成员之间流畅的沟通。
我们也不指定产品负责人，因为我们认为团队每个人都应当对产品的功能负责，每个人都需要参与用户调研，确定产品的指标，以及其他跟产品开发相关的工作。
不过，将团队分割为一个个独立的小分队，也是有一些问题。最常见的问题就是，可能出现重复劳动。两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码。为了解决这个问题，我们组建了几个小分队，主要负责内部基础工具的开发，类似于为其他团队遇到的共通问题，开发一些基础设施性质的工具，让大家不用在这些问题上重复劳动。
我们采用了类似开源项目的理念，把整个产品团队变成了一个开源项目，各个小分队都是这个开源项目的开发者、维护者。
我们的产品架构和部署，允许各个小分队自行确定产品功能的发布时间，从而避免各个小分队直接互相影响、拖延彼此的进度。
小分队可以选择他们觉得最好的工作方式。我们鼓励敏捷开发、快速迭代这些做法，但是我们不会对小分队提出具体的要求。如果小分队想尝试新的方式解决问题，那么自己去做就是了。如果这个小分队习惯这个工具，那个小分队习惯那个工具，那就各自用各自熟悉的工具就可以了。如果小分队觉得某种工具或者工作方式很好，我们鼓励他们告诉团队其他人，这样好的工作方式慢慢地会成为全团队的标准做法。
我们大概已经建立了25个小分队。如果没有一定的组织协调，那么小分队的数量发展到一定程度之后，可能就会陷入混乱了。这时候我们引入了部落这个组织级别。
Hudl内部按照产品模块不同，划分为若干个部落，包括：团队运动、个人绩点、社区、基础设施等。各个部落类似于一个独立的公司。每一个部落都围绕一个特定的目标建立起来，由多个小分队组成。比如，基础设施部落，它的工作目标是让人们更有效地工作，他们会组织小分队开发一些基础设施、内部开发工具和平台，为其他小分队提供工作的工具和框架。这些部落可以扩展到多个小分队，从而确保各个小分队向着共同的目标。
就像小分队一样，部落也是也是自主运行的，但是部落的工作目标与公司的总体目标需要保持协调一致。我们安排了一个产品总监和一个总经理来负责统一协调各部落内部的产品和业务发展目标。
各个部落都有自己的商业开发、市场营销、销售和客户服务，这些职能为部落内部的产品进行服务。
我们认为，Hudl内部每个部落都是一个独立的业务公司，所以需要囊括业务的各个环节，以确保技术人员和非技术人员流畅的沟通。
我们发现，有的员工分属不同的小组，或者还横跨多个部落，但是他们正在从事的某些工作是差不多的。于是我们建立了行会，让这些员工可以横向沟通，交换彼此的信息。比如，全公司所有的质量分析工程师每周会一起开会一到两次，所有的开发工程师也根据需要组织在一起开会。
会议的内容可以视情况而定，有的时候是分享可以采用的新技术，有的是讨论如何加快学习和提高，有的是讨论如何改进行会的工作方式。这些讨论可以让每个人都有机会表达自己的想法，共同面对和解决问题。
最后，我们还会组织一些公会。这些公会类似于行会，是横跨小分队和部落的松散组织。但是，行会是将相类似工作的人组织起来，而公会则更灵活，是把不同工作的人员按照兴趣组织起来，讨论该领域的新发展、交流彼此的想法。
任何人在任何时候都可以组织公会。如果你觉得需要成立一个公会，而且你觉得会有人感兴趣，你就可以成立一个。然后你会发现跟你一样对这个领域感兴趣的人。公会慢慢的也可能发展成为一个新的业务方向，形成新的小分队和部落。
我们希望我们的组织结构可以解决团队规模扩大后遇到的问题。但是，这种组织结构也是有缺点的。我们现在也遇到了一些问题，并且正在努力解决：
防止各个小分队之间的信息和专业知识割裂开，无法交流；
努力让各个小分队有信心在其他小分队的工作基础之上进行开发；
在产品团队实行这种组织结构的情况下，仍然与公司其他团队（如销售团队）保持紧密的关系。
这些问题解决起来并不容易。但是，我们仍然决定把这个问题丢给小分队。只有小分队和团队所有成员之间可以进行公开的交流、不停地探索如何改进工作、乐意分享自己的知识，那么这些问题可以在沟通和工作中找到解决方法。
本文来自“创思舍”，关注创业中的管理经验与商业故事，微信公众号“创思舍”。
|
