lundi 6 février 2012

Optimiser son temps : prioriser les tâches

Lorsque l'on développe dans un contexte professionnel, on 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 je vais travailler ?"


Classification des tâches

Une fois le jeu sorti, on peut distinguer les tâches suivantes (pour le développement) :
  • Corrections de bugs : normalement vos joueurs relèvent plus ou moins fréquemment des bugs en production (serveur de jeu)
  • Optimisation de code : le code d'un module vous semble sâle 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.
  
Priorisation

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 bugs 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 bugs (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 sâle. A moins d'améliorer franchement les performances (et donc le ressenti des joueurs), refaire une classe de manière propre pendant 2 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 inmaintenable, 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'a pas besoin d'être refaite, sauf si on n'a vraiment rien à faire (ce qui arrive rarement).

C'est sûr qu'idéalement il faudrait avoir un code niquel 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 bugs. Je ne parle pas des bugs mineurs comme les fautes d'orthographe et compagnie. D'ailleurs normalement vous devriez trier ces bugs par criticité en partant de critique/bloquant pour les plus graves jusqu'à mineur pour les moins graves. Un bug 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é. Le public est en général assez casual et l'ergonomie est souvent priorisée même par les boites 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, l'ajax à outrance et surtout les boites professionnels 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 bugs à réptition ou d'une interface affreuse... Travaillez sur ces nouveaux contenus si ce qui est déjà en ligne fonctionne correctement (pas de bugs) et que le ressenti utilisateurs est bon (ergonomie satisfaisante). 

A quoi bon prendre le risque de générer de nouveaux bugs si vous n'avez même pas corrigés 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.

  


Le coup de poker d'une nouvelle fonctionnalité

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 semble pas convaincue 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) voir 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 êtes 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 voir 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 personnage et que vous travaillez un mois sur une mise à jour en concernant seulement deux, les 80% de joueurs restant 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 bugs et donc d'avoir un coût caché (de correction des futures anomalies).

Est-ce vraiment intéressant de passer 65h (~ 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 bug, vous pourriez supprimer 65 bugs touchant 100% de la communauté dans le même laps de temps...

  

Ecoutez votre communauté

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 à jours, 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 que eux aimeraient avoir, si ça se trouve en deux heures de boulot vous pouvez faire plaisir à tout le monde.


En bref

Ma vision des choses est constestable 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 bugs 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

7 commentaires:

  1. Là on est même arrivé dans l'article "Créer un logiciel".

    Beaucoup de choses dont tu parles ici sont applicable au développement logiciel en général et plus spécifiquement aux sites web.

    RépondreSupprimer
    Réponses
    1. Je suis bien d'accord (un jeu par navigateur étant un logiciel & un site web). Mais bon, il y a quand même pas mal de jeunes qui se lancent dans un projet de jeu web sans forcément avoir de connaissances en développement logiciel au préalable ... je pense notamment aux gens qui (comme moi) n'ont pas la patience d'attendre la fin de leurs études.

      Supprimer
  2. Un petit fichier Excel (ou gDocs... ) pour gérer sa liste de bugs/corrections/suggestions est le bienvenu pour gérer tout ça ! (moins usine à gaz que les outils de suivi de bugs, surtout si on est seul à coder).

    RépondreSupprimer
  3. Un outil en ligne de suivi de bug et de développement, ça serait génial :
    J'utilisais celui ci :
    http://www.drafts.fr/fiche-projet.php?Id=20
    Mais n'ayant pas toujours accès selon les sites de travail ... j'ai été contraint à arrêter. (un outil de suivi, si on ne peut pas le suivre, ne sert à rien).
    Je ne sais pas comment fonctionne vos projets, mais je me heurtes souvent à des choix :
    - bug sur la partie joueur
    - bug sur la partie administration

    J'essaye de privilégier les corrections sur la partie joueur (et plus spécifiquement priorité au remonté faites par les joueurs déficients visuels) ... cependant, les bug dans la partie d'administration sont un point important, car nos administrateurs finissent par ne plus avoir confiance en leurs outils et réduisent ainsi la voilure d'administration sur le site.

    Bref ... peut-être auriez vous à disposition un outil de bug/evol tracing ?
    J'essaye actuellement celui-là :
    https://magdales.uservoice.com/admin/forums/146562-bug-suggestion
    mais je n'en suis pas vraiment satisfait.

    Quel outils utilisez vous ?

    kéké

    RépondreSupprimer
    Réponses
    1. Sur notre projet on est sous TRAC : http://trac.edgewall.org/

      Supprimer
  4. Dans la gestion des taches, idées ou projets il y a des outils comme K-linq Decisions qui peuvent s'avérer très utiles. ils permettent d'impliquer des équipes dans le processus ce qui améliore l'efficacité, l'organisation et également la motivation dans l'entreprise

    RépondreSupprimer
    Réponses
    1. J'y jetterai un oeil à l'occasion, merci!

      Supprimer