Re: Documenting A Moving Target

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


Previous by Author: Re: Request for change
Next by Author: Salary range in Silicon Valley
Previous by Thread: Re: Documenting A Moving Target
Next by Thread: Re: Documenting A Moving Target


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads