Pourquoi le projet le plus petit mérite qu’on en parle
Les histoires de produits publiées gardent en général les gros chiffres et perdent tout ce qui les a précédés. CUTE mérite qu’on en parle précisément parce qu’il est venu plus tôt, qu’il était plus petit et qu’il a été construit par deux personnes. Il montre les conditions dans lesquelles l’expérience suivante a été acquise.
La fiche qui subsiste l’identifie comme un jeu Casual, Trivia et Word publié en décembre 2018. Un outil archivé l’a plus tard estimé à environ 250 000 joueurs par mois, mais c’est une estimation tierce et non un chiffre venant de nos propres statistiques.
Le jeu lui-même est hors ligne et seules quelques captures d’écran subsistent. Ceci parle donc du produit et de notre façon de travailler, plutôt que d’une visite guidée reconstituée à partir d’archives incomplètes.
À deux, le périmètre est la stratégie
Une petite équipe n’est pas simplement une version plus lente d’une grande. Elle porte un autre type de risque. Les deux mêmes personnes qui construisent une fonctionnalité la testent aussi, la déploient, lisent les statistiques, répondent aux e-mails quand elle casse et décident de la suite.
Ce qu’une fonctionnalité coûte à entretenir compte donc davantage que ce qu’elle coûte à construire. Quelque chose que vous ajoutez en une journée mais qui génère un flux permanent de contenu, de modération ou de support est généralement un mauvais calcul. La version qui survit est celle dont la surface complète tient dans l’équipe que vous avez vraiment.
Facebook Instant Games nous a donné un levier que nous n’aurions pas pu construire : ça tournait dans le navigateur, ça gérait l’identité, ça vivait dans les conversations et ça ne demandait aucune installation. Le bon réflexe était de s’appuyer là-dessus et de garder le jeu assez petit pour que l’un ou l’autre puisse le modifier sans hésiter.
Gardez les décisions dans la même pièce
À deux, les besoins n’ont pas la place de voyager à travers des documents et des réunions, ce qui est un avantage tant que la boucle reste honnête : remarquer quelque chose, se mettre d’accord sur le plus petit changement utile, le publier, regarder ce qui s’est passé.
Le piège est de remplacer le processus par la mémoire. Même à deux, il faut s’accorder sur le chiffre important, noter ce qui change dans une version, pouvoir déployer deux fois de la même façon et tenir une liste courte de ses paris du moment. Ce minimum de structure vous rend plus rapide, parce qu’il vous évite de redécouvrir la même décision.
L’outillage qui aide est ennuyeux. Des builds automatiques, une check-list avant la mise en ligne, une remontée d’erreurs et quelques événements auxquels vous faites confiance feront plus qu’une plateforme interne qui devient une chose de plus à maintenir.
Concevoir pour quelqu’un qui ne s’est pas engagé
Un joueur qui a ouvert votre jeu depuis une publication Facebook a investi bien moins que celui qui a cherché dans un store et attendu un téléchargement. C’est l’occasion, et c’est aussi la contrainte : vous avez beaucoup moins de patience à dépenser.
Gardez le téléchargement léger, rendez évidente la première chose à faire, et donnez au joueur quelque chose qui vaut la peine avant de demander des permissions, un partage ou un paragraphe d’explication. Les fonctions sociales passent bien mieux une fois qu’on a compris ce qui sera envoyé et pourquoi son ami s’en soucierait.
C’est du design et de l’ingénierie en même temps. Un premier écran lent change le tunnel, et un pack de ressources lourd décide en silence quels téléphones et quels pays peuvent jouer. Sur ce type de plateforme, le poids des fichiers fait partie de l’accueil.
Tout ce que la plateforme donnait, elle pouvait le reprendre
La plateforme faisait un travail que deux personnes n’auraient pas pu reproduire raisonnablement. Elle contrôlait aussi la validation, la découverte, le fonctionnement de l’identité et ce que nous avions le droit d’envoyer aux joueurs. Ce ne sont pas des détails administratifs : cela décide de ce que vous pouvez construire et de qui reste.
Il vaut la peine de garder cette dépendance visible. Notez vos hypothèses, rassemblez autant que possible le code spécifique à la plateforme au même endroit, et sachez quelles pannes laissent le jeu jouable. Surtout, ne confondez pas la portée de la plateforme avec une relation avec vos joueurs qui vous appartiendrait.
CUTE et tout ce qui a suivi ont énormément profité de la distribution de Facebook. Qu’aucun d’eux ne soit en ligne aujourd’hui est l’autre moitié de cette phrase.
Archivez avant que la plateforme ne le fasse pour vous
Le point pénible quand on écrit une rétrospective des années plus tard, ce n’est pas de retrouver le code. C’est de reconstituer ce que les joueurs voyaient : les écrans, le texte de la fiche, la date de lancement, les langues publiées, ce que les chiffres voulaient dire et pourquoi telle décision a été prise.
Une archive modeste suffit. Six choses, saisies pendant que le produit est encore en vie :
- Des écrans représentatifs, et un court enregistrement du produit en usage.
- Les chiffres que vous acceptez de citer publiquement, avec leurs dates.
- Qui était dans l’équipe, et de quoi chacun était responsable.
- L’architecture, à un niveau compréhensible de l’extérieur.
- La fiche du store, la date de lancement et les langues publiées.
- Un paragraphe sur les raisons de l’arrêt.
C’est largement assez pour nourrir une étude de cas plus tard, sans exposer quoi que ce soit de privé sur les clients ou les joueurs.
La trace publique ténue de CUTE fait aujourd’hui partie de sa leçon. Publier compte, mais garder de quoi expliquer ce qu’on a publié est aussi un travail de produit.
