Re: Defining Your Tasks

["House, Barry" <BHouse -at- LRS -dot- COM>]

Every application I've ever documented began as some sort of user
request. Somewhere, a user (or potential user) asked if it would be
possible to do some sort of work on a computer. Then analysts and
programmers began work and, all too often, got mired in the details of
programming the computer to do specific things to make it possible for
the user to do what he or she wants to do.

The key for me has always been getting people back to that original user
request. What was it somebody wanted, what benefit was someone seeking,
that lead to this project? Someone in your organization knows that, and
part of your job (IMO, at least) is to find out that piece of
information.

> -----Original Message-----
> From: NetBrett Thorson [SMTP:bmthorso -at- AVISTAINC -dot- COM]
> Sent: Monday, July 27, 1998 2:31 PM
> To:   TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject:      Defining Your Tasks
>
> I am reading the "Managing Your Documentation Projects" book by
> Hackos.
> Previously, we were in an ad hoc state for creating our documentation.
> However, I am bringing our doc projects up to par with our very
> organized
> software creation projects.
>
> There is one thing that I don't understand so far.
<snip>
> Further more, I am wondering how you people write these documents
> without
> even having a product made that you can show them.
>
> So in the end, I guess what I am asking is how do we as tech writers
> discover what the user wants to do with the system, before they know
> what
> the system can do?
>
>