Ten Secrets of Successful Tech Support: Page 3

(Page 3 of 3)

8. Educate

Remember the old proverb "Give a man a fish and you feed him for a day, give a man a stick of dynamite and you feed a village." Or is it "Give a man a fish and you feed him for a day, give a man a fleet of trawlers and you feed a nation." Whatever. In any case these pearls of fishing wisdom apply to computer support as well as to angling, and I'm not talking about weaving fishing line with vintage-1995 10Base2 Ethernet cable.

When you answer someone's question, give them more than just a list of esoteric instructions that traverse a narrow path to the problem solution. Give them the what, how and why of the solution, so if the problem manifests itself again—perhaps under slightly different circumstances—they'll recognize the symptoms and solve it themselves.

Here's an example of giving without teaching:

You observed an “Error applying transforms” error message while attempting to run an Adobe Reader update.

To fix this problem, run the kb404307.exe utility from the Adobe website.

And, the alternative, giving and teaching:

You observed an “Error applying transforms” error message while attempting to run an Adobe Reader update.

A problem in the Windows registry may be present if the "Acrobat 8.1 Japanese OCR Update" and/or "Adobe Acrobat 8.1.2 Security Update 1" have been applied to Adobe Acrobat 8 or Adobe Reader 8. Affected users will not be able upgrade to the latest version or repair or uninstall the existing version while this problem persists. This problem does not affect the correct functioning of the installed application, and no other application is affected.

To fix this problem, run the kb404307.exe utility from the Adobe website at http://ardownload.adobe.com/pub/adobe/acrobat/win/8.x/8.1.2/misc/KB404307.exe.

In the latter case, the user has a better chance of being self-sufficient should they encounter the same or a similar problem.

9. Follow Up

After you’ve spent 40 days and 40 nights trying to resolve a user’s problem, you owe it to yourself and your technical support compadres to find out if the proposed solution solved the problem.

If the user hasn’t responded, you may have to switch roles—you badger the user instead of the user badgering you. Don’t assume that the proposed solution solved the problem because you have heard nothing. Perhaps the user no longer cares about the problem because he has retired to an island in the Caribbean after winning the PowerBall lottery or she has been reassigned to another job or – God forbid – your software has been jettisoned in favor of a competitor’s product.

Take a few minutes to follow-up and get a final update. Leaving the problem discourse open-ended is like taking a rain delay in the bottom of the ninth inning and never finishing the game.

10. Make It Better

You’ve contacted the user. You’ve seen the smoking gun. Perhaps you’ve even pulled the trigger on your own computer to see the damage firsthand. Now, depending on your role, the nature of the problem, and the structure of your organization, you may have to set aside the hat of code troubleshooter to don the fedora of code fixer.

Before breaking out the repair kit, you need to take the vows of good design and well-crafted code. The fact that you have been helping some befuddled user is often the consequence of poor design and sloppily written code. You don’t want to propagate bad practice. And if you’re not sure what constitutes good practice, leave the job of fixing the code to someone else.

Good practices in software development and maintenance include writing code to prescribed standards. Use alignment, indentation and comments in a manner consistent with the existing code.

While the primary goal of software is to accomplish an intended function, just as important is that it be maintainable since maintenance accounts for 80% of its lifetime. And to be maintainable, it must be readable.

With regard to function, well-written programs check return codes from all calls to operating system functions and APIs. You may be tempted to skip a check of the return code from a call to write a record to a file your program just created because you know the file will be relatively small. But that snippet of code that has never failed in your test environment may not work so well in version 17358 of the operating system (or on some media that has yet to be dreamed of).

Readability and checking return codes are just two items from an extensive list of software best practices. Become a learned master of the software craft so the hours you log at the keyboard unraveling code, fixing faulty logic and reassembling source modules will result in working, bug-free programs and happy users.

Giving support and getting support is part and parcel of the job of Edward J. Joyce, a principal software engineer at CA, Inc.


Page 3 of 3

Previous Page
1 2 3
 



Tags: Windows, Microsoft, server, Vista, Tech Support


0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.