Comment mieux reconnaitre les compétences chez les Brickodeurs

Kit pédagogique de démarrage du hackathon Appliqué aux Brickodeurs pour identifier les compétences des Brickodeurs et les inciter à partager leur compétence.

Mise en œuvre du kit de démarrage à partir d’un exemple • Afin d’illustrer comment utiliser le kit de démarrage d’un hackathon, nous allons l’illustrer à partir d’un exemple concret.

• Il s’agit d’un kit de démarrage, c’est-à-dire qu’il sert à amorcer la démarche pour identifier la problématique et ses acteurs pour commencer à imaginer des pistes de solutions.

• La partie « Réalisation » consiste à définir le plus clairement possible la solution envisagé sans rentrer dans les aspects (trop) techniques.

Brief de design thinking

1 – Identifier

• Pourquoi ? Problème :

• Les animateurs du club ne savent pas qui fait quoi au sein des projets du club, ni qui sait quoi, ni comment contacter un tel ou un tel. Ils doivent passer par Christophe ou attendre la prochaine réunion pour avoir leur réponse.

• Nous ne pouvons pas mettre en valeur ce qu’apprennent et ce que font les Brickodeurs auprès de leurs parents et du public.

• Qui ? Les acteurs du problème :

• Les animateurs, les membres adhérents, les parents.

• Quoi ? Le But

• Disposer d’un moyen de savoir qui fait quoi au sein de Brickodeurs : quel projet en cours, quelle équipe, quelle compétence disponible ?

• Possibilité de l’intégrer dans l’existant (site brickodeurs.fr )

Brief de design thinking

1 – Identifier

• Avec Quoi : Existant

• Le fichier des adhérents HelloAsso, • Le site brickodeurs.fr • Une appli web sur notre vps.

• Qui d’autres : Concurrences, autre solution ?

• Les autres associations locales ne semblent pas concerné par ce problème.

• CoderDojo ne propose pas, via son site, une telle approche.

• Nous ne pouvons pas nous permettre d’acquérir une solution professionnelle.

• Combien ? Budget, restriction.

• Nous souhaitons que l’application soit développé avec nos propres ressources en interne avec une équipe de 5 personnes.

Brief de design thinking

1 – Identifier

• Quand ? Calendrier, Scénario d’utilisation.

• L’application sera utilisé majoritairement tous les samedis par les animateurs. Elle sera accessible 24/7.

• Les animateurs alimentent les profils, les projets, les compétences (?)

• Les membres mettent à jour leurs compétences, • Ces compétences pourraient être « prouvées » par la rédaction d’un wiki.

• Ces compétences pourraient être « récompensées » par des badges de compétences.

• Comment pouvons nous [Identifier] et [valoriser][les compétences], [les projets], [les équipes] pour chaque Brickodeurs pour permettre aux [animateurs] et aux [parents] de voir leur progression.

1 – Identifier

les interactions

• À l’aide des cartes et des jetons du kit Hackathon, essayons de voir et de comprendre comment tout cela interagit.

Identifier la constellation d’acteurs 1 – Identifier Parents

Association

Informations

Budget

Adhésion

€

Cotisation

Droits

Administration Temps

Compétences

Identifier les flux entre acteurs

Utilisation

Membres Ressources Animateurs

2- Imaginer : Acteurs + Flux = Ressources ?

Acteur

Flux

• Nous allons imaginer pour chaque acteur associé à un flux de quelles ressources il a besoin. Cela nous permettra d’en déduire des fonctionnalités.

• Les Parents : • + cotisations : flux financier alimente le budget de l’association • + adhésion : • + informations : ils sont informé des activités à venir du club par une newsletter.

€

Droits

• Administration de l’association

• + Budget : gestion des ressources financières, • + Compétences : gestion des ressources humaines, • + Temps : gestion du Planning et horaire.

€

2- Imaginer • Les animateurs :

: Acteurs + Flux = Ressources ?

