Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: They don't specify because they don't know what they want

by Sherlock (Deacon)
on Oct 02, 2001 at 20:03 UTC ( #116165=note: print w/ replies, xml ) Need Help??


in reply to They don't specify because they don't know what they want

This is a very common problem when creating software systems. More often than not, the customer comes to you with a problem they want solved. They usually have a rough idea of what they want in order to solve the problem, but that rough idea is usually a lot rougher than we'd (as developers) like.

There are a number of things that can be done to counter this, and you've already hit on a number of them, such as giving the customer more time to influence the project and also to get them more invloved in the project. The second concept, getting the customer involved, is VERY important. If the customer sits back and simply waits for results (and you allow them to), 99% of the time, you're going to give them a final project that isn't what they expected and probably doesn't do what they wanted it to. Obviously, this is not a good situation. You need to actively get the customer involved. Bother them. Question them. Keep hacking at the problem until both of you know exactly what the system is supposed to do. If you do a good job of this, what you eventually hand over to the customer will be exactly what they expected and they'll be much happier with the project.

So how do you keep the customer involved? Like I said, keep questioning them. Try to identify anything about the project that you don't know for certain - anything from how something should be displayed on the screen to complicated business rules. Believe me, your customers like to feel like they know their business (don't you like to feel like you know how to write software?) and they'll be more than happy to talk to you about how their business runs. This is a good way to get the customer involved right away.

Another good method of getting the customer involved and verifying concepts is to create a rapid prototype. This is a rough mock-up of the final project that doesn't do a whole lot, but it lays out the basic interface and "look and feel" of the final project. Showing this to the customer can help identify and resolve issues with future functionality and interface early in the development process. Of course, rapid prototyping isn't without problems of its own - look here for a fairly extensive node on the subject.

Of course, one danger with this whole process is to allow the customer to alter the projet requirements throughout the entire process. At some point, you need to be able to "sign off" the requirements and tell the customer that this is what you'll be getting. At that point, the requirements have been worked out to the point where the customer will get what he/she needs from the project and you will be able to complete it on time. Once the customer signs off, the project need to go into some form of "change control." By that, I mean that the customer should have very limited ability to change the project. Only absolutely necessary changes should be made (something that would cause the project to fail that had been overlooked). Why must this be done? If you allow the customer to keep adding new features as the project advances, you'll run into the horrible beast known as scope creep. Soon, you'll end up with a project so large that you'll be unable to maintain it or add to it. This is a very nasty situation to get into. After that sign-off, any new features that the customer wants should go into a later release of the software or some such thing.

So I've babbled quite a while about this topic. It really all comes down to one thing that you've already hit on - customers seldom know what it is that they really want. There are ways to get around this (which I've been trying to outline here), but the most important thing to do is to know, ahead of time, that your customer is clueless. Not that they don't know business, but they don't necessarily know your business. It is our job, as develoers, to teach them as much about our business as we need to learn from them about theirs.

- Sherlock

Skepticism is the source of knowledge as much as knowledge is the source of skepticism.


Comment on Re: They don't specify because they don't know what they want

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://116165]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2014-07-26 13:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (177 votes), past polls