Cómo un PM puede transformar la producción de arte: Un estudio de caso en juegos AAA

Descargo de responsabilidad

Mientras trabajaba como gerente de proyecto, a menudo escuchaba comentarios como: "¿Por qué necesitamos PMs? ¿Qué hacen realmente? Solo hablan y nada más." Es una opinión bastante común.

Así que preparé un artículo sobre lo que un PM puede hacer realmente (junto con su equipo) y qué tan impactante puede ser ese trabajo para un proyecto. Como a nosotros los PMs y productores nos encanta — con números, tablas y gráficos. Hay tres partes sobre Art Pipeline, Optimización de Rutina Diaria y etiqueta de JIRA.

Este caso proviene de mi experiencia personal y se centra en cómo construimos un departamento de Cosméticos desde cero en un proyecto AAA y finalmente optimizamos la producción de arte, acelerándola por un factor de 3,3.

Muchas gracias. Disfruta la lectura.

Art Pipeline

El Caso

Una vez me mudé a producción como Gerente de Proyecto con una misión: construir un departamento de cosméticos que entregara skins (y más) para pases de batalla y eventos en el juego.

Al mismo tiempo, ya teníamos un departamento de arte de personajes. Habían creado ocho personajes en varias etapas de finalización y una skin de alto nivel con cambios de geometría. Producir esa única skin le tomó al artista 16 meses.

Mi tarea era establecer un pipeline de producción funcional y cumplir completamente con los requisitos del editor para la fecha de lanzamiento: 21+ skins con nueva geometría y 40+ recolores. Después de eso, teníamos que lanzar 7+ skins de diferentes tipos cada mes — y el año siguiente, duplicar esos números.

Trabajo

Primero, analicé la experiencia previa y el ritmo de producción actual de mallas (personajes y una skin). Usando datos de Jira y toneladas de hojas de Excel, identificamos varios puntos débiles.

Hoja de ruta de producción de arte

No había una hoja de ruta estructurada para la producción de arte de personajes en general y cosméticos en particular. Las mallas se consideraban parte del pipeline de desarrollo de personajes, y todo el trabajo relacionado con ellas se colocaba en tres grandes etapas — L0, L1, L2 — desde el prototipo hasta la versión final pulida. Cada una de estas tareas sobredimensionadas podía exceder la duración del sprint no solo por dos ciclos, sino a veces por tres o incluso cuatro.

Falta de un estándar

Cada malla se trataba como una característica de I+D. Cuando comparamos las etapas L0/L1/L2 en diferentes casos, descubrimos que tomaban cantidades de tiempo completamente diferentes — tanto tiempo limpio (horas registradas) como tiempo sucio (el intervalo entre la creación de la tarea, moverla a "en progreso" y marcarla como "hecha"). Incluso el número de tareas para tipos idénticos de mallas variaba significativamente, y algunas de ellas tenían descripciones que eran casi imposibles de entender.

Algo separado que se destacó: un artista asignado a la tarea trabajaba en la malla de principio a fin (a juzgar por el historial de asignados). Y durante la producción, no había puntos lógicos donde pudiera haberla entregado a alguien más sin perder calidad o tiempo. Toda la tarea parecía un enorme bloque continuo de trabajo.

Falta de transparencia del proceso

No estaba claro qué estaba sucediendo durante el desarrollo o cómo se estaba llevando a cabo. La calidad y consistencia de las actualizaciones de tareas dependían completamente del propio desarrollador. No había forma de rastrear el progreso de forma remota o fuera de las reuniones matutinas. Si un artista se enfermaba, el líder podía tomar parcialmente su tarea, no dejar notas en absoluto y aun así cerrarla.

Número de iteraciones

Incluso desde el historial de estado básico era obvio que la tarea iba a revisión, luego regresaba, luego volvía a revisión, y luego regresaba al trabajo. Y eso sin mencionar la completa ausencia de comentarios explicando por qué la tarea estaba siendo devuelta al trabajo y luego enviada de nuevo — ni una sola palabra.

Nos reunimos con nuestro pequeño círculo de Illuminati — yo (como PM), el artista principal y el líder de arte — y nos pusimos a trabajar.

Solución

Para empezar, tomamos dos decisiones importantes de alto nivel para detener la confusión en el nivel superior.

Introdujimos grados

