Slashdot Mirror
Giving the Customer What They Wanted?
"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?"
I'm an independent web developer, and as such I have a one on one relationship with the (non-technical) people who dictate the 'features' of the software I produce. Most of the time I'm doing not-so-glorified copy editing, but when I do have to create a maintenance tool or a more dynamic feature on the sites I work with, I find that I start to come up against what I perceive as a certain technical ignorance on their part--which is really a lack of communication between the two parties. Many times we'll get to a certain stage with a project, and our mutual assumptions will all of a sudden rear their ugly heads. Me: "Oh, didn't you realize that javascript/perl/unix/the current state of computer science and physics/etc. won't let me blah-dy blah blah?" Them: "Oh, didn't you realize that if you were going to build that thing it was necessarily going to have that feature because that's just a given?"
Having the relationship with my clients that I do, I find most of these problems pretty easy to solve; talk it through, try to understand what they really want, express the issues involved with implementation in as non-patronizing and non-technical a manner as possible. The most difficult point for me though is the debate between feeding the customers the line "that's not technically feasible" or trying to figure out some way to get what they want. I've found that 9 times out of 10 it's the case that I can do what they want if I push and prod myself a bit harder. What's even harder is those times when it's a balance between what the customer needs, what they are willing to pay for, and how long it might take me to do something, and I'm really not clear how it might all play out. An interesting problem.
I would also imagine that my personal solution to this problem wouldn't scale very well if you shifted it to a team of programmers working with a marketing department, customer service department, etc. My "organization's" small size is what enables me to solve these problems quickly and easily.
Sorry I've not supplied any real specifics, I really shouldn't; just wanted to comment on this issue because I definitely find it personally relevant.
One person whispers a short phrase into someone's ear who then passes it along in the same manner to another person, until the phrase gets transcribed by all people in the room, and the oft-hilarious result then disclosed.
I've often thought software development is like that.
Unless you're contracting directly with the customer, and note the requirements in his/her words, translating them to a technical equivalent (and, of course, translating back, and making sure you got the jist of what he/she wanted), you run the risk of these translation problems.
Often, such insulating layers are placed between well-meaning programmers and the customer to make sure they don't try to deliver more "work" than what the customer is willing to buy. This gets difficult because the programmer where the buck ends is expected to make the customer happy, but to spend the least amount of time possible on it, so that he/she can be assigned to the next project.
I've always thought that was a bad idea. Novice programmers' enthusiasm can be restrained by senior project leaders who might actually be the contact point with a customer -- they're called "systems analysts" for a reason -- the supposed ability to translate human-speak into technical requirements and estimate the work to be done.
In an ideal world, this estimate would be returned back to the customer via sales and a human-speak description of the work to marketting so they can get a feel what piece of it might be reusable on other projects and to feel the pulse of market desire.
More likely, much of this initial analysis is done by people not qualified to do it (sales and marketting types, though technically savvy people do exist in such roles), and critical customer requirements are either lost or not questioned.
I've been in situations where a customer's technical team rejected outright our technical proposals purely because of miscommunication across our respective management hierarchies. I've also been in situations where such miscommunication finally gave way to both technical groups getting together to convey an understanding of what's really wanted, usually after wasting much time and money. Often, in such meetings, one can almost feel the light bulbs finally turning on above the heads of those responsible for the confusion: "Oh! So when you said you wanted it ON a hard disk, you meant INSTALLED on the hard disk in the system, say, from a CDROM, and not DELIVERED that way!!" In all fairness I can see both ways being legitimate software delivery systems (the latter particularly if you're serving as hardware integrater too), but it is important to recognize the ambiguity and resolve it early.
What I've found works is a close technical liason to define the work to do, but, of course, no programmer delivers anything except through official channels, which are gated by the money stream.
You could've hired me.
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"
...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.
Karma: Chevy Kavalierma.
There's a job called 'systems analyst' that covers this. Back in the 80s I was one (later I became a programmer). The job was to act as liaison between the customer (user) and the computer people, and speak both their languages.
System analysts then make up the design documents (called a 'functional requirements') for the programming team and customers to serve as the 'treaty' (or battle plan, if you like).
It's a profession that may have fallen out of favor in rapid startups, I guess-- isn't edgy enough. It's essential for any good project, but too many people are in a hurry and do the usual "I'll write up the requirements while you start coding, go!"
A.
Well, how often do you talk to the customer? Depends upon how big the company is. It's broken down into one of two scenarios:
Large company: You will never talk to the customer. Any communication between you and the customer will pass through at least five people who will all either add in their comments, edit text at whim "to make things clearer", or just make stuff up out of the blue.
Small company: You will always talk to the customer. In fact, you will never avoid being able to talk to the customer, even if you have four other projects that need to be done by end of day.
No, I'm not cynical. Why do you ask?
I've almost never met a customer who actually knew what they wanted. At least, not consciously; but over the years you learn different ways to pry information out of them... sometimes it takes visual aids (in the form of an interface mockup to look at), or lengthy meetings, or in extreme cases a hammer and chisel, but I've never had a project where the actual coding was anywhere near the bulk of the work.
h alf.ht ml
Unless you're part of a team working in a large organization, the job of programmer is less than half technical IMHO. As a freelancer, I feel my value to the customer lies more in my years of experience working with non-technical end users than it does in my understanding of a particular language or platform. Of course, that's tough to get across to someone you're trying to get work from...
The problem I'm having with my current main project - a customized time-tracking application - has more to do with requirements-creep. The customer (a state government agency) keeps coming up with strange and irrelevant types of information they want gathered along with the stuff that is actually necessary for the research. Fortunately, I'm just a subcontractor in this case; there's a layer between me and the client, and it's those people who are really suffering from their behavior since they'll have to figure out how to cope with this non-orthogonal information while compiling the report. All I have to do is keep adding more buttons and forms, periodically reminding them how much more complicated and intimidating the interface is becoming and how far past our original budget we are... it's actually nicer than a lot of other jobs I've had.
Another sideline I have is doing websites for friends in the entertainment industry. One site I've been trying to get started on for over a year now is for a comedian who, by his own report, is so bad at self-promotion that he freezes up when the emcee asks how he wants to be introduced! So this has been a long, hard slog to get anything out of him to put online...
Anyhow, enough rambling. The point is - helping the customer to figure out what they actually need is the unspoken part of the business that they don't teach you about at school. It's more than just leaving the jargon out of your conversation, and it's a skill too few of us have developed.
This pretty much says it all:
http://www.netfunny.com/rhf/jokes/91q4/prog
Perfectly Normal Industries
I think the story in the article really illustrates one of the most important things about giving the customers what they want quite beautifully.
Don't let the customer just hand you requirements. By virtue of the fact that they are coming to your firm for help, it is fairly safe to assume that they aren't experts on the kind of product you are producing for them. Because of this, they probably don't know enough jargon or have enough knowledge to translate all their ultimate goals into a good list of requirements.
When the customer says, "this product also has to do foo," make absolutely sure you ask them why they want it to do foo and what place activity foo has in the process of getting whatever productive work they want out of the software to be done.
Another classic example: professor goes to a computer lab attendant with a few sheets of paper, and asks them to be scanned. The student scans them and hands them to the professor as Photoshop images. The professor takes them back to her computer & tries to load them up, but doesn't have photoshop, so she can't load them. She calls the help desk, & the helpdesk helps her install photoshop.
Then she complains that she can't edit the text in the images, and ends up going through a crash course on editing images on Photoshop. Only after all of this happens does someone get around to realizing that since the papers were all text documents, she probably wanted them run through OCR and handed to her as Word documents, not image files.
Because of this the best way to develop software is prototyping. I strongly believe this.
Extreme Programming, Rational Unified Process, MS Solutions Framework... with little variation they believe in small iterations and phases.
My website is http://www.chrisranjana.com and I do php perl freelance work and I have felt the same way a numerous times.
1) isn't web designing included in your quote I thought it was default ?
2) oh for making changes in those user options I thought there is going to be an admin panel by default ?
so what is the best way to solve all these issues
Chris ,
Php Programmers.
It's been my experience that customers do know what they want. However, most often their frame of reference is their existing work process and supporting software. Typically, customers expect new software to alleviate specific annoyances in their current environment, but they have little insight into how new software might transform their working environment. Developers should bring that insight to the effort, but, again typically, are disinclined to study the customer, preferring to go off to their cubicles and code to a requirements document. Inevitably, someone in the customer camp begins to get a clue, prompting changes to the requirements.
Requirements should be written by techies who have actually worked alongside the customers long enough to understand what it is their are really trying to do. The author of the requirements should be required to explain them, in lay terms, to the customers, to ensure that both sides think they mean the same thing. And, foremost, both the customer and the tech staff must designate one individual each -- someone who has at least a passing acquiantance with the other's working environment -- to act as a translator, a bridge, between the communities.
-- Slashdot: When Public Access TV Says "No"