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.
>Most companies I've worked with have made a conscious decision that if the
>documentation isn't complete, too bad, ship it anyway. This is a result of
>marketing saying to management we've got to get something out on the
>street, our competition is getting ahead of us.
I don't think that this diagnosis matches the patient's symptoms. The
case we're examining involves a small company with one technical writer.
Normally, the examiner would tend to form a diagosis of "generalized
pain caused by ignorance."
According to the original posting, the product was changing in an
unstable way, day by day. In the past, the documentation was done
after the product was completed. On the face of it, I would say that
that was an appropriate reaction to the company's unpredictable design
process. Daily rewrites to try to keep up with the changing product
is a Red Queen's Race. It doesn't guarantee the earliest possible
documentation, and it certainly doesn't guarantee good documentation
(though these often happen). It DOES guarantee that the documentation
will be very expensive.
Most companies have very little control over their own engineering processes.
Little companies generally have a single person doing all of the crucial
work on a given product, and everyone is stuck with that person's
methodology. If the person approaches the problem in an iterative,
at hoc fashion, I (for one) would not care to follow him around and
chronicle his daily design changes. If the person does top-down design
and rarely varies from his initial plan, then the documentation can
be done much earlier. (Both design methods produce good products in the
hands of masters.)
You have to use a documentation strategy that is suited to the realities
of the situation. Sometimes management can be a great help, but no one
is going to change the way a given engineer approaches design problems.
In small companies, the habits of the lead engineer will affect everyone
in the entire company.
-- Robert
--
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139 http://www.pioneer.net/~robertp
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
