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: New task From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Thu, 26 Sep 1996 14:21:22 -0700
>On 26 Sep 96 at 16:03, Misti Tucker wrote:
>> Now I have a new opportunity! My current employer has asked me to help
>> move the company in a new direction. He'd like me to join the
>> development team in the beginning of the next project and write *all*
>> the documentation, including that which the programmers would otherwise
>> have written.
>>[snip]but honestly I'm feeling
>> kind of "at sea" and I could use some guidelines and pointers. If any
>> of you can give me some ideas about how you handle these projects, I'd
>> really appreciate it!
Sounds like you've got a good thing going there! Getting started
(or is that "startled") is the hard part.
Design documents, project requirements, functional specs,
product architecture documents, any and all planning docs
that come before a software product happens are, basically,
programming's version of the doc plan. They'll cover target
audience, a list of features, tools to use (programming
envirnoments, class structures, GUI conventions, etc), and
all the other stuff that needs to be decided before work
The best way to start is to review the documents that came
before and, from them, create a template for all documents
of that type going forward. Gather as many of each type as
you can find, take a good look at the *type* of information
they contain, and create the skeleton of a document into which
you can put the same information for the current project.
At first, there'll be a lot of stuff you won't understand.
Don't let that intimidate you. There aren't too many programmers
out there who won't take the time to help you if it means they
don't have to write the planning docs themselves. Trust me.
I *know* this. ;-)
Best of luck!
sgallagher -at- expersoft -dot- com
-- The _Guide_ is definitive.
Reality is frequently inaccurate.