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:08] – 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 39: | Line 34: | ||
| 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. | ||
| - | Think Problems | + | See also: [[bikeshed|]] |
| + | |||
| + | === Think Problems | ||
| * Understand the problems in detail before considering solutions | * Understand the problems in detail before considering solutions | ||
| * Listen to all stakeholders, | * Listen to all stakeholders, | ||
| * 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 | ||
| - | Think Emergence | + | === Think Emergence |
| * Understand how your solution works in the end application - how does it interface, what is its boundary? | * Understand how your solution works in the end application - how does it interface, what is its boundary? | ||
| * Consider the environment in which it is operating and how it may interact - what negative or positive behaviours or consequences may emerge? | * Consider the environment in which it is operating and how it may interact - what negative or positive behaviours or consequences may emerge? | ||
| * Identify how it may go wrong and mitigate those effects | * Identify how it may go wrong and mitigate those effects | ||
| - | Think Analysis | + | === Think Analysis |
| * Consider multiple possible solutions and analyse trade-offs against the requirements you have gathered | * Consider multiple possible solutions and analyse trade-offs against the requirements you have gathered | ||
| * Iterate - start with simple quick proof of concepts and use them to learn | * Iterate - start with simple quick proof of concepts and use them to learn | ||
| - | Think Validation | + | === Think Validation |
| * Validate early to identify changes and errors as soon as possible | * Validate early to identify changes and errors as soon as possible | ||
| * Constantly communicate with stakeholders in case their needs change | * Constantly communicate with stakeholders in case their needs change | ||
meetings_how_to.1591024109.txt.gz · Last modified: 2020-06-01 15:08 by tkerby