J’ai croisé à de multiples reprises des projets qui stagnaient, ne parvenant jamais à respecter une date de sortie, sous prétexte de vouloir atteindre la perfection avant de sortir vraiment du bois.

Bien sûr, l’objet de ma réflexion du jour n’est pas de mettre en ligne n’importe quoi, ou de fournir au client des versions complètement buggées de ses outils.

Mais il ne faut jamais oublier une chose : dans le monde virtuel du numérique, rien n’est figé. Si une maison, une voiture est mal conçue, “buggée”, il y a de fortes chances que cela va entraîner de lourds travaux, et parfois remettre en question l’ensemble du projet.

Ce genre de situation est rare dans le domaine du numérique. Essayer, puis revenir en arrière, est le lot de tous les développeurs. Dans certaines méthodologies de conduite de projet, on enseigne même le “courage” de jeter du code, qui a deux vertus :

• déjà, on s’est assuré d’avoir essayé
• jeter puis réécrire, c’est s’appuyer sur son expérience pour refaire proprement, plutôt que de bidouiller un existant
• enfin, on utilise la souplesse du numérique pour se dire que jeter n’est pas très coûteux ; dans des cycles de développement agile, on parle d’une journée au maximum.

Une perfection utopique

Se dire qu’on va atteindre la perfection lorsqu’on aura parfaitement exécuté un cahier des charges, c’est se fermer les yeux sur une composante essentielle : le feedback utilisateur.

Un cahier des charges n’est souvent qu’un ensemble d’hypothèses faites sur la potentielle adaptation d’un outil à un utilisateur. On peut tenter de s’approcher d’une forme de vérité en impliquant un maximum d’utilisateurs dès les phases de conception (c’est même fortement conseillé) ; en revanche, même avec une implication maximale, il y a fort peu de chances que l’on parvienne à l’outil idéal dès sa première version. Parce qu’on n’est jamais exhaustif. Parce que l’utilisateur n’a forcément qu’une image imparfaite de l’outil tant qu’il ne l’a pas entre les mains.

Ce constat pourrait être affolant. Plutôt que d’affoler, il est souvent ignoré, en rejouant pour la n-ième fois la comédie du cahier des charges parfait. Mais il pourrait bien mieux être pris en considération en appliquant le principe du “mieux vaut fait que parfait”.

Rome ne s’est pas faite en un jour

Facebook était loin de ressembler au Facebook actuel lorsqu’il est sorti dans sa première version. Il était très loin d’être parfait, ni même très conforme à l’idée même d’un réseau social puisqu’il n’était qu’une esquisse, codée à la va-vite sur un coin de table, pour noter le physique des filles de l’université où était Mark Zuckerberg.

Windows était loin d’être parfait dans sa version 1.0. Il était même catastrophique.

On pourrait reproduire ces exemples à l’infini. Et surtout les décliner à d’autres univers que celui de la création logicielle. N’importe quel Youtubeur vous dira que leur première vidéo était catastrophique.

Mais il y a un principe important : Ne jamais publier sa première vidéo, ou son premier jet, ou clore un projet dans sa première version sans attendre la perfection, c’est aussi ne jamais se donner la chance de faire un deuxième jet, une deuxième version qui tirera des leçons de la première. Et ainsi de suite.

Lorsque j’ai eu l’occasion de travailler avec des grosses structures, des administrations, je m’attendais souvent avec crainte à des organisations pesantes, à des processus tuant toute motivation et créativité. Mais en fait, très souvent, j’ai eu affaire à des gens très compétents, motivés, mais qui souffraient d’un défaut qui plombait leurs projets sans souvent qu’ils s’en rendent compte : le désir de rendre quelque chose le plus parfait possible.

Le numérique est l’idéal pour expérimenter

Dans un univers qui bouge en permanence, on est très souvent amené à faire du “jetable”, du temporaire. Parce que les délais sont contraints, parce que la ligne directrice est trop floue pour en faire quelque chose de solide. Plutôt que de subir une frustration d’avoir quelque chose de “jetable”, une bonne façon de voir les choses est de se dire qu’il s’agit simplement d’un essai, d’une première version que l’on sortira de la manière la plus souple possible.

Peut-être qu’il n’y aura pas d’autres version, mais peut être aussi que de cette expérimentation naîtra une nouvelle idée, ou une variation du projet qui finalement le fera aller de l’avant. Parce que l’on aura eu un feedback peu coûteux.

Certes, ce principe est plus facile à appliquer lorsqu’on effectue en travail en interne que lorsqu’on passe par un sous-traitant, une entreprise de services qui réalise le travail pour vous, et qui elle n’aura qu’une seule logique : celle de facturer au plus tôt, et donc de clore définitivement un projet au plus vite, quitte à ensuite faire des opérations de maintenance ultérieures qui seront facturées à leur tour. Mais de plus en plus d’entreprises du numérique se font à ces façons de procéder, ne serait ce que, comme on l’a vu plus tôt, c’est le mode de fonctionnement habituel des développeurs.

Devenir accro au feedback

Si je n’avais qu’une seule leçon à donner à mes étudiants en gestion de projet, ça serait de devenir un drogué du feedback. C’est la seule chose qui compte, et tous les projets devraient être conçus ainsi : comme des outils à délivrer du retour utilisateur.

Lorsque l’on met les utilisateurs dans la confidence de cette phase “expérimentale”, on s’aperçoit souvent qu’ils ne prennent pas mal du tout l’information, voire qu’ils peuvent se sentir presque flattés d’être impliqué ainsi dans votre projet.

Pour les personnes impliquées, délivrer à un rythme très fréquent sans chercher la perfection, c’est se donner la possibilité de “jeter” certains travaux sans vivre le traumatisme de mettre à la poubelle d’un coup des années de travail. Et ils vous seront redevables d’avoir pris la peine de recueillir du feedback le plus tôt possible.

Et pour le décideur, c’est l’outil parfait pour sortir de la “pensée magique” d’une vision hors sol qui devient une réalité à succès. On trouvera toujours des exemples où un entrepreneur a trouvé la formule miracle dans son coin, mais la plupart du temps, une vision ne se retrouvera que plus solide si elle est nourrie par un feedback conséquent.

Ce cher Steve Jobs, exemple type du dirigeant intuitif, disait souvent qu’il ne voulait pas s’appuyer sur l’avis de ses utilisateurs, en citant Henry Ford : “Si j’avais demandé à mes clients ce qu’ils souhaitaient, ils m’auraient parlé d’un cheval plus rapide”. Mais il ne faut pas oublier que, si Apple est effectivement parti d’une intuition, ou plutôt d’un pari (celui de l’explosion du marché de l’ordinateur individuel), le vrai succès de la firme s’est fait via de nombreuses sorties, plutôt fréquentes, qui ont permis d’affiner la stratégie de la marque pour aller vers quelque chose de vraiment conforme aux besoins réels de l’utilisateurs. Et, à moins d’avoir les moyens d’Apple, le meilleur moyen pour vous d’y parvenir est encore d’adopter la devise : Better done than perfect !