<br><div class="gmail_quote">On Nov 10, 2007 8:27 AM, Josh Welch <<a href="mailto:josh@joshwelch.com">josh@joshwelch.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Quoting Wayne Johnson <<a href="mailto:wdtj@yahoo.com">wdtj@yahoo.com</a>>:<br><br>> I know this is a bit off topic...<br>><br>> Our support organization is trying to create a problem determination
<br>> guide for our product. What I mean is a "scripted" flow chart that<br>> they run through to try and isolate (or even fix) a customer's<br>> problem. The biggest issue I see with this is that as a product
<br>> changes over it's lifetime, the contents of this guide will change. In<br>> addition, we'll want this to be developed by the support personal as<br>> they gain experience with the product, finding new diagnostic
<br>> procedures and tools.<br>><br>> This is likely something built on a<br>> hierarchical database with a bunch of questions like, does this work?<br>> Does that error occur? Is there this message in a log?
<br>><br>> Anyone seen this? Any suggestions.<br>><br></div>Yeah, I've seen this to varying degrees of success. If the product for<br>which you are trying to do this has any degree of complication, then<br>it's damn hard to put together a document of this sort. There are too
<br>many ways that a troubleshooting process can fork.<br>I'm assuming the point here is that you're looking to get new people<br>up to speed in a rapid fashion, correct? Your best bet is to identify<br>the low hanging fruit, those simple issues which address a large
<br>number of your problems, and tackle those. That should get you part of<br>the way there. Your next bet bet would likely be to break down the<br>product into specific areas of functionality. Perhaps have a top level<br>
guide that helps your support staff to determine which area the issue<br>lies in. They then turn to the document for that particular area which<br>drills down more deeply into specifics.<br>It would seem that this format lends itself well to a Wiki, I've never
<br>actually gotten to implementing such a thing but it's great in theory.<br><br>Josh<br><br></blockquote><div><br>I heard Wiki too. Many Wiki's offer templates and forms for structure, but also have whiteboards for "X is being Y'd this week." Support people can follow a process tree and still have search capabilities. Wiki also has the benefit of a sense of ownership, which was implied in Wayne's original post. I was once a TWiki freak; I still think it's a good solution, but I've been scolded here for being too retro or something. Maybe geeklog. I dunno. My main point is that this can be done well within any of a number of already-built web frameworks without much if any coding. And it can be implemented and grown rather quickly.
<br><br><br> _______________________________________________<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div>
<div class="Wj3C7c">TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br><a href="mailto:tclug-list@mn-linux.org">tclug-list@mn-linux.org</a><br><a href="http://mailman.mn-linux.org/mailman/listinfo/tclug-list" target="_blank">
http://mailman.mn-linux.org/mailman/listinfo/tclug-list</a><br></div></div></blockquote></div><br>