     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Secret's in the Schedule: Cross-Functional Now that the internal workings of a given functional group are moving forward, it's time to look at cross-functional communication. This is often the trickiest part of process, because now people start talking different languages. The amount of frustration that I've seen as programmers and artists try to work together is mind numbing and almost always due to a basic difference in language. Most of us learned our particular crafts in college where we were segregated from other disciplines. We developed vocabulary specific to our job that was understood by our peers and no one else. And now we need to work with other groups that lack years of training in our niche. This is where the cross-functional breakdowns occur. Therefore, having technically bilingual employees on a team is a requirement. Technical artists and artistic programmers go a long way in merging disparate groups into a cohesive team. Another valuable step in managing multiple team functions is to set up a minimum of one meeting per week for all group leads to gather and discuss past progress and current requirements. This is the setting where the engineering lead would let the art lead know that a new rendering effect had just come online and was ready for use, or where the test lead would inform the group that the latest milestone build passed successfully but still had a few issues. This is where high-level discussions take place without all the tiny details of "how" getting in the way. At this level, the leads should have enough years of experience that no one is blind to the needs of the other groups. With these systems in place, the functional teams are now regularly exchanging information every week, but we're still a long way from true knowledge sharing. The largest step here is consolidating schedules across disciplines so that dependencies between art, design, and code are visible. It surprises me how many teams I have worked with over the years keep their departmental schedules separate with only occasionally discussions merging them in each lead's respective head. But until you actually see the dates line up on paper, you won't really know if a mistake is waiting for you up ahead because the art team needs a tool done in March but engineering isn't planning on working on it until May. Therefore, the leads must come together with their manager and create the single project schedule.
During the final stages of development (alpha and beta), information flow between the departments becomes even more critical, as fires are erupting within hours and minutes. A special-case, cross-functional process that I've used in the past is called the triumvirate. At Microsoft, we used a triumvirate of producer, lead engineer, and lead test to run the final bug push. Driven almost entirely by the bug database, we would all gather once a day, or even more often, to scrub all new bugs and assign them or resolve them as "no fix". All issues would be argued within the triumvirate, with the producer given final authority over all deadlocks. However with this power, the most effective producers used this final veto power very infrequently; instead trusting in the engineering and test representatives to guide them in the correct direction. This check-and-balance group becomes the center of all decisions related to the game and shipping on time. Globalization So far the processes I've written about assume that everyone is located between four walls. But what happens when you decide to use off-site support? As games become more advanced, companies are looking to off-site developers more and more. Whether it's buying shrink-wrapped software from Rad Game Tools, working with New Pencil for art asset creation, or using external programmers that are sharing your source base, a lead has to be able to deal with the difficulties of global management. During the past year I've worked on multiple projects, including Counter-Strike for Xbox at Microsoft, and my latest title for EA that both required some level of programmers sharing resource across time zones. This greatly expands the difficulty of controlling your project. Remember that there are two ways to handle communication on your project: widen the pipe so more information can get through, or reduce the need for communication through intelligent division of labor. When dealing with long-distance development, you won't have many tools for widening the pipe given differences in time zones, languages, and the lack of face-to-face time. Reducing the dependencies and thus the communication requirements is the best approach. Start by identifying the most obvious lines of separation over the game. Multiplayer vs. single-player. Front-end vs. in game. Pre-rendered cinematics vs. gameplay. Preproduction vs. production. These are all strong division lines that can be exploited for reducing communication requirements. Hand off the multiplayer map generation, the entire front-end interface, or all the cut scenes. There are many pieces of a computer game that can be cleanly dissected for outsourcing. Perhaps the most important decision about long distance development is whether to even start it. Due to the difficulties I've described, it's obviously not something you want to dive into without careful consideration. When does it make sense? If your head counts won't allow more hires but you need more help often external contractors allow you to get around head count allocations. If you only need help in the short term, external people can save you the pain of having to reduce work force later-, after the push is over. If you require a specialized skill for a limited time on the project, such as costume or set design, then a contractor can make sense. The cost of bringing a person in-house as a full-time employee is extremely expensive in relocation and benefits, so going external will often be the most sensible, cost-effective approach. As our projects becomes larger, as Sony and Microsoft insist on
releasing more complex consoles, as the home user demands more realism,
so to must our team and management layers expand. We will require
more people adept at the ambiguous art of handling information.
People that work in positions that bestow all the responsibility
of the project but none of the actual power of the hands-on construction.
It's a skill that other industries have had for decades and we're
finally catching up to as electronic entertainment becomes a more
viable force in the world economy. So put down your code, art, or
design work, and spend some time thinking about information as a
resource. Consider your own company's communication requirements,
how what I've written about can help, and how you can expand on
it. Maybe… just maybe… we can use information management
to limit these insane crunches that plague our industry.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|