     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Secret's in the Schedule: Building a Schedule Traditional scheduling in the form of a Microsoft Project document or a simpler Excel spreadsheet is most critical during the prototype, pre-production, and production phases of development. Concept development is too freeform and the final bug push is too reactionary; neither will benefit much from a schedule. The prototype phase is really just an abbreviated form of pre-production and production, so to understand those is to understand prototyping. Therefore, let's focus on pre-production, production, and the differences between them. Creating a schedule first requires building a task list, which is in fact an expression of your design document. Are you building a racing game? Do you need a four-point suspension system? Do you need a flight control model? Is water surface dynamics critical to the boat level? Do you need a custom lightmapper? These game features need to be filtered into independent engineering, art, and level-construction tasks. The resolution of these tasks is dependent on where you are in the timeline of your project. We begin with system-level tasks during pre-production and constantly refine these as milestones are started, progressed, and completed. By the time you reach production with the major unknowns resolved, you should be able to make a valiant effort to refine the entire schedule down to days, but don't. Tasks should initially be timed at a resolution of about a week. Anything that needs to be completed in the next two months should be resolved down to days. Refining the resolution too much, too soon will be work wasted since the dynamic nature of a schedule will lead you to redo it anyway. Understand the Team The next stage is understanding your team's manpower. You should begin by identifying the type of developer (any team member including programmers, artists, level designers, and so forth) each person on your team is. One simple way to do this is to analyze how they fall into four basic types, based on combinations of skill and dedication. These types can be represented on a simple 232 matrix with their skill level on one axis and their dedication on the other. Developers near the low end of both axes, those with little skill and poor morale, should be removed from the project after attempts are made to improve their dedication. Skill takes significant time to improve--so don't expect that to rise over the course of one project, but a person's morale certainly can. However, if you can't promote improvement in a reasonable time, say 1/4 of the total project length, remove them from either the project or the company. Too many leads allow poor performers to stay in positions where they drop the ball and bring down the morale of those around them. Removing a poor performer can quite often create a net gain for the entire team even with the loss of the head. My previous work at Presto Studios showed me first-hand the damage one or two low-end members can do to the overall workload and morale of a team. The next type of developers are the highly skilled persons who are poorly motivated. Maybe they don't like the game. Maybe they're angry because they didn't get the lead positions. Maybe they just came off a horrible crunch and just aren't ready to dedicate long hours again. Whatever the reason, they simply want to work their 40 hours, do their job effectively, and then go home. But since they are still highly skilled they are valuable in their own way. They will be most useful when working on exactly what they want to work on. If they're masters of networking, then that's where they go. They will put up with the least amount of unpleasant work when compared to the other developer types. Due to their skill level, they will require less hand holding but their strict hours mean keeping them on their schedule will be most critical. Luckily, their own sense of pride will often be their strongest motivation for getting the job done right and on time.
