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.
OK, let me ask this: is not tracking the state of the product and
modifications to the product "real work"? I assume that documenting
the changes is "real work", so how do you know what to document, how
do you know what's coming, and how do you budget the time to include
these doc changes into your existing "real work" schedule?
I'm not talking hours here - well, aside from the first time you do
it, perhaps. But if you're on top of the bug base daily, we're talking
minutes a day - a warm up with a cup of coffee each morning.
Just try it. Start with 30 minutes a day per writer to see how much
coverage you get on day 1. Devise a convention that lets other writers
know an issue has been investigated. Make the notes in the bug record
as to what the doc impact is and such (just quick notes should
suffice). At the end of 30 minutes, stop. See how many you went
through, and of those, how many are docs issues. You then not only
have insight into what you'll need to document, but will already have
a rough plan of attack documented in the issue itself.
So why not try it, say for a week. See how far you get at 30 minutes a
day (maybe even 15), and see over time whether or not the flagging
part and/or the impact notes in the bug records help you manage the
actual writing work or scheduling surrounding these bugs.
On 8/28/07, Roger Bell <RBell -at- vcgsoftware -dot- com> wrote:
> Thanks for your input Bill. We have been trying to do what you
> described, but "real work" and deadlines typically pull our tiny
> department off this task and we fall behind and never seem to catch up.
> We have more TeamTrack issues than our small department can examine on a
> regular basis and still get our work done. We almost need a dedicated
> resource to perform this function, but we are looking for a
> less-expensive solution for our company.
--
Bill Swallow
HATT List Owner
WWP-Users List Owner
Senior Member STC, TechValley Chapter
STC Single-Sourcing SIG Manager http://techcommdood.blogspot.com
avid homebrewer and proud beer snob
"I see your OOO message and raise you a clue."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
