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: question on speedy collection of engr info From:"Scott Wilborne" <wilbornes -at- vtls -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 6 Sep 2001 15:39:15 -0400
Julie,
Your problem speaks to the need for a stronger design process. If the
customer is going to use these commands, it seems like there should be a
list of them in a design document before the coding begins. Unfortunately
this is not the way reality always works. In lieu of a good design document
to work from, I would pester the engineer until he realizes it would be
easier to keep me updated on the commands that make it into a release than
have me standing in his cube asking questions every 30 minutes. This really
works! Be a bastard if you have to.
As to your suggestions . . .
>* trying to get the engineer to add a short message to his CVS check-ins,
>and setting up an auto email to me on his check-ins
I think communication of this sort can be very useful. And if it is set up
as an automatic process as opposed to a "please do this if you have time"
sort of thing, you can be reasonably assured that you're getting all the
information
>* meeting with the engineer more often (difficult, because he's generally
>out of the office and kinda flaky about making meetings anyway)
Bug him until he develops a tic everytime you come within 100 feet
>* breaking up the toolkit guide into portions and emailing the engineer
>what i have in bite-size chunks, hoping he'll review it and send me
>comments
If the developer doesn't take time to give you the information you need to
write the document, I would not count on him taking the time to do an
adequate review of the document.
>* doing the above, but using the bugdb instead of an email
>* trying to get QA person to warn me a couple days before he plans to test
>the new commands so I can pester the engr for exact usage before QA tests
>it
How does the QA person know the commands to test? Whatever method QA is
using seems like the best route.
>* trying to get some manager types to realize that a ton of tiny point
>releases aren't as helpful as they might seem
I would think point releases are better suited for bug fixes than new
features. Although the release schedule might be the cause of your problem,
I wouldn't put too much money on it changing.
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
