RE: Seeking counsel - yet another difficult work situation (extremely long)
I am the sole documenter in a software development company whose products are developing at an extraordinary rate. The work environment is geared towards getting new features out quickly. As a result, almost all of management's time is directed toward ensuring the development progresses smoothly.
This, however, does not extend to the documentation. Documentation issues seem to 'fall through the cracks', with nobody seemingly able (or willing) to do anything about it.
Documentation always falls through the cracks when NOBODY cares. The person who should care is YOU.
Although there is a lot of 'lip service' to the documentation (verbal "thank you's" from development managers and even an email expressing gratitude and support from the CEO), there is no practical backup for me as the documentor.
What kind of documentation are you expected to produce? If you don't know, or don't know who to ask, decide on your own what kind of documentation that you need.
In my opinion, the most important document is the requirements specification. What do you expect the software to do? Is there a testing department? They must have some of these requirements somewhere, otherwise it is impossible to test.
Or, take a look at the software that your company is developing. Write down what you see in screen shots. Write down questions that you don't understand and find someone who can explain it to you. I've been known to ask a random person, who then refered me to someone else, who sent me to another person. Eventually, I got the answer.
Set a list of documents that you expect to produce for each piece of software. Next, see what you have already and find where the gaps are. Then, start filling in the gaps.
My list is simple: Statement of Work, Requirements Document, Design Document, Test Plan, Help File. (Because of the nature of my software, we don't need or produce user manuals.) Now that I know what is needed for each piece of software, I keep a spreadsheet listing them and talk periodically to the project managers, "Hey, we still need to get that Test Plan together."
I have been trying to implement procedures to:
a) get the information I need to keep the information up to date, and
b) review the documentation,
but with little lasting success
You need to be more assertive. Someone else suggested making a meeting; this often works. Be sure that you have snacks, though, even if it means bringing in donuts or cookies yourself. Food is a great motivator, and will ensure higher attendance.
Someone else suggested getting on email lists. That has always worked well for me. Often co-workers are surprised at the number of lists that I am on. I filter them to specific folders, then check each day to see if there is something that I missed.
Make a pest of yourself. Ask someone at lunch how their project is going. "Accidentally" walk past a cubicle when someone has the application up, "Wow! That looks great! Did you create that screen? Can you show me what it does?"
At one dot-com, my desk was in a hallway just outside of the men's room (we had 20 cubicle for 35 employees, so some of us were in strange places). I would often snag guys as they went in or out (catching them on the way in was a way to ensure the conversation was short and to the point. Longer discussions ensued on the way out.)
To make matters worse, there are no SME's who can verify the content - coupled with the 'unwillingness' of the developers to review, this could lead to serious problems with the documentation, with the responsibility lying squarely with me.
Find one. As I mentioned before, the SME may be a tester. It could also be a project manager, or, if you have a public product, a friend or family member who uses the product. Or, you may become the SME. I was once one of only five people in the world who knew how to use a piece of software, and I knew more than the other four because they each concentrated on a single aspect.
I am currently in the position where I don't even know to whom I report (the company I work for is a recent amalgamation of several software dev companies and is still in a state of flux).
Who signs your timecard? Who do you tell if you are sick? If you don't know, take a sick day and tell the receptionist. He or she should know where to transfer your message; if not, someone will come by the next day and ask where you were. That should be your supervisor :)
Good luck in your situation. I hope my advice helps.
Diane Evans
Technical Writer/Requirements Analyst
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.
Follow-Ups:
References:
Seeking counsel - yet another difficult work situation: From: Robyn Richards
Previous by Author:
RE: Fwd: difficulties with the boss
Next by Author:
Re: "Printer-friendly" web pages
Previous by Thread:
Re: Seeking counsel - yet another difficult work situation
Next by Thread:
Re: Seeking counsel - yet another difficult work situation (extremely long)
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads