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:RE: Productivity metrics, take II From:dan roberts <droberts63 -at- earthlink -dot- net> To:"Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com> Date:Mon, 10 Jul 2000 10:55:59 -0400 (EDT)
(my apologies for the messy "Original Msg" included below. this email system is not so great.)
Geoff, I think now you're mixing the quality of the way the end-user performs the task, and the relative importance of the task, rather than addressing the items that illustrate the quality of the presentation of the information. Using the ideas you're putting forth, I can write a really great chapter about the *important* aspect of something, and write crud for all the other chapters, and have a quality document.
Let's say we have topics about CPR and about emergency tracheotomies. What criteria would you use to judge whether one has more quality than the other? Obviously, successful end-user experiences would be one indication, but I don't think we'll go for usability testing in either of these cases <g>. So what is it about a hunk o'text that makes one 'quality' and the other 'not' quality? And once we identify those characteristics, can't we ensure that those characteristics are in every hunk o'text we write? Cuz that was the original point--productivity metrics--one of them being this 'quality' thingie.
Anyway, the vampire died a most interesting death--drowning in an ice-covered moat. Leave it to Hammer Studios!
Dan Roberts responding to my observation that a productivity metric should include "a measure of the _required quality_ for each concept", observes:
<<The problem is that 'quality' is another one of those words for which each person has an individual definition.>>
Yes, and I rather foolishly didn't qualify <g> that word. In my example, "exiting Word" doesn't require much quality because, with the possible exception of a reminder to save your file (which Word ask you to do anyway), it really doesn't matter whether you do it right or not... at least not in
comparison with my second example, "performing CPR". Here, quality is crucial: you can kill someone if you don't do it right, or at best fail to save their life. So you'll still have to define quality in such a manner that you can measure it (see my original quote, excerpted above) and thereby confirm that you've achieved it, but my main point was that some things are
much more important than others, and thus required more quality, however you define that term.
