Getting information

[Ben Kovitz <apteryx -at- CHISP -dot- NET>]

Matt Ion wrote:

> Agreed!  A friend of mine found this out recently, writing a
> proposal for a gov't contract.  All the information he needed was
> help by people within the organization; he could have retrieved
> everything he needed from three or four department heads and
> organized it into his proposal in a few hours.  But, since he was
> an "outsider", and since the departments were ridiculously
> xenophobic to begin with, nobody would tell him what he needed to
> know.

In some of the discussions about how tech writers don't get
enough respect, the complaints usually center around salary and
just plain prestige.  But what you describe seems to me to be
the more common scenario: it can be very difficult to extract
information out of people, because they just won't put the time
into it.

Actually, I think there are a lot of causes for this, not just
lack of concern for documentation or the view of tech writers as
glorified typists.  I think the biggest cause is that on most
projects in software companies, the more important the
information, the less likely are people to commit it to
writing.  Consequently, there's usually only one person who
understands how everything fits together.  And because he's the
only person who understands the system, his time is *extremely*
valuable.  His top priority is usually to spend time on site,
putting out fires with the customer; then comes various
management stuff; then comes making decisions for programmers;
and then, in the remaining 0% of his time, he can dispense a few
tidbits of information to people who ask for it.

A secondary problem is that often people simply haven't thought
through the information that we need.  For example, I continually
ask people these questions: "Which users operate this part of the
software?  When are they supposed to operate it?  Which fields
should they fill in and which should they leave blank?  Where do
they get the information that they enter?  What do these field
labels mean?  What does each value in this pick list mean?"
Generally people say, "I don't know," but of course this is the
information that needs to go into a user's manual.  On a good
day, these questions stimulate people to rethink the user
interface, showing that it never crossed people's minds to
address these questions during design.

Unfortunately, this means that learning some techniques for
interviewing won't help: the information is just not there to be
found.  My main "technique" is just to try to corner the guru for
a couple of hours, and to write up a very focused, organized list
of questions in advance.  I come up with these questions mainly
by playing around with the software and noting what is
confusing (usually everything).

But I'd be very interested to hear some people post some of their
favorite techniques for extracting information out of people.

Anyone care to offer anything?  I've just added Matt's interesting notes on
schmoozing to my list...


> Heck, one of the best ways to get knowledge from someone is to
> play stupid - people LOVE to show others how smart they are!  :)

Playing dumb is one of my favorite techniques, too.  (And often
it's not acting.)  One of many advantages is that it gets
people to talk about the very elementary things that seldom come
up in conversation because normally they have to be assumed.
Such elementary information as "Booksellers can return books to
the publisher for a refund" typically explain a great deal about
why the software is designed as it is, as well as give you
important clues about when people are supposed to do various
tasks.  But if you just ask someone to explain the software to
you, this is exactly the kind of information they're most likely
to omit.

However, playing dumb can backfire: it can lead people to think
that it's not worth their time to talk to you.  After all, all
those unstated assumptions are unstated and assumed in order to
facilitate conversation.  "If he doesn't even know *that*, well,
I can't give him a basic course in how they do things at
bookstores..."  Never mind the facts that (a) this information
is very difficult to find without actually working at a bookstore;
and (b) any other source of information would explain
*different* fundamental premises than the ones that your SME
assumes.

Any tips on how to avoid these potential backfires of playing
dumb?

--
Ben Kovitz <apteryx -at- chisp -dot- net>
Author,  _Practical Software Requirements: A Manual of Content & Style_
http://www.amazon.com/exec/obidos/ASIN/1884777597
http://www.manning.com/Kovitz

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=