TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
We've had a lot of discussion lately about the problem of errors in our
documentation and who's at fault or not at fault.
It seems to me that the real question is what we can do to get better
reviews of our work.
There are some processes of reviewing that are, at least to me, a recipe for
complete disaster. In some companies I know of, writers wait until they've
finished their deliverable and then send out that deliverable to all of the
people who are stakeholders and ask for a review. I've only work with
computer software, but usually at the stage when the completed document is
given out for review is an extremely busy time for the intended reviewers.
Usually they are very deep in the QA cycle fixing bugs or working hard on
last-second new requirements. And who isn't intimidated by someone dropping
a few hundred pages of documentation on their desk wanting detailed review?
Under these circumstances, I think it would be impossible to get a decent
review out of anyone.
Another problem with sending out a completed document to lots of people is
that the reviewers aren't always sure what they should be reviewing. So,
like most of us, they start at the beginning and get as far as they can
until it's time to hand in the comments. I've seen so many manuals where the
first two chapters have been reviewed and corrected sublimely, and the
remainder of the manual are lucky to have been read by anyone except the
writer.
Over the years, I've come to believe in handing out small amounts of
information (a chapter, a section, a "book topic" in online help) early and
only to those people who are directly involved with that feature set
(developers, designers, interface specialists). Knowing they only have to
work with a relatively small number of pieces of paper is a great relief to
them. And, because they're asked to read and review only the information
they are familiar with, they are typically not averse to reading and
returning their comments quickly. I've seen turnaround of less than a day
about 75% of the time.
Of course, there will always be some people who should and must read the
entire deliverable; good scheduling and negotiation can help ensure a good
review.
Suzanne
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
