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: Documenting A Moving Target From:Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM> Date:Wed, 21 Feb 1996 08:31:33 -0800
At 04:16 PM 2/20/96 EDT, you wrote:
>HELP! What do other people do? Do other software companies build in time at the
>end of the development cycle for doc to catch up? Whose responsibility is it to
>notify doc of all these changes as they occur (that's the other thing; I
>happened to find this item, no one told me of the change).
Good software methodologies should account for documentation. However, most
do not, as most IS management still does not tie documentation to the bottom
line. Many software methodologies continue to focus on the business of
creating the software, not the business. IMHO, they fall short in the areas
of usability, documentation, and support, all of which are critical to
customer satisfaction. And, IMHO, they fall very short of the mark in the
area of PLANNING, which is absolutely critical to creating a WHOLE (read:
healthy, usable, marketable) product.
OK, enough ranting. Here are some suggestions for improving communication
between you and developers:
(1) Does your company use some kind of problem tracking or design control
software such as Tracker or DCS? This software is common in software
development shops and is used by programmers to document bugs, fixes, code
enhancements, and even large scale development projects. It usually exists
in database form accessible to the development team. If your programmers are
using this kind of software, you should have access to the database also.
Then, regular checks by you will keep you on top of fixes, planned
enhancements, etc. Hopefully you will not encounter resistance to gaining
access to such a database.
(2) Be proactive with your developers, meaning that you initiate
communication with them instead of the other way around. Set up regular
"status" meetings with a SENIOR developer with whom you have a good
relationship already established. These should be no longer than 1/2 hour
once every week or two weeks. The purpose of the meeting is to update you on
fixes, changes, and upcoming enhancements or new products.
(3) Look at your company's software methodology, which should be documented
somewhere, and recommend changes. Go slow at this; don't force anything.
Good luck.
Regards...Kris
--------------------------------
kjolberg -at- ix -dot- netcom -dot- com (preferred)
kjolberg -at- aol -dot- com
102031 -dot- 3556 -at- compuserve -dot- com
