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.
When I was an engineer/writer in the aircraft industry back
in "the stone age" (1970's) we *never* relied solely on "the
engineers" (i.e., ourselves) to be the sole source of data
for procedures. We ran our first drafts past mfg, field
test and service, then went out onto the factory floor and
field sites, spread the docs out on a bench with the
parts and tested them, either by working with techs or by
running the procedures ourselves. Writing product docs to
input from "the engineers" never gets you docs that describe
the way things work; you just get docs that describe the
way "the engineers" *expect* it to work. I wish I had a
$100 for every time a design engineer told me that testing
was a mere formality and that something I was about to put
on the test bed really didn't need to go through all that
because "it was designed to work," then got to take his
test unit back in a box in pieces because my
"nondestructive" tests had reduced it to debris. I
wouldn't need to be working now.
And BTW, in the 70's I did work with Boeing on a few
projects, and the people writing their procedures then
weren't people who *had* spent years building and installing
their systems, they were the same people who were doing it
*at the time.*
Gene Kim-Eng
At 09:31 AM 6/16/2003 -0400, Richard Lippincott wrote:
I've seen cases where engineers provide data that just doesn't work in real
life. Parrot back that data to the same engineer for review, and it will get
a passing grade and QA approval. Then the customer takes it out into the
field, and discovers it doesn't work. ("Call the field service rep...")
My fear (and I admit I don't know the facts) is that Boeing may be in a
situation similar to what GE is. Our office has a group of tech writers that
includes a core group with extensive experience in hands-on engine
maintenance. These are people who spent years building and repairing the
engines they now write about. Other Lockheed Martin divisions hire tech
writers from a pool of retiring aircraft mechanics and flight engineers.
I'll bet Boeing does the same. The result is that the writers deeply know
the subject matter, and are able to spot issues such as "If you want the
change -here- then it's going to also affect systems covered -there-..." and
"We can incorporate this as you say, but don't forget that this won't
actually work on the systems you built back ten years ago which had the
following differences..."
---
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.
