[BC] User input (Engineering v-v Air Staff)

[Jeffrey Kopp]

>[Willie:] Yes, getting user input is most definitely important! Since I
>*wasn't* going to be spending any time running *that* board, I remember
>asking questions of the air staff back when I was doing some PT
>Engineering work...

Well, first I'd like to apologize for my bombastic reminiscence. Willy
and several others noted the importance of asking, but what I was trying
to get across was the importance of observing before inquiring.
Operating tasks often become automatic, ingrained habits through
repetition, so some snags might not come to mind upon being asked.

Of course, people dislike being observed too closely while working, so a
discreet subterfuge like adjusting or cleaning something nearby helps
avoid appearing intrusively inquisitive. Done in the right spirit, it's
not spying, it's op analysis and training prep.

Also, there are often quirky little legacies: some unnecessary step
still taken, or a necessary one made in wrong sequence, because the
habit predates a change in equipment or procedure, or from an arbitrary
mandate imposed by someone no longer around (often in overreaction to some long-past snafu; institutional memory is a wonderful thing, but
inevitably includes rough edges). If you watch, you'll spot these long
before they might be mentioned, if ever.

Comparing reports of old-timers with new hands usually brings these out;
perplexed newbies will often confidentially inquire, "Why do we do
that?" Checking back with the experienced will yield revealing details
like, "Oh, that used to be over there" or "We had a problem with [some
previous subsystem/vendor/person]," which knowledge can be invaluable
when tracing another problem down the road (Where does this cable go? or
Why did it ever get wired like this?). Conversely, exploring a forgotten
or neglected system or procedure (or kludge) can help prevent things
from falling through the cracks--it was established for some reason,
whether still valid or not--and can also help avert little disasters
like yanking something that makes no apparent sense but still has some
necessary, if perhaps only occasional, reason for existing.

If you're fortunate enough to find a memo board that hadn't been weeded
for several years, skimming it can reveal tons of past history that'll
explain a lot of what doesn't seem to make sense, and becoming so
informed will make unsnarling things much easier.

I never got the hang of flowcharting, but redesigning forms (after
studying the way they're currently used) and putting them out for
testing is often revealing, and the end result may significantly
streamline a process.

The hard part (which I never quite mastered) is introducing an improvement without offending; people are proud of their skills and
experience, and will naturally be embarrassed to have some idiosyncrasy
spotted by an outsider. Plant the idea for a change and let it seem like
theirs; they would have thought of it eventually (giving generous
benefit of doubt in come cases...). This requires a capacity for ego-
swallowing I never developed, though I eventually realized (a bit late
in the game) that if things work well and you clearly had some hand in
it, you'll be appreciated, regardless of whose bright ideas they supposedly were. And after all, they did tell you, in their own way,
what needed to be done.