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:where do docs fit in the development process? From:Susie Pearson <spearson -at- espial -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 28 Jan 2002 08:29:43 -0500
Hello,
I was just wondering where documentation fits into the development cycle
where you work. How is a documentation project initiated? Is there a
process, or does somebody tap you on your shoulder and say "Hey, I need
this" (that would be the 'process' we use where I work). If there is a
process, when are docs (final draft, and final doc) expected to be turned
in, relative to the product's golden release? Where I work, they want the
final docs at the same time the release candidate is given (with the final
docs) to the test group. This makes no sense -- we never have any time with
a solid product to check our documentation against it, and I do a lot of QC
when writing the documentation, so there are lots of changes while I'm
working on the 'final' copy.
Some backgound on the company -- small-ish company (approx. 75 ppl) with a
very immature process model for everything, but docs process is the worst.
We develop SDKs, so the docs I'm writing are programmer's guides that tell
developers how to write their own e-mail clients, browsers, etc. using our
SDKs. We have a pretty vigorous release/maintenance schedule. We don't
have the time for Hackos-type project planning / processes, but we need
something more formal. I have tried to implement a form to kick-off
documentation projects. This form required information about the intended
audience, resources, dependencies, draft dates, etc. Unfortunately, the
development managers had a hard time filling it out (really, it wasn't that
difficult, no math questions or anything). I'm at the point now where my
attitude is 'to hell with it', and I couldn't care less if the documentation
is crappy and late, because at least that will get somebody's attention, and
maybe things will change (I've been trying to change things myself for over
a year, but to no avail).
Oh yeah, and how do you get developers to review your docs? I mean actually
read them? It's painfully obvious that these ppl aren't reviewing stuff,
but no one seems to care. When I got back from maternity leave and found
some *big* mistakes that should have been caught, ppl were very nonchalant
about it. I've implemented a sign-off, so that there's some accountability,
but I don't want to pass the buck, I'd prefer our docs are reliable. I'm
seriously considering flinging myself down on the floor in front of my boss'
office, and throwing a temper tantrum that would rival any two year old's!
regards,
Susie Pearson
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/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.