Perhaps.
However, I can speak from the experience I had at a company where the
manager of documentation attended design-phase meetings for the products, and
then she assigned a writer when a prototype was available. The doc mgr was
able to provide key input about the user base and do some basic QA of GUI
concepts that eliminated a lot of the inconsistency issues within the GUIs,
and she provided ideas for combining GUIs or menu architecture in ways that
made sense to the users, based on comments we received in (oddly enough)
documentation feedback forms. (Apparently people will complain whenever they
see an opening, in hopes that someone will pass it along.) When a prototype
was available, the doc mgr then assigned a writer and handed off to the writer
at a product meeting.
After about 6 months of handling products this way, product managers
commented positively about the effect on the product of having the doc mgr
involved. They didn't have as many issues with rework at a point when the code
was more complicated. They got better feedback from customers when marketing
presented prototypes. QA was pleased with the improved consistency and
usability of the screens. Engineers, while initially resistant to the idea,
discovered that they could leverage TWs for screen checks, freeing up
themeselves for more technical efforts in development.
Of course, the impact on documentation itself of earlier involvement in the
process was readily apparent. TWs knew more about the subject product, because
they had more time to learn it before the final delivery. Extending the
timeline for the documents by involving TWs earlier in the process resulted in
higher quality documents from a technical standpoint as well as from an
organizational/doc structure/writing quality standpoint. It became possible to
deliver high-quality documentation AT the general availability (GA) date of
the product, rather than doc lagging behind. And of course, the customer
benefited.
It may be an old argument, but when it is put into practice, the proof is in
the pudding. It's an old argument because it stands the test of time and trial.
Rene Stephenson
Technical Writer <tekwrytr at hotmail.com> wrote: .hmmessage P {
margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma } The argument that TWs should be involved from the design
inception is an old one, and not often found outside the circle of TWs. The
reason is simple; in the olden times when the waterfall was the design method
of choice, the docs--and the app--pretty much stayed the same. And most of
both failed miserably.
In 2007, agile development is proliferating, and RAD and XP are the methods
of choice for initial prototyping and proof-of-concept. The reason some 70% of
software development projects fail is not that it is especially difficult to
write good apps; it is because the majority of those apps are so poorly
designed that they don't do anything useful. With RAD, it is more useful to
develop a working prototype, and let the people paying the bills see what they
are going to get. THEN is the time to involve TWs--at the same time it is
handed off the Java Dilberts.
---------------------------------
Date: Thu, 18 Oct 2007 17:27:59 -0700
From: rinn...@yahoo.com
Subject: Re: radical revamping of techpubs
To: techcommdood at gmail.com
CC: athloi at yahoo.com; framers at lists.frameusers.com; tekwrytr at
hotmail.com
HA! Quite true! TW's usually also bring an approach that is closer to "green
field" than the developers, engineers, etc., can provide. Because they
understand how THEY INTEND for it to function and be used, they can be a bit
myopic about how what they have CREATED actually plays out.
Rene
Bill Swallow <techcommdood at gmail.com> wrote: I'd say that those are
additional skills. What I took Chris' remark to
mean is that writers should be there through the entire process,
involved with design, so not only do they influence the product design
along with the other stakeholders, but also have a means of thoroughly
planning the entire documentation effort as part of that product
development planning. Let's face it, most tech writers come at a
product from a different angle than an engineer or a tester. It may
not always be user focused, but it certainly is from a task-based
angle. "Is this thing going to be well thought out and therefore easy
to explain or is this going to be yet another 100 page install
procedure?"
---------------------------------
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try
now!
