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: Why doc aren't tested From:Caryn Rizell <caryn -at- HPPTC95 -dot- ROSE -dot- HP -dot- COM> Date:Thu, 11 Aug 1994 08:48:30 PDT
All I can say is "Hear, hear!" John hit it on the head with
the statement that the situation is the result of our attitudes
and behavior.
When we see ourselves as important to the process and are willing
to stick our necks out and get involved, the benefits are many.
If we really want to do something, we can. It is just a matter
of will and time.
I can say this because I have worked in an environment that
did not want writers to be anything more than typists. But over time
(a few years), with patience, the attitude of the management
and the rest of R&D began to change. But the change had to
come from us, a little at a time. Noone was going to
just start involving us in development, we had to find ways
to get involved without making it seem official. Then, when
others saw the benefit, we became officially involved.
That doesn't mean that life was perfect and documentation
got all the time it needed to produce marvelous manuals. It
just meant that our views were important in the design and
development process and therefore we were given more voice
to express our opinions and hold out for better docs.
It is a very long-term process, but IT IS WORTH IT! If
you really want to change your role in development, then
do it!
I hope this does not get me too many flames. I know there
are going to be some responses that it is impossible where
they work, but, really, nothing is impossible!
Caryn Rizell
caryn -at- hpptc95 -dot- rose -dot- hp -dot- com
> Mark Levinson told us that documents are not tested for these reasons: (1)
> Software managers don't see documents as part of the product. (2) After
> software is frozen, there isn't enough time left. (3) Problems caused by
> untested documents are in the future.
> This may be true, but do we have to sit back and accept it as inevitable?
> I don't think so. My guess is that Mark doesn't think so either.
> I believe that this situation is largely the result of our attitudes and
> behavior. If we can overcome our tendency to relegate ourselves to a minor
> role in development programs, behave as the competent professionals we
> believe ourselves to be, and integrate ourselves early into the
> development process, there is no reason why documentation can't be
> developed in parallel with product development. If the product and its
> documentation are tested throughout the development process, the
> documentation can be tested and ready with the software distribution
> media. This results in better products with better integral documentation.
> I've seen many products developed with this process. The technical
> communicators who worked on these projects are proud and confident.
