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.
RE: Specifics on the too-good-to-be-true job PLUS question
Subject:RE: Specifics on the too-good-to-be-true job PLUS question From:"James Jones" <doc-x -at- earthlink -dot- net> To:"'Bonnie Granat'" <bgranat -at- granatedit -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 18 Jan 2006 13:38:41 -0600
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 :)
-----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