La plus grande erreur que j'ai faite en construisant Oblivion
Avec le recul, la plus grande erreur n'était pas technique. Elle concernait la manière dont j'abordais le projet lui-même.
On me demande souvent quelle a été la plus grande erreur pendant la construction d'Oblivion. Certains s'attendent à une réponse liée à un bug, à une stratégie ratée ou à une décision d'architecture.
Étonnamment, aucune de ces réponses ne serait en haut de la liste.
La plus grande erreur a été de croire que construire le produit suffisait.
Construire ressemblait à du progrès
Pendant longtemps, chaque nouvelle fonctionnalité donnait l'impression d'un vrai progrès.
Un meilleur dashboard. Un nouveau mécanisme de gestion du risque. Un monitoring amélioré. Plus d'automatisation.
Chaque amélioration rendait la plateforme objectivement meilleure. Au moins techniquement.
Le problème, c'est que presque personne ne savait que la plateforme existait.
Les produits invisibles ne trouvent pas d'utilisateurs
Un logiciel ne réussit pas simplement parce qu'il est bien conçu. Les gens doivent le découvrir, le comprendre, lui faire confiance et éventuellement décider de l'utiliser.
Avec le recul, j'ai passé des années à améliorer le produit en consacrant très peu de temps à expliquer pourquoi il existait.
Ce déséquilibre est devenu de plus en plus évident une fois qu'Oblivion a atteint la production.
L'ingénierie et la distribution sont des compétences différentes
Écrire du logiciel est une discipline. Aider les gens à comprendre sa valeur en est une autre.
Aucune n'est plus facile. Elles demandent simplement des manières de penser différentes.
Pour quelqu'un qui aime vraiment l'ingénierie, il est tentant de croire qu'un meilleur produit attirera naturellement l'attention.
Parfois, cela arrive. La plupart du temps, non.
La qualité est nécessaire. La visibilité est tout aussi importante.
Partager le parcours
Lancer ce blog faisait partie de la correction de cette erreur. Pas parce que je voulais marketer chaque fonctionnalité. C'était même l'inverse.
Je voulais documenter le parcours derrière la plateforme.
Les décisions. Les compromis. Les leçons d'ingénierie. Les erreurs.
Si quelqu'un décide un jour d'essayer Oblivion, je veux que cette décision repose sur une compréhension de la manière dont la plateforme a été construite, plutôt que sur des promesses irréalistes.
Un état d'esprit différent
Aujourd'hui, je passe plus de temps à réfléchir à la communication qu'au début du projet. Pas parce que l'ingénierie est devenue moins importante, mais parce que les deux aspects méritent désormais le même niveau d'attention.
Un produit fiable que personne ne découvre aide très peu de gens. Un produit populaire qui manque de substance finit par décevoir ses utilisateurs.
L'objectif est de construire les deux.
Avec le recul
Si je pouvais donner un conseil à la version de moi-même qui a commencé ce projet il y a des années, il serait simple : commencer à partager le parcours plus tôt.
Pas quand la plateforme semble terminée. Pas quand chaque fonctionnalité a été implémentée. Beaucoup plus tôt.
Parce que le logiciel grandit par itération.
Et, comme je le découvre lentement, l'audience qui l'entoure aussi.