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.
First off, congratulations on getting the contract. Second, thank you for
telling us, in the process of asking for advice, that there is a growing market
for technical writers in Russia. The list, naturally enough, tends to be
US-centric and it's nice to be reminded that we have peers in other parts of
the world.
> * what software is the most appropriate for a beginner who starts from
> point zero (I apologize in advance for any potential polemics this
> question could trigger)?
This depends on what machine you're using to create the documentation, and what
system is being used for the product you're documenting. Most of us tend to
feel that MS Word is OK for short documents but Framemaker is preferable if
you're doing a multiple-chapter document, or if any of your chapters are longer
than 20 pages. You CAN use Word for big documents, but it has limits that
Frame doesn't. And yes, this topic tends to spark 'religious wars' on the list,
because there are those whose experience is different.
> * taking into account the market properties (in a sense that Russia
> today, as to informatics, is where the States were 10 years ago), what
> should I ask my potential employer? Maybe some of you have experience
> working in pre-informatic societies?
One of the most important questions you can ask is "Who is the audience?" Many
young technology companies don't realize that the kind of document a writer
will produce needs to be targeted at a particular set of people with known
backgrounds and expectations. You'd write a different document, for instance,
for an experienced programmer than for a new end-user. Another question has to
do with your employer's experience in the technical document creation and
production process. Many young companies, for instance, have no idea about the
importance of document reviews AND about the importance of limiting those
reviews. Still another important question has to do with the state of
development of the product you'll be working on - is it being done to some
specifications? Is there a known schedule and are they on target? Is there a
provision for interaction between developers and the writer? There are lots of
questions you could ask here.
> * the job I'm about to get is on contract basis and I'm offered an
> hourly payment rate. If I don't work in the office, how to calculate the
> time? What inputs do I include in the calculation?
Probably the most widely used set of metrics is in JoAnn Hackos' "Managing Your
Documentation Project" (or something similar). Whether you work in the office
or offsite, your time involved depends on (1) how accessible source information
happens to be, and (2) how fast you can translate the source information into
usable prose.
You asked some very broad questions. Perhaps the list can help you more if you
make the questions a bit more specific.
