Hi, Nick.
Oh, boy, does it resonate. I've had to pass on troubleshooting skills
several times. I'll boast around a 60% success rate, but I'm sure it's
lower once you correct for positive bias. :-) The method I use is
something like this:
1) Wait for a simple (!!!) 5-minute trouble ticket to come through.
2) Block out at least 4 hours to get through this one 5-minute ticket.
Yes, painful, but 20 hours now can save you hundreds once the
troubleshooter learns how the process works.
3) One and Two could be difficult if he (or she) has been supporting the
product for a while using a knowledge base. You might have to wait for
a unique problem, then block out several days for troubleshooting if
this is the case. Since you mentioned they're contractors, and
hopefully knowledgeable about TSM, it sounds like this might be the case.
4) Give him a simple troubleshooting flowchart that is not
product-specific. Stuff like verify the problem report really is what's
happening, check application and/or system logs, client and/or server
logs, hypothesize, test, rinse, repeat. It might be good to base the
flowchart on the steps of the scientific method.
5) Try to limit the assistance you give to these questions, or questions
that are similar in their vagueness:
a) Is that really what's happening?
b) What could cause that?
c) How would you test that?
d) Where would you look for information about that?
e) Have you checked all the available logs? This one might be a
bit too specific. Use with caution.
6) Try to sit there for the entire process so the neophyte
troubleshooter has no choice except to troubleshoot, and, unlike the
rest of the advice, don't let them use Google. You've already
preselected for a simple problem - Google shouldn't be necessary.
You're trying to teach troubleshooting skills, aka the scientific
method, not problem-lookup skills.
7) Be prepared to admit failure. You might have to weigh the effort
you've put in against how quickly he or she is learning to
troubleshoot. At some point, you may have to cut bait and find someone
else to do the job. #3 is a classic cause.
8) Post #7 where he can see it. (haha)
Also, I agree with Richard Sims. I believe it to be a cultural
phenomenon. I've encountered several cultures, including home-grown
ones, that seem to have an emphasis on rote learning as opposed to
emphasizing the scientific method. There's a lot of personality
acceleration*time (velocity, inertia, momentum, however you want to look
at it) that you'll be fighting against.
For me, the hardest part is to just sit there and not
troubleshoot-by-proxy. "Maybe consider looking at xyz" is contraindicated.
Good luck. You'll need it.
Alex
On 6/6/2012 5:24 AM, Nick Laflamme wrote:
Slightly OT, but I expect this might resonate with some of us.
How do you teach someone to solve problems? How do you teach them to look past
the first symptom (or the user's problem description) to gather all the
symptoms and determine if a common cause might cause many of the symptoms?
We've got some contractors are are TSM-certified but lack this skill of looking
past the first symptom. I really need to tune up their problem solving skills
so they handle more incidents themselves without punting to us all the time.
Help?
Nick
|
