Re: S/W doc question (kinda long)

["Cramer, Kim" <kcramer -at- NCSLINK -dot- COM>]

Melissa Hunter-Kilmer said:
>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?

Currently, I'm having the same difficulties.  We just acquired a
competitor and their client/server product has replaced our previous
product.  A decision was made that they would not follow our company's
standard procedures (which involve actually planning and documenting
what will be in a release) so that they could get the code out the door
quickly.  Of course, the code has been delayed several months because,
as there was no planning, the developers just kept coding.  Code
lockdown was supposed to have happened over a month ago, with just bug
fixes for stuff found in test.  I just found out this week that we have
new fields on several screens plus new reports - doesn't sound like bug
fixes to me!  If I hadn't overheard some developers talking about this,
I wouldn't have even known the new stuff was in.  So now I'm frantically
rushing to update four Help systems (there's ten total for the product)
in time for beta test.

The way it used to work around here was much better.  We tracked all
bugs and enhancements using a defect control system called Tracker.
Each SAR (software action request) was tagged with the release it was
in, a description of the problem, what the bug status was (unassigned,
development, test, etc.), and most importantly, resolution information.
All I had to do was pull a list of SARs assigned to the release I was
working on and I could easily see what was in a release and what wasn't.
 I could also get a heads up about what was in future releases.  I had
up to date information on the changes that were made to screens and code
- granted, sometimes I had to see a developer for more info, but they
quickly learned that if they completely documented what they did, I
didn't bother them too much!  It was a win-win situation for all
involved.  I can hardly wait till we go back to this method!

We also worked in teams that had reps from development, pubs, test, and
support that made the decisions on what bugs were fixed in what release
and the time frame necessary to complete the work.  We just had our
first team mtg for the new product.  It will take a while for the folks
from the new company to adjust to the concept of "empowerment" - under
their old company, the head dude said "this is what's in the release and
this is when it's going out the door" regardless of whether his desires
were even remotely possible, and as a result things went out untested
(shudder) and sometimes undocumented (bigger shudder).

So I'm crossing my fingers that we will soon pull this project into line
with standard practices!

*************
Kim Cramer
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