Documenter la "méthode Open Space Makers" de gestion de projet

Au fur et à mesure que les projets Fédération se développent, il me semble qu’une « méthode Open Space Makers » de gestion de projets est en train d’émerger. Pas quelque chose de révolutionnaire, ni une grande invention voulue, c’est plutôt une agrégation et une application particulière de plusieurs méthodes existantes.

Une base de Getting Things Done, un peu d’Holacratie, de l’Agile et même un soupçon de Montessori (oui, parce que le faire et le « toucher de composants » sont au coeur de la démarche !).

Ca pourrait donc être pertinent de se lancer dans la documentation de la façon dont les projets sont effectivement gérés, notamment pour aider les nouveaux porteurs et contributeurs potentiels à se rendre compte de ce qui est fait dans les projets existants et ainsi orienter leur approche.

Vu de ma fenêtre, les quelques caractéristiques clés :

  • la désignation d’un objet à fabriquer à relativement court terme (12 à 18 mois) pour focaliser l’énergie et la motivation de l’équipe, tout en prenant en compte que cet objet est une version à petite échelle ou un sous-système d’un système beaucoup plus grand
  • des points d’avancement réguliers (1 à 2 fois par mois) par visioconférence, avec un compte rendu des échanges rédigé en commun et conservé dans NextCloud, et une revue lors de chaque point de la progression des actions décidées lors du point précédent
  • la mise en place d’une liste de tâche partagée, visible et éditable par tous les membres projets, qu’elle soit sous OpenProject ou Gitlab.
  • la documentation des actions prises qui est faite naturellement au travers des outils utilisés pour les échanges : NextCloud, OpenProject, Discourse, Rocket.chat, Gitlab, wiki
  • la définition d’un guide d’intégration pour les nouveaux venus sur un projet, que ce soit une page statique de l’espace projet, un thread Discourse ou un document NextCloud. Cela afin de donner les clés aux nouveaux pour prendre en main leur intégration
  • un système de parrainage des nouveaux membres, par lequel un membre expérimenté du projet devient l’interlocuteur de référence pour le membre et assure le transfert d’information et l’orientation.
  • une capacité à se passer de « chef de projet » nommé, grâce à la méthodologie elle-même qui permet à n’importe quel membre expérimenté d’assurer le lead d’une réunion d’avancement et de vérifier le statut du projet. Cela ne permet néanmoins pas de s’affranchir de « membres actifs » capables d’être des locomotives du projet par le temps et l’énergie qu’ils y consacrent. L’important étant que l’arrêt d’activité de l’un ou plusieurs d’entre eux ne conduise pas à l’arrêt du projet, par manque de vue globale et de repères sur les prochaines actions à mener pour atteindre les objectifs du projet.

Ce n’est pas particulièrement ordonné, et ça mérite d’être complété. Merci par avance pour vos contributions !

4 « J'aime »

Je pense qu’une fois maturé, ça meriterai un beau article de blog et, même, un papier scientifique dans une revue de gestion de projet.

1 « J'aime »

Ca y est, c’est documenté dans le wiki et je viens de publier une news sur le sujet. Pour la papier scientifique, pas sûr que ça le mérite :slight_smile:

1 « J'aime »

il y a toujours besoin de papiers scientifiques :stuck_out_tongue: