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.
First, let me just preserve what Edwin Skau said, for proper bronzing
and hanging on the wall:
[...]
> >> He rattled off some QA-type statistics (code coverage, testing
> automation, trends in bugs found/fixed) as good examples of how a QA
team
> in
> Company X might be compared to a QA team in Company Y.
>
> We're really talking metrics, although we could call them sheep's eggs
or
> something else. The idea usually, is to establish a sheep's egg
> standard,
> and then set goals that sound like a 20% improvement per quarter, or a
> sick
> stigma target or something equally delightful. The problem is that
many
> qualitative factors can be twisted beyond recognition once they're
> quantified and converted into empirical targets.
>
> Some direct parallels to the QA-type statistics would probably be
topic
> (feature/task) coverage, task automation, (and since we've covered
bugs)
> process/product enhancement initiatives (prototyping, information
> re-architecting, usability testing,), percentage of content reuse
> potential realized, etc.
Part of my skill as a reasonably seasoned techwriter is to even out the
EXTREME variance in inputs that have a profound effect on the quality,
quantity, and speed of output.
Just as an example, a certain company of my acquaintance is moving
toward a more mature product project planning methodology, that evens
out the resource crunches a bit, makes scheduling easier, helps resolve
conflicts, and so on. Then, a big customer will ask for (demand, while
waving big bucks) a feature set that was planned for next year, or
wasn't even on the horizon. The customer has a big project of their own,
and they didn't consult /u/s/... er... the company of my acquaintance,
when scheduling their big roll-out. Similarly, some market shift will
open up a sudden opportunity to trump the competition, if only we can
push this-or-that functionality out the door in ... oh... 63 days, to
jibe with some industry trade-show or conference.
Other projects are already in process, Beta testers have been lined up,
schedules are pretty firm (as are the resources that those other
projects will need). So, /w/e/.... er, I mean that company sprints
toward the new, shoe-horned objective. There are bunches of developers,
and several testers, so it's possible to manage the new task... oh,
wait... there's only one writer-guy.
Dates are firm (speed).
Cost is not at issue - the timeframe is so short that it would be of
little benefit to hire writing help that would need to be brought up to
speed on the market/industry and the product.
That leaves quality. The docs _must_ be basically useful and technically
accurate, so the only other aspect that can give is the time and effort
that ensures the text is even-toned and flows, that there are all kinds
of helpful links, expanding/drop-down text, etc., etc. Furthermore, the
writer won't have any time to put time between his writing of a given
passage and the next time that he reads it. So, he'll miss things that
are right in front of his eyes (no editor). QA will check for technical
accuracy. Even if they see typos and awkward or possibly ambiguous
sections, they won't have time to create issues/tickets. Or, if they do,
they'll be "To be addressed in a future release."
So, the writer could pull out a couple of doc sets that he polished off
last year, and they'd be fine examples that would do well against most
reasonable and semi-objective tests, and he could probably look forward
to getting back to the "relaxed" pace (only two or three simultaneous
projects on the go), perhaps later in the year. But right now, he's
satisfied the immediate requirement with a set of docs that are kinda
rough, and on the thin side.
Does he get a passing grade or a failing grade against some set of
metrics?
Depends on the time of year when he (or his work) is being evaluated.
Life is already not fair. No need to add new layers of unfairness.
Turn all the above around, tell the writer that he IS going to be graded
against a set of metrics that's similar to how the developers are
evaluated, or the testers, and some writers would draw a line in the
sand. "Fine. You make me toe that line, and I start saying 'no' when you
bring rush jobs that I know will bring down my 'metrics'. I've always
prided myself on being accommodating, but I'll be forced to discontinue
that if it puts my 'metrics' at risk."
Why shouldn't sauce for the goose (developers) be sauce for the gander
(writer)? Well, several reasons that combine in unfortunate ways:
1) The writer is (often) one-and-only, while the developers are many. So
developers can be pulled from this or that project to briefly work on a
well-defined portion of the larger shoe-horned development project...
where the 'well-defined' aspect has been sorted out by a manager or
senior designer before being handed to that developer. The writer, being
a one-and-only, is pretty much his own manager in that respect, so the
time that the manager takes to block out a precise sub-task is time that
the workie didn't spend on his other work... since the two people are
actually one bod.
2) The writer is often very near to the end of the project flow,
starting his work when there's something to work with, or at least
attacking major portions of it when real product is finally in
existence. This means that it's the writer's schedule that tends to get
scrunched when other groups' sliding schedules crowd down against an
unmoving release date.
3) The writer doesn't have the luxury of peers who can perform
peer-review on his newest work, nor does he have the luxury of putting
it aside for days or weeks so that he can edit/review it with 'fresh'
eyes.
4) If SMEs are going to take vacations (or go on training, or whatever)
it'll be when they've finished their part and the writer is just doing
his work that needs technical review. (Thank gawd for a good Engineering
Test crew, that even though almost as pressed-for-time as the writer, is
willing to take a look and make some useful comments...)
I don't think I'm describing unique situations here. I think most of us
who are single writers in fast-moving businesses are in similar boats.
Metrics?
Sure. Next year. :-)
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.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
