Brainstorming for GlassFish v3 User Tasks: What and Who
By pauldavies on Jan 31, 2008
After a short break, GlassFish v3 documentation planning is starting again and is most definitely open to anyone who's interested in shaping, improving, or contributing to the GlassFish documentation. Several documentation meetings have already been held and more are planned, designed to determine the content, organization, and focus of the GlassFish v3 documentation. Community input is critical to this effort and members of the community are strongly encouraged to take advantage of the many opportunities to get involved.
A critical step in GlassFish v3 documentation planning is to identify user tasks. As was discussed at the GlassFish v3 Documentation Meetings of November 5th, 2007 and November 14th, 2007, the documentation team has agreed to write task-based documentation for the GlassFish v3 Application Server.
To write task-based documentation, the documentation team needs to identify the tasks that users will perform when they use the product. As was agreed at the meetings of November 20th, 2007, November 28th, 2007 and December 5th, 2007, the most effective way to identify the tasks is to brainstorm for tasks with subject matter experts (SMEs).
The process of brainstorming for user tasks is similar to the Rapid Task Analysis (RTA) process developed by Conrad Gottfredson (registration with the eLearning Guild required). In principle the process is quite simple: Gather together key SMEs for about an hour or so to brainstorm for user tasks associated with a particular aspect of the product or its use. The devil is in the detail, namely, determining which aspects of the product or its use are suitable as the scope of individual sessions and identifying the key SMEs for each session.
To this end, I have created a schedule of task brainstorming sessions that identifies the scope of each session and the key participants in the session. As I continue my research, expect this table to grow.
What: Identifying the Scope of Individual Sessions
The scope of a task brainstorming session defines one aspect of the product or its use on which a writer and subject matter experts will focus in the session. The scope might be limited to a particular feature of the product, a set of related features of the product, or a particular phase in the use of the product.
To identify the scope of individual task brainstorming sessions, I read source material about the Application Server and noted aspects of the product or its use that could be covered in a single task brainstorming session. Examples of source material that I read are as follows:
- User documentation for earlier releases of the product
- Use case analyses
- Requirements specifications
- Functional specifications
- Test specifications
- Detailed design documents
As I read the source material, I tried to keep in mind the primary goals of the product. Any aspects of the product or its use that I identified had be related to one or more of these goals. I determined the primary goals of the Application Server from What is an Application Server? in the GlassFish User FAQ.
For each task brainstorming session, I wrote a statement of the scope of the session. The statement also identifies the categories of users who will perform the tasks that the session will identify, for example:
To determine the tasks that a system administrator must perform to deploy an application in the Application Server 100–kbyte kernel.
Who: Identifying the Key Participants in a Session
The key participants in a task brainstorming session are as follows:
Subject matter experts. The subject matter experts are members of the product team who have expertise in the aspect of the product or its use that is the scope of the session. The subject matter experts are drawn from several functional areas of the product team, such as:
- Product marketing
The facilitator. The facilitator prepares for and conducts the task brainstorming session. The facilitator is typically the member of the documentation team who will write the documentation that will be based on the tasks that are identified in the session.
The recorder. The recorder keeps a record of all the ideas that are presented in the session. The recorder is typically a member of the documentation team other than the facilitator.
To identify key participants in a task brainstorming, I or the facilitator will consult project-level planning documents and the list of modules and leads to determine who is working on the aspect of the product or its use that is the scope of the session.