作者：Jesper Richter-Reichhelm（社交游戏公司Wooga工程主管）

去年底有篇描述Spotify如何使用分散处理方法管理部落和小组的文章深深吸引了我。它让我认识到我们并非使用这种方法的唯一团队，我希望在此讨论这篇文章所说的一些理论。

我还想借此说明，我们完全有可能在小型自治团队中采用真正的敏捷工作环境。这并非小事一桩，它需要我们每天都付出精力来保证这种结构顺利运行。以下就是我以自己在Wooga的工作经历为例，对保持团队独立性为何有助于衡量一家公司优劣的总结。

wooga(from thenextweb)

Wooga现状及愿景

Wooga成立于2009年，其愿景是到2020年，所有人都将成为游戏玩家。我们四年前大约20名成员，现在员工（来自40多个国家）已经超过250人，大家都在柏林工作室办公。
员工规模壮大是公司经济成功的一个副产品，在这个成长过程中，我们面临的最大挑战却是不要丧失我们所建立的企业文化。在早期阶段，公司中每个人都紧密合作，也不需要因为等待审批结果而拖延进度。通常来说，随着公司发展壮大，管理层的增加，这种工作方式就会发生变化，并且趋于低效率。

我们该如何守住这种文化？答案就是：一切以独立游戏团队为中心。我们曾对这种方法产生怀疑，但我们相似这至少值得一试。

Wooga是一个由许多小型独立团队组成的集合体，每个团队都要负责制作和运行一款游戏，并在跨职能和自治环境下自主制定决策。他们可以自由分享心得，无需相互较劲，这意味着他们能够在一个大型框架中像小型独立创业团队一样高效执行工作。

wooga structure(from thenextweb)

他们可以自己决定听从还是忽略外部建议——即使这些建议来自公司创始人。这种方法只适用于杰出的人才。所以雇佣正确的人就是我们在Wooga最重要的事情。我们相信“用人不疑，疑人不用”这个道理。事实证明这个原则非常管用。

团队

团队是Wooga组织的核心。70%员工是游戏团队成员。公司还有部门主管，例如两名负责不同领域的工程主管，以及其他监管各自部门工作的主管。

其余员工则负责提供营销、客服支持和本土化（20%）或者HR、PR、金融、商业分析等中心服务，以及维护游戏的简单服务。“服务”是这里的关键词——这些团队要支持游戏团队，而不是后者服务前者。例如，公司没有专人预算处理流程，游戏团队可以自主决定相关发布日期。

wooga team ratio(from thenextweb)

每个游戏团队都有一名产品主管负责为团队制定最终决策。这可以确保团队总能快速制定决策，公司高管也不会成为干预其决策的瓶颈。这实际上是核心管理层对团队的授权。从团队希望制作哪种游戏，到团队打算如何自我管理，都由游戏产品主管来决定。

wooga game team ratio(from thenextweb)

公司中的团队小至1-3人，首先入伙的人通常会成为未来的项目领导，并提供游戏的最初理念。他们会开发一个可评估并且可试玩的原型。如果原型不够好，团队就会重新开始。如果它看起来极富潜力，团队就会逐步扩大规模，但会尽量将其控制在10人以内。

在游戏上线之后，团队规模会保持稳定或有所增长。更多游戏功能的开发不会拖延开发过程，但会从在线数据分析、A/B测试中提取额外信息，并且需要管理整款游戏。

共享知识

重点在于，即使这些团队是独立动作，并且会相互比较KPI，他们之间却并不会相互竞争。他们之间会经常交换知识和经验。这也正是我们影响独立团队创新（以及弥补独立团队所带来的风险）的方式。

weekly meeting(from thenextweb)

每个团队每周都要开展一个5-10分钟的会议，向公司其他成员报告自己的进度，说明自己的收获（例如之前的A/B测试结果，或者宣布游戏新功能）。这种会议并不限制团队成员所分享的信息类型，只要其分享的是对他人有益的结果即可。

此外，任何人都可以参与这些会议。我们可以在游戏中尝试新事物，如果它们具有可行性，其他团队也可以效仿。

5 minutes of fame(from thenextweb)

另一种层面的知识交流发生于同个学科的成员之间。我们每月会织织一次内部快闪演讲（5分钟），公司任何人都可以上台说说自己想分享的内容，任何人都可以参与这种演讲。这是一种传播信息，在公司中展开讨论和增强联系的好方法。我们还有针对后端开发、前端开发、游戏设计、商业分析和美术的专门会议。

如果一个话题太复杂，无法在快闪演讲中解决时，就可以在“便当演讲”中提出，此时的参与者在发表25分钟的演讲之后可以得到一次免费的午餐。公司中有半数人参与这种演讲，我们每个月会举办一次这种演讲。

我们会在大礼堂举办这种“便当演讲”，而公司每周例会则在周一早上展开。在这种15分钟会议里，大家会给予新人温馨的问候，或者公布公司战略，宣布游戏发布等消息。这是每周重要的开端，有助于公司中的每个人都获得相应的知情权。

