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: Thoughts on working WITH developers... From:"Sonja Waller (SWUS)" <Sonja -dot- Waller -at- SMALLWORLD-US -dot- COM> Date:Fri, 26 Mar 1999 09:49:28 -0700
Another way to CYA is to document all conversations such as the one you had
with the developer and include it in your status reports.
Sonja Waller
Sr. Technical Writer
Smallworld Systems, Inc.
Communications Business Unit
TEL: 303.268-6163
FAX: 303.779-9945
Email:
sonja -dot- waller -at- smallworld-us -dot- com
-----Original Message-----
From: Eric Ray [mailto:ejray -at- RAYCOMM -dot- COM]
Sent: Friday, March 26, 1999 9:44 AM
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject: Re: Thoughts on working WITH developers...
>First thing he did was modify parts of the interface, so that the delay
>was no more his responsibility, but mine.
>Happily, this is not the rule, but knowing that there are people who
>have this behaviour helps.
If I'm understanding this correctly, your developer modified
the interface at the last minute, then (the unnamed someone
referred to above) assigned responsibility for missed deadlines
to you? Really?
You desperately needed management support, a clear
documentation development process, or both. That simply
shouldn't happen.
For those who are or might be in this situation...
When you agree to deadlines for documentation
deliverables, you need to specify the schedule with
respect to specific milestones in the product development
schedule. That is, something like:
Documentation draft due at functionality freeze+2 weeks
Final draft hard copy manuals at GUI freeze+2 weeks
actual real books at GUI freeze+6 weeks or at
review return date + 4 weeks
online help at GUI freeze or functionality freeze (whichever
is later) + 3 weeks
Obviously, insert your own lag time, based on changes,
size, scope, printer schedules, etc.
If your management etc. tells you that you have to deliver
documentation products on or before the day that the code freezes
or product ships, you need to have them sign off (literally
or figuratively) on what WILL NOT be done. That is,
"boss, I'll be happy to deliver the docs on the day that the
code freezes...would you rather have inaccurate screenshots,
inaccurate processes and descriptions, or what? I'll fill in
the rest in photocopied release notes as soon as possible."
Eric
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Eric J. Ray RayComm, Inc. http://www.raycomm.com/ ejray -at- raycomm -dot- com
*Award-winning author of several popular computer books
*Syndicated columnist: Rays on Computing
*Technology Department Editor, _Technical Communication_
