Rory feels pleased with his results; so pleased that he takes them to Mary to show her. He is rather disappointed when she looks at it and says, "I don't think that will work."
This is not an uncommon occurrence for a developer. It is very easy to get so intensely focused on a vision of what an application should look like that we fail to appreciate that chosen options do not actually suit the end user's requirements.
There are two methods to deal with this. The first requires that we get the users to create a detailed specification of what they want before we start, and then we develop to that specification. The second, is to start with a rough outline of what is required and then to involve the end user with the project development, showing them mock-ups, prototypes, and pre-production versions. At each stage, we take into account the user's comments and modify the design to suit them.
When creating applications for a separate organization, the first method has a lot of benefits, especially where contracts and payments for work are concerned. However, in the environment Rory finds himself, two things make the second method more appropriate.
- One, to create a specification with the level of details required to provide all the information needed through the development, takes time and Rory's tight deadline makes it difficult to set aside time to create a detailed specification.
- Two, probably more importantly, the end users are not sure themselves of what they want and therefore would be unable to create a detailed initial specification.
It is my experience that when developing small business applications, it is uncommon for the end users to have a very clear vision of what they want. They also commonly have a poor appreciation of what functionality can and cannot be provided by a small application. On the rare occasions when detailed specifications have been available, working with the user throughout the development has led to variation away from that initial specification and a better application as a result.
A problem with this method is that development can become aimless and meander, achieving little that is useful. The developer needs to ensure that they work towards a goal. We may not need to have a detailed map of how to get there, but we do need to know where we are going.
Fortunately, there is one thing that end users are always clear about. They know the problem they need a solution to. Always keep in mind the users' problem that is being addressed and make the solution to that problem the key goal. Put that goal at the top of your task list and remind yourself of it throughout the development process.
In Rory's situation he should do the following on starting a new project:
- Determine as clearly as possible the nature of the problem or issue the application will address. Write this and place it somewhere that will remind him of that goal throughout development.
- Initially, he should create a rough outline of the solution and discuss it with the users before starting development.
- Endeavour to create mock-ups and prototypes as early as possible so that users can see and understand how the final application will appear at an early stage in development. This will allow them to provide useful feedback early on in the process.
- Prepare him for the occasions when users will decide that what has been done so far does not suit their requirements.
It is always more fruitful to start development and then have to modify it as the specification develops, than to postpone development until we have an ideal specification. Therefore, the developer needs to be ready for review meetings that do not go as expected, and changes in the specification that were not foreseen.