Vous êtes PO et on a programmé la mort de votre produit Legacy. Mais les produits cibles ne sont pas encore prêts pour prendre la relève… Vous avez donc encore un peu de temps devant vous. Mais si on veut tuer le monstre, logiquement, il ne faudrait plus le nourrir.
Vous voilà donc dans une position d’équilibriste, à jouer les danseurs de cordes.
Alors que faire en attendant?
Quelle logique d’investissement dans un produit legacy?
Commençons déjà par nous poser la question suivante: doit-on investir sur des systèmes voués à disparaître?
Cela dépend bien évidemment – et comme tout, du contexte.
- Investir 1€ sur un produit qui va mourir, c’est mettre de l’argent sur quelque chose qui générera probablement moins de flux de cash qu’un produit cible, parce qu’ayant moins de temps pour ce faire, il générera probablement moins de flux de valeur.
- d’un autre côté, ces systèmes sont utilisés et assurent le business de tous les jours (on parle d’ailleurs aussi de systèmes Run): investir dessus, c’est ainsi améliorer le rendement de l’existant et donc optimiser ses coûts.
Monstre certes, mais aussi machine à cash. Le business repose dessus. Et système majoritairement utilisé, donc la moindre des améliorations aura une portée, et donc un impact, plus fort.
En fin de compte, pas si simple de trancher, n’est-ce pas?
Alors appelons la sagesse populaire à la rescousse. Un tien vaut mieux que deux tu l’auras. C’est également vrai en Product Management. L’homme n’est pas un être rationnel, il a tendance à surestimer sa capacité à tenir les délais impartis. Le plus probable, c’est que les deadlines qui ont été fixées, théoriquement, quand on a lancé le projet de décommissionnement, glissent. Et plus elles glissent, plus la durée de vie du produit actuel est rallongée et plus sa capacité à produire de la valeur ou à optimiser ses coûts de maintenance s’en trouve agrandie.
Quoiqu’il en soit, investir lourdement sur des systèmes qui sont voués à mourir est:
- difficile à expliquer – or, on a toujours des comptes à rendre, et aussi des soutiens à nourrir; or prendre des décisions controversées c’est diminuer sa capacité à être soutenu.
- et surtout complexe à exécuter: toucher à du Legacy, c’est s’attaquer à quelque chose de central, sans réel environnement de test, avec pleins de règles emmêlées comme un noeud gordien qu’on ne saurait prendre le risque de trancher crânement à la Alexandre, devant la quantité d’argent que cela représente
Il vaut mieux dès lors privilégier des petites évolutions
- peu complexes à réaliser, pour apporter rapidement de la valeur aux utilisateurs (plus on tarde, moins on génèrera de valeur) sans avoir à démêler tout le sac de noeud
- qui n’ajoutent rien à la couverture fonctionnelle du produit Legacy, pour ne pas plus creuser la distance avec les systèmes qui sont le remplacer.
Voici donc quelques conseils pour vous aider à faire vivre dignement votre produit Legacy et maximiser la valeur produite par l’équipe qui est derrière sans pour autant rentrer dans une optique d’investissement lourd.
#1 Ajouter des feedbacks
pour diminuer le support, faciliter la prise en main et documenter les fonctionnalités
Une caractéristique fréquente des systèmes Legacy, c’est la difficulté d’accéder à la connaissance qui entoure leur fonctionnement. Elle est bien souvent éparse et incomplète, si tant est qu’elle existe. Et oui, le système remonte à Mathusalem. Quasiment plus personne dans la boite ne sait comment il marche. Si ce n’est une seule personne, le super dev, aka l’homme qui valait 4 milliards; mais même lui peine parfois à expliquer le pourquoi de tel écran, ou ce qui va se passer si on touche à telle fonctionnalité.
Couplez ce manque de documentation à l’architecture souvent monolithique des systèmes Legacy et vous avez la recette du succès: on se retrouve devant un système qui fait tout, sur lequel on a entassé une quantité étourdissante de règles métiers (qui a parlé du poids des années :), lesquelles ont bien souvent été ajoutées sans vraie vision produit, pour répondre rapidement à une demande qui émanait du métier.
En résultent bon nombre de menus surchargés, d’écrans en double, de fonctionnalités aux règles obscures, parfois d’ailleurs non réellement achevées… Le tout emballé dans des interfaces au look Windows NT. Et avec différentes couches de codes d’interactions. Bref, on n’y comprend plus rien. On ne s’étonnera pas dès lors qu’embarquer des nouvelles personnes (utilisateurs, équipe support ou même développeurs) soit pénible.
Dans ce contexte, une manière astucieuse d’apporter de la valeur est de rajouter des feedbacks. Cela permet de documenter les règles fonctionnelles (pour tout le monde: utilisateurs, support, développeurs, etc) directement sur l’interface. On expliquera par exemple pourquoi un bouton est tantôt cliquable, tantôt non. Ou pourquoi telle manipulation n’a pas marché dans un cas précis. Bref, on donnera un retour aux actions utilisateurs, et ce retour sera très utile pour améliorer la productivité de la fonction support, que ce soit en terme:
- de diminution du nombre de tickets entrants (‘utilisateur qui sait pourquoi telle manipulation n’a pas fonctionné est moins enclin à émettre une demande d’aide)
- ou de temps de traitement des certains type de tickets (l’équipe qui aide l’utilisateur est plus facilement capable d’expliquer à l’utilisateur ce qui n’a pas fonctionné)
Petit conseil: pour vous aider dans l’implémentation de certains feedbacks, il peut être très utile de se créer un environnement normalisé où il est simple d’ajouter des logs, logs qu’on pourra enrichir progressivement. Ces logs vous seront d’ailleurs très utiles pour vos analyses d’occurence de bugs, pour la compréhension des process métiers ou des besoins en formation de vos utilisateurs. Vous avez donc plusieurs moyens d’amortir votre investissement.
#2 Factoriser les interfaces
pour diminuer le support, faciliter la prise en main et préparer le décomissionement
Les systèmes Legacy ne brillent en général ni par leur UI, ni par leur UX. On a non seulement affaire à des dinosaures qui ont été dessinés il y a longtemps, à une époque où la norme était encore RTFM (Read The Fucking Manual). Mais en plus, ces dinosaures, on les a réassemblés façon Frankenstein, en rajoutant, au fil des ans, des nouvelles fonctionnalités sur un tronc non réellement pensé pour (quelques exemples relevés par Jason Friedman de 37Signals/Basecamp).
On se retrouve donc avec un monolithe qui fait tout, des menus surchargés et incohérents, ce qui est doublement ennuyeux:
- passé un certain nombre d’items, c’est-à-dire une certaine charge cognitive, notre manière visuelle de scanner l’information est moins efficace;
- et si en plus la maison est mal rangée, on risque d’avoir du mal à y retrouver ses affaires.
Pour s’approprier le tout ce n’est pas un manuel qu’il faudrait, mais un dictionnaire. Et manque de chance, comme on n’a pas pensé à le documenter au fil de l’eau, ce dictionnaire, il reste encore à l’écrire… C’est ballot comme dirait l’autre, surtout que les utilisateurs ont désormais d’autres attentes, habitués qu’ils sont à des outils plus intuitifs. Et votre organisation, elle aussi, préférerait mettre son argent sur autre chose que la formation aux outils internes.
Mettre à jour l’architecture d’information de vos interfaces est une manière simple et peu couteuse d’apporter de la valeur à plusieurs niveaux:
- en éliminant les redondances et donc la complexité perçue du système pour les nouveaux utilisateurs
- en rangeant les fonctionnalités connexes au même endroit, ce qui simplifie leur « découvrabilité » et leur compréhension (la proximité entre les fonctionnalités aidant à préciser le sens des différentes options)
- en utilisant un même système de formulation (pour les menus, les Call to Actions, les feedbacks) pour améliorer l’appropriations par ls utilisateurs sur une approche UX Writing.
- en réalignant l’outil avec le nouveau découpage produit et les process cibles qui ont été définis, ce qui permet de commencer la transition vers le futur en douceur
Petit conseil: n’oubliez pas de communiquer à vos utilisateurs de manière intensive: l’humain préfère les routines, cela lui confère un sentiment de sécurité et lui évite les efforts inutiles. Il est donc naturellement résistant au changement: il faudra donc l’aider à s’habituer à la nouvelle organisation de l’information.
#3 Modifier le chargement des écrans
pour augmenter la productivité du système, le confort des utilisateurs (et la dignité de votre produit)
20km/h, c’est la vitesse d’un éléphant qui charge. Ce n’est pas tant que ça, si l’on compare à la vitesse maximum d’Usain Bolt (plus du double). Et oui, votre produit Legacy est un mammouth a bien des égards. Il est vieux. Il est poilu. Il est imprévisible. Mais en plus il n’est pas vraiment rapide. A chaque clic, vous avez le temps de vous préparer un café. Et si vous avez le malheur de vous tromper de menu, c’est la double peine. C’est encore plus troublant si l’on pense que ces outils Legacy sont bien souvent des outils internes de productivité.
Cette lenteur, tout le monde a fini par l’accepter. Pourtant, votre bouzin fourre-tout, il concerne actuellement beaucoup d’utilisateurs. C’est le principe du fourre-tout. Et leur faire gagner 30″ par appel, c’est
- s’ils font la même manipulation 25 fois par jour, leur faire gagner 750 secondes/jour, c’est-à-dire 1/8e d’heure
- si cette heure coûte 40€, c’est donc 5€/utilisateur/jour que vous laissez sur la table soit 1090€/an si vos salariés travaillent 218j
- et si vous avez 500 personnes qui utilisent votre système, c’est donc plus de 500K€ que vous laissez sur la table
Tout ça, juste pour une fonctionnalité. Et sans parler du coût induit par les frustrations dûes aux lenteurs d’un tel système, les pertes de concentration que cela engendre, le task switching auquel cela contribue (et son coût), etc etc etc.
Le plus beau dans l’histoire, c’est que rendre votre système plus réactif n’est peut-être pas si coûteux que ça: dans du code Legacy, il y a une probabilité élevée d’appels mal ordonnés, de librairies obsolètes ou de systèmes de cache trop contraignants. Etc. Il y a donc déjà de quoi optimiser, et ce sans rentrer dans des actions plus couteuses. Gros Impact, portée large, faible coût, incertitude maîtrisée suite aux phases d’analyse: RICE vous dirait d’y aller.
Bien évidemment
La valeur est contextuelle. Et ces conseils génériques ne vous permettront peut-être pas de la maximiser: tout dépend en fin de compte de votre situation. En revanche ce sont des initiatives qui produiront de la valeur rapidement, sans nécessiter d’investissements significatifs, en gardant un niveau de risque faible, et sans étendre le périmètre fonctionnel de votre produit. Autant de raisons qui rendront vos décisions simples à défendre 🙂
