As a developer, it is crucial that the client/employee clearly defines what they want. Specs can come in many forms; written, screen shots, interactive, a combination of those and other techniques; whatever it takes to get the message across clearly and succinctly. They serve as a underlying basis for what you need to do. Don’t know how a specific module you’re writing is supposed to work?, look at the spec, it’s all there..hopefully.
There is nothing more annoying than doing work and have the spec changed/altered afterwords. Sure, this wouldn’t be the case in a agile development where the main objective is to go with the flow and change things as necessary in iterations. I have had the opportunity to work on an agile project and it was very pleasant. There is still organization within the project, but it’s just a little more fluid.
However, waterfall development is a different story. It needs to be approved and verified by a project manager, business and anyone else involved (VP’s, Marketing, Editors, Designers, Devs, etc). This type of development model is very simple once everything is in order. It never is. There is usually miscommunication somewhere, different expectations, whatever. Once shit starts rolling down the hill, it’s up to the developer to follow the spec and do the job. If everything is written down and organized in the proper way, development is a breeze. However, if one person has a different interpretation of what needs to be done, if someone fudged up on time estimates, or if the spec makes no sense to a developer, waterfall development fails; everyone depends on everyone else and one error can put a cramp in your style. Not cool.
So, what can you do to prevent it? Well, you can’t control the actions of the people around you, but you can control what is expected out of you. Here are some tips that I picked up along the way:
- Confused?: If you don’t understand something, speak up immediately. It’s better to get it out of the way early than have the project delayed
- Prototype: If you see a potential problem that can slow things down, but are still required, build a prototype. Isolate the problem and see if it can fit into the bigger picture
- Estimate: If you are part of the requirement process, know your environment and make note of anything that would be time consuming or difficult (or impossible) to achieve.
- Padding: If you think something will take x amount of time, add 20-25% more time to it. Trust me. It’s better to slightly over estimate than underestimate and have to work later than you’d like
- Revisions: Prepare yourself for revisions. People love to be sure of what they want until they start to see it unfold, then it’s “move this here”, “add this here”, “let’s try this instead”. I wish this weren’t the case, but hey, people will be people after all
- Time is money, don’t waste it