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.
I guess everything comes down to viewpoint, experience, attitude, and
circumstances.
As both a contractor and an employee, I've never been in a situation
where I've been held to some arbitrary measure of productivity. Of
course, I'm also highly productive (but clients don't always know that
going in). I put out a 50-page manual in 6 days on this current
contract, and added a dozen more pages based on feedback in the last
week. My plan was flexible enough to include a surprise, major piece of
functionality that the developer is still working on because I
structured the document around user activities, and I also know enough
to project how it's going to work before it's done.
For me it's largely attitude. I'm brought in to do a specific job. I do
it with as little fuss as I can. The flexibility of my approach is not
an externally expressed process that people sign off on before they hire
me but rather an attitude that I bring to the table. But I'm also not in
your situation Elna. I am an employee of the company contracted to do
the software development work. Usually the client isn't worried about my
process. They say, "hey, our users need documentation for this product
by the time you're done!" So I do it.
I find that change is *not* a normal part of many writers' processes. We
hear it all the time on this list. It makes people nuts when developers
change the interface or somebody wants a new process or a technician
remembers late in the game that, oh yeah, you really need these other
three pieces of software to make the widget run. Another review cycle?
Ack! I remember interviewing one writer when I was working for the
start-up software company, who despised change. He had his methods and
he "didn't like for other people's emergencies to become his
emergencies." Naturally, he was not a good fit for that company!
I am curious why you say that "Endless iterations of a document are
expensive and time-consuming, and you usually wind up with a document
that doesn't quite hit the mark" and yet also assert that XP programming
can be cost-saving. If you're using the XP approach for the product, and
the documentation is part of the product, then they should both evolve
together and be more on the mark than anything developed using a
traditional methodology. Both will have been subject to testing and
rework based on customer feedback. And you should get the product out
the door more quickly, assuming that the claimed benefits of XP are
true. I'm also curious about the "3-5 years" figure. I haven't done
extensive reading about XP, but that would surprise me.
Lisa
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sponsored by eHelp Corporation, makers of RoboHelp. RoboHelp 2002 is now available! Get the very latest in Help functionality
to create superior Help systems. Get special savings when you buy
in January! Visit http://www.ehelp.com/techwr
---
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.
