RE: Interview what Interview? (WAS: Capturing info during meeting s with SMEs)

["Eric J. Ray" <ejray -at- raycomm -dot- com>]

On Thu, 5 Jun 2003, Giordano, Connie wrote:
GC >Lord, I think I'm on another planet than most of the software tech writers
GC >posting on this thread.... I haven't "interviewed" a SME in three years!
GC >Couple of reasons come to mind, and I'm wondering if any other long-term,
GC >FTE, or merely aged writers out there have gotten to a similar stage:
GC >
GC >1) I've been working on these 7 products for nearly four years,  not much
GC >new they're going to tell me about functionality.
GC >2) I'm an equal on the project team, go to status meetings, QA the builds
GC >along with the testers, and help write the specs.
GC >3) I just like finding this stuff out on my own.
GC >4) Doc (well actually on-line help) reviews are on the project plans, and
GC >everyone works to the plan.

Lots more good stuff snipped.

Connie,
I'm right where you are...I've been working on my current
project for over three years, and it sounds like we arrived
at exactly the same point in much the same way....complete
to the startle reaction when I wanted to be at meetings and
on email lists.

I'm thoroughly part of the project team, and as such,
there's rarely "interviewing" to do. For example, on a
recent project, I was involved in the initial kickoff
meetings and planning meetings, so I drafted the man
pages as a means of capturing the ideas and capabilities
of the product. Those ended up becoming a big part of
the functional specification for the product, and we
had complete reference documentation _before_ any code
had been written.

I play with/test/_USE_ the software, but more of the
information about what the product does and how it
works comes from planning meetings and head's up
email from developers to warn me about changes they're
making or from email asking for my review of UI text
or error messages. Using the software just finds bugs,
but the engineers appreciate that ;-) It's been well
over a year since an engineer slipped a change in
without my knowledge, and the engineers expect that I'll
review command lines, UI stuff, and write the error
messages.

The engineering team didn't expect me to fill this
role when I was hired--they were accustomed to writers
with a more traditional view of their jobs--writers
who interviewed engineers then went back to their
offices to generate voluminous information. Because
I explicitly define "us" as the engineering team, and
"them" as the rest of the world, and because I
have learned the technical nuances of the product, and
because I contribute in any way I can do the overall
team/product development, most of the discussions of
getting information from engineering and interactions
with engineering are largely irrelevant to me.

It's as easy to get any information I need from engineering
as it is from other technical writers I work
with--sometimes easier. That
wasn't the case when I started here, but by contributing
to the overall project and understanding--really
understanding--the product, that's how it is now.

Eric



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Robohelp X3, from eHelp, lets you quickly and easily create 
professional Help systems for all your Windows and Web-based 
applications, including Net. 

Order RoboHelp X3 in May and receive a $100 mail-in rebate, PLUS
free RoboScreenCapture and WebHelp Merge Module. 
 
Order RoboHelp today: http://www.ehelp.com/techwr-l

---
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.