In an interesting discussion that took place recently on the
Ubuntu Developer Discussion list about the scalability of communication channels for Ubuntu, this anecdote came up which i thought was worth sharing. First, part of
an email from Andrew Sayers, citing
two articles by Joel Spolsky, discussed a more effective way of dealing with issues that come up.
This suggests a solution I've pulled together from a couple of Joel on Software articles: when someone comes to you with a problem, first fix the presenting problem, then fix the second-order problem that caused it, then the third-order problem, and so on back to the original source. Although this significantly increases the amount of work per issue, it's more than offset by the reduction in the number of issues.
Of course, this is a better way to approach all of the problems in the world today, although perhaps starting with the source might be more appropriate in many circumstances. As in
Dr. Horrible's Sing Along Blog (i couldn't resist), when Billy tells Penny in response to her requesting signatures for a homeless shelter, "You're treating a symptom".
Onno Benschop posted
this response about his experience applying this
revolutionary philosophy to managing a help desk for 5,000 seats.
This approach speaks to me in many ways. As the manager of an IT help-desk for 5000 seats in the mid-90's I instigated a regimen where user problems were fixed by users. The way that worked is that the IT professionals were discouraged to just "click and fix" a problem, they had to explain to the user what caused the issue, how they got themselves into the problem, and how to dig themselves out.
This met with lots of opposition.
- Users were upset that phone calls took longer than "click and fix".
- Management was upset that call queues were escalating and that number of resolutions processed were declining.
- Helpdesk staff felt unloved because they couldn't just be a hero and fix the problem.
It has been said that I'm a stubborn person and I persisted. After 3 months, something really interesting started happening. The number of calls to the help-desk started declining. Initially management thought it was because users were so fed up waiting that they stopped calling us. Further investigation indicated that users were having less problems. They were more confident, more knowledgeable and more able to help themselves.
Yes, that's it. This shouldn't be incredibly revelatory or anything, but i hope that this kind of practice spreads. Fixing issues at a more fundamental level and creating competent users/customers just tickles me. Seriously, why can't people stop being so lazy and do things right? It pays off dammit!
In an interesting discussion that took place recently on the
Ubuntu Developer Discussion list about the scalability of communication channels for Ubuntu, this anecdote came up which i thought was worth sharing. First, part of
an email from Andrew Sayers, citing
two articles by Joel Spolsky, discussed a more effective way of dealing with issues that come up.
This suggests a solution I've pulled together from a couple of Joel on Software articles: when someone comes to you with a problem, first fix the presenting problem, then fix the second-order problem that caused it, then the third-order problem, and so on back to the original source. Although this significantly increases the amount of work per issue, it's more than offset by the reduction in the number of issues.
Of course, this is a better way to approach all of the problems in the world today, although perhaps starting with the source might be more appropriate in many circumstances. As in
Dr. Horrible's Sing Along Blog (i couldn't resist), when Billy tells Penny in response to her requesting signatures for a homeless shelter, "You're treating a symptom".
Onno Benschop posted
this response about his experience applying this
revolutionary philosophy to managing a help desk for 5,000 seats.
This approach speaks to me in many ways. As the manager of an IT help-desk for 5000 seats in the mid-90's I instigated a regimen where user problems were fixed by users. The way that worked is that the IT professionals were discouraged to just "click and fix" a problem, they had to explain to the user what caused the issue, how they got themselves into the problem, and how to dig themselves out.
This met with lots of opposition.
- Users were upset that phone calls took longer than "click and fix".
- Management was upset that call queues were escalating and that number of resolutions processed were declining.
- Helpdesk staff felt unloved because they couldn't just be a hero and fix the problem.
It has been said that I'm a stubborn person and I persisted. After 3 months, something really interesting started happening. The number of calls to the help-desk started declining. Initially management thought it was because users were so fed up waiting that they stopped calling us. Further investigation indicated that users were having less problems. They were more confident, more knowledgeable and more able to help themselves.
Yes, that's it. This shouldn't be incredibly revelatory or anything, but i hope that this kind of practice spreads. Fixing issues at a more fundamental level and creating competent users/customers just tickles me. Seriously, why can't people stop being so lazy and do things right? It pays off dammit!
This is how all help desks should function!
2 comments:
So, nobody leaves #ubuntu without filing a launchpad bug?
Does launchpad support usability bugs yet?
Launchpad “supports usability bugs” in the sense that you can report them just the same as you can report any other bug. For example, the One Hundred Paper Cuts project collects easy-to-fix usability problems for Ubuntu as bug reports.
However, it is more difficult to get design-related bug reports treated seriously than bug reports about stability, security, or technical correctness. First, some well-meaning bug reporters confuse a usability problem with their imagined solution, when there may be a better solution. Second, even if the bug report concentrates on the problem, some well-meaning triagers respond with the equivalent of “Yeah, well, you know, that's just, like, your opinion, man.” And third, developers who excel at learning strange interfaces themselves often under-prioritize usability bugs, because they overestimate the ability of other users to work around the problem. (All these difficulties apply to most Free Software projects, not just Ubuntu.)
To minimize these problems, when reporting a usability bug:
* Concentrate first on describing the problem, separate from any suggested solution. Present possible solutions in a separate paragraph, and avoid implying that they’re the only possible solutions.
* Where possible, cite an established usability guideline or principle involved in the problem (for example, from the Gnome Human Interface Guidelines).
* Where possible, give examples (or even better, statistics) of real people affected by the problem.
Finally, be careful about going overboard with this. If someone does something really strange in Ubuntu and gets lost, it’s possible that it’s just them, and trying to fix the interface for every individual problem anyone has ever had would result in a morass no-one wants to use. Report a bug only if you notice several people having the same problem, or if it’s fairly obvious that at many people will have the same problem.
Post a Comment