Mieux vaut fait que parfait

Dernièrement, un ami développeur me fit la confidence qu’il travaillait sur un moteur de jeu responsive. Permettant à la fois, pour un même jeu, de le faire tourner sur un mobile ou sur un écran 4K (ultra HD) Malheureusement il souffre d’une maladie répandue…

Le perfectionnisme

Aussi intéressante et ambitieuse que soit son idée, je doute qu’elle ne soit disponible bientôt à l’utilisation. Et pour cause : ça fait plus d’un an qu’il travaille dessus sans l’avoir montrée à personne. Un projet top secret en somme. « Le temps de la perfectionner, tu comprends » me dit-il. Sauf qu’en tant que designer, je suis déjà passé par là.

Il y a quelques années je bricolais mon portfolio en php, prenant des bouts de code par-ci, des ressources graphiques par là. Le projet évoluait sans cesse au fur et à mesure de mes trouvailles. Ce que je faisais une soirée, je le modifiais le lendemain parce que ça ne me plaisait plus. Le projet avançait, certes, mais la date de mise en ligne s’éloignait de plus en plus…

Ca n’aurait pas été gênant si j’avais déjà un portfolio en ligne que je pouvais montrer en attendant. Mais le temps avançant, je devais bientôt chercher un stage. Et difficile de faire sans portfolio en ligne…

Montrer plutôt que raconter

Plus un projet est important, et plus il risque de ne jamais sortir. Paradoxal, non ? Nous nous mettons trop de pression à vouloir sortir quelque chose d’absolument fini, de parfait. Et en attendant, rien ne sort. Rien n’est montrable.

Me faisant violence, je décidais d’aller au plus rapide : un portfolio en noir et blanc, statique. Il fut prêt en une journée. Il n’était pas parfait, je pense même que je me suis forcé à le mettre en ligne tellement je le trouvais trop simple, trop carré, trop minimaliste.

Et là se produisit quelque chose auquel je n’avais pas pensé : en partageant le lien de ce premier portfolio sur les réseaux sociaux, je récoltais au passage des avis et quelques compliments. Du feedback utilisateur qui m’a permis trois choses primordiales : voir les erreurs que je n’aurais pas pu voir tout seul, aimer cette version quand même et me remotiver pour la suite des évènements.

Reprenons les choses dans l’ordre

On ne peut jamais savoir si un projet va marcher ou non. Alors avant de passer trop de temps (et d’argent) dessus, il est intéressant d’avoir un retour utilisateur tôt dans le processus. Savoir si on va dans la bonne direction. Comme le dit ce bon dicton américain : « Fail Faster, Succeed Sooner » (Echouez vite, réussissez plus tôt). Et si vous échouez dès le début, au moins vous aurez testé. Tirez vite les leçons et passez à autre chose.

Le fonctionnement en versions permet également d’améliorer le produit à chaque sortie. En effet, il suffit de regarder l’App store pour se rendre compte que les développeurs corrigent des bugs et ajoutent des fonctionnalités à chaque version. Commencer petit pour grossir, quoi. A la Facebook. Je doute que le design du premier facebook par Mark zuckerberg fut parfait et aussi complet que maintenant.

J’ai déjà assisté en entreprise à des projets trop gros, trop ambitieux, engloutissant les K€ de la boîte. Et plus le lancement du projet était repoussé, devant la montagne de travail encore à faire et les soucis techniques, plus les décideurs avaient l’espoir qu’il sorte un jour. Ce projet n’a évidemment jamais été finalisé et a fatalement coulé… après 3 ans entre la vie et la mort.

Agissez.

N’ayez pas peur de sortir des prototypes, des tests, des Proofs of concept. Et de demander l’avis des autres. Pour mon ami développeur, je lui ai simplement conseillé de le poster sur github pour trouver des profils prêts à l’aider dans son projet ambitieux…