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.
Ron - At NCS, the product manager is responsible for the system
requirements document (the "vision" for the product), and the developers
are responsible for writing functional specs and detail design
documents. There's a standard format to follow and Word templates for
them to use. If requested, I'll proofread the documents (time
permitting). Once these documents are written, I use the information in
them to develop user documentation.
IMO, these documents should be written by developers as the information
in them may (most certainly WILL) frequently change as new client needs
are addressed. The developers are probably unhappy about the amount of
time they spend doing specs rather than coding, and they figure they'll
offload some of the work to the "Tech Writer." I'm not sure they'll see
the time savings they expect, however. For each revision, they will
need to schedule time with you to go over the changes, then you'll make
the changes, then they will need to review the document to be sure you
got it right (no slam on your competence - just covering for Murphy!).
This will take much more time from their schedules than just making the
changes themselves. If you can convince management to continue having
development be responsible for the content of the docs, you could offer
to proof them (and reap the benefits Alexia mentioned from being
involved in the spec process).
Alexia is also correct in pointing out that scheduling your time could
rapidly become an issue if you are working on many projects.
I also share your concern that you would not have the time to pursue
improvements to your documentation. This has been an issue for me
lately, too. With HTML Help looming on the horizon, there's a lot of
research to be done to determine how the new Help model will work, what
the conversion issues are, how users will interact with it, how it deals
with cross-platform issues such as fonts, and how it will impact Help
development time, etc. Hopefully, once this release is out the door, I
can spend some time learning about HTML Help and planning for the next
release!
*************
Kim Cramer mailto:kcramer -at- ncslink -dot- com
Sr. Information Developer
NCS Education, Mesa AZ
*************
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
