This is a great article and something that all developers and those who manage developers should review. In my experience, not in the game industry, there are times where you are going to work late - it is going to happen. However, if you plan and work smart those occasions can be rare - which should be the goal. On our team, we even had a lot of turn over due to family issues, people moving, and financial issues - and we were still able to meet are deadlines.
One item that was missingin the article, or perhaps I overlooked was the point of using the QA team. The mention of zero-defect milestones goes hand-in-hand with this. My roomate was the QA manager on several projects I have done and we both worked very hard to get QA involved in all phases of development. This allows development to write smaller pieces of code and turn them over to QA for testing while the team move forward. This can be tricky, but we found we were able to write quality code to begin with and spend the beta 'month' just tuning and optimizing the system. I found that in order for this to work you *really* need to plan your work and establish criteria for moving forward. This is especially important when the judgement is almost purely subjective. The other benefit is that your QA team is on top of the game from the get-go, and that means they are able to deliver more useful feedback to the developers.
We were rewarded by never having any severe problems reported by our support departments. This allowed us to continue to innovate and move the project forward. I have found that constant bug scrubs can cause burnout faster in developers then almost anything else - espcially with me. It makes sense too, as fixing bugs is not nearly as fun as inventing a new subsystem. If the project turns into "fix as many bugs as humanly possible and increment the revision number" things go south quickly. So I am a big believer in doing things correct the first time. Games are a little different, as you usually do not have Quake 4.0, 4.5, and 5.1 - but if you make use of a lot of milestones, ala an incremental development cycle, it can feel this way.
Something else that we did, which I don't know if it is possible in the game industry, was to get financial rewards for patents. This is sort of sticky subject with some people but the reality, in our case, was that the company owned the IP anyway so we might as well get some sort of reward for it. We used the money as a joint pool so at the end of the project we could take a week off in Tahoe, ski and gamble. I was never very fond of "team" building events but I thought the idea of "us" working towards a reward was good team building.
Anyhow - I hope these ideas are useful in some way. These projects were some of the best times I ever had in the Software Industry and I am a firm believer that the points made in the article work and *do* make your job enjoyable.
|
Posted - 4/3/2002 4:50:10 PM
