RE: Specifics on the too-good-to-be-true job PLUS question

["James Jones" <doc-x -at- earthlink -dot- net>]

Bonnie, this textbook that I used in a technical communication course a
couple of years ago might be helpful. The book is:

How to Communicate Technical Information

Jonathan Price and Henry Korman, Addison-Wesley 1993, ISBN 0 805 36829 9

This book is subtitled something like 'A Handbook of Software
Documentation.' I think that if you decide to go with the opportunity, and
even if you don't, glancing and or reading the stuff here will help you. The
book does not get into all of the types of docs that you mention, but it
still gives you a good intro to the topic I think. 

As to your question , I do not know anything about the RUP methodology. And
as to the other part of your question, I don't know either, but I suppose
that you could learn by doing. The docs that you would prepare would have a
totally different audience from what you are used to. You would have to
adjust, but I do not know whether this kind of adjusting is easy or
difficult. I would say that probably there are other technical writers out
there who have made such an adjustment. They would know whether it's
difficult. I quote from another writer:

Melissa Nelson wrote:
> 
>> I think some of you here have a rough idea of my capabilities as a
>> technical writer. I'm a good end-user writer, but I have no experience 
>> with software development documentation. I would be truly a novice -- 
>> but maybe it's something that a novice could pick up quickly?
> 
> If I can pick up Software documentation...I am positive you can :)
> Seriously, if you can work well with the developers, it is not that 
> tough. The toughest part is often the working well with the developers :)

Jim Jones	http://www.tinyurl.com/4arjc

-----Original Message-----
...This would include the architecture doc, design doc, deployment doc, user
guide, etc. You would work with the analysts, developers, testers, and build
master to document all aspects of the project. We are using a Rational
Unified Process (RUP) methodology (modified) and following their
documentation templates. It is an iterative process and the iterations are a
generally a month long. For each iteration there is a design doc, release
notes, etc. The project is three years and covers 4 releases. I would
anticipate you could work from home a lot. Up front we would need you onsite
four days a week but could then transition dow to 2 or 3 days a week once
you have integrated.

-------------

I think some of you here have a rough idea of my capabilities as a technical
writer. I'm a good end-user writer, but I have no experience with software
development documentation. I would be truly a novice -- but maybe it's
something that a novice could pick up quickly?

Question: Can I learn this by doing it? Is the RUP process intuitive? Am I
just out of my league here, and should I say so upfront and not waste his or
my time on further discussion of this project?

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

Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy.  Watch the demo at http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.