|
Explain to them nicely that what they want can't be done.
|
|
|
|
|
Any real developer knows that the job doesn't stop after receiving the money for it. Implementing something that's knowingly wrong is just going to make matters worse for you in the future. Present the customer with the alternative and explain why his/her way will not work. At the end of it all the most logical answer will be reached.
<br />
while (customer.Answer != Problem.Solution)<br />
Conversation.Convince(customer);<br />
Those whom have the ability to take action, have the responsibility to take action.
|
|
|
|
|
I have a database query GUI allied to a very fast (1 billion rows per second) inverted index database - when I first developed it and had just implemented the rudimentary selection logic system with And, Or and Not operators I was showing it to a prospective client who was very impressed but immediately asked for a feature request: "The And, Or and Not operators are excellent but can we have a "But" operator?"
Does it need a But
|
|
|
|
|
I certainly hope you resisted the temptation to tell them to kiss it
|
|
|
|
|
Let's just say there was a rather pregnant pause while I formulated my reply - when I did reply it bore very little resemblance to my first thoughts on the issue.
|
|
|
|
|
The customer is not always right, but he does pay the bills. If he isn't hamstringing you with something that prevents success, and thus collecting your check, then you let him slide a little.... There are limits. If he is hamstringing you with something that will cause project failure, then you owe it to yourself to try to talk him out of it. That means getting all your ducks in a row, and trying to convince him.
I got into many arguments with another person here, because he believed the customer should absolutely no say in the process, ever and he would degrade the customer or simply ignore them. I was reminded of the old used-car-salesman joke... the customer asks for a VW bug and the salesman brings out a truck. Just because you think something is how it should be, doesn't mean forcing your opinion on the customer. If he was expecting something else, he's gonna cut your pay or never send business back. Your best bet is convincing, but that means you have got to do your homework and be ready to convince the customer.
Ad absurdem works too. Once we were designing a van that ran computers on a diesel generator. After the first time the generator went out, we asked for a UPS.... it was a biiiiig UPS (to match the big generator). The bill was significant... so the customer, horrified at the cost of the UPS, said, "Why don't we just flash up on the computer screen a message that power was lost and not to panic." I was dumbfounded. I was new here and didn't know how to respond. My predecessor, without even much of a thought, grabbed a sheet of blank paper and started sketching out the most fantastic Rube Goldberg machine that eventually dropped a flag with the message on it in front of every computer monitor, and turned on a flashlight, all caused by the loss of electricity. It was amazing. The customer agreed to the UPS.
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
Though sometimes customers talk gibberish let us make an honest effort in convincing and explaining them the reality. If they are still adamant and arrogant on their egoistic pursuit I believe we ought to leave in their own directions.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
The problem is... once they got you to do something that is completely stupid or wrong, they will realize that it is, well, stupid, and make YOU responsible for messing it up.
The customer is always wrong.
|
|
|
|
|
Isn't it humanly, if you do really senseless stuff for getting a certain amount of money?
|
|
|
|
|
|
Most of the time a customer is "wrong" when they request a specific solution to a real or perceived problem. I find out what the real problems is (this may take some time), I then determine a general solution and if I cannot convince the customer that this is the correct solution, I will delay the customer and implement my solution. If after using the solution, they are still not convinced (depending if I own the software or am writing it for them), I might do what they asked.
|
|
|
|
|
Imagine that your physician would take the word of his clients (as opposed to his own knowledge) as a basis for treatment.
The client is paying for my knowledge because he/she can't invest the time to figure out what's right and what isn't. This implies that the customer is paying to get the best result possible, as opposed to the result that gives him/her the best possible feeling.
That's some other profession
I are Troll
|
|
|
|
|
Medical cases are far from clear cut.
And no, the doctor is not always right when you take consider a problem holistically.
God is REAL unless declared int
|
|
|
|
|
BloodBaz wrote: Medical cases are far from clear cut.
Neither is there a standard recipe for every automation-problem.
BloodBaz wrote: And no, the doctor is not always right when you take consider a problem holistically.
I didn't claim that a doctor is infallible, only that the client is paying the man because he's a doctor. If you're going to doubt what the expert in his field has to say, then why would you even rent that expert?
You're right in the fact that even the expert won't be always right. Now, I'd wish that both parties bring forth arguments, and that the best things float to the top. I needn't point out that there's a high probability that the one who studied the subject and who has worked in that field will come to the table with good arguments.
..because they usually don't. Most of the time it's plain bickering
I are Troll
|
|
|
|
|
I have customers (dept of defence) and users (the boys in green). The users are good at what they do but not good at telling us what they want. You have to keep going there and keep asking, and show them a prototype. They whinge about the user interface and miss the hard bits. You build what you think is right and it's still wrong, you keep trying. This is why defence projects are so often over-budget. The boys are sensitive, you can never tell them they're wrong, you just have to say, sorry, I am too slow, tell me again. It helps to be a woman, I get politeness the male colleagues don't get.
Once the customer insisted on a feature I thought was a waste of time - an admin feature for officers to monitor what the others were doing. I could not pin them down, what do you want it to do, and it just got more complicated the more we discussed it. The project was delayed because of it, they had to re-plan field trials, and it was all my fault. In the end they never used it.
Now if they want me to implement something which is technically wrong, I do it the right way, and say, something they said gave me the idea to do it like this.
If they want me to do something unsafe I refuse pointblank. I have also reported dangerous errors to my boss and refused to continue - if you have ever experienced a 30-ton rocket launcher deciding to act independently you know what fear is. (Fear of what it could do and fear of going to prison if someone gets killed.)
------------------<;,><-------------------
|
|
|
|
|
how customer is smart?
I vote for its depend(last one).
Life's Like a mirror. Smile at it & it smiles back at you.- P Pilgrim
So Smile Please
|
|
|
|
|
A "smart customer". What's that?
|
|
|
|
|
In most of cases customer is non technical person
so it is frequently happend that he may ask stuppied question in terms of softawre development
Its depend on client intelligency wheather he undesrtood our explation
Life's Like a mirror. Smile at it & it smiles back at you.- P Pilgrim
So Smile Please
|
|
|
|
|
When one of my customers is asking for something ludicrous, I dig deeper to find out what they are trying to achieve. With a better understanding of what the customer wants, I can often supply a logical alternative than what was originally requested.
I've found that customers start asking for silly stuff when they start dictating implementation details. To me, that is useful for communication. The customers are using what tools they have to describe what they want. It seems to work better (with noncommercial apps) when the customers describe what business process/issue they want to deal with, then, we in IT can give them useful implementation options.
In 20 years of programming, I can't recall a customer adamantly requiring a feature that was a really bad idea when they were given an opportunity for a better solution. Perhaps I've been fortunate to work with good folks... Or maybe my mind has blocked those painful parts of life.
Scott H.
|
|
|
|
|
The option offered, to "explain in detail", which is non-ambiguous and leaves very little honest wiggle room for "what is detail" kinds of arguments, is perfect in this circumstance. The unstated portion of the option is the artifact creation process that one must have in place. Your customer will appreciate that the "diary" clearly demonstrates that you were trying to do the right thing and that in the future your clarity of purpose should be given significantly more weight. I smell repeat business, implementing the correct solution, and a higher fee.
|
|
|
|
|
... I use to work at a small family owned business. A customer was barganing very hard, the owner gave him some break, then started joking with the customer. Then the customer asked for more discounts and then....
Customer: ... you know the customer is always right.
Owner: <jokingly>Not in my store. I am always right, Customers are dead wrong </jokingly>
Customer: Pays and thanks the owner and walks out.
Needles to say, the customer became regular repeat customer.
|
|
|
|
|
The answers are too much "me vs. them". I prefer to work with my clients in a collaborative manner, rather than a confrontational one.
[soapbox] If this is the general attitude of developers and also of customers/clients, no wonder our industry is so f*** up. [/soapbox]
Marc
|
|
|
|
|
Doesn't the third choice come close to what you are looking
Explain in detail why they are wrong, try hard to convince them, but agree with their final decision
isn't there a collaboration?
|
|
|
|
|
Yusuf wrote: isn't there a collaboration?
No, because in collaboration, while there can be an obvious "wrong", what people try to achieve is better, and one doesn't have to convince the other person, it's just obvious, nor is it "their" final decision, but a consensus.
In other words, it's not a war, it's a partnership!
Marc
|
|
|
|
|
Equal Partnership = Equal Money.
If you are the suppler then there has to be a customer. If you are a partnership then you should both benefit from the product and have equal investment. Not a tradition client customer relationship.
Why is it when you are busy everyone whats it yesterday, But when your not no-one has any work for you?
|
|
|
|