作者：Samuel Rantaeskola

现在，许多游戏工作室是按学科组织的。比如，所有动画师同坐在动画部的办公室，所有程序员都呆在程序部的办公室。虽然也有一些学科混杂的团队，但他们都严重依赖其他部门的支持。

在这种结构组织下，大多工作不能由某个团队独立完成，而是划分成若干子部分，每个部门分摊一个属于自己学科的子部分。

举个例子：

故事(from gamasutra)

（玩家用超级散弹枪杀掉僵尸）

从上面这句话中，我们得知这个功能的组件有散弹枪的设计、枪的机制代码和僵尸的死亡动画等。

完成以上功能需要设计师、程序员、动画师、特效美工、建模师、声音设计师和QA测试员。假设这个功能可以一支由这些人组成的团队完成，并且能在为时两周的一个工作周期内完成。

而这个工作室的组成结构是这样的：

组织

没有一个部门能独立完成这个功能。管理部门必须将它划分成子部分，然后分配给相应学科的部门。整合功能的部分则由制作团队完成。我们的划分描述如下：

分支故事(from gamasutra)

（玩家在激活散弹枪时它能正确响应。玩家用散弹枪打死僵尸时会播放僵尸的死亡动画。）

不过，更常见的情况是，这个功能已经被分成描述需要完成什么的预备工作。将功能的构成描述为“如何”而不是“什么”似乎显得不太自然。

散弹枪代码 & 僵尸死亡动画 (from gamasutra)

这种组织结构有两个负作用，一是预备工作的完成速度必须快，即使是小型的游戏。另一个副作用是，为了让工作顺利进行，各个部门之间的合作工作量会很大。

预备工作的作用就是，使开发人员能在功能的水平上讨论工作的优先次序，以及理解整个项目的开展线路。理想地说，玩家阅读你的预备工作条目时应该会感到兴奋，因为知道你将把这么多好东西放时游戏里。当预备工作变得太大、太细时，决定不同功能之间的优先次序就很困难了。你看到的只是任务/执行的细节。

执行这种分解过后的功能，我们必须仔细规划工作，以便各个部门能按时完成自己的部分，不影响下一个部门的进度。我们的工作流程可能是这样的：

工作流程

我们可以开始重复初始设计时，整个过程应该有三个环节。就算不加上评估品质，也需要五个环节才能完成和验证功能。当然，同时开展工作和跨团队合作可以加快进程。但那样做会增加项目的难度和各个部分的失败率。越是同时开展工作，越是需要合作上的努力。

跨职能组织的目标是，使团队在最不依赖外部支持的情况下达到完整的目标。另外，他们应该自己决定内部相关性的问题，而不借助太多外部合作。

在这个例子中，如果这支团队是由设计师、程序员、动画师、特效美工、建模师、音效师和QA测试员组成的，那么他们的各自需要完成的工作就分别落在一个环节中。工作的周期越短，迭代的次数就越多，产品的品质就越高。因为少了外部依赖性，所以对外部合作的需求也减少了。

最后，跨职能组织的规模大小会更合理。增加一支团队造成的组织复杂度并不会像分部门的组织那么多。因为决定相关性是在团队层面上发生的，不会增加管理层上的工作量。在“传统”的组织结构中，管理层的工作量在后期会非常大。

简而言之，一个组织良好的跨职能团队具有以下优势：

总结

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Why cross-functional?

by Samuel Rantaeskola

A lot of game studios today are to some degree organized by discipline. For example, the animators are sitting together in the animation department and the programmers are sitting in their respective offices in the engineering department. There usually exist some teams of mixed disciplines, but they all depend heavily on support from the different departments.

When it comes to planning in these organizations, most of the features in the backlog cannot be handled by a single team. This leads to breaking down the features into sub-components; each representing a portion that can be handled within a single discipline.

Let’s consider the following story:

In this example we conclude that the story consists of components such as shotgun design, gun mechanics code and zombie death animation amongst other things.

Developing the feature will require a designer, an engineer, an animator, an effects artist, a modeler, a sound designer, and a QA. For simplicity, let’s assume that it can be completed by a team consisting of the above people within a sprint of two weeks.

Our example studio is organized by disciplines and looks like this:

None of the departments can develop the story solo. Management will have to break the feature down so that each sub-component can be handled within a department. Coordinating the completion of the feature will lie upon the production team. When tackling this, one approach is to break the feature down in to sub stories like these:

More commonly, however, the story is broken into tasks already in the backlog, describing what work needs to be done. It might feel contrived to construct stories that represents HOW instead of WHAT.

In both cases, the organizational structure forces the backlog to grow rapidly; even in a rather small game. Another side-effect is that each feature requires a large amount of coordination between the departments, in order for the whole thing to work in harmony.

The reason for having a backlog is to have a good place to discuss prioritizations on a feature level and also have an understandable road map for the project. Ideally, a player reading your backlog should be excited by all the cool stuff you are going to put in your game. When the backlog becomes too large and too detailed the prioritization between features becomes impossible. All you are looking at is tasks/implementation details.

Implementing this broken-down feature in our example organization, we would do wisely to try to plan the work so that each department can complete their part of the work before the next department starts. The story components might flow through the sprints in the following manner:

It would take three sprints before the feature is at a state where we could start iterating on the initial design. Even without iterating on quality it would take five sprints to complete and verify the feature. Sure, there are ways of streamlining the process by starting concurrent work and cross team collaboration. But attempts like that will increase the complexity and likelihood of failed sprints. The more concurrency, the more need for coordination efforts.

The goal of a cross-functional organization is to give teams the tools to deliver complete goals with a minimum amount of external dependencies. With this, we also trust them to resolve their internal dependencies without much need of external coordination.

In this example, if we had a team that consisted of a designer, an engineer, an animator, an effects artist, a modeler, a sound designer, and a QA they would have the resources needed to complete the work within one sprint. Shorter turn-around time leads to more iteration which should lead to a higher quality product. With less external dependencies we would also be decreasing the need for coordinators that exist outside of the teams to handle this complex process.

Finally, a cross-functional organization scales nicely. Adding a team does not increase the complexity as much as in a departmentalized organization. Since resolving dependencies is within the teams the management layer can be pretty thin. The need for additional layers of management will come a lot later than in “traditional” organization.

In short, a well-structured cross-functional organization has the following benefits:(source:gamasutra)