現在，許多遊戲工作室是按學科組織的。比如，所有動畫師同坐在動畫部的辦公室，所有程式設計師都呆在程式部的辦公室。雖然也有一些學科混雜的團隊，但他們都嚴重依賴其他部門的支援。

在這種結構組織下，大多工作不能由某個團隊獨立完成，而是劃分成若干子部分，每個部門分攤一個屬於自己學科的子部分。

舉個例子：

 

故事(from gamasutra)

（玩家用超級散彈槍殺掉殭屍）

從上面這句話中，我們得知這個功能的元件有散彈槍的設計、槍的機制程式碼和殭屍的死亡動畫等。

完成以上功能需要設計師、程式設計師、動畫師、特效美工、建模師、聲音設計師和QA測試員。假設這個功能可以一支由這些人組成的團隊完成，並且能在為時兩週的一個工作週期內完成。

而這個工作室的組成結構是這樣的：

 

組織

沒有一個部門能獨立完成這個功能。管理部門必須將它劃分成子部分，然後分配給相應學科的部門。整合功能的部分則由製作團隊完成。我們的劃分描述如下：

分支故事(from gamasutra)

（玩家在啟用散彈槍時它能正確響應。玩家用散彈槍打死殭屍時會播放殭屍的死亡動畫。）

不過，更常見的情況是，這個功能已經被分成描述需要完成什麼的預備工作。將功能的構成描述為“如何”而不是“什麼”似乎顯得不太自然。

這種組織結構有兩個負作用，一是預備工作的完成速度必須快，即使是小型的遊戲。另一個副作用是，為了讓工作順利進行，各個部門之間的合作工作量會很大。

預備工作的作用就是，使開發人員能在功能的水平上討論工作的優先次序，以及理解整個專案的開展線路。理想地說，玩家閱讀你的預備工作條目時應該會感到興奮，因為知道你將把這麼多好東西放時遊戲裡。當預備工作變得太大、太細時，決定不同功能之間的優先次序就很困難了。你看到的只是任務/執行的細節。

執行這種分解過後的功能，我們必須仔細規劃工作，以便各個部門能按時完成自己的部分，不影響下一個部門的進度。我們的工作流程可能是這樣的：

 

工作流程

我們可以開始重複初始設計時，整個過程應該有三個環節。就算不加上評估品質，也需要五個環節才能完成和驗證功能。當然，同時開展工作和跨團隊合作可以加快程式。但那樣做會增加專案的難度和各個部分的失敗率。越是同時開展工作，越是需要合作上的努力。

跨職能組織的目標是，使團隊在最不依賴外部支援的情況下達到完整的目標。另外，他們應該自己決定內部相關性的問題，而不借助太多外部合作。

在這個例子中，如果這支團隊是由設計師、程式設計師、動畫師、特效美工、建模師、音效師和QA測試員組成的，那麼他們的各自需要完成的工作就分別落在一個環節中。工作的週期越短，迭代的次數就越多，產品的品質就越高。因為少了外部依賴性，所以對外部合作的需求也減少了。

最後，跨職能組織的規模大小會更合理。增加一支團隊造成的組織複雜度並不會像分部門的組織那麼多。因為決定相關性是在團隊層面上發生的，不會增加管理層上的工作量。在“傳統”的組織結構中，管理層的工作量在後期會非常大。

簡而言之，一個組織良好的跨職能團隊具有以下優勢：

總結

via：遊戲邦/gamerboom.com