Re: Defining Your Tasks

[Richard Mateosian <srm -at- CYBERPASS -dot- NET>]

>The last thing I worked on, I had to work mainly from
>the technical specifications, filling in by talking to
>the developer to see what was being added and deleted.

>The best I could do was a skeleton doc, with some bits
>and pieces roughed out based on existing docs for applications
>with similar features. Not at all an efficient use of a
>writer's time, but you've got to be doing something ;+)

You could do several useful things.

You could try to write a detailed user guide. If you can't do it, the
functional spec is incomplete. This could be because the developers know
things that they haven't written down, or because they haven't thought
things through.

You could take over maintaining the functional spec. In many
organizations developers leave the spec behind once they start designing
and implementing.

You could attend design meetings and represent the end user's interests.
Often developers make design changes on the fly when they encounter
implementation problems. Someone -- why not you? -- should make sure
these changes

  * make sense from the user's point of view.

  * find their way back into the functional spec.

Documentation is not an add-on. It's part of the product, and the people
who produce it ought to act like members of the development team,
even if
they don't know how to write code.  ...RM



Richard Mateosian <srm -at- cyberpass -dot- net>    www.cyberpass.net/~srm/
Review Editor, IEEE Micro                Berkeley, CA

© Copyright 1998.  All rights reserved.