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:On Validating documentation [longish] From:jgarison -at- ide -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 25 Mar 2002 10:23:45 -0500
Eric, I think your experience pretty much matches my own. It hasn't always
been this way at every place I work, but there have been times and
situations where we did forge real team relationships.
Currently at IDe we have real, honest-to-goodness cross-functional teams.
EVERYTHING we do is developed, designed, documented, tested, and shipped by
a team representing all groups in the company.
It starts here from the very top down. The Chairman of our Board of
Directors (and founder of the company) is the author of PACE (tm) -- Product
and Cycle Time Excellence, a methodology for cross-functional development.
At the very top of our company is a PAC - Product Review Committee -
consisting of the Chairman, CEO, VP Support, CTO, and one of our Board of
Directors. They set the vision and direction for our development. [We make
software that manages product development across an enterprise.]
For each release of our product, we have a Core Team that is comprised of
representatives from Marketing, Sales, Support, Finance, Development, and
Product Management. [For the current release, I, the doc manager, am the
Core Team Leader.]
For each feature of a release, there is a cross-functional development
Feature Team consisting of a writer, developer, tester, and designer. [We
have found the tech writers to be the best Feature Team leaders.] All
features are initially designed and specced, then given to the feature teams
to do final design and to manage all the development (coding), testing,
documentation, and to go into final testing in time to make the release.
As you can tell, the technical writers are integral to the process. We are
involved in all aspects - from design through to release. We are involved in
technical design sessions as well as daily development meetings. We are
looked to as the team leaders for the Functional Teams.
Is our process perfect? No. We are constantly looking at ways of making it
better. But I can say that in the three years I have been here, we have only
missed one deadline for shipping a software release, and that was because we
had to do a customer-critical mini-release in the middle of our development
cycle. And we do four releases a year.
Just last week one of the software development managers and I participated
in a Boston/Northern New England STC program about cross-functional teams.
I can't imagine working in any other manner. It's great to be part of a real
cohesive team, and our results show it.
John
John Garison
Documentation Manager
IDe
150 Baker Avenue Extension
Concord, MA 01742
-----Original Message-----
From: Eric J. Ray [mailto:ejray -at- raycomm -dot- com]
Sent: Monday, March 25, 2002 9:55 AM
To: TECHWR-L
Cc: Andrew Plato; etymes -at- lts -dot- com
Subject: More on Validating documentation
<snip>
So, in your experience, are relationships with developers
really as non-existent or dysfunctional as some threads on
TECHWR-L would suggest? Is there really no sense of
"we're all working together to make this overall product
as good as we can make it"?
If so, are _you_, as a tech writer, part of the solution,
or part of the problem, or both? Why?
</snip>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.