To briefly recap Part I, the idea is to try to establish a rapport while getting more information, as well as learning about what kind of user is behind the report. By now, you have heard "the story of the bug".
- After hearing the basic story, decide whether you have a clear enough understanding of the problem. If so, restate it to the user to see if they agree. At that point it mostly becomes a negotiation to make sure that any remaining disfluencies are ironed out.
- If you feel that there are still gaps or confusing elements, it might be because of one of a few things:
- There is some word that you both think is clearly defined but which you are actually using differently and that is preventing good communication.The key here is to focus on the phrase that is leading you astray. The user might say "and then the mouse stops working", and they really mean that they can't click on something that they think should be clickable, but in your head you are imagining some kind of driver or hardware failure. Try to get them to state the problem in different words or better yet, see if they can demonstrate the problem for you live (assuming you don't have a major physical distance issue).
- The user keeps restating the problem in terms of the way that the system is currently operating (which they think of as a wrong) but is not stating what they actually want.The user may not really know what they want, they only know what the don't want. In that case, it is often helpful to start offering up your own countersuggestions to play a little game of "warmer/colder". If they say, "the reports are generated biweekly", you might counter with, "We could easily generate them every week". If the problem is that they want more frequent reporting, they might continue along that line and say, "How about twice a week?", but if the problem is that their inbox is choked with stuff already and they don't need that much information, they might say, "no, no, that's even worse". At least you can start to see the direction in which the change should be made.
- If you reach a state where the problem is not clear, but at least the steps to reproduce are, then it is often useful to end your conversation with the user and move on to replication as that can give you a more direct understanding of the problem. Once you can see if firsthand, then you can always call back the user to gather more information.
- If you determine that the user is making a feature request and not a bug report, be upfront about it. "I agree that what you are describing would be very nice to have and would save you time. It would probably take a fair amount of time to build, but I'm sure that we could get it out in the next release if you can get it added to the list of features." Encourage them to discuss it with other users to create a critical mass, and point them to the customer contact for your project.
- If all else fails, and you have already developed another trusted user contact (see next item) end your conversation with the current user and talk it over with your trusted contact. "I got this bug report from another user that I just can't make heads or tails of. Does this make any sense to you?" Since they likely speak the same language as the reported, they make pick up on language that you did not, or they might even say, "yeah, I have that problem all the time, but I didn't really know how to explain it". In any case, they will likely give you additional assistance in deciphering it.
- At the end of the conversation, make sure you are clear on the severity and timetable for this problem. State it to the user: "I know that this is really keeping you from getting any work done. I will get back to you in an hour or so with a status report. Hopefully I'll have a fix ready to go by then.", or "Thanks for the info. I'll check in next week and let you know if I've thought of anything." Also, make sure to be clear if you think you will need more information: "I may have a few more questions for you as I look into this. Would you mind if I gave you a call tomorrow or the next day?"
- Finally, if after discussing the report, it becomes clear that the reporting user is committed to/passionate about your system, has a natural rapport with you over the phone, and is somewhat technically savvy, you will want to think about escalating that relationship into a trusted contact or intermediary. That will be the subject of tomorrow's post.
Tomorrow: Developing a Trusted Contact