Chronique d'une cheffe de projet en TMA

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.

Quand un projet passe t’il en maintenance ou en TMA ?

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.

La demande est-elle une corrective, évolutive ?

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.

La TMA traite t-elle les évolutions structurantes ?

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.

Comment est facturée 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.

Pourquoi un site une fois en ligne, aurait-il besoin de nouvelles interventions ?

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.

Mon quotidien : priorisation, recette et relation client sur un temps long

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 :

• 20% de réunions ;
• 35% de recette fonctionnelle ;
• 35% de briefing des équipes ;
• 10% de planification des équipes.

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.

Outil de ticketing : qualifier et prioriser les demandes

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,

1. Un client créé un ticket sur la nécessité de mettre son site en conformité avec les exigences "RGPD de la CNIL" ;
2. Je liste dans le ticket les actions à entreprendre et les impacts fonctionnels ;
3. La cliente me donne son accord ;
4. Je planifie les développements avec mes collègues développeurs ;
5. Une fois les développements réalisés, j’effectue la recette des fonctionnalités développés (Mon conseil de lecture Recette d'un projet Web : Comment la réussir ?) ;
6. Si tout est valide de mon côté, je commente et renvoie le ticket à mon client pour qu’il fasse sa propre recette ;
7. Si le développement est validé côté client, le déploiement se fait sur les différents environnements et les allers-retours dans le ticket se poursuivent jusqu’à la MEP (Mise En Production) finale ;
8. Une fois le développement validé en production, le ticket est fermé par mon client.

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.

Comment créer un ticket de TMA ?

Pour que le traitement de chaque demande soit rapide et efficace, je demande à mes clients de réaliser les actions suivantes :

1. Créer un ticket par demande.
   Par exemple, si la demande concerne la remonté sur un site des posts facebook et twitter ; J’ai besoin d’avoir deux tickets car les développements, les tests sont différents pour les deux réseaux sociaux.
2. Qualifier la criticité des demandes : Bloquante, Majeure ou Mineure ;
   Cette criticité va me permettre de prioriser et de paralléliser le travail de l’équipe mais aussi de savoir si l’anomalie doit être traitée dans l’urgence. Certains contrats de maintenance définissent des GTI (Garanties de Temps d’Intervention) qui définissent en combien de temps doit être traité un ticket suivant sa criticité.
3. Après, le contenu des tickets diffère selon le type de la demande :
• Pour les demandes d’anomalies :
  • Mentionner la version du navigateur et celle de l’OS utilisées. Oui, cette information est précieuse pour les anomalies concernant le front-end car d'un navigateur à un autre l'affichage peut varier par exemple.
    Vérifier que le comportement attendu est bien conforme aux SFD initiales ;
  • Faire des captures d’écran et indiquer les urls des pages concernées ;
  • Indiquer éventuellement quel est le profil utilisateur qui rencontre l’anomalie.
• Pour les demandes d’évolution :
  • Détailler précisément le besoin dans le ticket ;
  • Faire un bon de commande associée à la demande, si besoin.

💡 Petite astuce : Des outils tels que Browerstack permettent de simuler l’affichage sur différents écrans et navigateurs sans avoir les terminaux physiquement.

Comité de projet : se parler et travailler ensemble au quotidien

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.

Compte-rendu : définir un plan d’actions

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 :

Documenter les échanges du COPROJ permet :

• D’éviter la déperdition d’information ;
• De savoir qui doit faire quoi et pour quand via un plan d’actions ;
• D’avoir un historique des décisions prises ;
• D’avoir une photographie à l’instant T du site ;
• Permet de faciliter la transmission d’information à un nouvel acteur projet.

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.

TMA : tracas et opportunités

Quels sont les points de vigilances ?

On pourrait résumer la TMA à plusieurs spécificités :

• La TMA s’inscrit dans un temps long ;
• La TMA couvre un flux continu de demandes, évolutions et correctifs confondus ;
• La TMA couvre un large portefeuille de projets ;
• La TMA hérite de sites parfois sans documentation ou connaissance métier.

Voici donc les points de vigilances qui découlent.

> Temps long : est-ce que je peux quantifier le nombre de demande à traiter dans les moins à venir ?

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.

> J’hérite d’un site et de sa documentation fonctionnelle (parfois partielle)

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.

> Je dois être vigilante aux effets de bord par une recette cadrée

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.

> Les développeurs et la TMA … une relation complexe

Travailler sur de la TMA pour un développeur n’est pas toujours aisé :

• Il faut travailler sur un code que l’on n’a pas créé ;
• Il faut rapidement comprendre la logique métier ;
• On hérite parfois d’une dette technique importante ;
• Les effets de bord et régressions sont à surveiller.

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 !"

> Flux continu de déploiements selon les validations client

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.

Quelles sont les perspectives ?

> Une refonte totale et partielle en s’appuyant sur des tests utilisateurs en ligne

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.

> Une optimisation du code pour améliorer les performances du site

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 :

• Demande une bonne organisation pour gérer et prioriser parallèlement de multiples demandes pour divers projets ;
• Exige une bonne connaissance métier des sites ;
• Appelle à une documentation concise mais nécessaire pour la transmission d’information entre les acteurs ;
• Permet d’éprouver le site sur plusieurs mois et d’optimiser avec le client le site.

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