Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.
Human resources and requirements are changing.
We have already had the documents and a plan. Will there be a happy ending?
The progress will not go smoothly, the tasks will delay, and the human resources will be idle or will leave at some time.
What should we do, when the schedule is delayed, and the next task shall start?
The advantage of assigning all tasks at the beginning is able to estimate the whole period of time. However, when we estimate or predict something, it means there will be inaccuracy or errors.
If the excutor knows the starting time of his next job, he will be rushed to be "on schedule", or will pretend that the working task is completed. If we test inattentively, and let the working task pass, we will pay it back in the future. If we verify it seriously, the next job and the whole schedule of course will be delayed.
Shall we flog our workers?
We must understand the future is un-certained and every project is a new challange waiting for explore. If we know exactly the whole period of time, that is not a project, it's just like something we have done before.
Being different from assigning the excutors in the first, I try another way dynamically. The estimation is for whole schedule roughly, when the next job is about to start, the true excutor is assigned. This kind of method results in dynamic or floating period of total time of course, but as my experience, the excutor can actually do their job with good quallity when no other thing is chasing him. In this case, the management bravely keep un-mature workers and tasks at the same place.
And of course, the next job will "always" be taken by any idle member "in time". Who takes the most jobs is the one with high productivity.
Back to the game product, its requirements somehow change faster than other kind of products. There are many reasons for changing.
- We change, because the idea is not fun after the prototype.
- We change, because our technology level cannot support our idea.
- We change, because the schedule is too long beyond our budget.
- We change, because the boss don't like the color of background.
- We change, because we complete the project too fast and still have lots of time.
- We change, even because we spend on the project too long, the market changes.
The bible of design pattern loudly tells us "requirements are always changing."
Even Workers with fully enthusiasm will wait and see if the requirements do not move anymore. Because if the requirements keep changing, the tasks will not be finished obviously. Even we complete them as fast as we can, the new tasks will keep popping.
This is not a good thing to mangement. However, as my observation, they are not this kind of workers at the start, this environment effects them.
From the viewpoint of result, the changing of requirements will have these type:
- Totally different requirements, completely re-work the features. This kind of changing will need analysing again, estimating again, and implementing again. From the bright side, this kind of changing usually will have a new schedule.
- Reduce the requirements, this kind of changing is friendly to excutors. If we did plan in detail, we can skim some parts to achieve the goal.
- The type of requirement propagates, a animation of waving a knife is not enough, now we have to add sparks, add the shadow of blade, the background scene changed to the moon, and back to earth after this animation. This kind of changing is annoyed, because it happens gradually. And this kind of changing will ruin the architecture of system designed originally. It sometime is a nightmare to those workers.
I can understand the necessity of changing of requirements, however in my oberservation, the management often ignores that the schedule shall be changed at the same time. We know that the schedule changing means that the budget changes too. No one want to take the responsibility. Obviously over-time work usually is the first strategy been used. If no miracle happens, we can show mercy later.
This kind of thing hurts the team, not only we ignore the risks and possiblity that we can't make it in time, but we ignore the reacting ability to possible danger. We ignore the mayday signal send by person with vision, we hurt the trust between our team members.
When the schedule is not possible to excute, the solutions are obvious:
- Increasing time.
- Reducing requirement.
- Looking for more hands.
The sequence is in the order of quantiy that they help.
Try deciding a reasonable schdule to the whole team, do not be chased by our schdule.
The procedure of requirement changing shall include these steps:
- With somehow certain reason, we change the requirements.
- We discuss how it will be.
- We analyse and estimate the new schedule, if that is not acceptable, back to step 2.
- Replace or insert to the schedule.
- Modify the documents.
- The tasks are excuted by programmers, artists, or designers.
As my experience, there will be a disaster without completing this procedure,
For example, with only step 1 and 6, the boss shows up, he convinces artist changing the model he doesn't like. I am sure the model will be replaced at the day after tomorrow.
Without step 5, someone will implement the old document, and the quality assurance may be produced by this old document after failing in test.
Without step 3 and 4, just change whenever we want, extra works in old schedule, over-time works there should be, bad ending.
Each modification will take some time, even just a small hour. Those "one hour" will finally accumurate to huge thing we can not ignore.
I humbly think that the best time we should insert the tasks of requirement changing is "after this milestone". We shall let the excutors rush in current goal without hesitation. Start new specification at next version, that will minimize the damage to our team.
At the end of this article, I cite the ancient wisdom of the Confucius
"The most important is trust, the second is living(of members), and keep the weapons(our products) at the last."