Team 7 - Jaeger/Lopez
To review documentation, you send it out to get the reactions of other people who are involved in the project.
Reviewing may take the most time compared to all other activities associated with document production.
Getting the most out of your review cycles - follow these 6 steps:
1.) Review the Document Objectives from the Documentation Plan
- Consider the documents objectives in the planing stage
- If applicable, make sure it meets company policy and reflects well on the company
2.) Determine the Type of Review Needed
- The kinds of reviews you design will depend, in part,m on the kinds of persons who have a stake in the documentation.
- Reviews offer challenges and problems, because not all of the persons whom you need to do the reviewing may be at your job, or may lack familiarity with your project.
3.) Establish a Review Schedule
- Make sure you give your reviewers enough time to fit the reading into their schedules.
- Careful reviews take approximately 1 hour per 15-20 pages.
- Sequential Circulation involves making only one copy of the document and then passes it to the next person to review it. Main advantage is minimal cost
- Simultaneous Circulation involves making a copy for all of the reviewers and receiving every ones review back. Main disadvantage is its expensive to create all the documents but you can tailor to diverse reviewers.
4.) Plan the Reviews
- A well-articulated review plan encourages you to think the process through by making it a goal-driven process.
- A plan provide3s background material to help reviewers respond more productively.
5.) Write a Cover Letter with Questions for the Reviewers
- To get relevant information out of your reviewers you should provide them with a cover sheet specifying what exactly you want them to pay attention to.
- Tell the reviewers exactly what you want them to do.
6.) Prepare Feedback Materials for Reviewers
- Reviewers need to know that you have read their comments and paid attention to them. Let each person know the effect of his or her work on your project.
- Use memos or thank-you letters for giving feedback to your reviewers
Reviewing Differs from Testing
Testing tends to concentrate on users and issues of accuracy and statistics. Reviews develop information about conformance of a product to management schedule and company policy. Also, reviews don't produce quantitative data about a document or statistics.
Reviewing Differs from Editing
Editors bring their training in editing. Reviewers such as managers, subject-matter experts, and programmers bring their professional opinions.
The Purpose of Reviews
Communication function - help communicate with people associated with your project
Management function - help you manage your project
Quality assurance function - help you maintain the quality of your product.
Reviewing Throughout the Documentation Process
Planning and Design Stage - your documentation plan should undergo thorough testing and review by managers, clients, and users
User Analysis Stage - an audience analysis should be presented to your managers, clients and users as a way of checking their validity and accuracy.
Development and Writing Stage - early in the development process you should validate the accuracy of your task list.
Draft Stage - you may want to schedule and implement draft reviews of parts of the document that have reached completion.
Reviewers as Partners
Tell them the benefits of participation - Make your reviewers understand that not only you benefit from them reading your document, but they also benefit.
Don't abuse the privilege - Don't overuse a good reviewer.
Show them revisions - Share your revisions. If you managed to get good feedback from reviewers, let them know how you used it.
Hold review meetings or walkthroughs - Have reviewers meet each other.
Keep contact over time - Keep a file of information about the work they have done which will help you avoid overusing them.
Return the favor - Don't compensate them. It's good business practice these courtesies in a meaningful way.
Thank them in print - When you have the opportunity, list the name of those who reviewed for you.
Negotiate Changes Diplomatically
Be firm only when necessary - The more you respect another culture's tendency to leave things undecided, the better chance you have of discovering a solution in the future.
refer to the Relationships Rather Than to the Person - Reinforce relationships when dealing with cultural conflict.
Acknowledge Cultural Differences and Give them Value - Engineers come from a "high context" culture where writers come from a "low context" culture. Compromise between the two.
Do a User Walkthrough
This is where you present the document form end to end and focus on the key issues of usability.
How to Set Up a User Walkthrough
1.) Decide on the issues you want to examine.
2.) Choose the attendees.
3.) Prepare a meeting agenda.
4.) Make copies and provide files for all attendees.
5.) Run through the walkthrough. Begin by announcing the agenda.
6.) Do a follow-up review. Send copies with the suggested changes to users after the meeting.
User walkthroughs offers a number of advantages for writers and users. Users can have a say in the development of the documentation and allows you to gain valuable insight into the usability of your document.
Subscribe to:
Post Comments (Atom)
8 comments:
It is interesting how a person can just give someone their work and say "Can you review this for me and tell me what you think?" It's hard to do that sometimes because of the factors discussed in this book, such as familiarity with the subject. However, if a plan is involved as extensive as this one and the writer and the reader are familiar with it, then items can be categorized accordingly when reviewing to make it easier for the reader to understand later. After all, if there is any confusion in the process, the writer might ask another person to review it all together and then time will have been wasted.
One thing I have found important when asking someone to review something for you is that you need to make it clear that you may or may not accept the reviewer's suggestions. Of course, if you continually disregard the suggested changes of a reviewer, this may cause some friction. However, if you make it clear about having the final say, I think it helps. We have had some issues with reviewers who definitely want things their way, even if the original content is not wrong, just different than what they are suggesting. It's a tough thing to deal with sometimes.
I have found that there are people who make better reviewers than others. The best reviewers are those who have a stake in your writing project because they probably understand the subject matter and will provide useful feedback. Barker differentiates between reviewers and testers and editors,which was helpful to me for my projects. I think it's a good idea to include those who don't have a stake as well, since they will view the project with the fresh eyes of a novice. In the real world of business, a writer may not be able to select reviewers so Barker's ideas are relevant guidelines. I've found adhering to a schedule for reviewing keeps everything on track. I like the idea of reviewing throughout the planning and design stages as I think this could save the writer extra work in case the project is getting off track early in the process. From personal experience, I've found that it takes specific people skills to accept feedback from reviewers so the experience is helpful for the writer and the reviewer. Mary wrote about the importance of making sure reviewers understand who will have the final say regarding any and all suggestions to a project;this is an important point to clarify from the start. The idea of 'walkthroughs' invites the users and others with a stake in the project to contribute to and feel a part of the process. This theme seems to follow all stages of writing documentation.
This chapter really put the focus on more than just the necessary steps for obtaining useful review information. As with any aspect of technical communication, the writer needs to have a good understanding of human nature - going back to the fundamental concept of "knowing your user," whether that be managers, editors, programmers, or clients.
For example: one of the advantages of sequential circulation is promoting team spirit, but almost all of the disdvantages result from basic human nature: someone feeling slighted because they didn't get the copy first; one person's margin notations can distract from the rest of the document by subsequent reviewers, causing margin arguments; early review can affect later reviews, etc. I came away realizing that a technical writer really has to wear two hats: being a good technical communicator, and understanding and dealing with differences in personalities, perspectives, and office politics, regardless of what you are trying to accomplish. Handling your audience correctly can improve your review process results.
Reviews can be a touchy subject depending on who you ask to review your document. The review is part of the approval process for our documents. If the third reviewer on the list makes comments or suggests changes, then the review will start again so the first two reviewers can have the opportunity to agree/comment on the third review. It can get very time consuming and there are those that argue that this is a waste of time. And like Barker points out,if you have someone that sits on it for an extra week or looses the document this can cause delays and even some anger. Team work is an essential part of our review process but can sometimes cause confusion and delays.
I have to agree with what others are saying here. I think that there are better reviewers than others, often those with something in the project. I think that good reviewing can be wasted at times because there are certain people who will not take suggestions. Sometimes you may ask someone to review something because of their experience with the product. They do not necessarily have to be someone that helped create the document but someon who will be using it and may have seen many in their day. Reviews are only as good as you let them be.
I never thought so much work went into reviews. This chapter really emphasized what was important to do to get the best reviews. I like the idea of knowing who your reviewers are so you can use their comments as best as possible. The six steps of review cycling really show how much thought needs to go into reviews to reach the best outcome. The differences between reviewing and testing are also more clear to me now. Testing really focuses on the users while reviewing focuses on others' opinions of the actual documents. I haven't had much experience with reviewing yet, but I can tell that it can be a tricky process. Telling reviewers how their comments benefited the project can make them more willing to comment in the future, even if all of their comments weren't used in the way they intended.
I can be horrible at reviewing things at times; I'll start to go after grammatical and spelling mistakes just to have something to point at. Thankfully, nobodies actually complained about the nitpicking yet, unless you count internet message boards.
Post a Comment