L’une des difficultés de fin de projet est d’en préparer la phase de généralisation, qui est le moment redouté pendant lequel les équipes opérationnelles vont utiliser les fonctionnalités livrées pour la réalisation des opérations quotidiennes. Pour que cette phase se déroule dans des conditions optimales, un effort de préparation est à réaliser en amont, et CMG Conseil partage ici ses constats de terrain les plus constructifs.
En effet, et quelle que soit la méthodologie appliquée au projet, il existe une série d’activités structurantes qui permettent la généralisation des fonctionnalités délivrées dans des conditions optimales. Ces activités impactent évidemment la planification des ressources et leur temps opérationnel sur le projet, et pour autant, leur bonne application permet de réaliser des économies notables et de piloter la généralisation avec succès. Mais concrètement, quelles sont ces activités structurantes que l’expérience permet de préconiser ?
Préparer les jeux de données
Il peut paraître étrange de titrer ainsi ce premier paragraphe puisqu’il est le résultat d’une bonne préparation des cas de tests. Il est donc entendu que cette étape préalable est réalisée et permet d’identifier l’ensemble des données qui sont à préparer pour permettre le bon déroulé de l’ensemble des tests jusqu’au pilote fonctionnel, et plus tard du pilote de déploiement. Nos constats de terrain démontrent qu’une préparation aléatoire des jeux de données engendre plusieurs effets pervers, et notamment :
- La réalisation partielle des tests et le report non souhaité de certains tests à des étapes ultérieures du projet,
- Le blocage de l’équipe de recette (dans le cas d’un cycle en V) pour défaut de jeux de données,
- Une difficulté supplémentaire du management de projet à piloter les phases de tests pour défaut d’informations complètes.
Notre préconisation est de conserver à l’esprit que la production des jeux de données peut être une activité consommatrice de temps et que le nouveau cadre réglementaire, telle que la réglementation générale sur la protection des données (RGPD), en complexifie la bonne réalisation. De manière générale, nous avons observé que les meilleures pratiques sont :
- L’identification au plus tôt des jeux de données complexes et des cas de tests afférents,
- L’isolation de ces données afin de les rendre anonymes et aisément exploitables,
- L’identification d’une personne responsable de la livraison de ces jeux de données métier.
Pour partager plus avant notre expérience de terrain, nous avons constaté que l’absence d’un jeu de données peut avoir des incidences néfastes lors de la généralisation, comme par exemple :
- La « découverte » d’anomalies lors de la généralisation,
- La mise en péril de la bonne utilisation de l’outil, produit ou service, voire le rejet de certaines fonctionnalités par les équipes,
- La surcharge des canaux de support pour report desdites anomalies. L’action la plus importante est de désigner une personne responsable de la production des jeux de données en accord avec les cas de tests à réaliser, la communication entre les différents métiers projet étant un élément clé de réussite.
Séparer les anomalies des évolutions
En préambule, rappelons qu’une anomalie est un dysfonctionnement d’une fonctionnalité attendue, là où une évolution est, selon le cas de figure, soit une fonctionnalité imprévue dans le périmètre initial soit une extension d’une fonctionnalité existante. En suivi de l’ensemble des tests qui ont permis de préparer les fonctionnalités, le pilote fonctionnel et celui de déploiement sont d’une importance particulière car ils permettent d’analyser dans différents cadres les anomalies et évolutions qui y sont décelées. À cette étape, il est vivement recommandé de disposer d’une bonne maîtrise de la documentation de cadrage, car l’empressement des équipes à porter les fonctionnalités en généralisation les entraînent souvent à reporter anomalies et évolutions dans le même panier. Les pilotes fonctionnels et pilotes de déploiement doivent être le sas où une ferme séparation des anomalies et des évolutions est réalisée. Pour ce faire, une bonne vision du périmètre fonctionnel et de sa définition est nécessaire, afin de qualifier ce qui est une anomalie d’une évolution.
Cette ferme séparation a plusieurs avantages :
- Le premier est la capacité à estimer le flux des anomalies séparément des évolutions, et par là même de pouvoir séparer les charges respectives. Les évolutions et anomalies pourront être listées, spécifiées, estimées, et suivre une procédure décisionnelle claire.
- Le deuxième, en adhérence au premier, est la capacité d’atteinte des conditions préalables à la généralisation avec une visibilité accrue.
Aussi, les phases de pilote doivent permettent de préparer les pages d’erreurs dont le contenu pourra être utilisé afin d’aiguiller le support sur le bon traitement à apporter à chaque requête. L’expérience montre qu’un utilisateur confronté à une page dont le contenu est explicite a) comprend que le dysfonctionnement n’est pas de son origine, et b) est capable de reporter le contenu affiché afin de permettre l’identification rapide de l’anomalie reportée. Il est donc important de pouvoir grouper les anomalies sous des thématiques explicites pour l’utilisateur final afin d’améliorer son expérience du produit et sa capacité à participer à la correction des dysfonctionnements de celui-ci. En effet, les utilisateurs finaux ayant en toute logique reçu une formation leur permettant une bonne connivence aux outils, l’affichage d’une page d’erreur explicite leur permet de ne pas remettre en question leur savoir-faire et d’être en situation de maîtrise pour participer à l’amélioration des fonctionnalités. Deux actions-clés permettent donc de mieux préparer la généralisation d’un projet. En tout premier lieu, la séparation au plus tôt des flux d’anomalies et d’évolutions, ce qui permet de clarifier le pilotage et les décisions d’étapes, mais aussi être proactif sur les évolutions identifiées. En deuxième lieu, c’est donc la préparation des thématiques d’erreur en collaboration avec les équipes de support qui assure la mise en place de messages spécifiques permettant au support une qualification et un routage précis.
Organiser les canaux de support
Le constat est, qu’au delà de la bonne formation des équipes de support aux fonctionnalités délivrées, il est nécessaire de pouvoir distinguer au plus tôt une anomalie fonctionnelle d’une anomalie technique, afin de ne pas surcharger les équipes avec un flux entrant qui ne nécessite pas leur intervention. Selon notre expérience, la deuxième problématique majeure est de mettre en place les bonnes procédures afin de router les bonnes anomalies vers les bonnes équipes et garantir un traitement efficace du stock. Enfin, il paraît nécessaire de ne pas organiser l’activité du support en silo mais de multiplier les échanges durant toute la phase de généralisation afin de s’assurer que a) les équipes d’assistance disposent d’une bonne connivence au produit et d’une capacité d’accompagnement. Idéalement, les ressources affectées au support ont rencontré les équipes opérationnelles lors d’une ou plusieurs sessions d’accompagnement au changement ou , a minima, de formation. Et b), que le pilotage du projet lors de la phase pilote et de généralisation prenne en considération des métriques quantitatives comme qualitatives.
Impliquer au plus tôt les “clients” finaux
Pour des raisons qui sont toutes valables (pression des délais généralement), il est souvent constaté une remontée difficile des métiers utilisateurs finaux lors de la phase de généralisation. L’approche est extrêmement centrée sur l’outil et on en oublie les hommes. L’impact de ces métriques partiellement restituées est à considérer :
- L’absence de métriques permettant de restituer l’adéquation entre la solution mise en place et les besoins réels des métiers et utilisateurs, clients – volontaires ou non – de l’outil, produit ou service proposé,
- Une difficulté décisionnelle quant à la nécessité de développer les demandes d’évolution et les intégrer à la feuille de route du projet.
D’autres points pourraient bien sûr être soulevés, mais leur impact est moindre. En effet, à l’exception des cycles Agiles qui mesurent la satisfaction des utilisateurs au fur et à mesure des itérations fonctionnelles (et bien que cela ne puisse tout résoudre), les autres méthodologies projets ont tendance à pouvoir uniquement mesurer la satisfaction du métier utilisateur final lors de la généralisation desdites fonctionnalités. Dans la majeure partie des cas, la satisfaction métiers sur les fonctionnalités délivrées est mesurée lors de la généralisation, ce qui reste, sur le fond, problématique. En effet, si nous prenons l’exemple du cycle en V, l’idéal est de modifier l’approche générale afin que l’avis des utilisateurs métier finaux puissent être recueillis juste après les spécifications fonctionnelles par exemple, ce qui permet d’identifier les problèmes fonctionnels majeurs en début de chaîne, et ne pas avoir à modifier la fonctionnalité une fois celle-ci réalisée. L’économie sur le développement, les tests, la recette, est immense. Dans le cas de figure où c’est impossible, il reste nécessaire de poser la problématique suivante : « comment mesurer l’alignement de la fonctionnalité délivrée avec la satisfaction des métiers lors de son utilisation ? », car finalement , c’est bien la délivrance de cette valeur qui justifie l’investissement sur le projet, la mesure des efforts fournis (le consommé) ne pouvant être un indicateur de réussite en soi.
Quatre facteurs clés de succès de la généralisation d’un projet ont donc été abordés :
- Préparer les jeux de données, en relation avec l’exhaustivité des cas de tests identifiés,
- Séparer les anomalies des évolutions, afin de gagner en clarté de suivi,
- Organiser les canaux de support, pour le confort du client utilisateur,
- Impliquer en amont les clients finaux, afin de prévenir des constats en fin de chaîne qui mènent souvent à des correctifs coûteux.
Pour conclure
Cette approche reste certes synthétique, et chaque réponse est à étudier plus finement. CMG Conseil accompagne ses clients et leur apporte cette double expertise métier et projet afin de préparer les meilleurs choix de réussite, qui sont à chaque fois contextuels. En effet chaque besoin s’inscrit dans un cadre et toute réponse normalisée peut avoir une efficacité partielle. L’étude de chaque contexte est ce lien qui rapproche le cabinet CMG Conseil de ses clients année après année, et renforce son savoir-faire, mis à votre disposition.
Arno G.
