Comment un PM peut transformer la production artistique : une étude de cas dans le gaming AAA

Avertissement

Lorsque je travaillais en tant que chef de projet, j'entendais souvent des commentaires comme : « Pourquoi avons-nous même besoin de PM ? Que font-ils réellement ? Ils ne font que parler et rien de plus. » C'est une opinion assez répandue.

J'ai donc préparé un article sur ce qu'un PM peut réellement faire (avec son équipe) et l'impact que ce travail peut avoir sur un projet. Comme nous, les PM et les producteurs, aimons — avec des chiffres, des tableaux et des graphiques. Il y a trois parties sur l'Art Pipeline, l'optimisation de la routine quotidienne et l'étiquette JIRA.

Ce cas provient de mon expérience personnelle et se concentre sur la façon dont nous avons construit un département Cosmétiques à partir de zéro sur un projet AAA et finalement optimisé la production artistique, en l'accélérant d'un facteur de 3,3.

Merci beaucoup. Bonne lecture.

Art Pipeline

Le Cas

Un jour, je suis passé à la production en tant que chef de projet avec une mission : créer un département cosmétiques qui fournirait des skins (et plus) pour les battle passes et les événements en jeu.

En même temps, nous avions déjà un département d'art des personnages. Ils avaient créé huit personnages à différents stades d'achèvement et un skin haut de gamme avec des modifications de géométrie. La production de ce seul skin a pris 16 mois à l'artiste.

Ma tâche était d'établir un pipeline de production fonctionnel et de répondre pleinement aux exigences de l'éditeur d'ici la date de sortie : 21+ skins avec une nouvelle géométrie et 40+ recolors. Après cela, nous devions sortir 7+ skins de différents types chaque mois — et l'année suivante, doubler ces chiffres.

Travail

D'abord, j'ai analysé l'expérience précédente et le rythme de production actuel des meshes (personnages et un skin). En utilisant les données de Jira et des tonnes de feuilles Excel, nous avons identifié plusieurs points faibles.

Feuille de route de production artistique

Il n'y avait pas de feuille de route structurée pour la production d'art des personnages en général et des cosmétiques en particulier. Les meshes étaient considérés comme faisant partie du pipeline de développement des personnages, et tout le travail lié à eux était placé dans trois grandes étapes — L0, L1, L2 — du prototype à la version finale polie. Chacune de ces tâches surdimensionnées pouvait dépasser la longueur du sprint non seulement de deux cycles, mais parfois de trois ou même quatre.

Manque de standard

Chaque mesh était traité comme une fonctionnalité R&D. Lorsque nous avons comparé les étapes L0/L1/L2 à travers différents cas, nous avons découvert qu'elles prenaient des durées complètement différentes — à la fois le temps net (heures enregistrées) et le temps brut (l'écart entre la création de la tâche, son passage à « en cours » et son marquage « terminé »). Même le nombre de tâches pour des types identiques de meshes variait considérablement, et certaines d'entre elles avaient des descriptions presque impossibles à comprendre.

