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.
Oh that such a thing were possible! I haven't seen it yet. I'm doing last
minute updates to help files on the day the product is released to the
client. If the build works in the client's test environment, we'll FTP the
help projects into the build that actually works. It's crazy, but it's one
of the more common ways things get done.
You make excellent points, however I'd put one before your first one.
Establish that you are ALL working on delivering a usable product with the
highest acceptability by users. Get involved in designing the product, not
just the support, and you'll know what the features are at the same time, if
not before, the developers do. Chances are that you're better at it anyway.
Your reporting line matters less than your involvement in an integrated
process. As does when and how you enforce a "feature freeze" (lovely
concept, that). The real world is that QA finds bugs, and sometimes we have
to go back and start over. We build our schedules so that doc/user support
gets delivered to QA and BA at the same time as the final scheduled
development build. So QA has the same amount of time to finish regression
testing, and QA real-time help systems, as we do to finish writing and
editing.
Bottom line: You shouldn't "demand" anything--you can work with development
and QA to ensure that your development and production cycle is integrated
into theirs. Demanding TW's just get a rep for being unreasonable. Try
helping the QA folks finish regression testing--you'd be amazed at how many
favors you can call in later.
I report to the installation and product support department. I work with the
marketing folks, the business analysts and the developers. Our goal: let
marketing sell a product that we actually make, and let's make a product
customers will actually use.
New topic, back to 2 cents worth!
Connie Giordano
-----Original Message-----
From: Andy Becraft [mailto:andy -at- trados -dot- com]
Sent: Thursday, March 22, 2001 2:44 PM
To: TECHWR-L
Subject: RE: Content Moratorium
Hi Colin,
The problem here seems to be something that is relatively common in the
software development industry -- at least if you believe the venting that
takes place on this list (which I do). That problem is that your
deliverables are not considered part of the actual product. This perception
is exacerbated at some companies by tech writers reporting into the
marketing or support departments instead of being part of the development
organization.
Changing the perception that your deliverables are ancillary or somehow
secondary in importance is the first step in establishing a process that
allows you to meet the expectations of your peers and managers by delivering
on time. The bottom line: Educating your peers and managers in development,
product management, marketing, QA, and other interested parties is the only
way to succeed in this endeavor. So, don't give up quite yet on education!
What you call a "content moratorium" is something I would probably call a
feature freeze (no new functionality!) and/or GUI freeze (no further
modifications to the user interface!).
Here's how I might go about effecting change (I'm painting with broad brush
strokes, now):
1. Convince those responsible for scheduling product development and
deployment that your deliverables are integral to the success of the product
launch, and are indeed a part of the product as a whole. Therefore, you need
a reasonable amount of time AFTER the product has been finalized to finalize
YOUR deliverables. Outline the exact problems that last-minute changes to
the application cause. For example:
* Your procedures are dependent on stable functionality, and
therefore your procedures have to be rewritten every time
functionality changes.
* Your screenshots are dependent on a stable user interface,
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
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.
