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.
There is nothing inherently unethical about "playing politics". ALL
governmental officials (for example) do it. Yes, I know that some
percentage of them are crooks, but many are among our greatest
citizens.
Do technical communicators need to "play politics"? You betcha. Tom
DeMarco said that "Analysis requires the negotiating skills of Henry
Kissinger". (Structured Systems Analysis and Specification, by Tom
DeMarco. Yourdon Press, 1979).......
Elna Tymes responded:
Not necessarily. Much of task analysis requires nothing more than
simple observation. Some of the fine points may need explanation by
the source person.........
Tony Markatos responds:
I disagree. My formal education in task analysis was through company
(McDonnell Douglas and Hughes Aircraft) in-house training programs
back in the mid-80's. (The Aerospace industry was a pioneer in task
analysis.) What I was taught (and my work experience has confirmed)
is essentially this:
1.) There are three basic categories of tasks: Planning, Control, and
Execution. (These three categories actually came out of research work
done in task analysis by the National Science Foundation.)
2.) Only one of these is directly observable - execution (i.e.,
doing) type tasks. Planning and control are though-intensive and not
observable (i.e., you can not "observe" someone's thoughts).
3.) For information systems design, knowledge of planning and control
tasks is much more important than knowledge of execution tasks.
(Stands to reason: planning and control is where most of the
information intensive decision making is done and, after all,
software systems are essentially decision-support systems.)
4.) Therefore, the main thing that a task analyst has to do is
directly solicit procedure through aggressive interviewing techniques
-- not make observations.
Sure I have done a significant amount of observation, but Elna,
getting information from the people who primarily execute -- the
"indians" -- is not hard. Time-and-again my experience has been that
getting procedure from the planners and controllers -- the "chiefs"
(most noteably mid-management types) -- is difficult. Not always but
very often.
To put it bluntly, the planners and contollers within an organization
are often so turf-concious that, unless the analyst is very
politically savy, he / she will be "eaten alive".
Elna Tymes said:
Most of what technical writers do.....has little relevance to turf
and therefore to politics, and a great deal more to do with the very
simple 'how does this work?' types of explanations.
Tony Markatos responds:
I disagree (again). First of all, the question that needs to be
asked is "WHAT does this do?" not "HOW does this work?" Effective
end user documentation is always focused on the WHAT.
For complex systems, getting a clear, concise, integrated
understanding of the tasks accomplished (i.e., understanding of the
WHAT)is VERY difficult. The WHAT translates to mean "essential
procedures accomplished". And since knowledge of procedure is turf,
getting the WHAT involves incroachment upon turf.
Tony Markatos
(tonymar -at- hotmail -dot- com)
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
