|
|
If you work as a team to write the final project for this course, you and your team chooses to document a hardware component or software application. Depending on your instructor's requirements, your team develops team rules, decides on team roles, develops a schedule, plans the design and format of the document, writes a documentation proposal and documentation plan, produces prototypes, and other such activities.
Note: Even though this project is a team effort, each team member must not only write at least one section of the final document but also "build" the final document using the sections of that document written by the other team members. Building books in FrameMaker is an essential skills everyone in this course should develop.
Assemble a Documentation Team
Once you have your team members assembled, appoint one member of this team to go to the project startup page and set up your team's project page.
There is a later requirement to define roles for your team project and to get individuals to fill those roles. At this early point in the project, meet in the chatroom and get to know each other. Toss around ideas for a project; find out what interests and background people have. Find someone who is willing to post information to the team home page: specifically, the project description, the audience description, the outline, project-design notes, team roles, and team rules.
Note: Take a look at a draft chapter from Power Tools for Technical Communication on documentation teams.
Define Team Rules
If you work as part of a team, you'll need to anticipate problems involving team members such as the following:
- Certain team members don't "show up," don't do their agreed-upon part of the work.
- Certain team members end up doing too much work and become resentful.
- Certain team members simply don't have the skills to do their part of the work.
- Certain team members have personal crises and have to drop the course or else the quality and timeliness of their work suffers greatly.
- Certain team members get into disputes that eat up meeting time, upset everyone, and can't find a resolution.
- Certain team members are bullies and seek to dominate the team; other members are quiet anfd unassertive.
You must have a set of rules that all team members take part in developing and agree to abide by. If necessary, use your instructor as the final arbiter of disputes. You must figure out a way for your instructor to know about slackers on your team and to modify their grades accordingly.
When you've developed a set of team rules, have your team-page updater post this information your team page for all to see (and on or before the due date).
Define Team Roles
However the teams are defined, you'll need to meet with your team members (in the chatroom, for example), get to know each other, find out about each other's backgrounds and special skills, and start forming ideas about who should do what. In a documentation team, people plays the following sorts of roles:
- Writers. Ideally, everybody does some writing — after all, this is a writing course. However, there is so much else to do that this may not be possible.
- Technical leads and researchers. Inevitably, you'll have technical questions about the application or component you are writing about. For example, in a graphics application, just what are those terms such as antialiasing, hue, saturation, and gamma correction? Surely, someone on your team will be comfortable and good at researching these issures and translating them into language nonspecialists can read.
- Editors and proofreaders. You'll need to find those on your team who have a sharp eye for stylistic, usage, and punctuation problems. You'll need people who can spot inconsistencies. No doubt, you can find at least someone on your team who has some special talents in these areas.
- Style guide owner. To prevent your team from having to do massive editing and reformatting, get someone to "own" the project style guide and facilitate decision making on style issues. Have that individual document these decisions, announce updates and distribute revisions of the style guide.
- Graphics specialists. Find out if someone on the team has experience or talents with graphics—manually drawing them or developing them in graphics applications. Appoint that person to be the developer and maintainer of all "artwork" for the project. Have writers submit artwork requests to that individual.
- Designers. You will also need someone to lead the charge for the overall design of the documentation project—for example, page size, fonts, margins, color, graphic design elements (such as chapter icons, rules, etc.). You'll need this individual not only to create the desitgn and propose it to the rest of the group but also to maintain it as the project continues.
- Template and character- paragraph-tag owner. Someone in your team will need to own and maintain the FrameMaker template for the project as well and the character and paragraph tags. You don't want individual team members making up their tags. Instead, they should request the tag to the tempage/tag owner who coordinates a discussion of that request, updates the template if approved, and makes the new template and tags available to the team.
- Formatting and production specialists. You'll probably need one individual to take charge of formatting your documents and getting them consistent. You may need someone else to get your project printed properly, bound, and delivered.
- Team-page updater. Find someone in your team to post project description, team-member information, audience description, outline, team-design notes, and other such material on your team home page. (It will be help if this individual knows some basic HTML tags.)
- Project coordinator. And, to ensure that all the different pieces of this project go more or less accordinging to plan, you need a project supervisor—someone whom everybody agrees to take direction from. Most likely, this person handles the schedule, date changes, work assignments, special problems, and deals with problems involving team members. Choose this person carefully!
Obviously, you won't need a separate individual to handle each of these tasks. For example, the editor/proofreader cam also maintain the style guide. The graphics specialist perhaps can also handle project design work. And you may need to define roles that aren't mentioned above—for example, your project may need a scheduler (someone to stay on top of due dates) or an information tester (someone to try out the instructions you write).
Post Team Info
To enable your instructor to follow your progess, go to the project startup page and set up your project page.
When you've defined team roles, have your team-page updater post this information your team page for all to see (and on or before the due date).
|