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.
While you're buttering them up to make changes in how they do things, just
try to learn the product more with each build and work hard to get along
with those programmers! I have a hunch you're going to be the main product
tester. I'll bet your company has no QA department either, am I right? I've
been there, and in less than 3 years my company has progressed to better
planning, a QA department, testers, and a more useful "big picture" approach
by the development teams.
The changes were brought on just a little bit by me constantly playing the
user advocate. I'm always pounding home the fact that we are designing
software for our users and not for our engineers. Mostly the changes were
brought on by the developers' frustration with the inefficiency of their own
working habits. They started to realize there could be a better life for us
and they do have a genuine concern for our customers. The programmers here
aren't afraid to try new things and they want to improve the system. A new
head of engineering is also working hard to organize and turn the culture
around. Changes won't be effective if they're not supported at the top.
Oh, and we've also hit several snags where I finally documented the feature
first and told the programmers to make it happen. They seemed to like that!
Some books on software development that push structure and planning might be
a nice gift.
From: Edwin Tudsbery [mailto:tudsbery -at- matranet -dot- com]
Sent: Thursday, May 04, 2000 3:27 AM
Subject: No specifications
I'm writing a manual for a product with no specs. The developers don't write
anything about what they're up to, and what they're planning for the future.
Part of the problem seems to lie in the fact that most of the source code
for the product is licensed from another company.
Have other people encountered this problem? What have they done to resolve
the situation? What can I do to persuade the developers to put their ideas