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.
"Vlad Dracul" <vladvampiredracul -at- hotmail -dot- com> wrote in message news:214083 -at- techwr-l -dot- -dot- -dot-
> I work for a software start-up in which technical writers are expected to
> write in tandem with the development process, i.e., the
software-development
> life cycle has no definite phase for documentation. Often, technical
writers
> in this company have to write about features even before they are fully
> developed and stabilized.
> * Is such a situation normal in a software company?
Yes. Very normal. I'm not sure a dedicated documentation phase is a good
idea, anyway.
> I work for a software start-up in which technical writers are expected to
> write in tandem with the development process,
First, make sure you are really working as a peer on the development team.
If everyone but you is getting timely information, you aren't being treated
as a peer. Make sure you are on all the distribution lists, and crash the
meetings if you have to. Drop in on people unexpectedly.
Don't accept a lesser form of communication than the rest of the team. For
example, if the developers are speaking freely with each other whenever they
want, in face-to-face ad hoc communcation, then that's how *you* should
communicate with them. Don't let them tell you to "Send me a list of your
questions" or "Schedule a meeting with me next week/year/century."
> Consequently, technical writers are under
> tremendous pressure to ensure that features are accurately documented.
Of course, first make sure you are doing everything you can to get the job
done on your own. But once you have done everything you can, transfer the
pressure back to the people who created the situation. Clarify the lines of
responsibility. You can develop your own bag of tricks to do this.
Remember, you can almost never control other people's behavior. However you
have 100% control of your own behavior, and 100% control of the document. So
those are the levers you need to pull
Here are some ideas. If you don't like them, you can develop your own:
- Embed your questions directly in the document along with the responsible
person's name, then send the document out for review.
- Declare your own timely content freeze on the manual (check the archives
for discussion on this).
- Date-stamp your drafts (or even individual topics) with something like
"This describes Build #98761 released on 9/1/2003. "
- Release your own project plan that shows "Discuss with techwriter" as a
required predecessor for each development milestone. They just might adopt
your plan as the official plan.
...etc.
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
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.
