     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Manager In A Strange Land: Everybody agrees communication is important. What's not so clear is how to make sure it's happening on your project. And also not clear is how much you're willing to let the efficiency of a given individual on your project suffer for the greater good of keeping everybody on the same page. I have no easy answers. At times on the Spider-Man team it feels like we're over-communicating, with e-mail spam about trivial design decisions flooding the team to the point where people stop reading e-mail, and noise and distractions in the hallways at the point where it disturbs other teams on other projects. And yet, on the other hand, sometimes key things don't get communicated, and mistakes that cost people days or weeks are made that could have been avoided if only the right two people had let each other know what they were doing. Still, in the spirit of "hey, it shipped, so we must have done something right" I'm sharing some of the things we do which I think help communication. This month I hit the ways we do it in software. E-mail Mailing Lists The obvious mailing list to have, if you're at a company with more than one team, is the list that will e-mail everybody on the team. If your project is called, say, Octopus Boy, then the mailing list might be named allOB. Important things that everybody on the team needs to know should be directed to this mailing list. But that can't be the only list you have, because otherwise people's mailboxes will fill with spam about things they couldn't care less about. So break it down further: every discipline gets its own mailing list: codeOB, artOB, and designOB. The leads of all the disciplines should be grouped: leadOB. These groups shouldn't be exclusive--if a coder is close to the design group they should be on the design list. If the lead artist wants to keep tabs on the coders, he should be on the code list. It's worth having an chatOB, so the kind of people who do like to spam the group with funny news items or websites have an outlet, and can be easily filtered out by the people who don't want to read the spam. Finally, you should have feature mailing lists, such as cutscenesOB, stencilshadowsOB, iatlantislevelOB. All the people working on that feature, cross-discipline, can get on the mailing list and use it to schedule meetings, ask questions, and raise red flags. On an eight-man team, this would be overkill. But on a fifty-man team, it never hurts to make a new mailing list, even if it doesn't get used. Nick Doran, producer on Triple Play 2001, once said you can feel the pulse of a project from the amount of e-mail it generates. If nobody's e-mailing each other it probably means they don't care. Call the coroner. Allow Instant Messaging We have no formal policy on instant messaging. Some use it; some don't. The people who don't like the distractions don't use it; the people who want to stay reachable do. Formal Documentation Although e-mails may get sent into space and lost forever--(mine don't; I still have almost every e-mail I've written at Treyarch dating back to 1996; that's what Find is for)--there are ways to document communication that leave a nigh-invulnerable trail. In theory, a team is supposed to work off of design documents, screenplays, and concept art that's generated and signed off on before they're slated to begin work. In reality, this doesn't happen as much as it should. Sometimes the concept isn't generated at all; sometimes it's not signed off on; sometimes it isn't looked at before the cowboy makes something up that's cool; sometimes it is looked at and the cowboy thinks they can do better and they go on ahead. Sometimes a lead steps in and says, "No, that's wrong, do it over." Sometimes they say, "Whatever, that's good enough, next task." There are some documents that do get respected, though: If you write a screenplay, those lines will get recorded, and most of them will make it into the final game. (And you can have testers check against the screenplay to make sure those lines all made it in.) If you storyboard a cutscene, the animators will work off that. (We do a thing where our concept artist will quickly storyboard a cutscene on a whiteboard at a meeting, all the while taking feedback, and then we take a digital photo of the whiteboard. If the storyboard goes to a contractor, we clean it up, otherwise we work off it as-is.) If you have a master schedule, people will work on tasks on that schedule. All of these documents, including the oft-ignored design document, should be in a place that's easy to get at. We:
The Bug Database You probably have some kind of task or bug tracking system. If you don't, get one. A problem with the bug tracking system is sometimes people are sensitive about being assigned bugs. This is an attitude that should be squashed. You can start by setting a good example. When somebody asks you to do something, say, "Can you write me a bug on that? I've got a zillion things to do and I don't want to forget about it." And you can also send out e-mail reminders to the team, "Sometimes we put things in the bug database just to make sure tasks don't fall through the cracks." Finally, you can be polite in your bug reports or task requests. The great thing about a bug report is it contains a validation system to make sure that communication does not fail: once somebody does a task, or decides they won't do a task, the bug bounces back to the submitter, so they can verify that the task is done to their requirements, or agree that the task does not need to be done, and sign off. Everyone becomes a mini-lead. The other problem with the bug database is that sometimes large piles of low priority bugs languish on people's plates... Semi-Formal Documentation Finally, there's the Wiki. Not formal. Sometimes un-maintained. Often ignored. But, for the people who do use it, it is a valuable tool. There's a time in your project, usually near the end of full production but before you're completely working off the bug list, which Steve McCarthy calls "The Time Of Lists." Lists of things that need to be done before levels are complete, lists of rendering artifacts that need to be fixed for a magazine demo, lists of problems that a feature has. We used to keep these "kill lists" (Cameron Petty's term) on whiteboards; now we keep them on the Wiki, all accessed by a central page, all attached to someone--a mini-project that that person is responsible for. So Now You're All Communicated No, you're not. These software tools are
nice but they're no substitute for in-person, human interaction.
Next month: communication the old-fashioned way.
|
|||||||||||||||||||||||||||||||||||||||||||||||
Better
Communication Through Software
Features
|
|
|