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.
-> KEG writes:
-> <What I am trying to do is write based on what the developer of the module
-> is telling me will be there and how it will work. This seems like a lot of
-> wasted effort and frustration to me, but I have been told to start
-> documenting the system now.>
-> If you don't have a formal process for new product development in place,
-> now is the time to start one. It should show critical dependencies - like I
-> can't document the features until they are there! - and drop dead dates for
-> production. JoAnn Hackos' book will give you some good ideas.
I agree, her book is an inspiration, and I don't bestow that epithet
lightly.
You have the chance on this project, and on future projects, to help
define and organize the development process, by offering to "help" with
such things as user interface prototyping, developing a written
engineering specification for your engineers to work from, and
coordinating your efforts with your marketing department.
Benefits: you get information earlier, and you're part of the team that
actually defines the product, so you have an inside track on what to
document. You may, if you manage your time and resources well, help
streamline the development process by defining the goals in advance.
Your involvement in the design and development will give you leverage
when it comes time for in-house review of your documentation, since it
will be difficult at that point for your colleagues to argue that it's
not as important to the project as "their" work.
Creative tricks: Some people suggest offering to take notes at
development meetings, and distribute nicely-typed copies afterwords. You
get inside information on what's happening, and advance warning of
changes.
That can backfire, and you could end up getting coffee for everyone too.
Instead, consider meeting with your engineers, and then delivering an
intelligent analysis of the product, some points to consider about the
implementation, some suggestions for details of the implementation that
will improve the product, etc. etc. etc. Sometimes you have to gently
shove your way onto the team, and persistence eventually pays off.
Cheers, 805-873-2500
Gwen gwen -dot- barnes -at- mustang -dot- com
MSI * Connecting the world WWW, Telnet, FTP: bbs.mustang.com
@DISCLAIMER@ ` Free speech online `
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
