Skip to main content
Si haces clic en un enlace y realizas una compra es posible que recibamos una pequeña comisión. Lee nuestra política editorial.

Las condiciones de trabajo de los desarrolladores

Destripando la industria.

Como hemos estado un par de meses hablando de cuestiones un poco técnicas, he querido variar un poco. Cuando alguien esta pensando en dedicarse a hacer videojuegos, algún otro saca rápidamente el tema de las condiciones de trabajo en la industria. Si lleváis algo de tiempo siguiendo la actualidad del mundillo, habréis oído hablar de los casos más flagrantes: EA_Spouse o el infierno de Team Bondi. No todas las empresas son como estos ejemplos tan extremos, pero creo que vale la pena dar una visión general de los problemas a los que se enfrentan los desarrolladores.

El primer tema del que me gustaría hablar son las horas de trabajo. Se suele decir que los programadores de juegos trabajan muchas horas. Lo cierto es que, en general, las empresas suelen estar adscritas a un convenio similar al de cualquier otro trabajo: las famosas 40 horas semanales, los días de vacaciones reglamentarios, etc. Lo que ocurre es que no es nada raro que las empresas de videojuegos decidan instaurar lo que se conoce como el crunch time. Si se va retrasado con el proyecto, se suele pedir que la gente haga alguna hora extra más al día y, en casos muy graves, que se vaya a trabajar los fines de semana.

El caso extremo del crunch time es la Death March. La mayoría de desarrolladores aceptan el crunch porque, se entiende, que es durante un periodo corto de tiempo y para un objetivo determinado: una demo para el E3 o una entrega importante siendo la más normal el hito clave, terminar el juego. Una death march es cuando se está en perpetuo crunch con el objetivo de hacer todo el trabajo posible. Este tipo de prácticas son las que acaban haciendo abandonar la industria a mucha gente y son de las que se oye hablar.

También se dice que en la industria del videojuego se paga poco. Esto es cierto a medias: de media, en videojuegos se paga algo menos, pero no mucho menos. Como queda un poco feo hablar sin dar números, he buscado los datos en la industria de los videojuegos y en el sector de la informática en general. Los números son de Estados Unidos (Dólares al año) y los he sacado, respectivamente de Game Career Guide (Gamasutra), de Dr.Dobb's y ComputerWorld (IDG). Para puestos de entrada, la diferencia es más notoria, pero a medida que se evoluciona profesionalmente, se reduce la diferencia. Seguramente porque las necesidades y ambiciones en ambos sectores cada vez se parecen más.

# Videojuegos IT
Programador Junior 65mil. 79mil
Programador Senior 80mil 90-97mil
Jefe de programación 120mil 100-120mil

El ultimo tema, y el que creo que es más determinante que el económico, es la poca seguridad de la industria del videojuego. Según la lista que mantienen los usuarios del foro NeoGAF, el año pasado cerraron 26 estudios de videojuegos y en lo que llevamos de año han cerrado ya 7. Una industria del AAA basada en grandes estudios con cientos de empleados requiere un número de ventas elevado y, si no sale bien un solo proyecto, muchos estudios optan por bajar la persiana. En la lista de NeoGAF podeis ver que en estos últimos años han cerrado instituciones como Ensemble, Sony Liverpool o el veteranisimo estudio Eurocom que llevaba haciendo juegos desde la NES.

¿De quien es la culpa?

Entre estos temas, me gustaría hablar un poco más sobre el crunch time. La inseguridad del modelo de desarrollo actual daría para otra sección y sobre el tema de los sueldos no tengo suficiente conocimiento para escribir de ello.

¿Porque se trabaja tantas horas? ¿Es necesario para hacer los juegos que los jugadores demandan o son los jefes unos perversos esclavistas? Pues, seguramente, ni una cosa ni otra. En mi opinión, todas las partes tienen un poquito de culpa, algunos más que otros, normalmente directamente proporcional al poder que tienen.

Los desarrolladores: Estamos en una industria joven y todavía tenemos el germen del desarrollador cowboy que se tira toda la noche programando para terminar una entrega y "salvar" el proyecto. La media de edad en el sector de los videojuegos es más baja que en otros campos y con treinta y pico los desarrolladores todavía "se sienten jóvenes" para tirarse la noche trabajando. Por experiencia os puedo decir que, de estas épocas oscuras, uno siempre se acuerda de lo bueno: del compañerismo y de las anécdotas "bonitas".

La gente joven tiene excusa: en la industria de los videojuegos es muy importante acabar un juego. Muchas veces, si es tu primer trabajo, estás dispuesto a sacrificarte más para tener un primer título en el curriculum.

