Créer votre équipe projet agile médicale !
Mettez en place votre équipe de projet agile pour un projet de santé numérique !
Précédemment, je vous faisais part de ma méthode de gestion des projets médicaux de manière agile. Cette fois-ci je souhaite aller un peu plus loin sur le sujet en parlant des rôles et responsabilités pour un projet de santé numérique. Je prendrai cette fois encore l’exemple d’un logiciel mais je montrerai comment transposer les rôles dans d’autres types de projets.
En effet, comme dans tout type de projet, il est vital de définir dès le début les rôles et responsabilités de chacun des acteurs du projet. En tant que coordinateur du projet c’est cet élément qui vous aidera pour avoir de la visibilité sur le projet. Cette visibilité vous permettra de savoir à tout moment la santé du projet et vous aidera à prendre des décisions.
Définir les rôles et responsabilités vous permettra également de faire gagner en autonomie votre équipe car chacun des membres du projet sera investi d’une mission à accomplir tout au long du projet.
Responsabiliser, c’est la clef. Mais comment s’y prendre ?
Dans un premier temps il s’agit de définir les différentes équipes qui interviennent au sein du projet. Dans un projet médical on peut distinguer les équipes de la manière suivante :
- L’équipe Marketing : Chargée de collecter le besoin auprès des clients.
- L’équipe Qualité : Chargée de veiller à ce que le produit respecte les procédures mises en place par l’entreprise.
- L’équipe Réglementaire : Chargée de collecter les exigences permettant la mise sur le marché du produit
- L’équipe Risques : Chargée d’identifier et de quantifier les risques du produit pour le patient
- L’équipe Spécification : Chargée de transformer les besoins en exigences techniques
- L’équipe Développement : Chargée de réaliser le produit
- L’équipe Vérification : Chargée de tester les exigences techniques du produit
- L’équipe Validation : Chargée de tester le produit auprès des utilisateurs finaux et clients.
- L’équipe Support : Chargée de l’installation et de la maintenance du produit
Il s’agit ensuite de définir les différentes responsabilités de chaque équipe. Le plus concret est de définir pour chaque équipe un livrable clef.
J’ai voulu présenter cela sous forme d’un tableau pour plus de simplicité :
| Equipe | Rôle | Livrable clef |
| Marketing | Collecter le besoin auprès des clients. | Scénarii d’utilisation du produit, appelé en agile “User stories” |
| Qualité | Veiller à ce que le produit réponde au procédures mises en place par l’entreprise. | Dossier de conception, appelé DHF pour Design History Files regroupant tous les documents rédigés et approuvés pendant le projet. |
| Réglementaire | Collecter les exigences permettant la mise sur le marché du produit | Document technique : resumé des caractéristiques du produit. Connu sous le nom de “Technical File” |
| Risques | Identifier et quantifier les risques du produits pour le patient | Dossier de management du risque : contient les risques tous évalués avec des mesures permettant d’atténuer l’occurrence et parfois la sévérité du risque. |
| Spécifications | Transformer les besoins en exigences techniques | Document de spécifications du produit, appelé Design Input, il regroupe toutes les exigences du produit définis à partir de tous les besoins des parties prenantes |
| Développement | Réaliser le produit | Le produit, par itérations successives. |
| Vérification | Tester les exigences techniques du produit | Le rapport de vérification contenant la liste des différents tests basés sur les exigences ainsi que leurs résultats |
| Validation | Chargé de l’installation et de la maintenance du produit | Le rapport de validation contenant la liste des différents tests réalisé auprès des utilisateurs finaux et leurs résultats |
| Support | Chargé de l’installation et de la maintenance du produit | Les procédures permettant l’installation et la maintenance du produit |
En définissant les livrables on remarque assez facilement que sur chaque phase de projet il y a une équipe clef qui prend naturellement en main la phase de développement. En reprenant les phases d’un projet médical on peut mettre en face une équipe. Les phases sont détaillées dans mon précédent article :
| Phase | Equipe clef | Livrable clef |
| Collecte du besoin client | Marketing | User Requirement Specifications |
| Ecriture des spécifications | Spécifications | Design Input |
| Développement | Développement | Le produit |
| Vérification | Vérification | Rapport de Vérification |
| Validation | Validation | Rapport de Validation |
| Transfert en production | Support | Procédures d’installation et de maintenance |
| La mise sur le marché | Réglementaire | Document technique |
La qualité intervient dans toutes les phases du projet, en support.
Bien évidemment, ces phases ne sont pas uniques et se répètent avec plus ou moins d’intensité sur chaque “sprint” jusqu’à obtenir le produit final. Vous trouverez plus de détails en lisant mon précédent article.
Et les rôles agiles dans tout ça ?
Les deux profils clefs de la méthode scrum ont chacun leur équipe : Le Product Owner est dans l’équipe “Spécification”, à l’interface de toutes les équipes. Le Scrum Master fait partie de l’équipe “Développement” où il agit comme facilitateur.
Effectivement il s’agit également de mettre les différents profils dans chacune des équipes :
| Equipe | Rôle | Profil |
| Marketing | Collecter le besoin auprès des clients. | Chef de produit : connaît le terrain, les praticiens et leurs besoins. |
| Qualité | Veiller à ce que le produit réponde au procédures mises en place par l’entreprise. | Chargé de projet Qualité Produit : connaît les procédures de l’entreprise et sait les faire respecter. |
| Réglementaire | Collecter les exigences permettant la mise sur le marché du produit | Chargé de projet Réglementaire : connaît le règlement des des dispositifs médicaux et les étapes permettant leur mise sur le marché. |
| Risques | Identifier et quantifier les risques du produits pour le patient | Chargé de projet Risque : expérience du terrain et des risques de manipulation qui peuvent exister. |
| Spécifications | Transformer les besoins en exigences techniques | Product Owner : lien entre les différentes équipes. Profil à la fois technique et connaisseur du terrain. |
| Développement | Réaliser le produit | Scrum Master : coordinateur connaissant la méthode agile et qui veille au respect de l’application de la méthodes.Architectes : connaissent les différents frameworks permettant de choisir ce qui correspond le mieux au besoin.Développeurs : connaissent les langages utilisés et les frameworks. |
| Vérification | Tester les exigences techniques du produit | Ingénieurs et techniciens vérification : savent rédiger des procédures de tests qui permettent de tester les exigences techniques.Testeurs : savent appliquer une procédure de tests et également pousser le produit dans ses retranchements. |
| Validation | Tester le produit auprès des clients. | Ingénieurs et techniciens validation : savent rédiger des procédures de tests qui permettent de collecter le retour des utilisateurs finaux.Testeurs : ayant le profil des utilisateurs finaux. L’idéal étant directement des futurs utilisateurs. |
| Support | Chargé de l’installation et de la maintenance du produit | Application specialist : connaît le client et sait réaliser des formations pour la prise en main du produit.Integration specialist : connait le logiciel et sait le déployer dans différent environnement. |
Définir les rôles, trouver les bons profils, c’est très bien mais la réussite dépend de comment vous allez les animer !
En tant que rugbyman, j’attache beaucoup d’importance à l’esprit d’équipe. Dans une équipe aussi diverse que peut être un groupe projet, il est très important de créer une cohésion d’équipe. Cela passe pour moi par des valeurs qui sont :
- La transparence : L’ensemble de l’équipe connaît la décision et la direction du projet. Les choix sont justifiés.
- La confiance : Chaque équipe est responsable et dispose de sa propre autonomie.
- La co-construction : Toutes les équipes interagissent ensemble afin de trouver des solutions tout au long du projet.
Ces valeurs ne sont bien sûr pas toujours partagées par l’ensemble des gens avec lesquels vous travaillerez. Néanmoins je pense qu’il est très important de les écrire en début de projet et de se les rappeler tout le long. Elles deviennent beaucoup plus évidentes dès lors qu’une cohésion se crée. Pour cela, je recommande fortement la mise en place de rituels qui ne sont pas proprement professionnels comme par exemple :
- Une activité sportive : un tournoi de futsal par exemple
- Des déjeuners d’équipe avec pour seule règle : ne pas discuter du projet
- Des concours : création de memes, photos à thème avec un cadeau à la clef pour le gagnant
Néanmoins attention, ces rituels peuvent passer pour une tentative “d’acheter” les membres d’une équipe. Pour qu’ils ne passent pas comme tel il faut bien veiller à ce qu’ils puissent se faire sur le temps de travail et qu’ils commencent en tout début de projet.
Enfin, de manière plus classique il faut également veiller à ce que l’information circule bien sur l’ensemble des équipes et que chacun puisse remonter ses difficultés.
Pour cela il y a un rituel agile qui fonctionne bien : la mêlée quotidienne. Ses caractéristiques sont les suivantes :
- Réunion debout
- 15 min maximum
- En début de journée
Elle permet à chacun de s’exprimer sur ce qu’il a fait hier et sur ce qu’il prévoit aujourd’hui. Il s’agit également d’une occasion de remonter les difficulté.
L’idéal est que chaque équipe puisse faire sa mêlée quotidienne et qu’une fois par semaine il y ait en plus un “maul”. Je pousse la métaphore rugbystique, malheureusement ce terme ne figure pas dans la méthode Scrum.
Un maul est pour moi une grande réunion debout où chaque équipe désigne un porte parole pour faire le bilan de sa semain et anticipe la semaine à venir.
Et si je ne fais pas un logiciel ?
Identifier les rôles et responsabilités peut se faire dans n’importe quel type de projet. Dans le cas d’un projet médical qui n’est pas un logiciel l’équipe support est bien plus large car elle comporte la production au sens large.
Dans d’autres domaines il y aussi certainement un peu moins de besoins sur les risques, la qualité et le réglementaire. Ces équipes peuvent potentiellement être regroupées en une seule équipe qui serait nommée qualité.
2 Commentaires