Re: Walk-throughs

[Sharon Burton <sharonburton -at- EMAIL -dot- MSN -dot- COM>]

And if they are new at this, expect a lot of "How could you write something
that is so obviously wrong/stupid/too simple/missed the point entirely/fill
in the blank?" The assumption is that if you couldn't get this obviously
simple thing, how can I expect you to get the finer and more complex parts
of this? Also expect that no one will actually read the chapter before the
meeting.

Even experienced people can produce this attitude. I have a client that
adopts this approach and it can make for some grueling walk throughs with QA
and the programmers. After weekly reviews of the manual for the last 6
months, they are still reorganizing and adding/editing. And since there is
no product manager/project manager... I imagine I will be doing this up to
the moment they ship. It is very difficult but I have adopted the bad
attitude of just tell me what you want and I will do that. I have given up
on ever having a decent and useful manual.

Fortunately, I have another wonderful client that really understands that
the manuals are only as good as the info given to the writer. And everyone
understands that the goal is to have a useful and accurate manual. So my
life balances out but it is frustrating as can be at times.

I have worked at a place where the people involved had their performance
reviews tied in part to their level of effort in the review process. It was
heaven. The great client mentioned above has fired programmers, in part,
because they refused to hold up their part of the review process. They are
my very favorite client in the world!

sharon

Sharon Burton
Anthrobytes Consulting
Home of RoboNEWS, the award-winning unofficial RoboHELP Newsletter
www.anthrobytes.com
anthrobytes -at- anthrobytes -dot- com


-----Original Message-----
From: Scott Miller <smiller -at- CORP -dot- PORTAL -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Tuesday, 02 June, 1998 2:54 PM
Subject: Re: Walk-throughs


>A few things to watch out for during documentation walk-throughs:
>
>- Reiterate repeatedly that you don't need to hear about minor errors
>such as punctuation, spelling, grammar. If they mark it up on the draft,
>fine, but it doesn't have to be brought up in the meeting.
>
>- Often, the only time engineering, marketing, and tech support are in
>the same room together is for a documentation walk through. Therefore,
>huge communication gaps are commonly revealed, such as which features
>are in the product, who the user is, the product name, and so forth. It
>is easy for a walk-through to get sidetracked. When this sort of thing
>occurs, tell the participants to either take up the discussion offline,
>or save it for the end of the meeting. The catch is that these issues
>often affect the documentation, so it's tempting to try to resolve them
>then and there. If you do, you sometimes spend the entire meeting
>discussing one or two issues, and the documentation doesn't get
>reviewed.
>
>- There is always someone who can't get with the program, who raises
>issues such as "is this document necessary," and other subjects that
>have already been resolved. Ignore them.
>
>- Scott Miller
>smiller -at- portal -dot- com
>
>------------------------------------------------------------------------
>-----------------------
>> > I was wondering if anyone out there had ever conducted a manual
>> > walkthrough, either in the preliminary or final stages. I'm looking
>> > for a different approach to our walkthroughs. I work for a company
>> > where nobody wants to sit down and dedicate a few hours to the
>> > quality of our manuals.
>> >
>
>
>