Au début, tout semble indispensable
Pendant les premiers échanges avec les équipes, les besoins apparaissent naturellement les uns après les autres.
Il faut pouvoir rechercher par tel critère, exporter certaines données, ajouter un tableau de bord, gérer un cas particulier, envoyer une notification ou encore automatiser une étape du processus.
Chaque demande a généralement une bonne raison d'exister. Le problème n'est donc pas de déterminer si une fonctionnalité est utile.
La vraie question est plutôt : est-elle nécessaire dès la première version ?
Car plus le périmètre initial augmente, plus le moment où les utilisateurs pourront réellement travailler avec l'application s'éloigne.
Revenir à l'objectif de l'application
Pour prioriser, j'aime revenir à des questions très simples.
- Qui utilise cette fonctionnalité ?
- Dans quelle situation ?
- Quel problème permet-elle de résoudre ?
- Que se passe-t-il si elle n'existe pas dans la première version ?
- Existe-t-il temporairement une autre manière de réaliser cette action ?
Ces questions permettent souvent de distinguer plusieurs niveaux de besoin.
Certaines fonctionnalités sont indispensables pour que le processus métier puisse fonctionner. D'autres apportent surtout du confort. Certaines concernent uniquement des cas rares qui peuvent encore être traités autrement pendant quelque temps.
L'objectif n'est pas de supprimer des fonctionnalités pour réduire artificiellement le projet.
Il est de comprendre où il est pertinent d'investir du temps en premier.
Construire un premier parcours complet
Une première version ne devrait pas être une collection de fonctionnalités partiellement terminées.
Je préfère chercher à construire un parcours métier cohérent de bout en bout.
Prenons par exemple une application permettant de gérer des demandes clients. La première version pourrait permettre de créer une demande, de l'attribuer, de la traiter et de la clôturer.
Il manque peut-être encore des statistiques avancées, certaines automatisations ou la gestion de cas très spécifiques.
Mais le cœur du travail peut déjà être réalisé dans l'application.
C'est beaucoup plus intéressant qu'une application contenant dix modules, dont aucun ne permet encore de réaliser complètement une tâche.
Mettre rapidement l'application entre les mains des utilisateurs
Les ateliers, les échanges et les maquettes permettent d'anticiper beaucoup de choses.
Mais tant qu'une application n'est pas réellement utilisée, une partie des besoins reste basée sur des hypothèses.
Dès que les utilisateurs commencent à travailler avec une première version, les retours deviennent beaucoup plus concrets.
Une fonctionnalité considérée comme secondaire peut soudain devenir prioritaire. Une autre, jugée indispensable quelques semaines auparavant, peut finalement ne manquer à personne.
Mettre une première version utile entre les mains des équipes permet donc aussi de prendre de meilleures décisions pour la suite du projet.
Une V1 n'est pas une application au rabais
Limiter le périmètre ne signifie pas limiter la qualité.
Une première version doit rester fiable, compréhensible et suffisamment aboutie pour être utilisée dans de bonnes conditions.
Ce que l'on réduit, ce n'est pas la qualité du développement. C'est le nombre de problèmes que l'on cherche à résoudre en même temps.
Cette approche permet de livrer plus rapidement une solution utile, d'obtenir de vrais retours et de faire évoluer ensuite l'application sur la base des usages réels.
Prioriser fait partie du projet
Définir une première version oblige forcément à faire des choix.
Ces choix sont parfois difficiles, notamment lorsque plusieurs équipes sont impliquées et que chacune défend naturellement ses propres besoins.
C'est aussi une partie importante de mon accompagnement : comprendre les usages, challenger les demandes et aider à construire un périmètre cohérent.
Définir une V1, ce n'est pas décider de ce qu'on ne développera pas. C'est décider de ce qu'il est pertinent de développer en premier.