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.
Melinda wrote:
> Our situation:
> Version 4.0 was scheduled to release Oct 1. Accordingly, manuals went to =
> press Sept 1. Due to marketing adding new features late in the cycle, =
> release actually happened in Nov. Of course, since the manuals were =
> already at press, we were unable to document the new features except in =
> the helps and readme file.
<snip lotsa interims>
> Today, I learned that another (4.1a??) release is tentatively scheduled =
> for Sept.
Have ya ever heard of ye olde "shooting at a moving target?" <grin>
> My questions:
> 1) Are frequent releases common in other software companies? Is this =
> more normal for a small company than a large one?
I think your releases are excessive. If there were that many changes,
that leads me to believe the initial product was pretty unstable.
Granted, marketing threw ya a curve ball, but the UI (and
features/functionality) should have been frozen.
> 2) What is the best way to handle documenting these changes? Should we =
> print one version of the manual for each main (e.g., 3.0, 4.0, etc.) =
> version of the software and then leave everything else in the readme and =
> helps? Oftentimes changes are not limited to new features--a current =
> feature might change or options might be added to existing dialog boxes.
I'd include a written (printed) addendum to the manual for the minor
releases (3.01, 4.1). And yes, reprint the manuals for the major releases (3.0,
4.0). I'd also do as you've done -- include the changes in readme's
and the online help.
I guess you could call it job security, but I'd also call it
extremely frustrating. That's an awkward situation to be in.
...sue
-------------------------
Sue Heim
Research Information Systems
Carlsbad, California USA
Email: Sue -at- ris -dot- risinc -dot- com
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
