This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: What the customer wants Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

Regarding the matter of a project's "requirements", many people will tell you that your customers don't know what they want. Just as many will tell you that customers do know what they want. Neither branch of this dichotomy is useful.

I'm always put off by the suggestion that "customers don't know what they want", or that they "know what they want but not what they need", and that it falls to someone on the project team to divine the requirements. (I've heard this asserted seriously.) On the other hand, I've also heard something along the lines of "if we do whatever the requirements say, at least someone else will be to blame when the software turns out to be useless". Too many teams expect that the requirements will be handed to them on a silver platter.

When I entered the field about 15 years ago (counting from the first few occasions someone asked me to solve a problem of theirs by writing software), I believed in "customers don't know what they want". I knew better than my customers what they needed. One sentence of customers' requirements was enough for me to generate volumes of source code, or pages of product specification. I preferred the former, and grew cynical about the latter.

Later on, I started to insist that customers should know what they want. Work would not start until I was handed a complete product specification. If anything in there was incorrect, it was someone else's problem. On several occasions I invested a lot of effort in tracing a bug back to someone's incorrect spec, so that I could come back with "I did just what you asked for, and that turned out to be a terrible idea".

Not only am I familiar with both attitudes from personal experience - I went back and forth from one to the other over the course of my career, and it's likely that I occasionally exhibited both on the same project. I'm not a bad person, so I suspect there was a sensible reason for both attitudes. If I had to name it, I would say that both attitudes ensured I could do my work with a minimum of contact with the customer. (Working with computers has always been a lot simpler than working with people.)

The most important thing I learned in 15 years could well be the realization that solving someone's problem with code involves listening to that person.

Nowadays, I expect the people whose problem I am solving by writing code to be articulate, and to have something to say about the problem. My own responsibility is to ascertain how code will help solve the problem. We (my customers and myself) are exploring the problem; that is a joint responsibility. What the customer wants, primarily, is for me to help as best I can.