[Author Prev][Author Next][Thread Prev][Thread Next]
[Author Index (this month)][Thread Index (this month)][Top of Archive]

Re: Gnaargh! Or, I Am Not Psychic

Subject: Re: Gnaargh! Or, I Am Not Psychic
From: circe -at- lmi -dot- net
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Wed, 13 Sep 2006 08:38:18 -0700

Quoting Gene Kim-Eng <techwr -at- genek -dot- com>:

Ultimately, the only effective process is to establish that the
documentation, whether online help, PDF or printed, is part
of the product, to be examined and compared to whatever it
is documenting as part of whatever pre-shipment QA is
performed so that discrepancies between what the docs say
is there and what is really there are flagged as product faults
that must be resolved prior to release.

I agree. We used to be in the same position as Sarah, and be surprised at the last minute with major changes. (In one infamous release, we had one week to completely rewrite a manual.)

It took us three releases, but in the last release, we finally got documentation included as a requirement for release sign-off. If QA hasn't validated the documentation, and if the documentation hasn't passed the approval process, the product doesn't get released.

We also got ourselves on the Development email lists, including the daily notifications from the code source control application about which files were changed. And I arranged for us to have lab machines, so that we can install builds ourselves, which helps us to keep up with the changes to the product and to provide feedback to development on issues and usability.

Our bug control application now has a documentation impact field for all issues and sends notification emails to the writer assigned to that particular piece of a product. Development is under orders to use this field as much as possible and, if they're not sure, to mark an issue as having doc impact. We can always change it if they're wrong.

As we worked to make all of the above happen, we actively participated in design reviews, and customer council presentations to the point where Dev now considers documentation to be part of the product and writers to be part of the development team. This was so successful that I was included in the team of developers when we received an award for our work on the primary new feature of the last release.

Jane


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l

Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.

Follow-Ups:

References:
Gnaargh! Or, I Am Not Psychic: From: Sarah Bouchier
Re: Gnaargh! Or, I Am Not Psychic: From: Gene Kim-Eng

Previous by Author: RE: Challenge (to me)
Next by Author: RE: Definition of Technical Writer
Previous by Thread: Re: Gnaargh! Or, I Am Not Psychic
Next by Thread: How important is up-to-date documentation? Was: RE: Gnaargh! Or, I Am Not Psychic

[Top of Archive] | [Author Index (this month)] | [Thread Index (this month)]

What this post helpful? Share it with friends and colleagues:

Sponsored Ads