Décider de la refonte d’un produit

De nombreux projets informatiques échouent car l’expérience utilisateur n’a pas été pensé dès le début. Convaincre de la nécessité de revoir complètement l’application n’est pas une chose aisée surtout si le développement est déjà bien entamé.

J’explique dans cette article ma démarche pour faciliter cette prise de décision en trois étapes :

• l’expérimentation de nouvelles idées
• le ralliement des parties prenantes
• la justification auprès de la direction

Mon contexte est celui d’un nouveau produit en cours de développement. Votre cas peut être différent avec davantage de contraintes techniques ou de temps.

Faire des prototypes pour penser autrement

Les personnes manquent souvent de recul pour donner un nouveau souffle aux produits dont qu’ils développent. C’est pourquoi, il est important de leur faire découvrir la nouveauté.

La façon la plus simple est de trouver des exemples d’applications innovantes du marché et de les rapprocher de votre contexte. Il faut ensuite s’en inspirer pour construire des propositions sous forme de maquettes et collecter les avis des parties prenantes. Il s’agit enfin de tester la faisabilité des meilleures idées retenues en développant un prototype.

Ce travail doit être limité dans le temps et impliquer quelques personnes motivées. En effet, il est difficile de savoir si l’expérimentation sera un succès et de justifier des efforts qui ne fait pas avancer directement le projet.

Il convient ainsi de faire les choses au plus simple et au plus efficace :

• Établir un scénario d’utilisation avec un choix limité d’interactions
• Inscrire les informations en statique dans le code
• Utiliser des librairies et thèmes existants pour accélérer le développement

Par ailleurs, il serait judicieux d’orienter le travail en cours sur les parties qui ne sont pas impactées par la refonte.

L’approche incrémentale et itérative est la seule qui garantit le succès du produit final

L’expérimentation doit être présentée comme la volonté de résoudre les problèmes actuels dans un cadre plus libre et moins contraignant. Il ne s’agit surtout pas de parler à ce stade de refaire le produit actuel. Cela risque en effet de frustrer ceux qui ne sont pas encore convaincus.

L’intérêt de cette démarche est de donner envie et motiver les parties prenantes et l’Equipe. C’est d’autant plus important pour les personnes qui ont été déçues par le produit actuel ou ont le sentiment d‘un travail qui mène à rien.

Il serait parfois nécessaire de faire plusieurs prototypes avant de trouver la bonne voie et qui remporte suffisamment d’adhésion. La posture de l’expérimentation permet justement de se tromper et de recommencer.

Enfin, il ne faut pas hésiter à faire preuve de patience et continuer à expérimenter tant que le sujet n’est pas mûr. L’exercice de protypage permettra aux participants de voir par eux-même la nécessité d’une refonte et le moyen d’y arriver.

Convaincre sur la nécessité de la démarche

Lorsque vous et une partie des parties prenantes êtes convaincus de la nécessité de revoir l’interface, il vous faudra rallier les autres personnes à votre cause.

Au delà de la qualité des améliorations que vous présenterez, certains interlocuteurs seront récalcitrants pour revenir sur le développement en cours.

La courbe de résistance au changement

Ci-dessous les types de réaction possibles et une façon d‘y répondre :

“ Le développement est trop avancé pour revenir en arrière.”

L’évolution d’un produit se mesure par la création de valeur pour l’utilisateur. Si des fonctionnalités terminées ne sont pas utilisables ou utilisées pour diverses raisons, alors il n’y a pas de régression fonctionnelle si on doit les écarter.

“On va retarder le lancement du produit.”

Sortir une application dont la première impression ne convainc pas, c’est prendre le risque de perdre définitivement des utilisateurs. Il vaut donc mieux avoir un produit de qualité en retard qu’un mauvais produit. Ensuite, on peut toujours chercher à réduire le périmètre fonctionnel de la première version.

“Il faut plutôt se concentrer sur les fonctionnalités.”

Le développement d’une fonctionnalité et de son ergonomie forme un tout. Des manipulations fastidieuses ou non intuitives est un frein à l’utilisation d’une fonctionnalité. De même, une interface simplifiée et optimisée contribue à réduire l’effort de développement pour une valeur métier équivalente voire supérieure.

“L’interface existante n’est pas si mal. Il suffit de faire quelques ajustements mineurs.”

Il faut avoir des avis représentatifs et objectifs sur le produit pour trancher, pourquoi pas en faisant appel à des personnes externes au projet. Ce travail permettra de recueillir et tester des propositions d’amélioration.

C’est l’ensemble de ces éléments qui permettront de décider avec l’Equipe de l’approche de refonte la plus efficace. Faire des améliorations par-ci par là peut s’avérer plus laborieux.

Justifier une décision rationnelle et concertée

Les parties précédentes doivent vous permettre de proposer une alternative crédible et viable soutenue par la majorité des personnes du projet. L’heure est venue de prendre officiellement une décision avec la direction.

Dans un premier temps, il faut présenter un état des lieux factuel :

• Illustrer des parcours utilisateur type avec des mesures quantitatifs : temps d’utilisation, temps d’attente, nombre de clics, taux d’erreur, taux d’abandon…
• Rapporter les retours qualitatifs d’utilisateurs testeurs en soulignant les incohérences et la complexité de l’interface existante

Il faut éviter de mettre en cause des personnes ou de donner un avis trop personnel et subjectif sur le produit.

Préparer la prise de décision finale en réduisant les problèmes en amont

De ces constats, vous présenterez la solution envisagée à savoir :

• Les pistes d’amélioration retenues et priorisées en accord avec les parties prenantes
• La méthode de refonte envisagée par l’Equipe pour reprendre l’existant
• Le périmètre fonctionnel et la feuille de route du nouveau produit
• La stratégie de communication vis-à-vis de l’interne et des clients

Si vous n’êtes pas arrivé à convaincre les décideurs, ne soyez pas découragé pour autant. Vous pourrez toujours intégrer au fil de l’eau certaines des améliorations proposées et pourquoi pas réussir à remplacer l’interface couche par couche plus tard. Enfin il est aussi envisageable de développer un produit complémentaire distinct.

La décision de revoir le développement d’une application est difficile car elle nécessite de prendre du recul collectivement. Le recours à un consultant Product Owner est pertinent pour mener à bien ce travail.