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: where do docs fit in the development process? From:John Cornellier <tw -at- cornellier -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 29 Jan 2002 10:44:23 +0100
>I was just wondering where documentation fits into the development cycle
>where you work.
I work for a large high tech multinational; however for historical reasons we are a smallish mostly self-contained unit of scientists, software engineers, and testers.
> How is a documentation project initiated?
* Someone comes to see me
* After projects are announced at format meetings
* Based on info from intranet project pages.
* By my monitoriing of software revision to the baseline
* While eating lutefisk in the canteen
> Is there a process
Yeah, but it's more of a guideline at the early stages. Mostly I find out about things by the above-mentioned. (We do have very rigorous processes later in the dev cycle regarding testing).
>(final draft, and final doc)
Don't have any labels like that. Basically when the software is turned over to testing there must be a doc for them to test. I just try to do the best I can given the time I have for that project. It's never going to be perfect, and if
it's utter bollocks then the testing vetos commercialization (this hasn't happened yet to me!)
> Where I work, they want the final docs at the same time the release candidate
We do that. Otherwise how can the doc be tested? It makes sense for the QC people to test both at the same time. Plus it's a great way to test the doc -- the testers don't understand a new function so ... they click Help. This is
a true test. I often get subsequent mod requests for the doc along the lines of "it may be obvious to you [who has worked with the project for months] but not to the newbie".
> I have tried to implement a form to kick-off documentation projects.
I break out in a rash when presented with a form.
> how do you get developers to review your docs?
I don't. No point.
* tech stuff is validated by me with engineers' help
* The writing is done by me then gets a reality check from the testers
* doc usability is checked by testers
>but I don't want to pass the buck, I'd prefer our docs are reliable. I'm
>seriously considering flinging myself down on the floor in front of my boss'
>office, and throwing a temper tantrum that would rival any two year old's!
Um, do you have a Plan B? OK, so you're unconfortable with the way things are going. You need to change the way things work, and to do that you need to get people on your side.
1. Get people in the group to recognise the need for good doc.
2. Find out whether or not your doc meets expectations of the point above. If your doc's not good, then show that in an objectiv-ish way -- such as from a bug tracking system.
3. Propose a viable solution (that's another thread).
John Cornellier
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Attention ForeHelp and Doc-to-Help Users! Upgrade your existing product to
RoboHelp for only $299, through January 31st. RoboHelp can import your
existing Help projects! Learn how else RoboHelp can benefit you. 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.
