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: How do I develop a doc plan.... From:"Gilger.John" <JGilger -at- acresgaming -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 13 Mar 2001 12:19:48 -0800
Johanna wonders: How do I develop a doc plan....
...when there are NO functional specs or feature
documents in place? None whatsoever (small start up).
All they have is a beta version of the system they'd
like documented.
Am I correct to assume that I need to sit down and go
through each user interface and determine the tasks
involved and write down all the procedures that will
need to be documented, using this to develop a ToC? I
am used to working with at least developers' specs but
in this instance they have abandoned all methodology
and just developed a system off the top of their
heads, it would seem.
If anyone else has any other effective methods of
coming up with a doc plan, please let me know.
==================================
This seems to be the norm for new companies lately. They claim they are
doing RAD (Rapid Application Development) by just coding without planning
first.
Get a copy of the source code. Maybe you'll get lucky and have a programmer
that understands the value of comments. But don't hold your breath. If it is
written in Java or C++ you may be able to glean some information from it
anyway - if you have aome coding in your background.
SQA is a good place to go to find answers to how it works. Develop an ally
in there.
Other than that, all you can do is go through it and document what is there.
Doc plan?
1. Familiarize myself with product.
2. Describe product.
3. Document review by product/project manager (places that don't plan
usually don't have time to review docs either)
4. Issue.
5. Revise when beta++ is released.
Time frame: You want it WHEN???!
HTH -- it is how we handle the problem here ;)
John Gilger
Technical Writer
Acres Gaming, Inc.
702.914.5585
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
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.
