Task Management
Overview
A few weeks into my job with BioWare I found myself overwhelmed. The tasks kept piling on. I had only ever received a few dozen e-mails in my entire life and now that was how many I was receiving every day.
Most of them were asking me to do more work!
To keep up I developed some task management systems for myself that worked more or less for my career, albeit requiring the occasional modification along the way to keep up with changing technology.
Here's a short discussion on what worked (and an example of what did not).
Get Lazy
One quick way to accomplish more is to improve the work process itself. If you have repetitious tasks that take significant time to complete determine methods to complete the task more quickly, even if it means expending effort to build tools (batch files or small utility programs) to do so. A small expenditure of time up front saves loads of time on the actual task.
Convert tasks you receive into prioritized checklists. This makes it easy to know which tasks are complete and which are not when asked. This might seem obvious but many struggling newcomers do not do this... they assume they'll remember the tasks given to them and become overwhelmed as more duties are added to them.
Technical Skills
In CHAPTER 1 I discussed why technical skills were important. The previous section is an example of why. Because I had the ability to program a quick and dirty scripting editor I was able to improve my task completion time. This made me more valuable to the team.
There's no right or wrong programming language to program in. The important thing is to learn one. Once you do that, adapting to new programming languages is not difficult. And if you are only developing temporary tools for yourself, the language you use is generally not relevant (as long as it works on your work computer).
Learning a programming language also helps you to think logically -- learning how to break complex tasks into simpler stepping stones is a valuable skill that will serve you well in every facet of game development. I am far from a skilled programmer but I learned how to enjoy writing code and often I still finding myself creating utilities to give myself a break from more stressful tasks. So, for me, programming serves two purposes -- it is my method of relaxing and it helps reduce future stress because I create tools to reduce my workload.
Estimates
I eventually learned to under-promise and over-deliver. This was probably my most effective task management strategy. Not only did it look impressive (I always completed more than I said I would and I did it faster than I said) but it also taught me to estimate -- because I was not completely overwhelmed I could assess how long I had predicated the task would take and record this information. Eventually I had enough data that I could hone my estimates better and be more accurate when estimating future tasks.
My estimates improved (though I always continued to under-promise/over-deliver). I was able to build schedules and see my entire task load in a global view. I realized I had time to finish all my tasks. Gradually my stress reduced (at least until I became a lead designer).
While following this philosophy gives you the appearance of being a diligent worker you still have to complete a reasonable amount of tasks! I could not have gotten away with small workloads and huge timelines. You have to be realistically realistic.
Don't Deliver Low Quality Work
In an effort to meet your schedules you might finish the bare bones of a task, honoring it to the letter of the request but not to the spirit. Do not do this. Do not finish a task and say to your manager, "I think this sucks but maybe you might kinda sort of tolerate it, no?"
I've read interviews with editors for short story magazines and some say they receive this kind of apology in cover letters accompanying story submissions occasionally (and I saw it occasionally as a design manager). If you are not confident in what you have written/designed you need to improve it before you show anybody else!
If you honestly do not know whether it is good or not then say so but as a designer you really should know -- at least the difference between terrible and great. The line between okay and not-okay might be harder to differentiate until you are more experienced.
On the other hand if you think you have created something amazing but say it sucks to mess with your manager's expectations, well, you are just being weird.
So: do not promise too much and kill yourself trying to be a task completion hero. But do not undersell your skills either.
Single-Tasking
You will always have dozens of simultaneous tasks.
Do not work on them all at the same time! Complete a task and only then move to others. Multi-tasking is a lie. You cannot work efficiently on more than one task at a time. In many of my performance reviews I am praised for multi-tasking. That was an illusion. I worked on one task and completed it and then moved to the next. When I tried to actually multi-task, I failed.
One exception would be if you are blocked on your current task (i.e, perhaps waiting for an e-mail reply to a question you sent to your manager asking to clarify requirements). When you are blocked it does make sense to move to another task.
Test Cycle
I am a obsessive tester of my own work. This was especially useful in the learning phase on a project. Instead of spending hours implementing content before testing it I would instead implement a few details at a time, push that content into the game engine and test. This implementation-test cycle hones a designer's skill and minimizes distraction and stress. It is easier to solve one problem at a time (i.e., why did this door not unlock) as opposed to a collection of issues (nothing in the level works!)
If the game engine you are using does not support such rapid implementation and testing then get the programmers to improve the engine. Seriously! Enabling rapid iteration saves money and improves quality.
Purge Thy E-mail
I made sure that I answered all my e-mail every day (I tried to continue this process even when I started getting a hundred or more e-mails a day, never quite succeeded but I was always as prompt as possible in delivering replies). I categorized my e-mail| and tried to reply to everything even if my reply was no more than a quick _okay, got it_.
If the e-mail was a task I copied it to my task checklist and moved the e-mail to a deal with later folder so that I could remember to reply to the person when the task was completed.
By moving an e-mail right away out of your inbox you help reduce the time you spend re-reading messages that you have already dealt with.
Folders are an Unnecessary Evil
If your e-mail software has a categorization or color-coding system, use that instead of using folders. Flag the e-mail as it comes in according to a handful of categories.
Basically I assigned mail to one of three categories -- Do Immediately, 'Do Soon, Look at Eventually. I also had other minor categories such as Dragon Age, Mass Effect and so on to label what project the e-mail was about -- the neat thing, and the advantage over folders, is that you can assign more than one category to an e-mail; I could assign e-mail to two categories, such as Do Soon|Dragon Age.
On the discipline side of things -- and you need to have some discipline to be an effective game developer -- I tried to ensure that the 'do immediately' category was cleared daily. Was not always possible but it was a goal to strive towards.
Disclaimer. I don't entirely hate folders. In all fairness, they do have some usages and I would never completely ditch them. Basically color-coding/categories only works wells if you have a limited number of categories. So I still have a folder in my inbox for each story I've written and then inside that folder I have all the e-mail acceptances/rejections for that story. I could use a category system but as I have had over a hundred stories in circulation that would be a significant number of categories (and would make the category list cumbersome).
What Did Not Work
Years ago I wrote my own task management software. While this was helpful for honing my estimates and automating a chunk of my task management it had flaws, the biggest of which was that I could not easily share the data with others. If your company does not have a task management tool it is best to use something simple like Excel because it is easily modified to work with a variety of systems and co-workers should know how to use it (and have access to it on their machines).
Random Bits
Designers are the last line of defense; if something goes wrong, and a designer can fix it and no one else will, then a designer should.
Here's a couple tips that will help increase your value to the company (and probably your satisfaction with the job).
In general these tips revolve around the idea of turning yourself into the go-to-designer -- somebody who other team members seek out when they need information and help.
- Test Everything Test (and send feedback) on every part of the game, especially those outside your area of responsibility. This allows you to understand how the entire game fits together and it hones your ability to give feedback (some suggestions on how to provide feedback are given later in this chapter). If you run out of things to test on your project, test another project in the company!
- Become an Expert Knowing a little bit about everything enables you to assist in a variety of roles but becoming an expert at everything is impossible. If you can master a specialization you should. Generally look at current holes in the project or company (things that are not going smoothly) and that you have an interest in learning more about. This can be as broad as being the 'cinematics guru' or narrowed down to specifics like mastering the certification requirements required to ship a title on the XBOX 360.
- An Open Door Policy Be available. Keep your office door open. Circulate on your free time to talk to your co-workers (but try not to disrupt them). Scan buglists and offer feedback... maybe you see a bug on somebody else's list and know how to fix it.
|
