Hoe een PM de kunstproductie kan transformeren: een casestudy in AAA-gaming

Disclaimer

Tijdens mijn werk als projectmanager hoorde ik vaak opmerkingen zoals: "Waarom hebben we eigenlijk PM's nodig? Wat doen ze eigenlijk? Ze praten alleen maar en niets meer." Het is een vrij algemene mening.

Daarom heb ik een artikel voorbereid over wat een PM daadwerkelijk kan doen (samen met hun team) en hoe impactvol dat werk kan zijn voor een project. Zoals wij PM's en producers graag hebben — met cijfers, tabellen en grafieken. Er zijn drie delen over Art Pipeline, Daily Routing Optimisation en JIRA etiquette.

Deze case komt uit mijn persoonlijke ervaring en richt zich op hoe we een Cosmetics-afdeling vanaf nul hebben opgebouwd voor een AAA-project en uiteindelijk de kunstproductie hebben geoptimaliseerd, waarbij we deze met een factor 3,3 hebben versneld.

Heel erg bedankt. Veel leesplezier.

Art Pipeline

De Case

Ooit stapte ik over naar productie als Project Manager met een missie: een cosmetica-afdeling opbouwen die skins (en meer) zou leveren voor battle passes en in-game evenementen.

Tegelijkertijd hadden we al een character art-afdeling. Zij hadden acht personages in verschillende stadia van voltooiing gemaakt en één high-tier skin met geometrische veranderingen. Het produceren van die ene skin kostte de artiest 16 maanden.

Mijn taak was om een functionerende productiepijplijn op te zetten en volledig te voldoen aan de vereisten van de uitgever tegen de releasedatum: 21+ skins met nieuwe geometrie en 40+ recolors. Daarna moesten we elke maand 7+ skins van verschillende typen uitbrengen — en het jaar daarop die aantallen verdubbelen.

Werk

Eerst analyseerde ik de eerdere ervaring en het huidige productietempo van meshes (personages en een skin). Met behulp van gegevens uit Jira en tonnen Excel-sheets identificeerden we verschillende zwakke punten.

Art production roadmap

Er was geen gestructureerde roadmap voor character art-productie in het algemeen en cosmetica in het bijzonder. Meshes werden beschouwd als onderdeel van de character development pipeline, en al het werk gerelateerd aan hen werd in drie grote fasen geplaatst — L0, L1, L2 — van prototype tot definitieve gepolijste versie. Elk van deze te grote taken kon de sprintlengte niet alleen met twee cycli overschrijden, maar soms met drie of zelfs vier.

Gebrek aan een standaard

Elke mesh werd behandeld als een R&D-functie. Toen we de L0/L1/L2-fasen in verschillende gevallen vergeleken, ontdekten we dat ze volledig verschillende hoeveelheden tijd kostten — zowel schone tijd (gelogde uren) als vuile tijd (de kloof tussen het aanmaken van de taak, het verplaatsen naar "in uitvoering" en het markeren als "klaar"). Zelfs het aantal taken voor identieke types meshes varieerde aanzienlijk, en sommige hadden beschrijvingen die bijna onmogelijk te begrijpen waren.

Een apart ding dat opviel: één artiest die aan de taak was toegewezen, werkte van begin tot eind aan de mesh (afgaande op de assignee-geschiedenis). En tijdens de productie waren er geen logische punten waar hij deze aan iemand anders had kunnen overdragen zonder kwaliteit of tijd te verliezen. De hele taak leek één enorm, doorlopend werkblok.

Gebrek aan procestransparantie

Het was onduidelijk wat er tijdens de ontwikkeling gebeurde of hoe het werd uitgevoerd. De kwaliteit en consistentie van taakupdates hing volledig af van de ontwikkelaar zelf. Er was geen manier om de voortgang op afstand of buiten de ochtend-stand-ups te volgen. Als een artiest ziek werd, kon de lead hun taak gedeeltelijk overnemen, helemaal geen notities achterlaten en deze toch afsluiten.

Aantal iteraties

Zelfs uit de basis statusgeschiedenis was het duidelijk dat de taak naar review ging, dan weer terug, dan weer naar review, en dan weer terug naar werk. En dat is nog zonder de volledige afwezigheid van opmerkingen die uitleggen waarom de taak werd teruggestuurd naar werk en vervolgens weer werd teruggestuurd — geen enkel woord.

We kwamen samen met onze kleine kring van Illuminati — ikzelf (als PM), de principal artist en de art lead — en gingen aan het werk.

Oplossing

Om te beginnen namen we twee belangrijke beslissingen op hoog niveau om de verwarring op het hoogste niveau te stoppen.

We introduceerden grades

