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

Customers never know what they really want

[Mr. Shiny And New]

This is why software evolves, and this is the power of extreme programming and rapid prototyping approaches to software development. You try to get a good idea up front what the customer wants, but then you build stuff really fast and show them something. Then they can try it and see what they think of it. You will find that new requirements pop up and old ones disappear.

I thought

[inerte]

That this was one of the main reason Extreme Programming was invented.

Differing priorities

[MrWa]

"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."

I think it is always unreasonable for either person to do the other's job: that is why there are two people there. Nothing gets an enduser more upset than not being able to do what he wants - being forced to do something one way because the programmer likes it doesn't cut it.

At the same time, the enduser shouldn't try to write the software! Instead, describing what the user would want to do with the software, discussing it with the programmer, and letting the programmer decide the best way to implement it should be how it is done....I've yet to see it happen well, though. Both sides have egos to protect, it seems. The endusers are dumb and don't know what they want; the programmers don't understand what the enduser wants to do or why he needs it.

The biggest complaint seems to be feature-creep or missed specifications because the enduser wasn't aware of what he wanted. This is where programmers typically need help, it seems. The figuring out what the customer wants and finding out how to implement seems to be a very low priority for most programmers...

Use Cases

[farnsworth]

Use Cases are the closest thing to a silver bullet I've come across. if you treat use cases as a high-level, *living* spec, and not a UI abstract and or component diagram, you save everyone a lot of trouble.

example:
Use Case For the "View of Contact Addresses"
Actor: user
Preconditions: there are at least one contact in the database
Motivation: Actor wants to locate a pacticular address
Outcome: Actor locates particular address
Step 1) (left blank until you agree on the above)
Step 2) (blank)
Step 3) (blank)

If you *start* with this, than you and the client have a lot of wriggle room as to how you finish the use case. with a sortable tree? or a text input that looks up contacts by name? it doesn't really matter as long you both agree to the above.

too often, the two parties talk to each other and both come away with two entirely different ideas of what the use case is. if you come up with a really basic use case (like above), *write it down* and pass it to the client for review, you've saved yourself a ton of work.

Re:Use Cases

[e8johan]

I must agree! User cases is the way to discuss software with users. You can draw user cases as in UML to make things really clear.

In mu profession I often write software to replace or complement older software. My applications are often used to reduce paperwork and to avoid doing things manually. To be able to do this in a good way, you need to know what your user does how and when and, idealy, why. This is why I often spend many hours letting the users explain their current work to me. When they are done, I put together a number of user cases trying to redescribe what they've explained to me and then schedule another meating. On the second meeting I try to explain what the user is supposed to do, and I explicitly as the user if this fits into the way they work. This process can take a few iterations 3-5 meetings (including the first 2), but always yeild good software and great user feedback.

Write Use Cases

[mjlesko]

Written Use Cases, until I saw and used them, thought they were a silly waste of time. Now I've used them and think they are indispensible for facilitating communication between the business and technical disciplines.

This is NOT UML!

Business Subject Matter Experts write the Cases, at the least the high-level ones, forcing them to really think out what they want and how it should work.

I recommend "Writing Effective Use Cases" by Alistair Cockburn. After looking at several resources, this is the only book I've found focusing exclusively on this area, and one I have found useful.