Pour ceux qui n'ont pas encore lu le récit de Benjamin, voici le lien vers "Chronique d'un Chef de Projet Digital". 😉
Petite précision avant de commencer : Tierce Maintenance Applicative ou TMA pour des sites Web, qu'est-ce que c'est ? 🤔
Alors, pour une entreprise, cela consiste à externaliser la maintenance informatique de son site web ou de son application.
Tout le long de sa vie, le site web passe par différentes phases et acteurs. La conception mobilise consultants, experts UX et UI, le développement fait appel aux experts techniques et aux développeurs et la gestion globale incombe au chef de projet fonctionnel. Une fois la mise en ligne et la garantie passées, c’est ici que mon rôle de chef de projet TMA rentre en jeu : le projet bascule sur une phase et un contrat de maintenance.
Une passation va se faire avec mon collègue chef de projet fonctionnel et après, je vais commencer à traiter les demandes de correctifs et d’évolutions, formulées par mon client.
Chez Adimeo, nous avons effectivement deux types de contrat : la TMA corrective et la TMA évolutive. Ma première mission est de qualifier pour chaque demande client... Est-ce une anomalie ou une évolution ?
> La TMA corrective couvre uniquement la correction des anomalies.
Mais qu’est qu’une anomalie "fonctionnelle" ? (Anomalie, anomalie, ça se discute…). Une anomalie est à définir en regard d’un état nominal, et ce sont les SFD (Spécifications Fonctionnelles Détaillées) qui gravent dans le marbre cet état nominal, défini lors de la conception.
Par exemple, si un client m’indique " J’ai trouvé un bug sur cette page : le chapô de l’article ne remonte pas ". Je plonge dans les sacro-saintes SFD pour vérifier si OUI, il était prévu qu’un chapô remonte sur cette page. Si NON, aucun chapô ne devait remonter à cet endroit, ce n’est pas une anomalie mais une évolution.
Lorsqu’on parle d’anomalie on vérifie en somme si le comportement d’une fonctionnalité est conforme aux SFD.
> La TMA évolutive couvre les demandes d’évolution qui ne nécessitent pas de phase de conception.
Pour toute demande d’évolution, je me questionne : " La demande est-elle suffisamment précise pour faire intervenir directement un développeur ? Ne va-t-elle pas risquer plusieurs allers-retours avec le client pour préciser le besoin ? ". Sans que cela soit une règle d’or, lorsqu’une demande d'évolution nécessite moins de 2h de développement, elle sera traitée en TMA. Mais comme il existe autant de contrat de TMA que d’agence, il ne s’agit ici que d’un exemple.
Non, la TMA n’est pas en général prévue pour traiter des évolutions de grande ampleur qui nécessitent une phase de conception. En tant que chef de projet, je dois être aussi en mesure, avec mes équipes, d’identifier les évolutions qui doivent passer par une phase de conception et donc sortir du cadre de la TMA.
La facturation de la TMA est soit au temps passé, soit au forfait. Si je traite une demande en TMA alors qu’elle nécessite une phase de conception, je risque de doubler le temps et donc le coût du traitement de la demande, sans parler du côté décevant qui en découle.
A titre d’exemple, modifier une étape dans un formulaire complexe peut sembler rapide mais les dépendances des données entre elles peuvent impacter des problématiques ergonomiques en chaine, et peuvent nécessiter un atelier UX/UI.
Pour la simple raison qu’un site web est un outil qui s’utilise dans différents contextes, par des profils utilisateurs variés, dans des temporalités différentes... Et plus les cas d’usages se multiplient, plus le client identifie les fonctionnalités à optimiser.
Le temps de la TMA s’inscrit dans un temps long où MOA (Maître d'Ouvrage) et prestataire travaillent ensemble à l’amélioration de l’outil.
Pour gérer dans le temps le flux continu de ces demandes, je m’appuie sur un cadre méthodologique souple mais important à poser.
Le quotidien d’une cheffe de projet en TMA reste proche de celui d’une cheffe de projet fonctionnel lors de la conception d’un site.
Il se compose de :
Souvent, le chef de projet ne traite pas un seul projet mais une multitude de projets dont il ne connait pas le métier derrière et les fonctionnalités. Il est important donc de s’appuyer sur différents outils et documenter la connaissance projet.
Pour avoir un suivi des demandes, il est important d’utiliser un outil de ticketing qui me permet de tracer le cycle de traitement de la demande.
Parmi les outils de ticketing les plus connus on peut citer Redmine, Mantis. Adimeo a fait le choix de développer en interne son propre outil de ticketing, Adimeo Project Manager (APM) afin d’adapter au mieux cet outil aux méthodologies et process spécifiques à l’agence.
A titre d’exemple,
Je pourrais échanger avec mon client en utilisant le mail mais je me perdrais rapidement dans le flux des échanges. Il est donc important que les échanges de chaque demande soient centralisés et "historisés" dans un seul outil.
Pour que le traitement de chaque demande soit rapide et efficace, je demande à mes clients de réaliser les actions suivantes :
💡 Petite astuce : Des outils tels que Browerstack permettent de simuler l’affichage sur différents écrans et navigateurs sans avoir les terminaux physiquement.
Les demandes ne sont pas traitées exclusivement via un outil de ticketing. Régulièrement, j’ai besoin d’échanger oralement avec mon client pour m’assurer que l’on s’est bien compris. Nous nous réunissons lors de comités de projet (hebdomadaires ou mensuels) d’une durée de 30 minutes maximum.
Ces comités se veulent pragmatiques et rassemblent les opérationnels du projet (3-4 personnes maximum). Si par exemple, je n'arrive à reproduire une anomalie, je demande à mon client que l’on reproduise, ensemble, le parcours utilisateur débouchant sur l’anomalie.
Le comité de projet permet de fluidifier l’avancement des sujets. Le relationnel et la confiance qui en découlent sont précieux car encore une fois la TMA s’inscrit dans un temps long. C’est peut-être la partie que je préfère personnellement : écouter, comprendre les problématiques métiers et travailler ensemble même si tout ne se passe pas forcément toujours bien... Je dois aussi savoir recevoir le mécontentement du client, tenter de trouver des solutions mais aussi savoir dire non quand cela n’est pas possible. Mais ce travail d’équilibriste est un commun à toute chefferie de projet.
Parler et échanger c’est une chose mais se souvenir s’en est une autre 🙄 ... Pour ma part, j’ai besoin de rédiger à l’issue d'un comité de projet, un Compte-Rendu (CR) afin d’avoir un état des lieux et un plan d’actions pour chaque demande. Personnellement, je rédige mon CR sous un format inspiré du Relevé Information Décision Action (RIDA).
En voici un exemple de Compte Rendu :
|
Sujet |
Informations / Décision / Action |
Dateline |
|
Passage en Drupal 9 |
Action (Adimeo / MOA) : faire une recette sur la plateforme de développement |
Fin mai |
|
Mise en conformité RGPD |
Décision (MOA) : Utiliser l'outil SFBX Action (MOA) : Faire un ticket dans l'outil de ticketing |
À partir de juin |
|
Évolutions |
Infos (MOA) : le budget des évolutions est en cours de validation |
S/O |
Documenter les échanges du COPROJ permet :
L’écoute, l’anticipation, la priorisation, l’organisation sont donc des qualités nécessaires à toutes chefferie de projet qu’elles soient. Concernant la TMA quelques points de vigilances spécifiques sont à noter.
On pourrait résumer la TMA à plusieurs spécificités :
Voici donc les points de vigilances qui découlent.
Non, je ne peux prévoir à l’avance combien d’anomalies ou d’évolution seront demandées. En conséquence, il est parfois difficile de dédier une équipe à temps plein.
Chez Adimeo, nous avons choisi de dédier une journée dans la semaine aux demandes TMA. Ainsi chacun des développeurs travaillent le reste de la semaine sur un projet de conception et gère les demandes TMA en tâche de fond. De fait, il y a toujours en permanence au moins un développeur sur les projets TMA.
Pour que la connaissance du site et du métier soit continue, je m’astreins à mettre à jour les spécifications fonctionnelles détaillées (SFD).
Même si les évolutions sont mineures, si elles ne sont pas documentées, il sera difficile lors d’évolutions plus complexes d’avoir un état des lieux réel de l’existant.
Lorsqu’on corrige un élément il peut y avoir des répercussions sur une autre partie d’un site. Avec le client, je peux définir de tester les parcours critiques du site, en plus de la fonctionnalité déployée. Pour se faire, la rédaction d’un cahier de recette et l’usage d’outils d’automatisation de tests utilisateurs peuvent être sécurisantes.
💡Encore une astuce... Ghost Inspector ou Sélénium par exemple, sont des outils d’automatisation de tests utilisateurs.
Faire de la TMA, oui mais avec parcimonie. Un développeur aime écrire son propre code. Il est parfois difficile pour lui de comprendre et de s'approprier le code d'un autre développeur.
Néanmoins, si le site a été codé en interne chez Adimeo, le suivi se fera de manière plus aisée et efficace, car les méthodes de codage sont connues. Les tickets de TMA peuvent donc être un bon terrain de jeu pour des développeurs junior, encadrés bien sûr par des seniors.
Vous connaissez mal le métier de développeur Web, je vous propose de lire notre article "Chronique d'un développeur : être développeur informatique !"
Il est courant que plusieurs développeurs travaillent sur un même projet. Le client peut valider quelques correctifs mais pas la totalité. Il est donc important d’avoir un solide process de déploiement continu architecturé par un DevOps. Vous ne connaissez le terme DevOps, je vous invite à lire notre article "Dev + Ops = DevOps ! Une (r)évolution en marche...".
Point de vigilances mais aussi perspectives, le temps long de la TMA permet d’avoir le recul nécessaire pour mieux comprendre les besoins utilisateurs et du client, les usages des contributeurs et les perspectives d’évolution.
Lorsqu’un site a passé un an en TMA, nous avons identifié avec le client les grands axes à améliorer. Il est aussi possible de faire des tests utilisateurs, durant cette phase de TMA car le site change peu fonctionnellement. Ces observations en temps réel et inline permet d’avoir un bon terrain de jeux pour penser des optimisations UX/UI.
Comme vu précédemment, reprendre le code de quelqu’un d’autre n’est pas chose aisé. Il est donc utile parfois de re-factoriser une partie du code en raison d’une dette technique trop importante. Cela peut passer par des développements très ciblés soit par un développement sur plusieurs fonctionnalités.
Pour conclure, la chefferie de projet en TMA :
Les missions de TMA sont des investissements sur le long terme. Elles permettent à la MOA mais aussi au prestataire, de mieux se connaître et d’établir une relation de confiance, essentielle à la bonne tenue et à l’évolution de tout projet.
Crédits photos : Ivanko_Brnjakovic - scyther5