Optimiser son temps : prioriser les tâches

Lorsque l'on développe dans un contexte professionnel, on n'a généralement pas vraiment le choix sur le sujet de son travail. C'est le chef de projet qui affecte des tâches précises à chaque développeur avec une deadline (date limite pour terminer la tâche) correspondante.

Dans le cadre d'un projet amateur personnel, c'est bien plus souple puisque vous allez vous-même faire le choix de la tâche sur laquelle vous allez travailler.

Si votre jeu n'est pas encore sorti (pas encore ouvert aux joueurs), il suffit en général de suivre votre cahier des charges en développant les modules par ordre de priorité.

Je considère que c'est un brin plus compliqué une fois le jeu ouvert, car il faut maintenant prendre en considération les attentes de la communauté.

Ce billet s'inscrit dans le contexte suivant :

« Tiens, j'ai quelques heures de libre, sur quoi vais-je travailler ? »

Une fois le jeu sorti, on peut distinguer les tâches suivantes (pour le développement) :

• corrections de bogues : normalement vos joueurs relèvent plus ou moins fréquemment des bogues en production (serveur de jeu) ;
• optimisation de code : le code d'un module vous semble sale et vous souhaitez le redévelopper en améliorant l'algorithme, la syntaxe, créant une bibliothèque de fonctions de base, etc.
• nouvelle fonctionnalité : développement de nouvelles fonctionnalités et mécanismes de jeu afin d'améliorer le Gameplay (et le jeu en général) ;
• ergonomie : améliorer le ressenti utilisateur en modifiant l'interface (UI), enrichissant la charte graphique, rajouter des effets visuels ici et là, etc.

Certaines tâches devraient être traitées avant d'autres et il est important d'en prendre conscience sous peine d'être chahuté par votre communauté. Si au bout de deux mois d'attente vous sortez une mise à jour ajoutant deux effets visuels kikou en AJAX alors que des bogues critiques ne sont toujours pas corrigés, il ne faudra pas vous étonner si certains joueurs se sentent un peu abandonnés…

Voici une priorisation possible (du plus prioritaire au moins prioritaire) :

1. Correction de bogues ( critiques ) ;
2. Ergonomie ;
3. Nouvelle fonctionnalité ;
4. Optimisation de code.

Bouh, comment ça « optimisation de code » en dernier ? Tout simplement parce que les joueurs se moqueront totalement de savoir si le code est propre ou sale. À moins d'améliorer franchement les performances (et donc le ressenti des joueurs), refaire une classe de manière propre pendant deux jours, c'est (côté utilisateurs) du temps perdu. Personnellement à moins que ce soit un handicap réel pour le reste de l'application (code non maintenable, vous tremblez rien qu'à l'idée de travailler sur ce module), je considère qu'une classe ou un module qui fonctionne correctement et avec des performances correctes n'ont pas besoin d'être refaits, sauf si on n'a vraiment rien à faire (ce qui arrive rarement).

C'est sûr qu'idéalement il faudrait avoir un code nickel, mais la vérité c'est que c'est invisible pour l'utilisateur, donc je préfère prioriser d'autres tâches.

La priorité ce sont les bogues. Je ne parle pas des bogues mineurs comme les fautes d'orthographe et compagnie. D'ailleurs normalement, vous devriez trier ces bogues par criticité en partant de critique/bloquant pour les plus graves jusqu'à mineur pour les moins graves. Un bogue nuisant à l'expérience du jeu doit être corrigé en priorité.

L'importance de l'ergonomie ne doit pas être sous-estimée, surtout dans un jeu web. Il y a des jeux au Gameplay pauvre, mais avec une interface riche et « high-tech » (AJAX et Cie) qui fonctionnent très bien et des jeux au Gameplay très riche qui sont délaissés à cause d'un design ou d'une interface dépassée. Le public est en général assez casual et l'ergonomie est souvent priorisée même par les boîtes professionnelles. Il suffit d'aller sur Facebook et de lancer quelques jeux « à la mode » pour voir que le Gameplay tient en quelques lignes (voir en quelques mots…), mais que l'ergonomie est très soignée justement pour attirer les casuals.

Avec le web 2.0, AJAX à outrance et surtout les boîtes professionnelles qui s'intéressent de plus en plus aux jeux web, vous ne pouvez pas vous permettre d'avoir un graphisme pauvre et des pages mal conçues.

Enfin l'ajout de nouvelles fonctionnalités est important sur le long terme pour redonner un peu de vie au Gameplay et donner envie aux joueurs de rester. Mais encore faut-il que le joueur ne soit pas déjà parti à cause de bogues à répétition ou d'une interface affreuse… Travaillez sur ces nouveaux contenus si ce qui est déjà en ligne fonctionne correctement (pas de bogue) et que le ressenti utilisateur est bon (ergonomie satisfaisante). 

À quoi bon prendre le risque de générer de nouveaux bogues si vous n'avez même pas corrigé ceux qui ont déjà été détectés ?

Ma classification se base donc sur cette analyse à savoir :

périmètre fonctionnel actuel opérationnel > bon ressenti utilisateur > besoin de renouveau > besoin de faire le ménage.

