Disclaimer While working as a project manager, I often heard comments like: “Why do we even need PMs? What do they actually do? They only talk and nothing more.” It’s a fairly common opinion. So I prepared an article about what PM can actually do (together with their team) and how impactful that work can be for a project. As we PMs and producers love — with numbers, tables and charts. There are three part about Art Pipeline, Daily Routing Optimisation and JIRA etiquette. This case come from my personal experience and focus on how we built a Cosmetics department from scratch on an AAA project and ultimately optimized art production, accelerating it by a factor of 3.3. accelerating it by a factor of 3.3. Thank you very much. Enjoy the read. Art Pipeline The Case Once I moved into production as a Project Manager with a mission: to  build a cosmetics department that would deliver skins (and more) for  battle passes and in-game events. At the same time, we already had  a character art department. They had created eight characters at  various stages of completion and one high-tier skin with geometry  changes. Producing that single skin took the artist 16 months. My task was to establish a functioning production pipeline and fully meet the publisher’s requirements by the release  date: 21+ skins with new geometry and 40+ recolors. After that, we had  to release 7+ skins of different types every month — and the following  year, double those numbers. Work First,  I analyzed the previous experience and the current production pace of  meshes (characters and a skin). Using data from Jira and tons of Excel  sheets, we identified several weak points. Art production roadmap Art production roadmap There  was no structured roadmap for character art production in general and  cosmetics in particular. Meshes were considered part of the character  development pipeline, and all work related to them was placed into three  large stages — L0, L1, L2 — from prototype to final polished version.  Each of these oversized tasks could exceed the sprint length not just by  two cycles, but sometimes by three or even four. Lack of a standard Lack of a standard Every  mesh was treated as an R&D feature. When we compared L0/L1/L2  stages across different cases, we discovered that they took completely  different amounts of time — both clean time (logged hours) and dirty  time (the gap between task creation, moving it to “in progress,” and  marking it “done”). Even the number of tasks for identical types of  meshes varied significantly, and some of them had descriptions that were  almost impossible to understand. A separate thing that  stood out: one artist assigned to the task worked on the mesh from start  to finish (judging by the assignee history). And during production,  there were no logical points where he could have handed it off to  someone else without losing quality or time. The entire task looked like  one huge, continuous block of work. Lack of process transparency Lack of process transparency It  was unclear what was happening during development or how it was being  carried out. The quality and consistency of task updates depended  entirely on the developer themselves. There was no way to track progress  remotely or outside the morning stand-ups. If an artist got sick, the  lead could partially take over their task, leave no notes at all, and  still close it. Number of iterations Number of iterations Even  from the basic status history it was obvious that the task went to  review, then back again, then back to review, and then back to work. And  that’s not to mention the complete absence of comments explaining why  the task was being returned to work and then sent back again — not a  single word. We gathered with our small circle of  Illuminati — myself (as a PM), the principal artist, and the art lead —  and got down to work. Solution To begin with, we made two important high-level decisions to stop the confusion at the top level. We introduced grades We introduced grades Before  that, the project was full of a whole range of terms and labels:  recolor, paintjob, skin, premium skin, veterans, and so on. Each word  referred to a different type of work, which only confused us further. We  dropped all of that and introduced a document that clearly outlined the  differences between skins and their grades. “One skin = One epic = One branch” rule “One skin = One epic = One branch” rule I  borrowed this organizational rule from the character development team.  One epic includes all work related to the skin on the development side.  Each epic contains a single branch and a single pull request dedicated  to that skin. In turn, the epic was linked to the relevant season (or  event) initiative/feature for easier navigation. This was our starting point. From there, we rebuilt the entire workflow. We got rid of L0–L1–L2 We got rid of L0–L1–L2 Instead, we divided production according to the actual production logic: Design → Geometry → Textures → Implementation. Each stage was broken into smaller logical steps, for example:Concept: Moodboard – 2D Sketch – 3D Sketch (if needed)Geometry: Low Res – High Res – FBX File ImportImplementation: Rig – GD Setup – Art Review – QA The  skin itself was also split into three parts: the body, the weapon, and  the modules. Meaning that from then on we could have three separate  tasks, such as:Body – Geometry Low Res,Weapon – Geometry Low Res,Modules – Geometry Low Res. This transformed what used to be a single massive block of work into a  Lego-like constructor that could be distributed among artists depending  on their workload. Now it was possible to track exactly which stage  production was currently in. The new art production roadmap The new art production roadmap Essentially,  everything we had done above was laid out as a sequence of actions.  This chart helped us — and any PM who might need to replace me during  sick leave or vacation — understand where and which processes could be  run in parallel to save time. Unified formatting for Epics and tasks Unified formatting for Epics and tasks The epic now contained only tasks related strictly to the skin’s grade — nothing extra. Each epic included the skin’s concept in its description, as well as the acceptance criteria from the producer. This  reduced confusion and gave the artist a clear understanding of what was  expected at each stage. (Later we refined the task descriptions even  more, but that relates to the topic of daily routine, which comes next.) I  also set up a separate section appeared in Confluence with a Mira board  where all these descriptions were listed for each task, with comments  for the project manager explaining when and what task should be created,  along with a Jira formula that could simply be copied and pasted into  the task body. Estimations Estimations We tried to  break tasks down so they would be easy to plan. The project used  two-week sprints, so we aimed to find a common structure: not exceeding  the boundaries too much while still giving each task a logical  completion point. Huge thanks to my colleagues —  without their experience we wouldn’t have been able to break this down  as precisely. Relying only on Jira numbers would have been much harder,  because in art production the individual specialist’s skill matters a  lot, and when designing estimations, we had to find a golden middle  ground between what we could realistically deliver and what we wanted to  achieve. That’s how we arrived at the formula that one development step = a sprint plus two days at most. one development step = a sprint plus two days Now  the artist could see how much time they had for each task and how close  they were to finishing it. With proper communication, this became a  support tool. If an artist saw that they had three days left for a task  but understood they wouldn’t make it — they could proactively tell me. This  meant I didn’t have to “control” the developer; they had all the tools  to help me and raise a red flag where we might miss a deadline. As a result, we managed to achieve developer autonomy.  When opening an epic, the artist found a ready, fully prepared task  they could start immediately — even if they weren’t completely sure what  to do at first. We made review sessions and evaluation criteria  transparent. developer autonomy Result Straight to the point. Numbers only. That’s the case.

This story contains new, firsthand information uncovered by the writer.

Adapting to AI: Insights from a Project Manager in Game Development

How a PM Can Transform Art Production: A Case Study in AAA Gaming

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Adapting to AI: Insights from a Project Manager in Game Development

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Fantastic JavaScript Projects for Beginners

11 Great Tips From A Guy Who Leveled Up From Intern To Dev

125 Stories To Learn How To Do X

3 Free Python Courses For Beginners: 2020 Edition

Adapting to AI: Insights from a Project Manager in Game Development

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Fantastic JavaScript Projects for Beginners

11 Great Tips From A Guy Who Leveled Up From Intern To Dev

125 Stories To Learn How To Do X

3 Free Python Courses For Beginners: 2020 Edition

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps