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: FWD: Setting Doc Requirements for Developers From:"Bilsland, Alex" <abilslan -at- HUSKY -dot- ON -dot- CA> Date:Tue, 11 Aug 1998 16:19:00 -0400
Ideally, you want to be involved from the outset. You have a lot to
contribute. The best book that I have come across that deals with a
documentation project life cycle is JoAnn Hackos' book "Managing Your
Documentation Projects." Another book that you might find interesting
from the point of view of software engineering is by Roger S. Pressman,
"Software Engineering, A Practitioner's Approach." I found this book
very useful for understanding how software is developed.
Alex Bilsland
Documentation Team Leader
Husky Injection Molding Systems Ltd.
----------
From: Eric J. Ray
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject: FWD: Setting Doc Requirements for Developers
Date: Tuesday, August 11, 1998 3:53PM
Name withheld upon request. Please reply on list.
*************************************************
I will make this short.
My six-year old company has only had an internal doc department for a
little
over a year. Before, all work was handled by an outside agency. Because
of
this, a lot of the developers are not used to having a full-time writer
assigned to their product.
I came on to write the doc for a new product, but I came on too late to
do
anything but a thrown-together guide. I thought I would improve it on
the
next rev.
Unfortunately, development continued adding new features without keeping
me
in the loop. Two weeks before the product was shipping an interim
release,
they called me to rev the doc. I had been regularly pinging the product
manager, but he is new to software development, and had no idea I needed
to
be in the loop.
I again have created a thrown-together guide.
For the next rev, I want to provide the entire team with a couple of
things:
* A clear understanding of my role and responsibilities
* An understanding of the type of info they should be passing on to me
* An understanding of what I can bring to the team
* A matrix of how their level of communication effects the quality of
the
doc I can provide
Pretty much, I have to teach them how to work with me.
My boss wants to sit down later this week to discuss this. As their are
another twelve writers, I am a guinea pig for showing how valuable the
writer can be to creating a quality product and doc.
I need help from you with how you have dealt with issues like this in
the
past.
I looked through all of my library of books, but none specifically
addresses
the process of how and where doc fits in the development schedule.