Newsletter of the Society for Technical Communication, San Francisco Chapter
February/March 2009
| Newsletter of the Society for Technical Communication, San Francisco Chapter February/March 2009 |
Are you a perfectionist? Of course you are - you're a tech writer. You argue about semicolons and hyphenation and the finer points of FrameMaker templates. Yet have you shipped documents with embarrassing errors, even after you thought you had proofed them?
If so, don't despair - you're not a bad person. You're not even a lousy tech writer. You're just using faulty processes, and Mysti Berry wants to help.
In her January presentation for the San Francisco Chapter, "The Leszek Method: Stop Trying to Be Perfect and Write Higher-Quality Docs," Mysti outlined the fail-safe processes she and her fellow writers at Salesforce.com use to produce consistently high-quality and error-free documentation.
Before describing the details of the Lezsak Method, named after her manager, Andrea Leszek, Mysti broke the ice by asking the writers in the audience to describe the worst preventable mistake they ever shipped. Mysti herself confessed that before the Leszek Method, her team shipped a doc with a Popeye placeholder on the cover. Another writer told of an Index gone bad. But the best horror story of the night came from a writer who, out of frustration with her product manager's countless product name changes, replaced the product name in all her docs with "Satan." Unhappily, after the docs were rushed out to several of the company's best clients, it became clear that Satan hadn't been completely exorcised when a customer in the Bible Belt called to complain.
Moral: Don't let this happen to you. Use the Leszek Method.
First and foremost, according to Mysti, the Leszek Method is a series of systematic quality controls that assumes that mistakes are inevitable. Software developers know mistakes will show up in the code, and they've developed sophisticated QA procedures to catch them. Tech writers should do the same. And, like good development processes, which include code reviews, the Leszek Method builds error checking into every step of the process.
If all this sounds too time-consuming, says Mysti, you should calculate the cost of NOT following systematic QA processes (such as shipping Satan-possessed documentation).
Mysti described the principles of the Leszek Method, as follows:
But. . . What about tight deadlines? What if you're a lone writer? What if you finish at midnight and there's nobody to check your work?
Mysti showed how some of the processes take less time than you would think - for example, just getting another set of eyes on a document before checking it in often takes only a few minutes. If you're a lone writer, you can read the doc the next day, hire an outside editor, read the document in another format (such as print), make a deal with someone in QA, or if you're a consultant, ask a friend or spouse to help. Above all, if you're alone at midnight and you're about to check in a doc -- don't!
One of the central elements of the Leszek Method is the Blitz. Mysti explained that in a Blitz, which happens at the end of a "sprint" in the Agile Development process, every member of the documentation team visually inspects every page of the doc set at the same time, logging or fixing bugs. At least one person checks every page of the documentation against a checklist. The challenge is to find as many bugs as possible, and according to Mysti, it's kind of fun!
Clearly, Salesforce.com is doing something right. Their team of talented, yet imperfect tech writers consistently produces thousands of pages of high-quality, award-winning documentation. The Leszek Method, although simple, is actually revolutionary. By freeing writers to stop worrying about being perfect, they can start focusing on the overall quality of the documentation. The Leszek Method also forestalls the sort of lone writer heroism that introduces new errors into the docs at midnight. It may be possible to write good documentation without systematic QA processes like the Leszek Method, but as somebody once said, "The Devil is in the details."
Abby Breedt has just recently returned to consulting, after many years as a lead technical writer for Autodesk Location Services in San Rafael. In addition to writing for a technical audience, Abby has also been an academic editor and writing coach since 1984. She specializes in administration and developer documentation and enjoys delving into complex technologies of all kinds. Contact her at abby@breedt.com.