Un post mortem est un regard sur une expérience passée, quelle qu’elle soit. L’expression est habituellement utilisée pour désigner un article fait par un développeur à propos d’un projet auquel il a participé et dans lequel il liste ce qui a marché et ce qui n’a pas marché, ce qui lui a plu et ce qui lui a moins plu.

Contexte.

La création de « Murmur » s’est faite dans le cadre d’un exercice lors de mon M1 à l’ENJMIN. La consigne de départ n’est pas réellement importante car elle a été largement dépassée par les 8 groupes. Un thème (« dérober », avec tous ses homophones), une technologie (Game Maker 7) et des délais (2 semaines pour fournir une version jouable et 1 semaine de plus pour présenter une version finale (20 minutes de présentation, 10 minutes de questions)) étaient donnés. L’équipe de « Murmur » était composée de deux graphistes, d’un game designer, d’un ergonome, d’un programmeur, d’un sound designer (qui était sur un autre projet en même temps) et d’un chef de projet (moi-même). L’équipe n’était pas à temps plein mais travaillait sur le projet en plus des cours quotidiens.

Description.

« Murmur » est une expérience interactive à utilisation unique. C’est à dire que le gameplay a été utilisé comme un outil de mise en scène interactive afin de véhiculer un message. L’utilisation est dite unique car la construction du message est séquentielle : lorsque l’utilisateur reçoit une information, il est supposé l’interpréter sans connaître la suite des évènements. Je ne rentrerai pas plus dans les détails, car les problématiques relatées dans ce post mortem concernent le déroulement du développement et se veulent donc compréhensibles par tout le monde, même, et surtout, ceux qui ne connaissent pas « Murmur ».

Pour plus d’informations à proprement parler sur « Murmur » :

• L’application avec ses sources
• Dossier de soutenance de l’exercice
• Support de présentation

Les difficultés identifiées en amont.

Dès la mise en place du projet, j’avais identifié trois difficultés majeures.

En premier lieu, les délais serrés promettaient d’être le facteur le plus contraignant. Deux livraisons étaient prévues : la première au bout de deux semaines qui devaient être une version jouable (mais éventuellement ni finale, ni complète) accompagnée d’un dossier décrivant divers éléments de conception et la seconde une semaine qui était la présentation de la version finale. De plus ces délais limitaient la possibilité de mettre en place une méthode de management projet complète.

Ensuite, j’étais inquiet au sujet de la technologie imposée (Game Maker 7 Pro). Une présentation conséquente nous en avait été faite mais si elle permettait de répondre en partie à la question de la faisabilité, il était encore difficile d’évaluer la charge de travail que représentait l’implémentation des fonctionnalités proposées par l’équipe.

Enfin, même si au final cela s’est avéré peu préjudiciable, je prenais au sérieux le manque d’expérience collective de l’équipe. Il s’agissait du premier travail de groupe qui allait de la conception à la présentation de l’objet réalisé. Si chacun d’entre nous possédait déjà des aptitudes certaines dans son domaine de compétences, il était nouveau pour tous de réaliser un projet nécessitant des compétences pluridisciplinaires et donc demandant à chacun de collaborer avec quelqu’un ayant un profil totalement différent du sien. De plus, cela signifie aussi que je ne connaissais pas réellement les membres de mon équipe dans un tel contexte.

Lever l’ancre malgré le brouillard

En temps normal, dans cette configuration (« faites quelque chose pour telle date avec telle équipe »), j’aurais déterminé le périmètre du projet en fonction des délais et des moyens de l’équipe en l’adaptant régulièrement en fonction des évènements durant le développement. Dans le cas présent, il m’était difficile d’évaluer les moyens. Que permet et que requiert la technologie? Quel est le degré de compétences des différents membres de l’équipe et notamment du programmeur sur qui l’implémentation du travail des autres repose? Quelles sont leur force de travail et leur motivation? Autant de questions sans réponses précises qui ont rendu la définition des contours initiaux du projet ardue.

De plus, dès le début de sa conception, le projet s’est voulu porteur de sens. Modifier le périmètre du projet en cours de développement aurait fortement remis en cause sa qualité car sa compréhension au près de l’utilisateur passait par le développement d’un tout cohérent et maîtrisé.

Mais ce dont j’étais réellement sûr était finalement assez simple. Les délais étaient serrés et ne nous laissaient pas vraiment le temps de tergiverser, surtout vue l’ambition de l’équipe. Ne pas tergiverser signifie deux choses : il faut faire quelque chose et ce qui est fait doit être nécessaire.

La discussion au sein du processus de création

J’avais choisi de mettre la discussion en équipe au sein du processus créatif. Cela m’a permis deux choses. D’abord, l’équipe adhérait à chacun des choix de conception et la cohésion, innée en majeure partie, s’en trouvait renforcée. Ensuite, cela me permettait d’être sûr que les choix faits engendreraient des charges de travail que l’équipe allait assumer. Dans l’idée, c’était parfait. Dans les faits, c’était beaucoup moins simple à gérer.

