> You've only added two lines – why did that take two days?
If this is hard for them to understand, the confused look when you reveal a change was a net removal of lines/statements must be amusing!
> Because the issue was reported with a vague description of how to recreate it
This is something my current management fully understands, but I wish we could get through to our clients. Short of being actively rude about bad requests I've run out of ideas over the years. Luckily these days we are big enough that I usually have a bit of a shield (provided first line support people and BAs who I trust) between me and direct client contact.
I'm quick to put tickets on hold as "needs more information", and been around long enough that I've developed the confidence to respond to "this is urgent, there is an SLA" with "and that service level agreement covers a minimum level of reporting from you before even an urgent matter can be progressed" or more facetiously "then it is urgent that you furnish me with the information requested", but while they accept it each time they never learn to give better details up-front next time - we still get reports of "an error" or something "not working" or, even worse, the open-ended question "is there a problem with...?".
Obviously this can't be applied to truly urgent issues, but they are usually massive problems that we are already aware of and working on before the client contacts us because, for instance, we've had an alert that something is down (sometimes we tell the client about an issue and resolution ETA before they notice, which they seem pleasantly surprised by and thankful of).
Decent logging of all changes and error happening on the platform I work on usually lead me to pretty much the following dialog :
" - I have a problem, the platform is broken"
" - Sure, do you have any rough idea when that happened " (I discovered that weirdly, people are very good to report a bug a day or even more after it actually happened)
" - Around [some hours range]"
(Get the logs for this time and this user)
" - Ok, I see every information I need in the logs, it will be fixed soon"
And that's pretty much it. Oftentimes, I don't even need the time bit, just finding the user history in the logs is enough.
I'm always puzzled at engineers rambling about "users never learn how to do a correct bug report", but it seems like they themselves never actively learned that and integrated it in their everyday life.
Since users indeed never learn, stop expecting them to !
> Since users indeed never learn, stop expecting them to !
I don't expect them to. That doesn't mean I can't be irritated that they don't!
We have various logs and audits too, that can usually be used to work out what has happened. Sometimes alerts based on those logs mean we are already fixing the issue before any user reports it. Even with full audits and other logs, it is usually still quicker to locate and diagnose a problem if given what useful information we know the user has access to (the standard set: approximate time (at least the date if not today), what were you asking it to do, what did it do instead, any error messages they were displayed).
If the user is give a message with a code that explicitly says "report this number when you report the issue" and they don't bother (they just say "I got an error") and that information would save me time, you bet your arse I'm pushing the issue back onto the queue and getting on with some interesting dev/infrastructure work until a better report arrives, or looking at another issue where there is decent information.
Want to be at the head of my TODO list? Then make at least a minute amount of effort to help me help you.
It particularly bothers me when clients who negotiate a discount because they won't need first-line support as they are "big enough to have a department that triages that sort of thing", still send through terrible reports because their idea of triage is just hitting the forward button whenever an email comes in. I've got better things to be getting on with than providing free outsourced work for a bad IT department!
I'm not very customer facing these days, since we have grown to the point where I have a bit of a shield provided by our support/PS/BA teams, which is good for both my irritation levels and the clients!
If this is hard for them to understand, the confused look when you reveal a change was a net removal of lines/statements must be amusing!
> Because the issue was reported with a vague description of how to recreate it
This is something my current management fully understands, but I wish we could get through to our clients. Short of being actively rude about bad requests I've run out of ideas over the years. Luckily these days we are big enough that I usually have a bit of a shield (provided first line support people and BAs who I trust) between me and direct client contact.
I'm quick to put tickets on hold as "needs more information", and been around long enough that I've developed the confidence to respond to "this is urgent, there is an SLA" with "and that service level agreement covers a minimum level of reporting from you before even an urgent matter can be progressed" or more facetiously "then it is urgent that you furnish me with the information requested", but while they accept it each time they never learn to give better details up-front next time - we still get reports of "an error" or something "not working" or, even worse, the open-ended question "is there a problem with...?".
Obviously this can't be applied to truly urgent issues, but they are usually massive problems that we are already aware of and working on before the client contacts us because, for instance, we've had an alert that something is down (sometimes we tell the client about an issue and resolution ETA before they notice, which they seem pleasantly surprised by and thankful of).