C'est évidemment tout à fait contestable, mais dans le cadre d'un projet amateur avec un temps de développement limité (car pris sur le temps libre) il vaut mieux - je pense - rentabiliser chaque développement.

Si le développement d'une nouvelle fonctionnalité n'est pour moi pas la priorité, c'est qu'il m'est déjà arrivé d'allouer mon temps dans cette voie et de me planter.

Une nouvelle fonctionnalité, c'est beaucoup de réflexion/conception, du temps de développement et enfin pas mal de tests. C'est donc en général assez chronophage.

Malheureusement, il arrive qu'une fois en production cette fonctionnalité ne plaise pas à la communauté. On ne peut pas satisfaire tout le monde, mais quand la majorité des joueurs ne semblent pas convaincus par ce que vous venez d'ajouter, il faut savoir se remettre en question. Il suffit en général d'un petit sondage pour confirmer une impression de rejet.

Cela peut passer par une modification (ça demande pas mal de temps), voire un abandon de la fonctionnalité. Dans le premier cas, cela coûtera encore du temps de développement, dans le second (le pire) cela conduit à une perte totale de tout le travail passé sur cette tâche. En général, ça fait assez mal et le moral en prend un coup.

Passer deux mois sur une mise à jour qui finit aux oubliettes, c'est dommage et démotivant. Il est impossible de savoir à l'avance quelle sera la réaction des joueurs vis-à-vis de ce nouveau développement. Vous pouvez limiter la casse en proposant la mise à jour sur un serveur de tests avant la mise en production, mais même là, si cela ne plaît pas la déception sera grande. Je pense que s'entêter en refusant toute modification ou l'abandon de la fonctionnalité est une erreur, il faut accepter les critiques et se braquer ne servira à rien…

Vous ne pouvez pas vous en vouloir de vous être trompé, lorsqu'un jeu est bien en place, enrichir son périmètre est assez difficile, car cela peut déstabiliser l'existant, déboussoler les joueurs, voire déséquilibrer le Gameplay.

Si vous choisissez de partir sur une nouvelle fonctionnalité, essayez de faire quelque chose qui concerne un maximum de joueurs. Si votre jeu contient dix classes de personnages et que vous travaillez un mois sur une mise à jour en concernant seulement deux, les 80 % de joueurs restants vont se sentir délaissés.

Enfin, il faut évaluer un petit peu le coût des nouveaux développements et voir si cela en vaut la peine. Par exemple si vous voulez créer une nouvelle classe jouable à partir de zéro :

• conception classe, Gameplay, objets, sorts et Cie : 20 heures ;
• développement : 40 heures ;
• tests : 5 heures.

Les chiffres sont imaginaires, mais je les trouve relativement réalistes. 

Cette nouvelle classe va vous coûter 65 heures de développement pris sur votre temps libre (donc deux mois si vous travaillez une heure dessus tous les jours ce qui est déjà pas mal).

Or cette mise à jour ne va concerner qu'entre 1 et 5 % de vos joueurs puisque toute votre communauté dispose déjà d'un personnage et peu vont repartir de zéro pour tester. 

De plus une telle mise à jour a des chances d'introduire de nouveaux bogues et donc d'avoir un coût caché (de correction des futures anomalies).

Est-ce vraiment intéressant de passer 65 h (~ deux mois) de travail sur une mise à jour ayant un faible intérêt direct pour vos joueurs ?

Si l'on considère qu'il faut une heure pour reproduire, corriger et tester la correction d'un bogue, vous pourriez supprimer 65 bogues touchant 100 % de la communauté dans le même laps de temps…

Le but étant de satisfaire les attentes de vos joueurs, il faut être attentif à leurs demandes. Parcourez le forum et regardez les points évoqués fréquemment, créez un sous-forum « suggestions et idées » dans lequel les joueurs proposeront des mises à jour, etc.

Faire ses développements dans son coin sans prendre en compte les attentes de ses joueurs est la meilleure façon de se planter.

C'est parfois étonnant, mais un développement de quelques minutes peut susciter bien plus d'intérêt que votre mise à jour top moumoute qui a pris plus d'un mois.

Pour les utilisateurs seul le résultat compte, ils se moqueront du fait que vous ayez utilisé le dernier Framework à la mode ou que votre code soit correctement indenté. Ils attendent du concret. Avant de partir dans des développements monstrueux, mettez-vous à leur place et demandez-vous ce qu'eux aimeraient avoir, si ça se trouve en deux heures de boulot vous pouvez faire plaisir à tout le monde.

Ma vision des choses est contestable, mais je pense que dans le cadre d'un jeu web amateur il faut vraiment prioriser en fonction de l'intérêt des utilisateurs (joueurs). Puisque chaque développement est pris sur votre temps libre, il faut optimiser ce temps et le rentabiliser au mieux.

• Priorité aux bogues bloquants/critiques.
• Pas de nouvelle fonctionnalité tant que le périmètre actuel n'est pas stabilisé.
• Être attentif aux attentes des joueurs.
• Ne pas oublier l'ergonomie (de plus en plus importante pour les jeux par navigateur).
• Make it count.

Merci à DA de nous avoir permis de publier ses articles que vous pouvez retrouver sur son blog.

Merci à zoom61 pour sa relecture orthographique.