Le premier des écueils est que la discussion est un contact concret entre plusieurs personnes. Ce contact peut être agréable et n’être que positif. Mais ce contact peut parfois irriter et se transformer en tension. Souvent, le basculement entre ces deux cas est difficile à anticiper et s’il survient, cela devient difficile à corriger. Heureusement, l’équipe s’est montrée intelligente et mature. Les caractères se sont peu télescopés et quand le choc était proche, les personnes concernées ont su prendre sur elle. Aurais-je pu trouver cet équilibre avec une autre composition d’équipe ou ai-je eu de la chance d’avoir cette composition d’équipe ?

Toujours en lien avec les caractères des membres de l’équipe, ce projet, qui était donc la première expérience du genre pour chacun d’entre nous, était aussi un terrain d’étalonnage quant à la place de chacun. Pour ma part, je pense qu’il n’existe pas de définition stricte et universelle quant aux délimitations du rôle de chacun car cela peut varier selon le projet et l’équipe. De plus, en mettant le dialogue au sein de la démarche de création, j’incitais chaque participant à donner son avis sur chaque décision, sur chaque idée (non technique) et à proposer des solutions, même si elles n’étaient pas totalement dans son champ de compétences.

Pour finir, le souci de la discussion est qu’elle n’est pas fondamentalement productive. Elle peut aider à l’être mais en soit, le temps qu’on parle, on ne le passe pas à développer à proprement parler. Par contre, on a évidemment besoin de communiquer pour savoir dans quel sens avancer. J’ai parfois eu du mal à sentir que la discussion tournait en rond et nécessitait une synthèse de laquelle je pouvais déduire des tâches de développement pour chaque membre de l’équipe.

Malgré tous ces écueils, je reste persuadé que la discussion doit être l’essence du processus de création. En plus de fédérer (adhésion de chacun au projet, assomption de chacun à ses tâches…), ces discussions limitent les risques de « tour d’ivoire ». Mettre à une idée, une opinion, un avis à l’épreuve de la critique dans un cercle fermé et connu est indispensable. Si jamais l’idée d’un membre de l’équipe ne passe pas ce premier filtre, quelles sont les chances qu’elle soit bien accueilli par le public cible ? Une idée doit avoir une raison d’être plus qu’une simple envie, plus qu’un simple désir profond, plus qu’une intuition. De plus, la confronter aux autres permettra de l’enrichir au contact des idées du reste de l’équipe.

Quelques éléments à corriger pour le futur.

L’élément qui me semble le plus important à corriger est un manque de formalisme. Si cela n’a pas porté à conséquences, c’est, d’après moi, dû à la taille réduite du projet en termes de délais, d’objectifs et de participants. Déjà quelque peu englués par la discussion omniprésente, j’avais peur d’alourdir encore plus le processus. Cependant, il m’apparaît comme indispensable que chaque réunion soit suivie d’un compte rendu synthétique qui, en une vingtaine de lignes, indique ce qui a été décidé et l’orientation générale des choses. De la même façon, chaque tâche doit être l’accomplissement d’une consigne validée par le chef de projet et les développeurs concernés afin de se prémunir des travaux qui seraient effectués sur une incompréhension.

Une seconde amélioration à apporter concerne la préparation de la présentation. Même si en soit elle n’était pas mauvaise et répondait aux attentes, elle aurait du être tout aussi soignée que le reste du projet et du temps de préparation conséquent aurait dû lui être consacré. La communication sur ce qu’on fait est aussi importante que ce qu’on fait.

Un autre point à améliorer réside dans l’intégration des recherches en ergonomie dans le processus de développement. C’est une partie essentielle du développement mais aussi une des plus difficiles, d’autant plus quand l’interaction en question doit soulever un propos.

Pour finir, j’aurais surement dû essayer d’alterner les moments détendus et les moments de rigueur lorsque l’équipe était réunie. Même si l’ambiance était bonne, certaines réunions auraient surement gagné à se passer autour d’un verre par exemple.

Et à propos du résultat ?

Je dois bien admettre que je suis satisfait de ce projet. En tenant compte des contraintes, le résultat me parait intéressant même s’il pourrait largement être amélioré. Ma plus grande satisfaction provient surement de l’identité (visuelle, sonore et conceptuelle) que l’équipe a réussi à donner au projet. Même si on est loin des problématiques de gameplay à proprement parler, l’utilisation de l’interactivité comme outil de mise en scène et vecteur de sens a été enrichissante.

Ayant pu observer des utilisateurs face à « Murmur », j’ai pu voir que les réactions espérées avaient bien lieu ce qui m’a rassuré. Cependant, j’ai toujours peur que l’expérience ne soit pas réellement accessible. Les informations données à l’utilisateur sur ce qu’il doit faire et pourquoi il doit le faire sont encore améliorables, sans tomber dans quelque chose de didactique qui dénaturerait l’expérience.

Conclusion.

Il n’y a rien d’exceptionnel à conclure, j’aurais surement pu écrire cette conclusion avant même le projet. Il m’aura permis de « me rendre compte de ce dont je me doutais ». Donc, cette expérience aura été très enrichissante car j’ai pu mesurer l’ampleur de la difficulté de gérer une équipe aussi éclectique et un projet de cette nature en situation réelle. La seule question est : est ce que je parviendrai à me servir de cette expérience pour être meilleur lors du prochain projet ?