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:Online help productivity From:geoff-h -at- MTL -dot- FERIC -dot- CA Date:Tue, 8 Jul 1997 12:15:01 -0500
Hope Creskoff, has been put in the uncomfortable position
of having to document her productivity: <<...they intend to
"measure" developers by how many lines of code written
(which has been proven to be an ineffective way to measure
a developer's productivity); [for us,] it's been suggested
to track the number of pages written per application.>>
I think if they measure productivity in this manner, the
number of pages you produce will coincidentally increase
until you meet their benchmark for productivity,
irrespective of whether this is any use to your employer or
the customer. Ask the managers this question: "If _your_
compensation depended on how many pages you produced per
hour, what would your incentive be to write concisely and
test the usefulness of what you write?"
I'd suggest that you measure productivity in terms of the
number of topics and subtopics covered, but build in some
measure of the magnitude of each topic. For example, a menu
choice with no submenus might count as one point, whereas a
tabbed dialog box with five tabs might count as five
points; to allow for complex tabs, each "fill in the blank"
field might count as one point. You can get even more
complicated by adding points for hypertext links, graphics,
etc., but the bottom line is that you need to figure out
some system that works for _you_ based on the variability
you anticipate in the difficulty of each chunk of text you
must write.
This will have interesting and beneficial side effects:
text will get shorter (i.e., less text, more "points per
hour"), more work will be done in less time (because you're
writing less text), and the resulting docs will probably be
far more useful to users (particularly if you build in more
hyperlinks and count them as "points").
--Geoff Hart @8^{)} geoff-h -at- mtl -dot- feric -dot- ca
Disclaimer: Speaking for myself, not FERIC.
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