协作

由于团队具有跨职能特点，大家就有了广泛可用的一系列技能，紧密合作的成员也由此组建了优秀的团队。但我们的理念并非让一人独自了解和决定一切，而是让每个团队成员都负起推动游戏前进的责任。

团队本身就有自治权，无需根据其他团队的情况来创造和运行自己的游戏。因此，开发团队在使用由商业分析服务团队提供的共享服务，以及一些标准KPI时要自己进行分析。与之相似，公司中也不会有运行/管理团队帮助他们运行服务器或其他基础设施，而是由编写软件的人自己来运行。公司也不会迫使工程师共享或重用代码，不存在人人必须使用的中心框架。

如果工程师想重用代码，可以访问github中的私人和公共套件库，但他们也可以选择自己重新做起。这是一个折衷方法：我们有时候会白费力气重复工作，但整个公司仍然更为灵活而创新。新团队开工时，原来的团队进度并不会被拖延，整个通信开销也仍然保持在较低水平。

凡是听说过Dunbar相关理论的人都应该知道，当一个群体成员超过150人时，其团队凝聚力就会开始下降。Wooga要求团队成员积极与其他游戏团队互动，相互学习经验，了解其他团队之前掌握的教训。为促进团队沟通，我们将团队一起整合到工作室中。这是我们正在执行的一个战略，目前来看效果理想。

studio structure(from thenextweb)

敏捷方法

我们认为敏捷开发并不是指运用特定方法，而是遵从正确的原则，并持续反思自己是否执行了正确的方式。

所以，这里并不存在团队开发软件的统一流程。团队可自主决定如何行事，不过他们通常会结合Scrum和Kanban元素来开发内容。

board(from thenextweb)

但这也存在一定约束性：

*团队需要在每周例向公司其他人汇报进度和收获。

*较小的原型团队需要通过批准之后才能开发完整的游戏。大量原型都没有通过这个阶段，这让我们能够在较短时间内测试大量新游戏理念。“失败”正是这个阶段的一部分。公司会分享从被取消游戏项目所得到的经验和教训。

*公司所有人都可以共享所有源代码。

*公司任何人都可以了解所有KPI和参数。

*我们希望大家根据常识来思考和决策。我们试图避免形式化的流程，因为规章制度并不灵活。我们也有一些引导个人决策的普遍原则，有时候也会给予必要的提供，但总体来看这些方法还是很管用。

总结

我是在2009年Wooga还只有10个人时就加入了公司。随着时间发展，创始人希望让Wooga成为一个人人为自己的工作、团队和公司负责的集体。保持独立性和自治性就是我们在Wooga的普遍工作方式。

所以我们的企业文化很强调自主权，公司信任大家能够制定正确的决策，并且多数时候，他们也确实做出了正确决策。当然，人也难免偶尔犯错，但因为大家并不会避讳这一点，所以他们可以很快纠正问题。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Using independent teams to scale a small company: A look at how games company Wooga works

By Jesper Richter-Reichhelm

Jesper Richter-Reichhelm is Head of Engineering at social games company Wooga. Here he gives an insight into the firm’s internal organization.

At the end of last year, a document was published that described how Spotify works using a decentralized approach of tribes and squads. Since then, the article stuck with me. It made me realize we were not alone in this approach of fostering independent teams and with this article I want to contribute to the discussion and challenge a few conceptions.

I also want to explain that it is possible to have a truly agile work environment based on small, autonomous teams. It’s no small feat though, it takes effort everyday to keep this structure working smoothly. The following is a work in progress summary of how keeping teams independent can help scale a company, using my experience at Wooga as an example.

Wooga – now and then

Wooga was founded 2009 with a vision that by 2020, everyone will be playing games. Four years ago we had around 20 employees and now there are more than 250 employees from 40 nations all working in our Berlin office.

While that employee growth is a byproduct of economic success, in the process of growing it was a big challenge to not lose the company culture we had built. In the early days everyone in the company worked closely together and were not slowed down having to wait for approvals. Normally as a company grows this changes as management layers are added, and work simply becomes less efficient.

How did we hold onto that culture? The answer: centering everything around independent game teams. We had doubts about this approach, but we believed it would be worth the effort to at least try.

Wooga is a collection of many small, independent teams. Each team is responsible for making and running a single game and is expected to make their own decisions while being cross-functional and autonomous. They should freely share learnings and don’t compete with each other, meaning they effectively act like small, independent start-ups within a larger framework.

It’s completely up to them if they want to listen or ignore outside advice – even if it’s from one of the founders. This is only possible by having great people. So hiring the right people is the single most important thing we do at Wooga. We believe in the mantra, “If in doubt, don’t hire.” That works very well.

Teams

Teams are at the heart of how Wooga is organized. 70% of employees are working in a game team. There are departmental heads, such as the Head of Engineering of which we have two who take care of different parts of that field, and others that look after their respective departments.

