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: Learning/researching phase of writing From:John Russell <johnr -at- BRS -dot- COM> Date:Fri, 20 May 1994 12:54:42 EDT
>I'm curious how folks on the list tackle the learning/research phase of writing
>What do you find most beneficial: Interviewing developers, hands-on experience
>with a beta product, looking at actual code, design specs, etc.?
>What works? I'm asking because I find interviewing developers is the least
>efficient and most frustrating. But maybe that's just me. :-)
This is an interesting question. I often find that the product/project
determines who I approach for information.
Some projects demand that I look at the spec almost entirely and rely
on the developers to answer specific questions when I find something
quirky about the way the product functions. Usually this is a QA/QC
type thing.
Sometimes what I'm doing depends on how the product is intended to
be sold, which means I'm dealing with development managers and
marketing people in order to include relevant information, or determine
if the information about the product should be broken down into more than
one book.
Other projects warrant dealing mostly with the developers for information.
I've found that they provide very detailed information, and a lot of it.
The greatest difficulty with this situation is that of trying to weed
out what's relevant to the document, and what's behind the scenes stuff
that an end user or system administrator won't care about or need to know.
Still other times, I find myself in technical support...becasue they
know more about how customers are using the product than anyone in the
company, and because they deal with solving customer problems every
day and tend to know the product better than--in some cases--the
developers, but most importantly because they are being paid for their
communications skills and are often the best resource available to
explain something clearly.
I would say that in general I approach technical support people first,
then developers, and then development management/marketing management.
(btw, our tech support department also handles qa/qc, which means they
often see the product first during development.)
--
kjr
johnr -at- lurch -dot- brs -dot- com
--------------------------------------------------------------------------
|/ K. John Russell \||/ \|
| Dataware Technologies, Inc. || My dog jumped out a window! |
| 5 Computer Drive South || Six stories to the patio below. |
| Albany, New York 12205 || I loved that dog. |
|\ (518) 435-4025 /||\ /|
--------------------------------------------------------------------------