Une chose distincte qui ressortait : un artiste assigné à la tâche travaillait sur le mesh du début à la fin (à en juger par l'historique des assignés). Et pendant la production, il n'y avait pas de points logiques où il aurait pu la transmettre à quelqu'un d'autre sans perdre en qualité ou en temps. La tâche entière ressemblait à un énorme bloc de travail continu.

Manque de transparence du processus

Il n'était pas clair ce qui se passait pendant le développement ou comment il était réalisé. La qualité et la cohérence des mises à jour des tâches dépendaient entièrement du développeur lui-même. Il n'y avait aucun moyen de suivre les progrès à distance ou en dehors des stand-ups du matin. Si un artiste tombait malade, le lead pouvait partiellement reprendre sa tâche, ne laisser aucune note et la clore quand même.

Nombre d'itérations

Même à partir de l'historique de statut de base, il était évident que la tâche allait en révision, puis revenait, puis retournait en révision, puis revenait au travail. Et ce, sans parler de l'absence totale de commentaires expliquant pourquoi la tâche était renvoyée au travail puis renvoyée à nouveau — pas un seul mot.

Nous nous sommes réunis avec notre petit cercle d'Illuminati — moi-même (en tant que PM), l'artiste principal et le lead artistique — et nous nous sommes mis au travail.

Solution

Pour commencer, nous avons pris deux décisions importantes de haut niveau pour arrêter la confusion au niveau supérieur.

Nous avons introduit des grades

Avant cela, le projet était plein de toute une gamme de termes et d'étiquettes : recolor, paintjob, skin, premium skin, veterans, etc. Chaque mot faisait référence à un type de travail différent, ce qui ne faisait que nous confondre davantage. Nous avons abandonné tout cela et introduit un document qui définissait clairement les différences entre les skins et leurs grades.

Règle « Un skin = Une épique = Une branche »

J'ai emprunté cette règle organisationnelle à l'équipe de développement des personnages. Une épique comprend tout le travail lié au skin du côté du développement. Chaque épique contient une seule branche et une seule pull request dédiée à ce skin. À son tour, l'épique était liée à l'initiative/fonctionnalité de saison (ou d'événement) pertinente pour une navigation plus facile.

C'était notre point de départ. À partir de là, nous avons reconstruit l'ensemble du workflow.

Nous nous sommes débarrassés de L0–L1–L2

Au lieu de cela, nous avons divisé la production selon la logique de production réelle : Design → Géométrie → Textures → Implémentation.

Chaque étape a été divisée en petites étapes logiques, par exemple : \n Concept : Moodboard – Esquisse 2D – Esquisse 3D (si nécessaire) \n Géométrie : Low Res – High Res – Importation de fichier FBX \n Implémentation : Rig – Configuration GD – Révision artistique – QA

Le skin lui-même a également été divisé en trois parties : le corps, l'arme et les modules. Ce qui signifie qu'à partir de ce moment, nous pouvions avoir trois tâches distinctes, telles que : \n Corps – Géométrie Low Res, \n Arme – Géométrie Low Res, \n Modules – Géométrie Low Res.

Cela a transformé ce qui était autrefois un seul bloc de travail massif en un constructeur de type Lego qui pouvait être distribué entre les artistes en fonction de leur charge de travail. Il était maintenant possible de suivre exactement à quelle étape se trouvait actuellement la production.

La nouvelle feuille de route de production artistique

Essentiellement, tout ce que nous avions fait ci-dessus a été présenté comme une séquence d'actions. Ce graphique nous a aidés — ainsi que tout PM qui pourrait avoir besoin de me remplacer pendant un congé maladie ou des vacances — à comprendre où et quels processus pouvaient être exécutés en parallèle pour gagner du temps.

Formatage unifié pour les épiques et les tâches

L'épique ne contenait désormais que des tâches strictement liées au grade du skin — rien de plus.

Chaque épique incluait le concept du skin dans sa description, ainsi que les critères d'acceptation du producteur.

Cela a réduit la confusion et a donné à l'artiste une compréhension claire de ce qui était attendu à chaque étape. (Plus tard, nous avons encore affiné les descriptions des tâches, mais cela concerne le sujet de la routine quotidienne, qui vient ensuite.)

J'ai également créé une section distincte dans Confluence avec un tableau Mira où toutes ces descriptions étaient répertoriées pour chaque tâche, avec des commentaires pour le chef de projet expliquant quand et quelle tâche devait être créée, ainsi qu'une formule Jira qui pouvait simplement être copiée et collée dans le corps de la tâche.

Estimations

Nous avons essayé de décomposer les tâches pour qu'elles soient faciles à planifier. Le projet utilisait des sprints de deux semaines, nous avons donc cherché à trouver une structure commune : ne pas trop dépasser les limites tout en donnant à chaque tâche un point d'achèvement logique.

Un grand merci à mes collègues — sans leur expérience, nous n'aurions pas pu décomposer cela aussi précisément. Se fier uniquement aux chiffres de Jira aurait été beaucoup plus difficile, car dans la production artistique, la compétence du spécialiste individuel compte beaucoup, et lors de la conception des estimations, nous avons dû trouver un juste milieu entre ce que nous pouvions réalistiquement livrer et ce que nous voulions réaliser. C'est ainsi que nous sommes arrivés à la formule selon laquelle une étape de développement = un sprint plus deux jours au maximum.

Maintenant, l'artiste pouvait voir combien de temps il avait pour chaque tâche et à quel point il était proche de la terminer. Avec une communication appropriée, cela est devenu un outil de soutien. Si un artiste voyait qu'il lui restait trois jours pour une tâche mais comprenait qu'il n'y arriverait pas — il pouvait me le dire de manière proactive.

Cela signifiait que je n'avais pas à « contrôler » le développeur ; il avait tous les outils pour m'aider et lever un drapeau rouge là où nous pourrions manquer une date limite.

En conséquence, nous avons réussi à atteindre l'autonomie du développeur. En ouvrant une épique, l'artiste trouvait une tâche prête et entièrement préparée qu'il pouvait commencer immédiatement — même s'il n'était pas complètement sûr de ce qu'il devait faire au début. Nous avons rendu les sessions de révision et les critères d'évaluation transparents.

Résultat

Droit au but. Chiffres seulement.

C'est le cas.

\ \ \