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.
Subject:RE: More on Validating documentation From:Syed Ahmed <SAhmed -at- DKSYSTEMS -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 25 Mar 2002 09:27:31 -0600
We (the documentation team) actually had a meeting last week with
development discussing exactly this topic. The head of development here
feels that documentation for the software we release is a component of what
our end ("shippable") product should be, and re-emphasized the importance of
development and documentation working closely together throughout the dev
process.
The documentation team (consisting of myself and I other writer) are
perceived as an integral part of the development team. Our relationships
with development is ideal, because we are very much incorporated into most
aspects of the development process (e.g. providing user feedback, system
analysis, and design input). We sit with the developers, which is great
because my interviews never have to be too formal. I can yell over the
cube, or just walk over to them and ask them anything I like. I shouldn't
omit the fact that I also spent my first year here becoming friends with
each developer by doing lunch a few times a week with each of them, and I
continue to do so with every new one we hire, because in the end, that seems
to make the biggest difference when I need questions answered, or docs
reviewed.
Documentation is also a bit spoiled here because the company on the whole
places a very high value on documentation, and realizes the disadvantages of
producing shoddy docs. This high level of consideration given to
documentation trickles down from upper management, and facilitates the
cooperation we receive from our developers; especially from the ones who
don't like interacting with anyone, let alone a pesky tech writer.
Syed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
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.
