作者：Samuel Rantaeskola

随着团队规模增大，协调各成员的工作也会变得困难。作为游戏从业者，我们非常擅长将小项目从概念做成成品。但是，当团队规模大到一定程度，许多看得见看不见的障碍和麻烦就露出苗头了。大规模团队如果没有运作项目的经验，就会非常阻碍行业的发展。

1、达成一致

在小团队里，各成员之间的持续交流是激发灵感、提高积极性和达成共识的有效方法。然而，在团队成员上百，再加上设计文件并非人人都看过的情况下，单纯依靠成员之间的交流就必然导致项目失败。游戏设计和制作计划之间的紧密联系是保证将高级概念转换成实际产品的关键。

当然，保持“是什么”和“怎么做”之间的联系只能达到一半的目标。达成最终目标的首要方法应该非常清楚，让整个团队都明确。这样，团队才能够既保持工作进度，又不断萌生创意。

team-structure(from smartinsights.com)

2、决定组织

在制作早期阶段，你应该考虑如何组织整个项目。当游戏还在制作时，你如何对它进行排错？记住，当你允许项目组的成员时，应该适当地扩充排错人员。另外，最好能尽制定工作流程，而不是等到有需要时才确定。工作流程可以帮助你计划进度。

3、细分问题

对于大多数团队，这是必须考虑的，但有不少团队仍然把项目当作一个大型拼图游戏。他们费了大量精力，试图最大程度上优化资源配置和管理，但在这样一个信息丛林里，这各方式是不可能产生好决策的。因为他们面临的困境在于，如何从一个大问题中细分出保持尽可能互相独立的小问题。

4、根据问题分配职能

理论上，似乎所有人都很熟悉交叉职能团队，但实际上，混合团队职能是极其危险的。这种形式其实是游戏行业中的落后习惯。如果能控制好交叉职能部门的规模，添加一两个成员产生的麻烦也不会超过在细分职能部门的组织结构中添加成员。并且，如果团队之间的依赖性较小，管理上的开支也会相对少。

5、下放决策权

你应该接受现实：你会失去控制权。自上而下的管理层级结构可能“适用”于小团队，但在大型开发环境下，极其容易出错和导致效率低下。你很快会意识到，这种形式很有风险，即使不能完全淘汰，也必须改革。大型开发团队从休闲游戏工作室的“鸟枪法”中吸取了经验， 也就是独立团队在自己的职权范围内行使决策权。在这种环境下，就不存在拖延团队工作进度的外部干扰了。自然而然地，休闲游戏开发团队非常适合这种管理方式。当然，如果能尽早把问题细化，以及下放权力，大游戏开发团队也能采用这种模式。

6、一个团队就是一个小单位

不要在管理个人上浪费时间了。信任你的团队会做好自己的份内事。在执行项目的某个任务时，个把人可能并没有参与，因为他等着团队中的其他人完成这个阶段的任务。相信我，他可能想到成千上万他可以为项目做的事。毕竟你的团队成员基本上是人才。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

How to not fail in scale

by Samuel Rantaeskola

As game teams are growing in scale there are some severe pains in coordinating these efforts. As an industry, we are quite capable and efficient at moving small scale projects from concept to a finished product. When the team sizes eclipse the century mark, many more obstacles and hindrances both seen and unseen begin to rear their ugly head. The general lack of production experience of running projects at this larger scale is handicapping us as an industry at large.

I am not claiming that the solution I’m proposing here is rocket science in anyway, but rather these are the common pain points I see and hear continuously within the games industry.

1. Unify what to do and how to do it

In a small team, continually communicating the vision of the project with each member is a battletested way to keep everyone inspired, motivated and on the same page. However, solely relying on that method when working in the hundreds and adding to that having a game design document that nobody reads, is a sure path to failure. A tight connection between the game design and production plan is one way on how you can approach breaking down the game from a high level vision into actual work. In this video, I talk about a method for achieving that: http://vimeo.com/51747636

Connecting what and how will only take you half way there.  The overarching method of getting to the end goal should be basic enough to be easily explained and understood by the entire team. Within that method, the teams should be able to select the best working formula for them moving forward whilst still feeding in to the whole project.

2. Decide on a structure

In the early phases of production, you should think of how to structure your entire project. How are you going to troubleshoot it when it’s being built? Bear in mind that it needs to scale appropriately as you will add teams to it. It is also a good idea to iron out workflows early on, instead of defining them on-demand. This process will help you plan how to track progress as you are getting into production mode.

3. Subdivide the problem

For most in our industry this is given, but there are a lot of teams out there that are looking at the project as one gargantuan jig-saw puzzle. They spend a lot of effort trying to optimize resources and dependencies to the smallest detail and in that jungle of information it is impossible to make good decisions. The challenge is to create sub problems that are as independent as possible from each other.

4. Build teams around the problems

Everyone seems familiar with the concept of cross functional teams in theory, but in practice evolving to a cross functional organization is extremely arduous. Historically, it has much to do with the outdated culture in the games industry, where the tradition has been to sit with peers in silence. A cross-functional organization scales nicely, and adding a team does not increase the complexity as much as in a departmentalized organization. Resolving dependencies is within the teams and the management overhead can remain fairly sparse.

5. Decentralize decision making

Accept that you will lose control. A top down driven management style and structure “works” in small environments, but is extremely slow and error prone in large scale development ecosystems. You will quickly realize that this strategy is fraught with hazards and will need to be corrected, if not eliminated outright. Large scale development teams have a lot to learn from the casual game studios’ “shotgun approach”, in so far as, the concept of having independent teams which are the decision makers within their domain.  In this kind of environment, there are no external bottlenecks which slow down the teams’ progress. Naturally, casual games lend themselves well to this style. However, with an early sub division of the problem and delegation of ownership, it can work in more complex games as well.

6. A team is the smallest unit

Don’t go on a duck hunt to optimize the hours. Trust your teams to make good calls within their area. Every now and then one of the guys in a team will be short on project specific tasks, because he’s waiting for the other guys in the team to finalize the level. Trust me; he can probably think of a million things that he could do that will add value to the game. After all you’re probably hiring talent.(source:gamasutra)