Los productores/editores: Quienes "mandan de verdad" también tiene parte de culpa. Como he dicho, la industria es joven y todavía no tenemos práctica estimando costes y, sobre todo, teniendo en cuenta desde el primer día el coste de muchas tareas, necesarias para sacar el juego a la calle, pero no para que "funcione": la localización, guardar partidas, pasar las certificaciones, etc. Todo esto suele traer bastante trabajo para tenerlo funcionando bien y, normalmente, son tareas que se suelen infravalorar cuando se planifica el proyecto.

Se ha olvidado de algo. Seguro.

No es nada raro que, para minimizar el "error de estimación", la gente de arriba decida exigir más de lo que el desarrollador puede abarcar para asegurarse que cada mes trabajen el máximo que puedan. Esto, que sobre el papel es óptimo, al final se paga porque la calidad de lo que se entrega cuando vas pillado de tiempo suele ser menor.

Y, luego, tenemos las sorpresas. Los que desarrolláis software ya conocéis los "cambios de requisitos". En videojuegos, además de que, de repente, al publisher le apetezca una característica nueva que es lo que lo está petando este año y que obligue a cambiar la planificación del proyecto, aparecen las sorpresas en forma de "demos" o "builds". De un día para otro el que paga quiere "ver el juego" o, aún más complicado, quiere enseñarlo y resulta que tienes que prepararle una versión con todo lo que tienes y que no requiera llevarle de la mano porque como toque algo se rompe. El proceso de "cerrar una versión" no es tan diferente de "terminar el juego" y todo ese tiempo haciendo versiones no lo estas invirtiendo en el juego.

¿Están los desarrolladores contentos?

Poco después de hacer la sección en radio apareció en Gamasutra un estudio sobre la satisfacción de los desarrolladores. Si os leeis los comentarios que aparecen en la entrada, claramente podéis ver que hay de todo, aunque los que se resaltan se decantan hacia el lado negativo. No obstante, si vamos al artículo de la revista Game Developer, casi un 30% de los encuestados afirman estar muy satisfechos y casi un 40% algo satisfechos. No obstante, el porcentaje de negativos alcanzaba casi el 20%. Es importante destacar que estos números incluyen también desarrollo independiente, de juegos sociales y móviles. Uno de los motivos principales por los que mucha gente da el salto indie (o a proyectos menos ambiciosos) es para mejorar su calidad de vida.

Otros números que resultan muy interesantes es que, aunque el porcentaje de desarrolladores que en picos de trabajo hacen más de 60 horas semanales es bastante alto (un 30%), casi un 70% de los desarrolladores se mostraba optimista con el resultado de su actual proyecto. Aunque me gustaría que se diesen los datos desgranados según la etapa del desarrollo, estos datos dan a entender que, en general, los desarrolladores consideran que están haciendo un buen trabajo. Lo que si se desgrana es que, en relación a proyectos anteriores, se establece una correlación entre horas y éxito del proyecto: en general, los proyectos en que se hacen menos horas, suelen considerarse exitosos (lo cual tiene bastante sentido).

¿Existe alguna solución?

En este artículo he dicho varias veces que la industria de los videojuegos es joven. Eso es algo que se soluciona con el tiempo y, sobre todo, la experiencia. A medida que la industria pasa por más proyectos y la gente que trabaja en ella tiene el conocimiento de experiencias pasadas es más fácil tener en cuenta todos los problemas que te has encontrado. Esto te permite tomar medidas preventivas, por ejemplo; añadir en las planificaciones todas la tareas que anteriormente pasaste por alto y con una estimación basada en la experiencia (si has sido precavido de contabilizar lo tiempos que invertiste) o con metodologías de integración continua donde intentas tener siempre una "versión" del juego que se pueda enseñar.

A veces, simplemente se retrasa el proyecto porque sí.

La otra solución, que no siempre es factible (ni esta en la mano de los desarrolladores) es retrasar el proyecto. Y no es nada rara, según la encuesta de Game Developer antes mencionada, menos de la mitad de los proyectos se terminaron a tiempo. Pero no siempre estas a tiempo de retrasar el lanzamiento. En alguna sección anterior he comentado que la época en que más juegos se venden es navidad. Es necesario sopesar el coste de "pagar" este sobreesfuerzo frente a las pérdidas de no sacar el juego en época de mayor venta. Hay veces que compensa pedir ese extra a los trabajadores porque las ganancias pueden ser enormes. El estado del proyecto también es importante, si el juego esta muy verde, por mucho que la gente trabaje como cosacos hay un límite al esfuerzo que puede desempeñar el equipo. También es muy importante la fase del proyecto, porque cuando el proyecto se acerca a su fase final se tienen que empezar a fijar fechas, tanto para la campaña de marketing como para la certificación o la "fabricación" que aún son más difíciles de mover.

Read this next