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

You're lucky.

[TheSHAD0W]

If you're not a lone coder, who is able to make up his own spec and make sure the software can do what the customer wants, the only time you meet the customer is when the sales rep has completely fubared the job, and he and your boss and the customer are all screaming for your head. This is a very common problem for large shops, where a middle man who can barely code is speccing the job out, and is why the spec winds up being revised every few weeks.

That's not it but I'll know it when I see it.

[sideshow]

That has to be the worst thing a client can say to us. Things are better now in the web business but in the last couple years we couldn't just tell the client to fuck off if they deviated from the signed definition of "done".

The second worst is: "The CEO who has never even cared about the website until now finally looked at and he hates the color blue." This is after 3 months of building an e-commerece site.

I aggree....

[oliverthered]

I usually put together a spread sheet of use cases, what currently hapens, in the case of a bug or automating a process and what should happen.

There's then a bit a back and forth, itterating over the processes until both the user and I understand what's going on.

If the user asks for something then I will always re-write it in my own words and get the user to confirm that this is the case.

an example may be

Process:

MTA's with an MTA between the current risk and the time of the MTA

e.g. A customer asks for his wife to be put on the policy in a weeks time and then a change of vehicle in two weeks time, the aditional driver MTA is in-between the current risk and the COV.

Resolution:

an MTA must use the risk at it's effective date, if the in-between MTA is deleted, it must delete all MTA's after it.

user comment 1:

Is this not the same as CLX003 ? If not further detail required[CLX003 being another process listed on the sheet]

response: (use case, a bit more detailed than the first)

A customer phones up and asks for his wife to be put on the policy in a weeks time. A couple of days later he says he's moving house in 2 weeks time:The first MTA is actioned 'between' the current risk and the second.

the use cases are also good for testing.