Vous vous lancez dans un projet de grande envergure ?
Que cela touche au digital ou non, il y a sans doute quelque chose que vous devez savoir avant de débuter.
Nous ne le dirons jamais assez, un des pièges de la transformation digitale à éviter, ce sont les projets longs et sans découpage.
De prime abord, cela semble pourtant une bonne solution. L’équipe prend le temps de structurer le projet en définissant les objectifs, les étapes, les fonctionnalités ou éléments à intégrer dans le projet, le planning, les personnes impliquées, l’ensemble des coûts liés, les risques et les plans B, de manière à le cadenasser un maximum.
De la sorte, l’équipe pense pouvoir maitriser ses coûts et surtout ne pas dépasser son budget.
La problématique, c’est que l’on risque de se retrouver en bout de course avec un décalage entre la solution et les besoins réels du marché qui auront évolué au fil du temps.
L’autre chose, c’est aussi la croyance limitante, bien trop ancrée dans les mentalités, que la solution doit être absolument parfaite pour être déployée sur le marché.
On reporte donc sans cesse la date de sortie parce que l’on estime que le produit n’est pas assez complet, pas assez étoffé pour répondre aux attentes des utilisateurs, plutôt que de sortir son produit en communiquant de manière authentique qu’il s’agit d’une première version test.
De nouveau, la problématique, c’est l’évolution des besoins réels des utilisateurs que l’on n'aura pas pris en compte ou encore l’arrivée potentielle d’un compétiteur sur le marché.
On arrive donc trop tard, avec une solution non adaptée et une probabilité de faire un flop total.
Le résultat : une perte d’argent plutôt qu’une maîtrise des coûts 🤷🏼♀️
Une méthode bien connue dans le monde du développement pour pallier ces problématiques est la méthode Agile, qui peut être mise en pratique au travers du framework Scrum par exemple.
La méthode Agile consiste en un découpage du projet en périodes relativement courtes, appelées des sprints. Les sprints durent généralement deux semaines mais peuvent être adaptés en fonction de chaque projet. Le maitre mot, vous le comprendrez, c’est la flexibilité.
Avant de démarrer le projet, un listing de toutes les fonctionnalités du projet, appelées des user stories, est effectué. L’ensemble des user stories constitue le product backlog. On a donc déjà une bonne idée de l’étendue du projet, des fonctionnalités et des coûts, tout en se laissant la porte ouverte à d’éventuels changements et réorientations du projet entre chaque sprint.
Effectivement, avant chaque sprint est organisé le sprint planning, qui permet de définir le sprint backlog en fonction des priorités, c’est-à-dire l’ensemble des user stories que l’on décide d’effectuer pendant le sprint. Les user stories peuvent alors être divisées en tâches, qui sont assignées aux bonnes personnes.
Après chaque sprint a lieu le sprint review, dont l’objectif est de faire le point sur les user stories réalisées, d’organiser leur remise et de les valider après les avoir testées.
A cela viennent s’ajouter des réunions quotidiennes avec l’équipe de production, de manière à favoriser une communication régulière, efficace et optimale.
La méthode favorise également le testing et la prise en compte de feedbacks utilisateurs.
En début de projet, il est possible de définir le contenu d’un MVP : un produit minimum viable, solution disposant d’un minimum de fonctionnalités et pouvant être mise entre les mains des utilisateurs afin de valider ou non des hypothèses et de récolter du feedback.
Une fois le MVP développé et fourni aux utilisateurs, l’idée est donc de le faire évoluer en tenant compte des feedbacks et d’entrer dans un cercle vertueux d’amélioration continue de la solution.
Des outils visuels de gestion de projets peuvent être utilisés, comme par exemple Trello qui s’inspire de la méthode bien connue du Kanban. Cela permet de classer les fonctionnalités dans des colonnes “To do”, “Doing” et “Done”, ou encore d’y ajouter une colonne “Feedback” pour permettre aux testeurs de centraliser leurs inputs.
Les avantages sont les suivants :
Remises régulières
Communication régulière avec l’équipe
Priorisation des fonctionnalités entre chaque sprint
Ajout ou suppression de fonctionnalités du product backlog si nécessaire
Evolution de la solution sur base des besoins réels
Ce qui permet donc :
D’optimiser les projets et leurs chances de réussite
D’impliquer les équipes de production et le client via une participation active
D’être flexible et de réorienter le projet si nécessaire
Et la bonne nouvelle, c’est que la méthode s’intègre parfaitement avec deux autres méthodes prônant la flexibilité et la collaboration des équipes : le Design Thinking et le Lean Management.
Qui sait, cela fera peut-être l’objet d’un prochain article 😏
Vous connaissiez la méthode Agile ? Vous avez eu l’occasion de la mettre en pratique ?
Quels sont les retours de vos équipes et de vos clients ?
Au plaisir d’échanger avec vous.
A très vite,
Hélène