Giving the Customer What They Wanted?

Longjmp asks: "Once again I though about how often programmers find themselves in a situation where they may have a specification for their work but, as it turns out later, the specs didn't really meet the customers' requirements. Techies and customers almost always speak a completely different language and likely the specs were written by a tech person who doesn't quite comprehend the customer's workflow, or sometimes even worse, by the customer himself, trying to 'speak tech' without having the technical background. In either case, the resulting product would be right out of a Douglas Adams novel: 'almost, but not quite, entirely unlike tea.' How often do you (as programmers) get a chance to talk to customers directly or watch them in order to understand their workflow? How often did you as a customer (or user) talk to the techies? What are your experiences?"

"Sometimes these different views can result in almost funny situations:

Back in the stone age of programming, we had a customer who wanted to have the result of a database query sorted by a specific field ('usable' databases at that time were either incredibly expensive or simply unavailable, so we had created our own proprietary database). He asked for this because the old software they were using could do this. However, we couldn't, and everyone was horrified by the thought of programming this 'ASAP' but we were ready to do it.

Eventually we talked to him and asked him what exactly he wanted this for. It turned out that he didn't even want a sorted list. He wanted look for a specific value in that field (something the old software couldn't do), and he got it by looking at the sorted query results. Our software, however, was capable of searching for field values already and return matching results only.

At this point both parts were happy: he got what he wanted and we didn't have to write a single line of code. Of course, there will always be the geek with the 'use-it-my-way-or-f*ck-off'-attitude. For me however, talking to customers and trying to understand what they want (as opposed to what they tell you) was always a big part of what made developing software fun and satisfying.

So, how often did you find yourself in a similar situation?"

Comments

Where do I start with this one.....

[MrBlack]

Where to begin??

As one other poster pointed out the customer may not really know what they want. They may have a vague idea, but haven't really thought about it thorougly enough. I see this sometimes when I'm talking to customers when you say "well what about X?" And this little light goes on inside their heads about some aspect of the system they'd never considered before, and reams of new requirements come spewing forth. If it is a time+materials project I try and work with them to fit the new requirements in to their budget, if it's fixed price they can sometimes get nasty and say they just "assumed it would be covered because Blah works that way" or some other nonsense when both of you are quite aware that up until 5 minutes ago they'd never even thought about it.

Another classic problem I've seen is when a "typical user" is chosen. Often this person is NOT a typical user of the system, they are the manager of a typical user, or a business analyst that "knows this area inside out". Politely listen to what this person has to say, and then go and find out what the _REAL_ users of the system think.

Another common defect is the "one line paradox specification". It goes a little something like this...."The new system should work exactly like the existing system, only better, and over the web".

Another common problem is the "user as frustrated interface desinger".. where a user will come up with very wild/unconventional/impossible ideas as to how items in the user interface should function. This is somewhat related to the "typical user" problem. This users crazy interface requirements might be possible, but you will end up building a system only they could like or even use.

Another problem is "users expectations completely out of synch with budget"..you have a budget for X hours, but the users have no idea of this and will run wild with features that will make their lives easier(if the project doesn't get canned beforehand), or playing amatuer graphic designer, screen layout games. Make not of all their suggestions but make sure you run by all the features they suggest with someone who is paying for what you are doing before you go and implement them.

Overall I would say that ineraction with users is great, but beware that the "user"

1. Has given as much thought as they can muster to all the aspects of the system before they talk to you...(this can be hard since some users seem totally incapable or unwilling from going beyond their abstract sketch of a system into something more concrete)
2. Are actually representative of the end users of the system
3. Is not an evil crazy user interface genius
4. Has a realistic understanding of the scope and budget of the project.

Re:Differing priorities

[greenhide]

...the programmers don't understand what the enduser wants to do or why he needs it.

So, ask why.

I have found that when you ask why a customer needs a particular feature, you get a much better understanding not only of what s/he wants, but how to best implement that feature.

Often, the customer attempts to speak in a more technical arena. It is at this point that they frequently make technical requests that aren't feasible (such as the example given above, with the sorted query results). When you ask them the what and why of that feature, you get a better understanding of what you actually need to implement.

I think oftentimes the problem with specifications is that the way that the customer phrases their needs. I recall trying to find directions to an Ethiopian restaurant. I was asking people where a given section of town was and wasn't getting helpful answers. Finally, when I rephrased the question to state the kind of restaurant I was looking for and the street it was on, they were able to give me better directions. I hadn't wanted to state my actual goal--"I'm trying to find an Ethiopian restaurant"--because I didn't want to broadcast what I really wanted (I thought it would make me look like a tourist which, admittedly, I was). When I actually stated my goals, I got a better response.

You have to squeeze better responses out of the customer. While it isn't my job to tell a customer how to do their business, nor is it their job to tell me how to program, I find that each can inform the other. Through my development work, I have helped many of the end users get a better conceptual understanding of their businesse processes, and their requirements have forced me to make creative programming decisions which have, in turn, made me a better programmer.

Basically, the fewer walls between developer and customer, the better.