Acteur

Flux

• + temps : disponibilité du bénévole  planning • + Compétences : qu’il va transmettre aux membres via des « médias » ou en séance, • + avec l’utilisation : des ressources du club (local, machines, site web... )

• Le membre / Brickodeur

• + Informations : il est informé des activités à venir du club par une newsletter.

• + Expérience : au sein du club, il apprend via les « expériences » qu’il fait en étant aidé par les animateurs et les autres membres  acquisition de compétences.

• + Projet : Les « expériences » se vivent au sein de projet : Construction de robot, création de programmes…  acquisition de compétences.

• + utilisation des ressources du club (local, machines, site web... )  acquisition de compétences.

2- Imaginer les fonctionnalités pour …

• Pour notre premier groupe d’acteurs :

• Les parents et l’administration de l’association : • Adhésions, Flux financier et budget

• Déjà géré par HelloAsso • Ne rentre pas dans notre problématique initiale

• Les informations sont déjà géré par le site web : articles et newsletter.

• La gestion du planning • Ne rentre pas dans notre problématique initiale

€ Droits

2- Imaginer les fonctionnalités pour …

• Rappel de la problématique :

• Comment pouvons nous [Identifier] et [valoriser][les compétences], [les projets], [les équipes] pour chaque Brickodeurs pour permettre aux [animateurs] et aux [parents] de voir leur progression.

• Pour notre deuxième groupe d’acteurs : • Les animateurs :

• Compétences qu’il va transmettre aux membres via des « médias » ou en séance, avec l’utilisation : des ressources du club (local, machines, site web... )

• Les Brickodeurs :

•  acquisition de compétences. Via expérience, projets et ressources du club.

2- Imaginer les fonctionnalités pour …

• La transmission et l’acquisition de compétences Via expérience, projets et ressources du club.

•  Identifier une compétence ?

• C’est Quoi ? Aptitudes et personnalité + Expérience → Compétences → Missions • Qui ? Détenu par un membre • Pourquoi : pour mettre en valeur ce qu’ils savent et partagent.

Donner envie aux autres de faire la même chose.

• Quand ? lorsqu’il l’a déclare, ou lorsqu’elle est identifiée par un animateur. Lorsqu’il participe à un projet. Lorsqu’il rédige un wiki dans une catégorie de compétences.

• Comment ? Avec un badge ?

• Où ? Sur le site des brickodeurs ?

2- Imaginer un modèle de données • Faire « rentrer » l’acteur dans la fonctionnalité.

• Acteur  rôle • Ressources : site brickodeurs.fr • Permet de rédiger des articles

• Description :

• Un [membre] rédige un [article] qui identifie une [compétence] • Un [Badge] appartenant un domaine de [compétence] récompense un [article] • Un [badge] est remis dans le [Passeport] possédé par le [Membre]

– Réali un cahier des charges 3 – 3Réaliser • Le modèle de données sera réalisé à partir de celui de Wordpress,

Modèle

• Il faut ajouter les « types de post personnalisé » (TPP): • Compétences, • Badges.

• Il faut créer les pages suivantes pour visualiser les nouveaux TPP:

Les vues

• Compétences : afficher leur description, qui les détient.

• Badges : conditions pour les obtenir, qui les détient.

• Il faut créer les contrôles suivants :

• Quand un membre rédige un (ou plusieurs) article(s) wiki dans une catégorie de compétence.

Les • La qualité de l’article doit être validé par au moins 3 autres membres en « likant » l’article. contrôleurs • Si le membre a déjà rédigé plusieurs articles wiki et a déjà obtenu un (ou plusieurs) badges de compétences alors il obtient un badge de niveau supérieur : • Novice  débutant  confirmé  expert  Ninja

4 –4-Partager partager la solution • Reste à faire : • Prévoir un plan de communication pour inciter les membres à rédiger des articles pour obtenir des badges.

• A suivre…