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.
Subject:Re: Quality of source material from Development From:Salan Sinclair <salansinclair -at- shaw -dot- ca> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 12 Dec 2001 10:55:32 -0800
Thanks for all the feedback to my question.
I don't think the answer to this question is as simple as it might appear,
based on the limited information I provided. It may depend greatly on the
following factors:
1. Product type:
This product is a command-line interface for networking appliances. Most of
the documentation is a list of commands, descriptions, syntax, defaults,
acceptable values, etc. Since this information cannot be transferred easily
in interviews and is not available through other means, it seems reasonable
to expect complete and accurate source material. The value that tech writers
add is ensuring consistency in syntax and language, identifying incomplete
areas, adding usage instructions, turning everything into English, etc, etc.
2. Product availability
The product is not functional so testing and working with it is impossible.
Specs consist of about 1 page per 100 page of documentation that must be
written. Most of the customer documentation must be delivered for review
before the product is functional.
3. Volume of work expected per writer
In this situation, there are two writers (including the Doc Mgr). They are
expected to produce 7 to 10 manuals for 7 to 10 products in 4 months, and
each manual has about 100 to 300 pages. It's not possible to have a tech
writer become an expert on 4 or 5 products in that time period. Each product
is so distinct and complex that most developers do not understand what each
other is doing.
About the issue of being an expert user of your product, I think this is an
ideal that only works in environments where the volume of documentation per
writer, or the volume of product features per writer, is low.
For example, I was a lone writer working for a company with a suite of about
10 products undergoing constant change and new products being developed
every few months. As much as I wanted to, I could not afford to work with
the products at all, let alone become an expert on them, if I wanted the
revised documentation to go out the door with the product. In that
circumstance, unless developers produce written source material, the tech
writers produces less documentation. Another option is to have the tech
writer produce "guesses" and let the developers to rework the guesses for
accuracy. In some cases, my wage was the same or higher than some
developers, so it made sense financially to use their time if it made me
more efficient. Hiring additional tech writers would be an obvious solution,
but not one within my control.
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