Antes de eso, el proyecto estaba lleno de toda una gama de términos y etiquetas: recolor, paintjob, skin, premium skin, veterans, y demás. Cada palabra se refería a un tipo diferente de trabajo, lo que solo nos confundía más. Dejamos todo eso e introdujimos un documento que delineaba claramente las diferencias entre skins y sus grados.

Regla "Una skin = Una épica = Una rama"

Tomé prestada esta regla organizacional del equipo de desarrollo de personajes. Una épica incluye todo el trabajo relacionado con la skin en el lado del desarrollo. Cada épica contiene una sola rama y un solo pull request dedicado a esa skin. A su vez, la épica estaba vinculada a la iniciativa/característica de temporada (o evento) relevante para una navegación más fácil.

Este fue nuestro punto de partida. Desde ahí, reconstruimos todo el flujo de trabajo.

Nos deshicimos de L0–L1–L2

En su lugar, dividimos la producción según la lógica de producción real: Diseño → Geometría → Texturas → Implementación.

Cada etapa se dividió en pasos lógicos más pequeños, por ejemplo: \n Concepto: Moodboard – Boceto 2D – Boceto 3D (si es necesario) \n Geometría: Low Res – High Res – Importación de Archivo FBX \n Implementación: Rig – Configuración GD – Revisión de Arte – QA

La skin en sí también se dividió en tres partes: el cuerpo, el arma y los módulos. Lo que significa que desde entonces podríamos tener tres tareas separadas, tales como: \n Cuerpo – Geometría Low Res, \n Arma – Geometría Low Res, \n Módulos – Geometría Low Res.

Esto transformó lo que solía ser un solo bloque masivo de trabajo en un constructor tipo Lego que podía distribuirse entre artistas dependiendo de su carga de trabajo. Ahora era posible rastrear exactamente en qué etapa estaba la producción actualmente.

La nueva hoja de ruta de producción de arte

Esencialmente, todo lo que habíamos hecho arriba se presentó como una secuencia de acciones. Este gráfico nos ayudó — y a cualquier PM que pudiera necesitar reemplazarme durante una baja por enfermedad o vacaciones — a entender dónde y qué procesos podían ejecutarse en paralelo para ahorrar tiempo.

Formato unificado para Épicas y tareas

La épica ahora contenía solo tareas relacionadas estrictamente con el grado de la skin — nada extra.

Cada épica incluía el concepto de la skin en su descripción, así como los criterios de aceptación del productor.

Esto redujo la confusión y le dio al artista una comprensión clara de lo que se esperaba en cada etapa. (Más tarde refinamos aún más las descripciones de tareas, pero eso se relaciona con el tema de la rutina diaria, que viene a continuación.)

También configuré una sección separada que apareció en Confluence con un panel de Mira donde todas estas descripciones se listaban para cada tarea, con comentarios para el gerente de proyecto explicando cuándo y qué tarea debería crearse, junto con una fórmula de Jira que simplemente podía copiarse y pegarse en el cuerpo de la tarea.

Estimaciones

Intentamos desglosar las tareas para que fueran fáciles de planificar. El proyecto usaba sprints de dos semanas, así que buscamos encontrar una estructura común: no exceder demasiado los límites mientras se le daba a cada tarea un punto de finalización lógico.

Muchísimas gracias a mis colegas — sin su experiencia no habríamos podido desglosar esto con tanta precisión. Confiar solo en los números de Jira habría sido mucho más difícil, porque en la producción de arte la habilidad del especialista individual importa mucho, y al diseñar estimaciones, tuvimos que encontrar un punto medio dorado entre lo que podíamos entregar realísticamente y lo que queríamos lograr. Así fue como llegamos a la fórmula de que un paso de desarrollo = un sprint más dos días como máximo.

Ahora el artista podía ver cuánto tiempo tenía para cada tarea y qué tan cerca estaba de terminarla. Con una comunicación adecuada, esto se convirtió en una herramienta de apoyo. Si un artista veía que le quedaban tres días para una tarea pero entendía que no lo lograría — podía decírmelo de manera proactiva.

Esto significaba que no tenía que "controlar" al desarrollador; tenían todas las herramientas para ayudarme y levantar una bandera roja donde pudiéramos perder una fecha límite.

Como resultado, logramos alcanzar la autonomía del desarrollador. Al abrir una épica, el artista encontraba una tarea lista y completamente preparada que podía comenzar de inmediato — incluso si no estaban completamente seguros de qué hacer al principio. Hicimos las sesiones de revisión y los criterios de evaluación transparentes.

Resultado

Directo al punto. Solo números.

Ese es el caso.

\ \ \