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.
> 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. Consequently, technical
> writers are under
> tremendous pressure to ensure that features are
> accurately documented. A lot
> of rework occurs, and the quality of output is
> abysmal.
In an environment like this, you really need strong
specs and need to write according to the spec. Then,
when it comes back that the info is inaccurate, point
to the spec. If the spec is inaccurate or old, then
they need to realize that it needs to be accurate in
order for EVERYONE to work in the same direction. Once
your spec-driven work is done, you can fill in the
remaining info from the finished feature.
> Those administering the development process have
> been requested to
> incorporate a documentation phase into the release
> cycle so that technical
> writers can work with a stable, tested product.
That should be for the remaining info that needs to go
in. You should be able to write most of the info in
tandem provided you have good info to start with.
> Unfortunately, this request
> has been turned down, and the reason provided for
> this refusal is that the
> company follows a three-month release cycle and
> hence has inadequate time
> for a dedicated documentation phase.
Propose what I suggested.
> * Is such a situation normal in a software company?
A start-up, yes. It all comes down to project
management. Planning and structure are the saving
grace for software projects. It seems like it's a
waste of time, as initially there's a ton of overhead,
but the overhead quickly dwindles once the game plan
is set and the specs are in place.
> Are there examples of
> other companies that work in such a fashion?
I worked for a few, but they're not around anymore. ;)
> * How does one produce good documentation in on
> schedule in a setup such as this?
Planning and cooperation, and good attention to
details by all involved parties prior to the start of
the physical project work.
> * Are there any documentation methodologies that
> lend themselves to this manner of working?
No, just good project management ones. This isn't a
writing issue.
=====
Goober Writer
(because life is too short to be inept)
"As soon as you hear the phrase "studies show",
immediately put a hand on your wallet and cover your groin."
-- Geoff Hart
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
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.
