Un projet de développement logiciel ressemble à celui d'un vendeur de hot-dogs.
Plus que vous ne l'imaginez.
Parce que celui qui veut se lancer dans un commerce ambulant de ventes de hot-dogs va rencontrer des difficultés similaires aux nôtres.
Par exemple, dans la préparation de son projet, le vendeur de hot-dogs va (comme nous) lister pleins d'actions à faire :
- trouver un food-truck au look sympa
- faire créer un logo, une marque, qui soient à la mode et faciles à retenir,
- une campagne de publicité pour se faire connaître (flyers, Facebook),
- des équipements de cuisine,
- un système de gestion de caisse, avec un lecteur de carte bancaire,
- un truc différenciant, par exemple des sauces originales qui changent du ketchup traditionnel,
- ...
Manque-t-il quelque chose ?
Oui.
La recette et les ingrédients de base ! C’est l'épicentre du projet. Car les clients viendront d’abord pour la qualité gustative du hot-dog.
C'est ce sujet qui doit mobiliser 80% des ressources de l'entrepreneur, et non pas les sujets annexes.
Pourquoi rechercher l'épicentre ?
L'épicentre d'un projet correspond à sa principale raison d'être. Sa valeur, son utilité première pour ses bénéficiaires.
S'il n'est pas clair dès le début, on risque d'errer.
Dans le domaine du logiciel, j'observe des chemins un peu tortueux qui détournent le projet de son objectif principal.
On discute longtemps de fonctionnalités "sympa à avoir" ou sur la construction d'architectures surdimensionnées.
On produit parfois un volume important de code qui n'est pas nécessaire dans la première version. Parce qu'on redoute que ça devienne infaisable plus tard.
Pourtant, au début d'un projet, chaque heure allouée hors de l'épicentre augmente les risques :
- de dépasser le délai et le budget prévus, et donc de générer de la tension sur le projet : "Ils n'avancent pas assez vite", "ils ont sous-estimé l'ampleur du projet", vs "Ils nous en demandent trop", "ils ne savent pas ce qu'ils veulent".
- de mettre en service un outil comportant des bugs sur les fonctions de base. Car ce sont les tests qui font souvent les frais de ce détournement. Mais quelle sera la première impression des utilisateurs s'il y a un plantage pour s'inscrire ?
En se forçant à renoncer systématiquement à tout ce qui ne constitue pas l'épicentre du projet, on se dégage des marges. Ces marges servent à améliorer l'existant (performances, ergonomie) et à approfondir les tests.
Comment le trouver ?
Il n'est pas toujours facile de trouver assez tôt l'épicentre du projet. Parce que pleins d'aspects, pleins de fonctions semblent essentielles.
Une méthode consiste à enlever une à une les fonctions puis à se poser la question suivante : " Les utilisateurs continuent-ils d'y trouver un intérêt ? "
Reprenons l'exemple du vendeur de hot-dogs :
- Faire l'impasse sur les sauces originales ? Ketchup et moutarde suffisent au départ.
- Enlever le logo ? Oui, ça fonctionne encore.
- Pas de lecteur de CB ? C'est contraignant mais pas indispensable.
- Une campagne publicitaire ? Essayons d'abord de se placer au bon endroit et au bon moment.
- Un food-truck sympa ? Privilégions la location d'un camion récent et facile à utiliser.
- Un pain industriel longue conservation ? STOP ! On a touché l'épicentre. La cuisine sans gant sur un plan de travail mal nettoyé ? STOP, ici aussi. Voilà ce qu'il faut travailler. Voilà ce qui doit monopoliser l'énergie pour améliorer encore davantage le produit.
Avant de réfléchir à ce qu'il faut ajouter, c'est souvent un exercice très profitable de réfléchir à ce qu'on pourrait enlever. Même sur un projet déjà existant, c'est une façon plus explicite de définir les priorités.
Cette démarche "soustractive" ne va pas à l'encontre de l'innovation : au contraire ! La volonté d'en faire moins est un catalyseur pour explorer de nouvelles idées.
Par exemple, cette méthode fonctionne pour améliorer l'ergonomie d'un logiciel. En se forçant à épurer chaque écran, en essayant de lui retirer un à un les composants (boutons, textes, menus, ...), on trouve des solutions qui vont rendre l'interface fluide et intuitive.
Le recherche de l'épicentre d'un projet le rend plus simple à piloter, plus fiable et plus facile d'accès pour les utilisateurs. Et il lui fait bénéficier d'un atout considérable : être impeccable sur sa fonctionnalité principale.
Nb : cette notion d'épicentre est inspirée du livre Getting Real qui propose une méthode de création d'une web application. J'aurais l'occasion de revenir sur d'autres thèmes abordés dans cet ouvrage rédigé par les fondateurs de BaseCamp.
