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.
We have a fairly close relationship with the QA department and use them to
perform technical reviews of our documentation. We've gone through several
reorgs in the last 3 years, but this is how we are organized now.
The programming manager and I both report to the VP/GM. The programming
manager is on the Executive Team and I am not, so he is at a higher level.
The QA manager reports to the programming manager. We are peers. We are now
located in the same building. This wasn't always the case, but it is
essential.
We have one major update a year, usually released in June. From January to
June, the head of R&D, the QA manager, the senior product analyst, the 3
senior QAAs and I hold a weekly meeting to track progress and make
high-level development decisions. We also plan the details of the release.
This meeting is usually led by the QA manager since she is responsible for
coordinating all development activities. (For smaller projects, similar
meetings are held between the individual writers, developers, testers, and
project managers.) After these meetings, I can inform my department of new
priorities, changes to beta schedule, changes to release schedule, or other
areas of concern, i.e. a particular area needs special attention.
Programming and QA are informed of our needs as well.
Time is planned for documentation reviews by the QAAs. This is written into
their job descriptions. Most of the coordination for this is handled between
the writers and QAAs. In fact, everyone is so accustomed to this that we
are often asked when the docs will be ready for review.
Normally, the QAAs have been testing the software for some time, so they
don't use our documentation as a road map. Instead they are the primary SMEs
for their areas. The QAAs review for technical accuracy and clarity.
Occasionally we get into p**sing contests over wording, but we have the
final say as long as the documentation is technically correct.
Mike Feimster
Manager, Information Design & Development
Computer Dimensions, Inc.
My company is considering a more formal approach to validating the software
sections of our operator manuals by developing a more intimate alliance with
our internal software QA department. Specifically, we are considering
asking software QA to validate the operator manual at the same time as
software builds are tested.
I have some questions - Any ideas on how such a relationship can best work
for all parties involved? Is this a natural alliance (i.e. should
techwriters of software be closely linked with SQA)?
Thanks for the input.
-Malkia
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
