meetings_how_to
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| meetings_how_to [2020-06-01 15:10] – [Think Problems] tkerby | meetings_how_to [2020-08-10 09:26] (current) – river | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== How to Meeting ====== | ====== How to Meeting ====== | ||
| - | This page is intended to develop a guide for how to have better meetings in the hacklab. | + | This page is intended to develop a guide for how to have better meetings in the hacklab. |
| - | + | ||
| - | === People who would like to have a meeting to discuss the terms of reference for the formation of a committee for the formation of a working group on administrative affairs and the writing of guidance on how to have meetings: === | + | |
| - | + | ||
| - | + | ||
| - | * River | + | |
| ===== Meeting facilitation training ===== | ===== Meeting facilitation training ===== | ||
| - | Would you like to learn how to run better meetings? I have been to a training session on this and found it worthwhile. It was run by someone who understands community organisations and was not unpleasantly corporate. If you would like to attend one please add your name below and if there are enough people I will organise it. | + | Would you like to learn how to run better meetings? I (river) |
| * River | * River | ||
| Line 24: | Line 19: | ||
| * Meetings should have a purpose. | * Meetings should have a purpose. | ||
| * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/ | * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/ | ||
| - | * After the meeting has finished, create | + | * Create |
| * Discuss this action list at the start of the next meeting if there is one. | * Discuss this action list at the start of the next meeting if there is one. | ||
| * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out. | * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out. | ||
| Line 38: | Line 33: | ||
| ===== Avoiding Bikeshedding ===== | ===== Avoiding Bikeshedding ===== | ||
| Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions. | Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions. | ||
| + | |||
| + | See also: [[bikeshed|]] | ||
| === Think Problems === | === Think Problems === | ||
| Line 44: | Line 41: | ||
| * Use techniques such as shadowing, brainstoming | * Use techniques such as shadowing, brainstoming | ||
| * Prioritise solving problems that are urgent, pervasive and valuable | * Prioritise solving problems that are urgent, pervasive and valuable | ||
| + | * Write don and communicate the problems - e.g. user stories, use cases, personas, problem statements | ||
| === Think Requirements === | === Think Requirements === | ||
| * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost) | * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost) | ||
| * Document the problems as requirements that can be validated against when considering solutions | * Document the problems as requirements that can be validated against when considering solutions | ||
| - | Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug) | + | * Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug) |
| * Remember specifications describe solutions and requirements describe problems | * Remember specifications describe solutions and requirements describe problems | ||
meetings_how_to.1591024216.txt.gz · Last modified: 2020-06-01 15:10 by tkerby