Cela fait maintenant plus de 6 ans que je participe à des projets de matériel spatial open source dans un cadre amateur, et l’un des sujets qui me fait le plus cogiter est celui de l’organisation des équipes projets. Je lance ce post pour contribuer à mon propre brainstorming sur le sujet, il n’est donc pas forcément très bien structuré, malgré 2-3 passes de relecture et réorganisation 
Parmi les principales problématiques qui différencient la gestion de projet dans un cadre amateur par rapport au cadre professionnel :
- gestion de la résilience : il faut prendre en compte le fait qu’une certaine part des membres de l’équipe quitteront le projet pour des raisons diverses au cours de la durée de vie du projet.
- tenue des délais : un projet amateur passant généralement à un niveau de priorité secondaire pour les membres de l’équipe, la prise et le respect d’engagements est particulièrement ardue, ce qui rend difficile de tenir des délais
D’un autre côté, en relisant ces points, finalement ce n’est pas si éloigné que ça d’un projet transverse professionnel, dans lequel la plupart des contributeurs ne sont pas dédiés au projet mais y contribuent « on top » de leur responsabilités habituelles.
Quoi qu’il en soit, ces éléments rendent complexe le fait de générer des livrables pour une date donnée. D’un autre côté, ces contraintes imposent finalement le management par objectif : il est essentiel de mettre en avant des objectifs clairs, et d’y rattacher chaque tâche dans la perspective de sa contribution à l’atteinte de cet objectif.
Les deadlines concrètes avec livrables à fournir (campagnes de lancement, tests avec un banc qu’il faut réserver en amont, évènement de présentation…) sont aussi des aides importantes pour concentrer les esprits et les efforts.
Au sein d’Electrolab Ad Astra, l’un des axes clés d’organisation à partir de 2018-2019 est précisément de se fixer des échéances avec des intervalles plus courts que la campagne de lancement annuelle. Nous avons pour le moment pour cela pris des évènements (Maker Faire Paris, FOSDEM) comme points de passage, au-delà des Rencontres des Clubs Espace (RCE) imposés par Planète Sciences dans le cadre des qualifications de fusées expérimentales. Nous regardons aussi les modalités de participation à des lancements de mini-fusées via Rocketry France pour tester des sous-systèmes individuels.
Est-il possible de se passer d’un « chef de projet » ? De mon expérience, le rôle premier et le plus important du chef de projet est d’être accroché à la liste des tâches et à relancer chaque contributeur lorsqu’il apparaît que des tâches sont en retard ou qu’un contributeur ne donne plus signe de vie.
J’ai beaucoup expérimenté avec les listes de tâches partagées, et ça me semble toujours le meilleur moyen de fournir un tableau de bord global et responsabilisant de l’activité en cours sur un projet.
Dans l’équipe Electrolab Ad Astra, les membres commencent à se saisir de l’outil Asana et à y inclure et suivre par eux-mêmes les tâches.
Sur le point de la résilience, une hiréarchie en forme de « responsables de sous-systèmes » n’est pas forcément facile à appliquer dans un cadre amateur. Notamment parce que cela favorise l’opacité en donnant le sujet global à une personne, et crée un risque sur la compatibilité avec les autres sous-systèmes.
Une solution pourrait être de favoriser le fait que chaque membre de l’équipe se sente au moins un peu impliqué dans chaque sous-système ? Pour augmenter le potentiel de résilience en cas de départ d’un membre de l’équipe, et aussi pour favoriser la génération d’idées et solutions originales. Faire que toute l’équipe se sente impliquée quand il y a un blocage sur un point, et pas seulement le « responsable du sous-système. »
En fait enjeu global de faire que chacun se sente responsable de l’avancement de l’ensemble du projet, et pas simplement d’un bout de ce projet. En encourageant chaque membre de l’équipe à s’intéresser à l’ensemble des autres systèmes, on perd certes le gain qui peut être obtenu en se spécialisant, mais on augmente les chances que le projet survive au départ ou à l’absence prolongée d’un spécialiste clé. Et finalement dans le cadre amateur, l’enjeu est de réussir à aller loin, pas forcément d’aller vite.
La vitesse minimum d’avancement étant simplement fixée par le seuil d’avancement en-dessous duquel les membres de l’équipe perdent l’intérêt au projet. Et on revient là à la question des points de passage avec livrables matériels concrets - s’il s’avère qu’il n’y en a pas suffisamment pour maintenir la motivation de l’équipe, il faut probablement réduire le périmètre de chaque point de passage.