Daarvoor was het project vol met een heel scala aan termen en labels: recolor, paintjob, skin, premium skin, veterans, enzovoort. Elk woord verwees naar een ander type werk, wat ons alleen maar meer verwarde. We lieten dat alles vallen en introduceerden een document dat duidelijk de verschillen tussen skins en hun grades schetste.

"One skin = One epic = One branch"-regel

Ik leende deze organisatorische regel van het character development-team. Eén epic omvat al het werk gerelateerd aan de skin aan de ontwikkelingskant. Elke epic bevat een enkele branch en een enkele pull request gewijd aan die skin. Op zijn beurt was de epic gekoppeld aan het relevante seizoen (of evenement) initiatief/feature voor gemakkelijkere navigatie.

Dit was ons startpunt. Vanaf daar herbouwden we de hele workflow.

We kwamen van L0–L1–L2 af

In plaats daarvan verdeelden we de productie volgens de werkelijke productielogica: Design → Geometry → Textures → Implementation.

Elke fase werd opgebroken in kleinere logische stappen, bijvoorbeeld: \n Concept: Moodboard – 2D Sketch – 3D Sketch (indien nodig) \n Geometry: Low Res – High Res – FBX File Import \n Implementation: Rig – GD Setup – Art Review – QA

De skin zelf werd ook opgesplitst in drie delen: het lichaam, het wapen en de modules. Dat betekent dat we vanaf dat moment drie afzonderlijke taken konden hebben, zoals: \n Body – Geometry Low Res, \n Weapon – Geometry Low Res, \n Modules – Geometry Low Res.

Dit transformeerde wat vroeger één enorm werkblok was in een Lego-achtige constructor die kon worden verdeeld onder artiesten afhankelijk van hun werkdruk. Nu was het mogelijk om precies te volgen in welke fase de productie zich bevond.

De nieuwe art production roadmap

In essentie werd alles wat we hierboven hadden gedaan uitgelegd als een opeenvolging van acties. Deze grafiek help ons — en elke PM die mij zou moeten vervangen tijdens ziekteverlof of vakantie — begrijpen waar en welke processen parallel konden worden uitgevoerd om tijd te besparen.

Uniforme opmaak voor Epics en taken

De epic bevatte nu alleen taken die strikt gerelateerd waren aan de grade van de skin — niets extra's.

Elke epic bevatte het concept van de skin in de beschrijving, evenals de acceptatiecriteria van de producer.

Dit verminderde de verwarring en gaf de artiest een duidelijk begrip van wat er in elke fase werd verwacht. (Later verfijnden we de taakbeschrijvingen nog meer, maar dat heeft te maken met het onderwerp van de dagelijkse routine, dat hierna komt.)

Ik richtte ook een aparte sectie in Confluence in met een Mira-bord waar al deze beschrijvingen voor elke taak werden vermeld, met opmerkingen voor de projectmanager waarin werd uitgelegd wanneer en welke taak moest worden aangemaakt, samen met een Jira-formule die eenvoudig kon worden gekopieerd en in de taakbody kon worden geplakt.

Schattingen

We probeerden taken op te breken zodat ze gemakkelijk te plannen waren. Het project gebruikte tweewekelijkse sprints, dus we wilden een gemeenschappelijke structuur vinden: de grenzen niet te veel overschrijden en toch elke taak een logisch voltooiingspunt geven.

Enorme dank aan mijn collega's — zonder hun ervaring hadden we dit niet zo nauwkeurig kunnen opsplitsen. Alleen vertrouwen op Jira-cijfers zou veel moeilijker zijn geweest, omdat in kunstproductie de vaardigheid van de individuele specialist veel uitmaakt, en bij het ontwerpen van schattingen moesten we een gouden middenweg vinden tussen wat we realistisch konden leveren en wat we wilden bereiken. Zo kwamen we bij de formule dat één sprint plus twee dagen op zijn hoogst.

Nu kon de artiest zien hoeveel tijd ze hadden voor elke taak en hoe dicht ze bij het voltooien ervan waren. Met goede communicatie werd dit een ondersteuningsinstrument. Als een artiest zag dat ze drie dagen over hadden voor een taak maar begreep dat ze het niet zouden halen — konden ze het me proactief vertellen.

Dit betekende dat ik de ontwikkelaar niet hoefde te "controleren"; ze hadden alle tools om me te helpen en een rode vlag op te steken waar we een deadline zouden kunnen missen.

Als resultaat slaagden we erin ontwikkelaarsautonomie te bereiken. Bij het openen van een epic vond de artiest een kant-en-klare, volledig voorbereide taak die ze onmiddellijk konden starten — zelfs als ze in het begin niet helemaal zeker waren wat ze moesten doen. We maakten reviewsessies en evaluatiecriteria transparant.

Resultaat

Direct ter zake. Alleen cijfers.

Dat is de case.

\ \ \