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

["Joe Malin" <jmalin -at- tuvox -dot- com>]

I always take job blurbs with a very large grain of salt (think cinder
blocks...)

Sounds like they are using some form of "extreme" development with rapid
cycles, or they *want* to do this.

Are you sure this is software development documentation? It sounds like
they're using a rapid development cycle for the software itself, but I'm
not sure who the end users are. I also wonder about having a tech writer
do the architecture/design docs. I personally think it's much better to
have engineers write them and have tech writers edit them.

Having said all this, I note that I prefer SW dev documentation to
end-user documentation. I'm a SW engineer by training, so I have a great
feel for what developers and enterprise customers need. If you go into
this area, and you don't have a SW dev background, you will face a steep
learning curve.

Still, you may want to accept the challenge. You may bring in something
that they need. I tend not to worry about whether or not *I* can do the
job. I focus on convincing *them* that I *can*. It's certain that if you
go into it worrying if you can do it, they'll notice.

Joe  


	 Joe Malin
Technical Writer
(408)625-1623
jmalin -at- tuvox -dot- com 
www.tuvox.com
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.	

-----Original Message-----
From: techwr-l-bounces+jmalin=tuvox -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+jmalin=tuvox -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf
Of Bonnie Granat
Sent: Wednesday, January 18, 2006 8:32 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Specifics on the too-good-to-be-true job PLUS question


Just got the following details about that job I queried the list about
last
week:

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?

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

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.