The rest are providing central services like marketing, customer care and localization (20%) or others like HR, PR, Finance, Business Analytics and teams that maintain simple services for persistence of games. “Service” is the key word here – those teams serve the game teams and not the other way around. For example there are no artificial budget processes and game teams can decide release dates themselves.

Each game team is led by a product lead that has the final decision for the team. This ensures a fast decision is always possible and the company can scale without top management becoming a bottleneck. In essence this is a delegation of power from central management to the teams. This starts with the type of game a product lead wants to make and ends with the way the teams organize themselves internally.

Teams start small with 1-3 people, with the first always being the future lead and providing the initial concept of the game. They develop a prototype that can be reviewed and most importantly, play tested. If it’s not good enough, the team starts afresh. If it looks promising, the team is ramped up slowly, keeping it below 10 people for as long as possible.

After going live the team size can remain stable or be increased. Further feature development does not slow down the development process but as extra information is derived from live metrics, a/b testing becomes possible and the whole game needs to be operated.

Knowledge sharing

An important point is that even though teams are independent and compare KPIs, they do not compete with each other. There is a constant exchange of knowledge and lessons learned between them. This is how we leverage the innovations made by individual teams (and compensate risks individual teams take).

On one level this is done by each team being asked to provide a 5-10 minute weekly meeting where they report their progress to the rest of the company and explain their learnings, which could be from something like previous a/b tests or new feature announcements. There are no limits or off areas regarding which information can be shared as long as others can benefit from the information.

Also, these meeting are open for every employee to attend. This way we can try out new things in one game, and when they work, that knowledge is spread to other teams. This works quite organically.

Another level of knowledge exchange is between members of the same discipline. We organize monthly internal lightning talk rounds called “5 minutes of fame” where anyone in the company can give a short talk regarding something they want to share and everyone can attend these talks. It’s a good way to spread knowledge and start discussion throughout the company and increase networking. We have specialized meetups for backend development, frontend development, game design, business analytics and art.

Whenever a topic is too complex to handle it in a lightning talk we do brown bag talks. This is a lunchtime talk where participants get a free lunch after the 25-minute talk. Half of the company usually attends these talks of which we have about one per month.

The brown bags are held in our auditorium area where our weekly company meeting takes place every Monday morning. It’s a 15-minute meeting where new hires get a warm welcome, company strategy is presented and announcements like game releases are made. It’s an important start to the week, and helps to keep everyone in the company connected and informed.
Cooperation

Since teams are cross-functional there is a wide range of skills to utilize and good teams organize themselves with members working closely together. Again the idea is not to have a single person knowing and deciding everything, but making it the responsibility of every team member to push the game forward.

Teams themselves are autonomous and do not depend on other teams to create and run their game. As a result teams do their own analytics while using a shared service provided by the Business Analytics service team and a few standardized KPIs. Similarly there is no operation/admin team to operate the servers or other parts of infrastructure. Those who write the software operate it themselves. Engineers are not forced to share or reuse code, so there is no central framework that everyone must use.

Instead, private and public repositories emerge on github when engineers want to reuse code, but they also have the option to start from scratch. This is a conscious trade-off: we sometimes reinvent the wheel and repeat mistakes, but the company as a whole is much more flexible and innovative. Existing teams are not slowed down when new teams start and the overall communication overhead remains small.

Those who have heard the theory behind Dunbar’s number will know that group coherence will start to dissolve when it grows beyond 150 members. At Wooga we rely heavily on team members proactively reaching out to other game teams to learn from their experiences and be aware of what those other teams have learned in the past. To assist communication we grouped together teams into studios. This is a work in progress strategy but so far it looks good.

Being agile

We think agile development is not about applying a specific methodology, it is about following the correct principles and to constantly reflect on whether you are aligned correctly and to correct things when necessary.

As a result there is no unified process on how teams should develop their software. Teams decide on their own how to do things, although they usually blend in elements of Scrum and/or Kanban. That means stand-ups in the morning are the standard, although variations do exist.

There are some constraints though:

Teams work in weekly iterations and present progress and learnings in weekly meetings to the rest of the company.

Small prototyping teams need to get a green light to develop a full game. A lot of prototypes do not pass this stage which allows us to play test many new game ideas in a short time. “Failure” at this stage is part of the process. Lessons learned from cancelled games are shared within the company.

All source code is available to everyone in the company.

All KPIs and metrics are available to everyone in the company.

We expect people to think and decide on their own using common sense. We try to avoid formalizing processes as the resulting rule book wouldn’t be flexible enough. There are some common principles to guide individual decisions and sometimes reminders are necessary but overall it works well.

Conclusion

I joined Wooga when we were just 10 employees in 2009. Over time the founders attitude to work lead to an organic evolution of the company based on everyone being responsible for their own work, their own team and ultimately their own company. Being independent and working autonomously are the common threads in every approach we take at Wooga.

This had lead to a culture where taking ownership is emphasized and expected. People are trusted to make the right decisions and they do make the right decisions most of the time. Of course sometimes people do make mistakes but since they don’t try to hide them it’s actually quite easy to fix things.（source：thenextweb）