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.
RE: The Problem With Keeping It Plain And Simple? (take II)
Subject:RE: The Problem With Keeping It Plain And Simple? (take II) From:mlist -at- safenet-inc -dot- com To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 24 Apr 2006 16:55:57 -0400
> I don't think the analogy holds. Plus, depending on the type of
> company and type of work you perform as a technical writer, the type
> of estimates you will need to provide (and the metrics used to back
> them) will vary greatly.
>
> On 4/24/06, Peter Sturgeon <prsturgeon -at- yahoo -dot- com> wrote:
> > How do distilleries measure production? We seem to be in a
> similar field, starting with lots of stuff and boiling it
> down. Or are we more like maple syrup producers?
When I'm writing new docs for a new product (rare), I'm
distilling a lot of info from many sources into notes,
which I then expand into an actual customer-oriented
document... which I then edit for MY reasons, if I have
time, and edit for reasons of final product turning out
different that what was originally conceived, described,
"planned"... whatever words the specifying people and
the designing people use to describe how they pull stuff
out of hats... (hey, it's an elipsis kind of day, OK?).
Most of my time is spent revising and editing my existing
docs for new product versions. That means adding new
pages for stuff they've added - or for stuff that customers
and support people wished I'd included in the original. It
means editing pages for product-stuff that has changed.
It means deleting pages for product attributes and old
commmands, etc., that have been removed or superseded.
Or, lately, I'm digging into existing documents from
the writers who were let go when we purchased yet
another small company, and are now issuing a new
version of whatever product(s) that company previously
sold. Sometimes, I'm just adding/tweaking because the
previous writer did good docs; sometimes
I'm slashing and burning and doing major re-write
because the existing docs are not very good.
I've yet to meet a metric that would adequately reflect
that sort of thing.
<ire>
How the mumble-de-mumble do you decide how much writing
you are going to do when you have not yet reviewed the
existing docs?
How do you estimate how long your review will take, if
the product update specs are not ready yet, so you don't
yet know what's expected to change?
I often do stuff "the lazy way", but I get things done,
normally on time and correct enough that QA has very
few things to remark on. I do it all myself, because I
am a local department-of-one, similar to many of you
captives and to most contractors, I'd expect.
I hereby promise to harbor a profound and irremediable
disrespect for anybody who comes to me demanding that
kind of brain-dead metric. There would, of course,
be no point attempting to persuade/argue them out of
their notions... they being brain-dead, and all.
Kevin </ire>
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
