Dev. Cycle and the Manual

[Brian Martin <martin -at- SODALIA -dot- IT>]

Yours is an interesting approach. I'll be considering the R&D
relationship in the future.

I too am involved in the  design phase, although I prefer not to write
till later to avoid redoing things a number of times as modifications
are made and the interaction between components becomes more clear.

There are probably enough variables-- from company to company and
product to product-- to make it worthwhile to actually write the manual
in multiple phases in one and a single phase in another.

Our product cycles make it unlikely that I would have time to write the
manual in multiple phases. Being involved in all those design meetings,
I don't have much time left over to write at that point in the project.
I'm also involved in interface development, so that too cuts into my
writing time.

With product design and interface responsibilities I spend time on
non-writing, but I save time later because the issues are familiar and
the interface makes sense to me (and others I hope).

Brian

Svi wrote:

Ideally the techwriter should be involved in the design stage. This
allows
the writer to prepare in-house preliminary manuals of the product before
it
is ready. As the product develops, you continually make changes to the
manual to reflect the actual operation of the product. This serves two
purposes.

1. R&D can use the manual as a guide for developing the product.

2. At the end, when the product is ready to be released, you have most
of
the work completed and are able to meet any deadline with an up to date
manual. Most of the work at the end is placing the finishing touches,
such
as reformatting, page breaks, indexing, rebuilding the TOC, and last
minute
proofing.

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=