Choisir le contenu d'une première version

Tout projet d’application commence avec plus d’idées qu’une première version ne peut en contenir. C’est normal. Les ennuis commencent quand on veut tout mettre dans la première version, que la date de lancement dérive et que l’essentiel reçoit moins d’attention qu’il n’en faudrait. Définir le périmètre consiste à choisir délibérément ce qui sort en premier.

Partez de la tâche essentielle

Notez la seule tâche que l’application doit réussir parfaitement. Parcourez ensuite le chemin le plus court pour l’accomplir : ouvrir l’application, se connecter si nécessaire, faire l’action, vérifier que cela a fonctionné. Chaque écran sur ce parcours fait partie du périmètre. Tout le reste doit être justifié.

Répartissez les idées en trois piles

Prenez chaque idée de fonctionnalité et placez-la dans l’une de ces trois piles :

• Indispensable : la tâche essentielle ne fonctionne pas sans elle.
• Utile : elle améliore nettement la tâche essentielle et reste simple à faire.
• Plus tard : tout le reste, aussi bonne que soit l’idée.

Soyez strict avec la première pile. Une fonctionnalité que « les utilisateurs attendront » n’est pas indispensable, sauf si l’application ne fonctionne pas sans elle. C’est sur la deuxième pile que portent les arbitrages, et ce n’est pas grave si certains éléments sont repoussés.

Comptez le travail invisible

Certains éléments n’apparaissent jamais dans une liste de fonctionnalités, mais doivent tout de même être livrés : connexion et réinitialisation de mot de passe, suppression de compte, politique de confidentialité, états vides ou d’erreur, paramètres, rapports de crash, analytique et fiche sur les stores. Ensemble, ils représentent souvent une part importante d’une première version. Intégrez-les au planning dès le début pour éviter les mauvaises surprises dans les deux dernières semaines.

Commencez manuellement dès que possible

Certaines fonctionnalités peuvent d’abord être gérées manuellement en coulisses. La validation des nouveaux comptes peut commencer par une personne qui vérifie une liste chaque matin. Un rapport hebdomadaire peut commencer par une requête lancée à la main. Automatisez dès que vous savez que la fonctionnalité est utile et comment elle est utilisée. C’est un moyen économique d’apprendre ce dont les gens ont réellement besoin avant de le développer.

Donnez une place au « plus tard »

Les idées en attente doivent être consignées quelque part, sinon elles reviennent en douce. Tenez une liste simple pour la version suivante et revoyez-la après le lancement, en vous appuyant sur les usages réels. Certains points s’avéreront inutiles. D’autres compteront plus que tout ce qui figurait sur la liste initiale, et vous ne l’auriez jamais su sans sortir une première version.

Figez la date, ajustez le périmètre

Une date de lancement fixe avec un périmètre adaptable est plus facile à tenir que l’inverse. Quand le planning dérape, décalez des fonctionnalités vers la version suivante plutôt que de repousser la date. Cela permet de garder une version compacte et de mettre l’application entre les mains d’utilisateurs réels plus tôt, là où les retours utiles commencent.

En résumé

Une tâche essentielle, une liste stricte d’indispensables, le travail invisible pris en compte dès le premier jour et une place pour tout le reste. Une première version qui en fait moins, mais bien, offre une base concrète pour apprendre. Une première version qui veut tout faire ne sort presque jamais.