|
|
Any tech support department will have stories like the following, the gist of which really happened at my company:
Customer: Your program won't start!
Us: Hmm. Well, let's try such-and-such a test to see if that tells us anything.
Customer: OK, let me quit your program first.
Us: Excuse me, did you just say you were going to quit the program? But I thought you said the program wouldn't even start?
Customer: Yeah, that's right. So? I don't understand what you're asking.
It took us almost 10 minutes to understand what the customer was really saying. After all, the program obviously must start, or else how could he stop something that never began? We eventually discovered he was merely confused that our program's GUI looked different from last time (because he had accidentally turned on the Advanced View mode). Furthermore, the customer became bothered when we asked questions to clarify the situation—"Why are you asking me all these questions? Why can't you just fix it?!?"
After two or three rounds of such conversations, who wouldn't think that customers don't know what they're doing? But try to see it from the non-technical customer's viewpoint. His behavior makes perfect sense if you realize he thinks of software as if it were any other product you might buy in a store.
Suppose your car was making a funny rattling sound. You take the car to a mechanic, and tell him, "It makes a rattling sound." The mechanic will probably say, "Leave the car in our garage, and we'll call you with an estimate later today." And that's it, you're done! Unlike the software world, an auto mechanic doesn't ask, "What operating system are you running?" He doesn't say, "Please try such-and- such as a test." He doesn't ask, "Can you look at your car's event logs and read us what the first line says?" He just fixes the problem. No further effort on your part is required.
Suppose you bought a new blender and it broke after a couple months. You call the manufacturer, who will say something like, "OK, just send us the blender with the receipt and we'll ship you a new model." They will not say, "We still haven't been able to reproduce your issue. Could you please provide some additional information about your configuration?" Again, they just fix the problem without you having to do a thing.
Suppose you bought a new shirt and then discovered the threads were unraveling. When you return the shirt, the store won't say, "I'm sorry but that is a known defect in the product that won't be fixed until the next version." Instead, the store will either refund your money or else give you a different shirt—either way, they just fix the problem.
Customers want you to just fix the problem with your software, too.
Unfortunately, software is different from any other product. Software is the only product where even the very best examples inevitably ship with bugs on the first version. Few other products require the same detailed "interrogation" about the customer's setup to diagnose a bug. Sadly, you'll never be able to entirely eliminate this: You can get a lot of information from the techniques described in the sections that follow, but for really nasty bugs, the only way to learn everything you need is to ask the customer lots of questions. But try to remember the customer's viewpoint so you understand why your customers are so bad at describing their setup.
Meanwhile, there are a few techniques you can use to reduce the amount of customer interaction needed. Anything you can to gather data through means other than asking the customer questions will pay big dividends. Not only will this make your customers happy, it will also make your job easier.
|
|