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.
> Problem: I am trying to document a product that is still being developed, not
> just tweaked.
The advice I received when I first encountered this problem was to sit in
on product development meetings as an observer, and to hang around the
programmers.
If you can't sit in on the meetings, then drop in from time to time on
those who are likely to influence product development, and ask how things
are going -- on the pretext if necessary of clarifying some point of
documentation. This will quickly give you a sense of which parts of the
product are solid, and which are subject to change. Look over the product,
and be prepared to document it, but don't knock yourself out on the parts
that have not yet stabilized in the minds of the designers.
Management may warn you away from distracting the programmers. Ignore
management if you can. The programmers are your most valuable resource.
Not only do they understand the product better than anyone, they also
enjoy talking about it, and especially getting feedback from a user on the
learning curve. Where I work, sometimes they seek me out and ask _me_ how
it's going!
--
James Owens ad354 -at- Freenet -dot- carleton -dot- ca
Ottawa, Ontario, Canada
