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: Is it just me? S/W doc question From:Heather Searl <SearlHL -at- SCIEX -dot- COM> Date:Mon, 2 Jun 1997 13:52:40 -0400
> When you're documenting an application, and it changes,
>is there a procedure in place to notify all concerned? Or
>do you just find out after you've written the chapter, and
>then you have to rewrite it?
Here is one idea for managing this situation that I haven't seen as I
skimmed through the last several days' postings.
At a previous company that I worked for we managed to convince the
development managers to make it the responsibility of the project leader
to include a readme file listing changes, major bugs fixed, and parts of
the software that weren't completed with every pre-release build of the
software.
After a lot of initial resistance, the results were very positive. I got
the information I needed, and I knew who to go after if it wasn't
included. QA received an overview of what areas were appropriate to test
in each build. External beta testers knew when their bugs were fixed and
when new features were implemented. Marketing had an idea of what they
could demo at any given time. Management had an informal way of looking
at the s/w's progress without lengthy meetings. One developer knew what
another had done. The project leaders (or some of them any way) found
that they were more on top of where the project was, fewer people were
calling them with general questions, and it didn't take them as long as
they thought it would to add each day's additions and changes to the
readme. An informal history of the project was created where more formal
means of tracking the project had failed.
Heather Searl
MDS Sciex
searlhl -at- sciex -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
