游戏开发团队应采用跨职能组织结构

sea_bug

作者：Samuel Rantaeskola

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

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

举个例子：

故事(from gamasutra)

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

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

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

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

组织

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

分支故事(from gamasutra)

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

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

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

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

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

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

工作流程

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

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

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

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

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

总结

来自：游戏邦