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.
Brian S. R. Bennett <bb18+ -at- andrew -dot- cmu -dot- edu> writes:
>>Of course writer's should be involved in the initial stages of product
design. The fact is, however, that most writers don't really have a grasp on
how they can be of help at that stage. Sure, if you're involved in early
design your job of documenting will be made a great deal easer (and arguably,
this has benefits to the organization as a whole) but if the writer doesn't
show how he/she can produce quantifiable benefits, he/she has no right to
expect to be involved.<<
I believe that benefitting the organization as a whole through timely,
accurate documentation is the benefit. I'm sure that it is quantifiable, but
being a writer and not an accountant, I don't know what number to assign to
it.
>>As you learn more about the purpose, structure, and content of specs (and
you will need to learn if you haven't done it before) ...<<
In fact, I am interested in the formal structure of specs. Would you happen
to know of a good manual dealing with the creation of design specs?
Finally, there is a lot my department and I can do for software design, as
well as for hardware design, QA, etc.. We have the talent and perception to
be quite the little helper-elves for the entire corporation. But we are a
tiny department. My feeling is, if I have to explain to you why I'm useful to
you, I'd just as soon add value to some other engineer's portion of the
system.
Software, above all other departments, should inherently understand the value
added by documentation to their product, without any marketing pitch on my
part. Walden Books and Barnes and Noble have rows and rows of 3rd party
software instruction manuals. This is a huge industry and suggests to me a
flaw with in-house document development vs a writer having the final product
in their hands to use and describe.
Perhaps rather than state my case to be included in product design, I should
request to have the finished product x months before the customer release.
<Just a dream...>
"I personally think we developed language because of our
deep inner need to complain." -- Jane Wagner/Lily Tomlin
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
