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.
> This process rule was regularly objected to by developers and marketing
> folks, sometimes strenuously. They didn't like the idea that the
> product might miss its ship date because the documentation was in error.
> However it usually highlighted the fact that documentation mistakes get
> through when (1) developers are late with correct information, (2)
> reviewers are less than thorough with their comments, or (3) writers
> don't get the resources they need to accomplish last-minute miracles.
Here we go again....when docs are bad its always somebody else's fault. I don't
buy that.
Since technical writers are supposed to own their documents and be responsible
for the content, any error in the document would therefore be something for the
writer to correct. It is not the engineers or QA's fault that a technical
writer placed the wrong (misleading, incomplete, etc.) content into a document.
QA and SME's are there to catch errors. It is the writer's job to repair them
or make sure they are not there in the first place.
Were I the project manager, and the documentation was in error (causing a ship
date to slip), I would be pointing the finger squarely at the writers, not QA
or the engineers. It is a writer's job to make sure the material is correct.
The SMEs are merely resources for them to ensure correctness.
If the writer came to me and tried to blame his/her inability to meet deadlines
on developers being late with information, I would tell that writer that he/she
had better learn how to acquire the information on his/her own. And I'd follow
up with: "if you can't make deadlines on the docs, I'll find somebody who can."
Engineers don't blame writers when their code fails to run. Writers don't blame
engineers when their docs suck.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