Then we have the young kids straight out of college with little skill but miles of desire. These developers want to prove themselves but they can get over their heads very quickly. Give them the systems with the most design in place. Put them in positions where they have the most number of seasoned developers working with them. They should be given non-performance-critical code such as UI. They should be watched over by more experienced mentors and be expected to make up for their inevitable schedule overruns with long hours. At this point in their career, they are paying their dues. And if their rookie mistakes are kept to a minimum by monitoring them closely, their ambitious attitude can help light a fire underneath everyone in the group. And finally, we are brought to the most important people on the team: the superstars. They are the highly skilled, highly motivated crew that makes the impossible possible. This is the white-hot fiery core of the sun that will drive your project when things get tough. They will work weekends without even being asked. They will bring in sleeping bags when necessary and work all night if needed to get back on schedule. Work for a 1:3 ratio between superstars and the other two types of developers. (Remember, you should have already fired the first group so we're only left with three total groups.) Your superstars are your first and last line of defense against missing your milestones. Assign the Team Once you understand your team, you can successfully begin to assign people from your pool of talent to the task list you have built. Assign the highly skilled but poorly motivated people first. Give them the systems their skills match and they are interested in building. If you run into conflicts such as too many physics programmers all wanting to own the system, try to exchange these resources with other teams. You do not want highly skilled, poorly-motivated people working on systems they don't want to. If you do this they will most likely start dragging their feet or sending out resumes. Next, layer in the superstars who most likely can do almost any system you assign to them. These people have written graphics, physics, sound, AI, and most everything else so skill matching should be less important. After they have been placed, the first two groups of developers should cover every major system, leaving the eager rookies to round out the corners and fill in the gaps. With people assigned to the task list, the lead should take the first pass at assigning time to each job. Be liberal with your estimates; optimism is a swift killer of any schedule, so assume mistakes will be made. Go ahead and assume your difficult, product-defining systems will need to be rewritten two or three times. Once completed, bring your team together and as a group discuss your estimates, gather contrary opinions, and negotiate final estimates for the schedule. Remember, even though you're the lead, it's the persons you've assigned to the task who have to complete it in the scheduled time. Give them the final word if you can't come to a consensus. You now have a full task list complete with people and time, however it's still not a schedule. I've seen many projects over the years stop at this point without truly turning the task list into a schedule by serializing the pieces. This process begins by determining dependencies among the tasks. You can't texture a level until it's been modeled. You can't animate a character until it's been skinned. You can't program the front-end UI screens until a base GUI system is finished. This is what creates a timeline that shows people what they should work on on any given day. This is also how you can identify the communication dependencies that lead to one of the central tenets of The Mythical Man-Month. It's at this point that you can see just how interconnected your different systems and the programmers building them will have to be to complete the project. We now must lay this data into our schedule software. Put each person down for six hours a day for five days a week. Even if you expect a death march, don't start by scheduling for it. That's a sure bet at blowing your deadlines down the road. The six-hour day covers the time during an eight-hour day the person will be in meetings, taking lunch, or hanging out in the kitchen eating a muffin with the team. Remember to put in holidays. (I laugh every time I see a schedule with someone completing a task on Christmas Day.) And as a general rule of thumb, assume each developer will take one personal week of time every four months. Now you might look down at your schedule and think something has gone horribly wrong. One or two people in the schedule will have way too much work that puts them months or even years beyond the rest of the team. Workload balancing is required to fix this problem. Move tasks to other developers, starting with the easiest, but remember as tasks move away from their ideal owners they may need additional time padding for someone not as familiar with the system. This is also when the idea of additional developers should be first introduced. If you have a hard date for delivery and the tasks just don't add up, start padding your team with TBD (to be decided) members. This true and honest schedule will be your ammunition to request more support from your boss. Fight the urge to simply schedule for a crunch this early in the process. If you can't get the people you need on this schedule, then make it clear cuts must begin now. By following these steps, you can start making these hard decisions early instead of in the final months. After days or weeks of working out the tasks and timeframes, you now have a schedule. You should know the size of your team, the tasks they perform, the order in which they will perform them, and how long the total project should take. Of course, it's all a big educated guess at this point but it's infinitely better than nothing. And remember that the schedule is a living document that should be updated daily by the owner. Don't be afraid to change it and make sure people know when their sections do change or when a major overhaul is needed to bring the schedule back into reality. If any one person falls behind his or her milestone deliverable time by more than 10 percent, the problem should be addressed that day. Maybe the person just needs to talk the problem out with a mentor. Maybe he or she needs assistance with the volume of work. Maybe someone else can take one item off the plate to give the person a couple of extra days. Be honest with the schedule. The more truthful the schedule is, the more flexible your team will be.
A schedule is knowledge. Yes, it's a human construct and therefore ultimately flawed, but it's still the best way project managers have to understand what lies before them. It's your map through the jungle and you'll be glad you have it even if a couple of the trails are mislabeled. With this information you'll be able to stretch your team into shapes and forms everyone around you will claim are impossible. And even if you do miss a milestone, a well-built schedule will help everyone believe you're only missing one instead of the constant slide most doomed projects face. My next article discusses process and useful ways to implement
your new schedule, so your team can continue breaking new ground
in game development while you keep the communication nightmare off
their backs. Now get back to work, you have a schedule to write!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|