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.
> Design docs are usually measured by meeting predictable
> deadlines. They're considered a part of project management,
> and so are measured by that standard. But here's one of my
> soap boxes... Tech writers can and should provide more value
> than merely producing pages of user documentation.
> Organizing and clarifying the design process is a
> whopping-huge opportunity for adding value. It resists
> outsourcing, and it gets the writer directly involved at the
> very start of the project. And it fits well with Agile.
The participation, including writing some of the design
docs is good. It takes a chunk of time, though. And that's
time that a lone writer doesn't necessarily have when
doing the customer-facing docs for multiple products.
> On your resume you would say something like, "I managed and
> maintained the design documents (ooo... maybe even designed
> them?) for the X project. Our team met every milestone on or
> before deadline. Our product generated X revenue."
Hmm. I would be the writer member of several teams doing
that, while also doing all the customer docs, both new
and updates, all at different stages, all sliding due
to shifting conditions. Those are the kinds of activities
that don't have any natural multi-week gaps in them. No
times when you can simply not be there participating for
two or three weeks. After all the years it took to get to my
current number of vacation weeks I hafta chuck 'em?
Drat!
Also, you can "design the design documents" when you
work for a start-up or very small company.
When you work in an established company or a
large one, they have standard docs that must
be created/updated the same way every time.
Sometimes there are automated processes that
strip whole sections from one document to
populate a succeeding document. The review
process is entrenched and needs docs from all
projects and all divisions of the company to
follow the format and content rules that allow
very structured on-line review-and-approval
processes to flow smoothly.
Don't think of me as being a nay-sayer here.
Just pointing out some alternate universes that
other people deal with, where the rules are not
quite the same. They still permit the existence
of life, just not "life as you know it." :-)
By the way, in the spirit of "different universe",
around here "Agile" refers to a component in an Oracle
ERP system (for us it <thank gawd, finally> replaces
Product Center). Has nothing at all to do with
Agile programming methodology.
- Kevin
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
