(English version below)
L'approche produit, clé des refontes tech qui s’estiment en milliers de jours hommes
N'êtes-vous jamais tombé sur ce projet dont personne ne veut entreprendre parce qu'il ne semble rien rapporter ? Pourtant, c’est nécessaire : les éléments techniques ne sont plus maintenables.
Ainsi, une logique tristement familière s'impose : une refonte technique à l’identique. Souvent, cela concerne de vieux produits IT qui ont subi de nombreuses évolutions et qui présentent un périmètre fonctionnel complexe.
Vous vous retrouvez alors avec le terreau d’une future catastrophe, qui sera potentiellement moins performante que le produit d’origine…
Je vais partager comment, au travers de cette complexité, nous pouvons déceler les clés du succès et, au fur et à mesure, vous faire part de mon expérience avec la refonte du backoffice de Meetic. Il avait l'âge de Meetic, soit plus de 20 ans d’évolutions, où son usage devenait un art :) (tout comme sa maintenance ^^).
Le travers : L’audit technique
Lorsqu'il s'agit d'un projet né d'une problématique technique, la tendance est de s'engager dans une démarche de refonte avec une perspective purement technique, ce qui est une erreur fondamentale. Le souci initial peut être d'ordre technique, mais la solution ne l'est pas nécessairement.
Prenons quelques exemples : un langage de programmation obsolète, des serveurs dont le logiciel n'est plus à jour, ou encore un code devenu inextricable...
L'organisation en vient alors à penser que puisque tout fonctionnait jusqu'à présent, il suffirait de reconstruire à l'identique. Cette approche simpliste ignore la complexité cachée, comparable à la partie immergée d'un iceberg.
Bien sûr, si la documentation existe encore :)
Alors, on se tourne vers un tech lead ou un architecte pour chiffrer le projet, tombant dans le piège de l'estimation impossible. On calcule au plus large, on double puis on superpose les risques, jusqu'à aboutir à un chiffrage qui ne tient plus la route. Mon expérience montre que le résultat est souvent désastreux.
Enfin, le cahier des charges se résume souvent à l'application telle qu'elle existe déjà. Ainsi, on s'engage à reproduire le même système, suivant une méthode en cascade… Et là, le drame se profile. Enfin, pour ceux qui seront encore là à la conclusion du projet. Car, typiquement, ce type de projet s'étale sur des années.
Les clé du succès : l’approche produit
Ce que les organisations ne saisissent pas toujours, c’est qu’aujourd'hui, notre culture produit nous dote du savoir-faire nécessaire pour accélérer le développement d'applications. Cette culture est fondée sur une approche lean, avec l’utilisateur au cœur du processus. Bien que cela puisse paraître évident, il est crucial de souligner ce point car il représente le changement de paradigme essentiel : l’attention se porte avant tout sur les besoins de l'utilisateur final.
De ce fait, l'équipe en charge de la “refonte” est en mesure d'identifier rapidement les premières étapes adéquates et de vérifier que nous progressons dans la bonne direction.
Lorsque les parties prenantes sont convaincues de la valeur de cette approche, nous pouvons alors nous engager pleinement dans une démarche de développement produit par phases.
Pour mettre en perspective l’approche produit sur ce type de projet, examinons l'excellent travail réalisé par Meetic dans la refonte de son backoffice. C’est une application métier qui a évolué pendant 20 ans, constituant ainsi un cas d’école :) Bien sûr, nous n’aborderons qu’une petite partie du périmètre fonctionnel.
1 - Principe
Il est essentiel de considérer ce projet comme la création d'un nouveau produit. Ce qui existe déjà ne doit être vu que comme une source de données, plutôt que comme un modèle à suivre. Autrement, des ancrages inappropriés émergeront, se révélant contre-productifs et encourageant le copier/coller.
2 - Une vision & des objectifs
Pour commencer, il convient de déterminer la cible de notre produit. Dans notre cas, l'entreprise elle-même peut constituer un axe, mais l'attention principale doit se porter sur l'utilisateur final. Quels sont les besoins spécifiques que notre produit doit satisfaire ? Quelle valeur unique notre produit apportera-t-il à ses utilisateurs ?
En répondant à ces questions, nous pouvons clarifier ce que le futur produit devra offrir à l'entreprise à travers l'expérience de ses utilisateurs. Cela permet d'établir des objectifs clairs, alignés sur les différents besoins identifiés.
Pour un backoffice tel que celui de Meetic, les exigences étaient multiples, principalement orientées autour du service client. Quand un utilisateur rencontre un problème, il contacte le service clientèle via un centre d'appel, où un conseiller s'efforce de résoudre sa difficulté. Dans ce contexte, nous avons identifié trois utilisateurs principaux, chacun avec ses objectifs propres :
Le client, confronté à un problème, cherche une résolution efficace et rapide.
L’agent du service client, qui doit fournir des réponses promptes et adéquates, améliorant ainsi l'expérience utilisateur.
Meetic, l'entreprise, visant à optimiser les coûts et les délais de gestion des requêtes, tout en intégrant les retours utilisateurs pour améliorer le service (par exemple, résoudre un problème de performance de l'application, corriger des bugs, etc.).
Il s’agit d’un premier objectif. Il en existe d'autres autour de la modération, les événements…
3 - Une outcome-based roadmap
Cette phase vise à définir les résultats escomptés et les impacts souhaités sur nos utilisateurs, en expliquant comment leurs besoins seront adressés. Il ne s'agit pas de lister des fonctionnalités, mais plutôt de se concentrer sur le résultat mesurable attendu. Pour rendre ce processus encore plus clair, il est également pertinent d'évoquer des cas d'usage, qui simplifient la compréhension des bénéfices utilisateurs en termes concret et mesurable.
Voici un article qui approfondit les outcome-based roadmap par Marion.
Notre équipe, et en particulier notre Product Manager, disposait d'une donnée clé : le classement des appels au service client. Cette information était idéale pour définir les résultats souhaités de notre premier objectif basé sur des cas d'usage.
4 - Le story mapping et son backlog MVP
Les expériences utilisateur offertes par nos anciennes applications étaient, disons, austères. De ce fait, une expertise approfondie était requise pour les manier, rendant les formations indispensables. Les fonctionnalités, étant organisées par catégories, exigeaient une bonne connaissance de leur fonction, de leur utilité et de leur emplacement pour répondre efficacement aux besoins.
Pour un produit entièrement nouveau, l'objectif est de concevoir des parcours utilisateur à la fois simples et efficaces, qui embrassent pleinement toutes les dimensions de l'expérience utilisateur. Une priorisation judicieuse, une approche lean visant à intégrer le minimum viable au sein même des fonctionnalités, et un story mapping centré sur des cas d'usage critiques, suffisent à établir un premier backlog pour le MVP.
Dans un contexte qui peut être très technique, nous associerons aussi l'event storming, qui aura les vertus de clarifier les interactions complexes entre les différents éléments et processus du système. Cette pratique permet de visualiser les flux d'événements et de déceler les opportunités d'amélioration, facilitant ainsi la compréhension collective et accélérant la prise de décision. Elle engage tous les acteurs du projet dans une démarche collaborative, renforçant l'alignement entre les besoins métiers et les solutions techniques à développer.
Pour l'équipe en charge du nouveau backoffice de Meetic, ce projet a été une source de grande satisfaction. Elle a défini les besoins des utilisateurs et conçu des parcours optimisés, permettant aux agents du sav de travailler avec efficacité -sans se perdre dans des dédales de fonctionnalités inutiles afin de se focaliser pleinement sur l'amélioration de l'expérience client.
Au fur et à mesure que l'application prenait forme, l'équipe pouvait se projeter dans l'avenir, envisageant les différentes prochaines phases du projet. La conviction que la méthode choisie était la bonne s’est renforcée rapidement. Le projet était partagé, discuté et validé.
C’était le feu vert pour avancer avec confiance :)
5 - Du scrum
Il est essentiel de s'assurer que le projet apporte de la valeur et évolue dans la bonne direction. L'implication des utilisateurs est cruciale à ce stade : leur validation, leurs projections et leurs retours sont des indicateurs clés de succès. Découvrir rapidement si l'équipe a omis un aspect important permet d'ajuster et d'améliorer ce qui a été développé sans tarder.
Pour ce faire, le recours au framework SCRUM est souvent privilégié. Sa simplicité, sa capacité à favoriser un engagement continu et son focus sur la création de valeur en font un cadre particulièrement efficace dans le développement de produits.
Bien entendu, l'adaptation de pratiques spécifiques au contexte du projet (comme les modèles de démonstration, les revues techniques ou d'architecture) est nécessaire. Cependant, les principes fondamentaux du cadre organisationnel dédié à la réalisation d'un produit doivent demeurer intacts.
Les premières démonstrations ont été couronnées de succès. L’équipe du service client s'est montrée enthousiaste, et les responsables des agents ont pleinement approuvé tant la forme que le contenu. Pour Meetic, cela a signifié le début de la version bêta et du double RUN. Une fois mise en production, l'application est devenue tangible, dissipant les craintes initiales : la migration du backoffice n’était pas aussi ardue qu’anticipé. Ce qui semblait auparavant colossal et intimidant est devenu réalisable.
Armée d'une aisance et d'une sérénité nouvelles, l'équipe a pu réévaluer ce qui restait à accomplir. Les feedbacks ont été unanimement positifs. Même les bugs occasionnels ont été rapidement minimisés, et les ajustements nécessaires ont été ajoutés au backlog. L'équipe a aussi compris l'importance de savoir dire non, une compétence cruciale pour garder le cap sur les objectifs stratégiques du projet.
Le projet était déjà considéré comme un succès et servait de modèle.
Takeaway
Meetic est passé de 1500 jours homme estimés à 400 en réussissant le produit : plus accessible, plus efficace, simplifie la maintenance…..
L’important c’est l’approche et sa démarche produit : pourquoi -> comment -> quoi.
Le projet de refonte du backoffice Meetic est un excellent exemple de la façon dont une approche centrée sur le produit peut être utilisée pour mener à bien des projets techniques complexes. En se concentrant sur les besoins des utilisateurs et en développant un produit à la fois accessible et efficace, l'équipe a pu obtenir des résultats significatifs.
Mais pour que ce soit possible, il est nécessaire d’avoir :
- Le sponsoring de la direction (Merci à Denis Herail & Jean-Marc Serin pour Meetic).
- Un product manager de qualité ! (l’incroyable Meriem Oheix)
- Une équipe de réalisation incroyable (Florian Durrieu & Nidhal Azizi)
- Une organisation qui joue le jeu (l’équipe du customer care)
The key product approach to tech redesigns estimated in thousands of man-days
Have you ever come across a project that no one wants to undertake because it seems to bring no value? Yet, it is necessary: the technical components are no longer maintainable.
Thus, a sadly familiar logic takes hold: a technical refactoring to the identical. Often, this concerns old IT products that have undergone many evolutions and have a complex functional scope.
You then find yourself with the breeding ground for a future disaster, which will potentially be less performant than the original product...
In this article, I will share how, through this complexity, we can identify the keys to success and, as I go along, share my experience with the refactoring of the Meetic backoffice. It was as old as Meetic, meaning more than 20 years of evolutions, where its use had become an art :) (as was its maintenance ^^).
The pitfall: The technical audit
When it comes to a project born out of a technical problem, the tendency is to engage in a refactoring process with a purely technical perspective, which is a fundamental error. The initial concern may be technical, but the solution is not necessarily so.
Let's take a few examples: an obsolete programming language, servers whose software is no longer up to date, or code that has become inextricable...
The organization then comes to think that since everything worked until now, it would be enough to rebuild identically. This simplistic approach ignores the hidden complexity, comparable to the submerged part of an iceberg.
Of course, if the documentation still exists :)
So, we turn to a tech lead or an architect to estimate the project, falling into the trap of the impossible estimate. We calculate at the widest, we double and then superimpose the risks, until we arrive at a figure that no longer holds up. My experience shows that the result is often disastrous.
Finally, the specifications often boil down to the application as it already exists. Thus, we commit to reproducing the same system, following a waterfall method... And there, the drama looms. Finally, for those who will still be there at the conclusion of the project. Because, typically, this type of project drags on for years.
The keys to success: The product approach
What organizations don't always grasp is that today, our product culture gives us the know-how to accelerate application development. This culture is based on a lean approach, with the user at the heart of the process. Although this may seem obvious, it is crucial to underline this point because it represents the essential paradigm shift: the focus is first and foremost on the needs of the end user.
As a result, the team in charge of the "refactoring" is able to quickly identify the appropriate first steps and verify that we are moving in the right direction.
Once the stakeholders are convinced of the value of this approach, we can then fully engage in a phased product development process.
To put the product approach into perspective for this type of project, let's look at the excellent work done by Meetic in refactoring its backoffice. It is a business application that has evolved over 20 years, making it a textbook case :) Of course, we will only cover a small part of the functional scope.
1 - Principe
It is essential to consider this project as the creation of a new product. What already exists should only be seen as a source of data, rather than a model to follow. Otherwise, inappropriate anchorages will emerge, proving to be counterproductive and encouraging copy/paste.
2 - Une vision & des objectifs
To begin, it is necessary to determine the target of our product. In our case, the company itself can be an axis, but the main focus should be on the end user. What specific needs does our product need to meet? What unique value will our product bring to its users?
By answering these questions, we can clarify what the future product will need to offer the company through the experience of its users. This allows us to set clear objectives, aligned with the different needs identified.
For a backoffice such as Meetic's, the requirements were multiple, mainly focused on customer service. When a user encounters a problem, they contact customer service via a call center, where an advisor strives to resolve their difficulty. In this context, we have identified three main users, each with their own objectives:
* The customer, facing a problem, is looking for an efficient and quick resolution.
* The customer service agent, who must provide prompt and adequate answers, thus improving the user experience.
* Meetic, the company, aiming to optimize the costs and timeframes for handling requests, while integrating user feedback to improve the service (e.g., solving an application performance problem, fixing bugs, etc.).
This is a first objective. There are others around moderation, events...
3 - An outcome-based roadmap
This phase aims to define the expected results and desired impacts on our users, explaining how their needs will be addressed. It is not about listing features, but rather focusing on the expected measurable outcome. To make this process even clearer, it is also relevant to mention use cases, which simplify the understanding of user benefits in concrete and measurable terms.
Here is an article that delves into outcome-based roadmap by Marion.
Our team, and in particular our Product Manager, had a key piece of data: the ranking of customer service calls. This information was ideal for defining the desired outcomes of our first use case-based objective.
4 - The story mapping and its MVP backlog
The user experiences offered by our old applications were, let's say, austere. As a result, in-depth expertise was required to use them, making training essential. The functionalities, being organized by categories, required a good knowledge of their function, their usefulness and their location to respond effectively to the needs.
For a completely new product, the objective is to design user journeys that are both simple and efficient, and that fully embrace all dimensions of the user experience. Judicious prioritization, a lean approach to integrating the minimum viable product within the functionalities themselves, and story mapping focused on critical use cases, are sufficient to establish a first backlog for the MVP.
In a context that can be very technical, we will also associate event storming, which will have the virtue of clarifying the complex interactions between the different elements and processes of the system. This practice allows us to visualize event flows and identify opportunities for improvement, thus facilitating collective understanding and accelerating decision-making. It engages all stakeholders in the project in a collaborative approach, reinforcing the alignment between business needs and the technical solutions to be developed.
For the team in charge of Meetic's new backoffice, this project was a source of great satisfaction. It defined the needs of the users and designed optimized paths, allowing the customer service agents to work efficiently - without getting lost in a maze of unnecessary functionalities in order to focus fully on improving the customer experience.
As the application took shape, the team was able to project itself into the future, considering the different next phases of the project. The conviction that the chosen method was the right one quickly grew stronger. The project was shared, discussed and validated.
This was the green light to move forward with confidence :)
5 - From scrum
It is essential to ensure that the project delivers value and evolves in the right direction. User involvement is crucial at this stage: their validation, projections and feedback are key indicators of success. Discovering quickly if the team has missed an important aspect allows them to adjust and improve what has been developed without delay.
To do this, the SCRUM framework is often used. Its simplicity, its ability to foster continuous engagement and its focus on value creation make it a particularly effective framework for product development.
Of course, adapting specific practices to the context of the project (such as demo models, technical or architectural reviews) is necessary. However, the fundamental principles of the organizational framework dedicated to the realization of a product must remain intact.
The first demonstrations were crowned with success. The customer service team was enthusiastic, and the agent managers fully approved of both the form and the content. For Meetic, this meant the beginning of the beta version and the double RUN. Once put into production, the application became tangible, dispelling the initial fears: the backoffice migration was not as difficult as anticipated. What previously seemed colossal and intimidating became achievable.
Armed with a new ease and serenity, the team was able to reassess what remained to be done. The feedback was unanimously positive. Even the occasional bugs were quickly minimized, and the necessary adjustments were added to the backlog. The team also understood the importance of knowing how to say no, a crucial skill to stay on track with the strategic objectives of the project.
The project was already considered a success and served as a model.
Takeaway
Meetic went from an estimated 1500 man-days to 400 by succeeding in the product: more accessible, more efficient, reduces the learning curve, simplifies maintenance…
The Meetic backoffice refactoring project is a great example of how a product-led approach can be used to successfully deliver complex technical projects. By focusing on the needs of the users and building a product that is both accessible and efficient, the team was able to achieve significant results.
The important thing is the approach and its product approach: why -> how -> what.
But for this to be possible, it is necessary to have:
- The sponsorship of the management (Thanks to Denis Herail & Jean-Marc Serin for Meetic)
- A quality product manager! (the incredible Meriem Oheix)
- An incredible realization team (Florian Durrieu & Nidhal Azizi)
- An organization that plays along (the customer care team)
Here is an article that goes deeper into outcome-based roadmaps by Marion.