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.
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:
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.
3.14.252.56