¿Por qué puede fracasar un proyecto?

Los éxitos suelen parecerse entre sí, pero cada fracaso es diferente.

Para que un videojuego tenga éxito, debe cumplir una serie de requisitos imprescindibles, además de contar con un poco de suerte; sin embargo, basta con cometer un solo error para que su destino quede sellado para siempre. Hemos sido testigos de la desaparición de muchos videojuegos que, a primera vista, parecían prometedores, y también nos hemos lamentado por proyectos que, a pesar de tener aspectos destacados, cayeron en el abismo por un descuido.

Un productor me describió una vez lo delicado que es llevar adelante un proyecto: la producción de un videojuego a partir de cierta envergadura es una tarea compleja, y siempre surgen obstáculos imprevistos en el camino.

Aunque a la mayoría de las personas les cuesta mucho aprender realmente de las experiencias ajenas y solo se puede adquirir experiencia a través de los propios errores, observar los fracasos que han vivido otros puede servir, en mayor o menor medida, como advertencia.

En esta edición de la mesa redonda de Youcha, hemos hablado con profesionales del sector sobre el tema: «¿Por qué fracasa un proyecto?».

▍Los Nómadas de Caohejing: El Rey del Oeste

El fracaso de los proyectos en los que he participado se puede resumir en una sola causa: trabajar a ciegas.

Desde el jefe hasta el productor, pasando por los mandos intermedios, todos rebosan una extraña arrogancia: rechazan cualquier experiencia externa, eluden todas las opiniones y sugerencias, y solo quieren hacer las cosas a su manera; no ven necesario comprobar nada, la retroalimentación no les importa, y creen que todo saldrá bien una vez finalizado el desarrollo.

Durante el desarrollo del proyecto también se organizaron algunas sesiones de pruebas y entrevistas con jugadores a pequeña escala, pero los cuestionarios de opinión de los jugadores no eran más que un trámite; en las entrevistas, el productor se limitaba a responder uno por uno, para luego volver a sumergirse en su pequeño mundo de desarrollo, sin tener ni idea de lo que era el mercado de los jugadores.

Esta forma de trabajar a puerta cerrada no puede durar para siempre; cuando las pruebas con jugadores adquieren cada vez mayor envergadura y los datos son tan pésimos que ya no se puede seguir haciendo como si nada, la arrogancia se convierte en pánico, lo que lleva a realizar ajustes descabellados en la dirección del proyecto, sin pensar en las consecuencias, en un intento por salvarse; al final, debido a que la situación es ya irremediable y los datos son pésimos, el proyecto acaba hundiéndose por completo.

▍Miguel, que ayer dejó el sector de los videojuegos

En realidad, en los proyectos en solitario, el proceso de fracaso es bastante habitual. Es como ahogarse poco a poco: parece que puedes aguantar cada problema por separado, pero al final todos los problemas te abruman a la vez.

Creo que la causa fundamental es, en definitiva, que nuestra creatividad está desconectada de la realidad. Tras varias pruebas, la reacción de los jugadores no fue buena, pero en aquel momento era demasiado terco: pensaba que los jugadores no tenían paciencia para entenderlo y no me atrevía a descartarlo todo y empezar de nuevo.

Y ahí empieza ese círculo vicioso: aceptar trabajos por encargo para ganarse la vida → el proyecto se estanca → se acaba el dinero y hay que aceptar más trabajos por encargo. A veces, estamos tan ocupados con los trabajos por encargo que ni siquiera tocamos nuestros propios proyectos. En cierto sentido, quizá estemos fingiendo no verlo.

Un día estuve retocando los efectos hasta las tres de la madrugada, cuando de repente me di cuenta de que no estábamos avanzando, sino que simplemente estábamos parcheando lo mismo. En ese momento, admitir que el proyecto ya estaba muerto resultó ser más fácil que seguir aguantando a toda costa.

▍XX, veterano retirado de la 3A

La gran mayoría de los videojuegos mueren al día siguiente de su lanzamiento, pero no se dan por terminados hasta pasado un año y medio, o incluso más tiempo.

▍La cinta que busca la victoria sin arriesgar

Es innegable que la gran mayoría de los juegos de compra definitiva tienen un ciclo de vida corto, y que el retorno de la inversión (ROI) del proyecto se puede predecir en el plazo de un mes tras su lanzamiento, o incluso antes, lo que significa que la inversión en la explotación posterior de estos juegos suele ser mucho menor que en el caso de los juegos como servicio (GaaS). Por lo tanto, cuando se habla de la «muerte» de un proyecto de juego de compra definitiva, normalmente se refiere a que el proyecto se queda en el tintero durante la fase de desarrollo.

Desde el punto de vista de los editores o los inversores, esto supone dejar de invertir en el proyecto y dejar de «aportar fondos» al equipo de desarrollo. Entonces, ¿qué motivos pueden provocar una pérdida total de confianza que lleve a la desaparición del proyecto?

Mi experiencia se limita exclusivamente a proyectos de videojuegos independientes, y la decisión de colaborar e invertir en un proyecto supone una evaluación de riesgos multidimensional: una demo jugable y con potencial, un posicionamiento de mercado claro y un carácter único, planes e ideas para el desarrollo futuro, y un equipo que «parezca» fiable.

Evaluar el potencial futuro de un proyecto de videojuegos es un requisito previo para la colaboración; además, creo que lo más difícil de prever es la estabilidad del equipo, ya que el desarrollo de videojuegos independientes suele recaer en personas individuales o pequeños estudios, cuyos miembros principales rara vez cuentan con experiencia en proyectos exitosos o con una solidez técnica contrastada.Durante la fase de contacto, solo podemos hacernos una idea limitada de su capacidad de comunicación y colaboración, de la claridad de su plan de proyecto y de si cuentan con un «entusiasmo disciplinado», lo cual es, con mucho, insuficiente.

Desde el punto de vista de los recursos humanos: la pérdida de personal clave y la ampliación de la plantilla; el equilibrio entre la plantilla y la ambición de los proyectos; los problemas de eficiencia en el desarrollo derivados de la falta de personal o de conocimientos técnicos.

Desde el punto de vista del control del proyecto: la incorporación constante de nuevas ideas y funcionalidades amplió los límites del proyecto, lo que impidió su finalización e incluso lo alejó de la mecánica de juego principal inicial; además, la acumulación de deuda técnica, debida a la falta de capacidad del equipo, y la aparición frecuente de errores provocaron una caída exponencial de la eficiencia en el desarrollo.

Se suele decir que un juego «aburrido» pero completo es peor que uno «divertido» pero a medio terminar, porque al menos el primero se puede vender.

Pero incluso tras superar problemas como las decisiones sobre la creatividad del juego o la prolongación del ciclo de desarrollo, y una vez que el proyecto finalmente se ha puesto en marcha, aún nos enfrentamos a un último escollo: los cambios en las tendencias del mercado de los videojuegos. «Por ejemplo, si en ese momento aún están de moda los roguelikes de acción, en otro momento el interés por ellos puede verse totalmente desplazado por los juegos de acción AAA».Por ello, cuando surge una crisis en el proyecto, los inversores suelen recurrir a una evaluación del estado del mismo para decidir si mantienen la colaboración o cortan por lo sano a tiempo, lo que supone la supervivencia o la desaparición de un proyecto de videojuego con contrato de compra exclusiva.

Debido a diversas razones como las mencionadas anteriormente, los estudios de desarrollo independientes actuales se ven obligados a completar el 70 % o más del desarrollo de un juego antes de poder plantearse siquiera una colaboración para su distribución; además, la creatividad de la mecánica de juego principal debe ser lo suficientemente destacada. Por ello, el nivel máximo de finalización del juego está predeterminado a no ser muy alto, lo que constituye un círculo vicioso en el entorno de desarrollo de los juegos independientes en China.

Sin embargo, sigo siendo optimista: todos los problemas se pueden resolver con el tiempo. Confío en que siempre habrá más expertos o coincidencias en las que los desarrolladores y los editores se complementen mutuamente, lo que permitirá construir poco a poco el mercado chino de los videojuegos 3i.

▍Un profesional lll

Antes de hablar de por qué fracasan los productos, debemos plantearnos primero: ¿por qué se crean?

El ciclo de vida de cada producto queda, de hecho, determinado desde el momento en que sale al mercado, y la base que determina dicho ciclo es la calidad del propio producto.

En el proceso de investigación, desarrollo y explotación, factores como el marketing, la opinión pública, los incidentes o la optimización no son más que un reflejo del propio producto. En esencia, el 90 % de las causas del declive de un producto están íntimamente relacionadas con su propia calidad.

Creo que la razón fundamental tiene que ver con la intención inicial con la que se pone en marcha cada proyecto dentro de cada empresa. Tanto si se trata de proyectos exitosos como de proyectos fallidos.

He visto demasiados casos en los que, partiendo únicamente de los «gustos» y los «ideales» del director creativo y del productor, a mitad del proyecto se dan cuenta de que su producto es demasiado específico o no lo suficientemente universal (o que carece de potencial comercial), por lo que empiezan a adaptarse a los usuarios y a hacer ajustes, hasta acabar creando algo que no es ni una cosa ni otra.

Son demasiados los equipos que, por las razones mencionadas, crean un producto poco acertado: un producto que no se adapta a los tiempos, ni a la tecnología de la empresa, ni a las necesidades de los usuarios. Aunque una minoría de ellos logra triunfar gracias a su excelente calidad y solidez, la mayoría de estos productos acaban siendo, en realidad, un fracaso.

Por eso, ¿por qué fracasa un proyecto? Creo que lo más importante es cuál es su punto de partida. El punto de partida determina la vida útil y la forma que tomará el proyecto. Hay algunos productos que, por decirlo con una frase típica de las series de televisión, «este niño no debería haber nacido».

▍Los Muertos del Hito -D

Un proyecto puede fracasar por las horas extras sin límite y las jornadas maratonianas (estoy convencido de ello)… De parte de un diseñador que está trabajando horas extras y lo está pasando fatal.

Por supuesto, esto es una broma: que haya o no horas extras, que el entorno del proyecto sea o no difícil, o incluso que la rentabilidad alcance o no las expectativas… Básicamente, ninguno de estos factores puede considerarse determinante a la hora de decidir si un proyecto fracasará o no.

Solo hay una causa directa que realmente puede acabar con un proyecto: que el propio jefe o inversor no quiera seguir adelante.El proyecto de al lado lleva un año en marcha, sigue perdiendo jugadores, casi siempre opera con pérdidas y el personal de I+D se va en oleadas, pero solo porque el jefe considera que este género debe contar con un producto digno, el proyecto se ha mantenido a flote con firmeza; aunque, por supuesto, la mayoría de las veces, la decisión del jefe trae consigo la mala noticia de la disolución del proyecto.

Aparte de los proyectos ya lanzados que presentan señales claras de fracaso (los ingresos no cubren los costes de los servidores), la posibilidad de que los proyectos en desarrollo lleguen a lanzarse y cuánto tiempo podrán mantenerse a flote suele ser una cuestión que los miembros del equipo de I+D apenas pueden prever. Puede que hace un par de días todo fuera de lo mejor, con todo el mundo disfrutando al máximo de las ventajas sociales y riendo y divirtiéndose en actividades de team building, y que, tras pasar el fin de semana, el proyecto haya desaparecido de repente.

También es posible que dentro del proyecto reine el pánico, que nunca se alcancen los objetivos de plazos, que todo el mundo piense que hay problemas de calidad y que haya que culpar a alguien, pero que el proyecto siempre tenga nuevos retos y nuevas inversiones, y que el lanzamiento parezca estar muy lejos, aunque el equipo de I+D siga en pie tras tantos años.

Hace tiempo, un amigo del sector me dijo que las horas extras no sirven para cumplir los objetivos de producción, sino para calmar la ansiedad del jefe.A veces, mientras se hacen esas horas extras, uno se siente realmente perdido: durante el largo periodo de desarrollo, no dejamos de «darlo todo», pero ¿lo hacemos para que el proyecto salga bien y se ponga en marcha, o simplemente para tranquilizar al jefe y evitar que el proyecto muera antes de que amaneze un futuro incierto?

▍Guía para el fin de un proyecto, elaborada por dos productores de videojuegos

Desde las reuniones hasta el presupuesto: las trampas que hacen que un videojuego fracase:

Las charlas vacías en las salas de reuniones, los presupuestos excesivos y los equipos desorientados están acabando silenciosamente con un proyecto de videojuegos tras otro. «Siempre nos limitamos a extraer conclusiones de los éxitos, pero rara vez repasamos las experiencias fallidas; ¿acaso es para echar sal en la herida?», escribió un profesional al resumir las lecciones aprendidas de los fracasos de los proyectos.Detrás de las relucientes historias de éxito de la industria de los videojuegos se esconden muchos más proyectos que fracasan en el anonimato. Estos fracasos no son casualidades, sino un colapso sistémico que abarca desde las reuniones y los presupuestos hasta la falta de valentía y la incapacidad para centrarse en lo esencial.

Las reuniones, que deberían ser un espacio para resolver problemas, suelen convertirse en el primer escenario donde los proyectos fracasan. Para que una reunión sea eficaz, es necesario llevar a cabo tres acciones clave: establecer objetivos claros, determinar métodos viables y definir una hoja de ruta concreta para la ejecución.Muchos responsables de proyectos pasan por alto esta norma básica y se dejan llevar por la autosatisfacción de «hablar por hablar». El planificador principal habla solo por hablar, el responsable del equipo dirige debates sobre cuestiones abstractas —como si el juego necesita una trama— e incluso se recurre a votaciones a mano alzada para resolver cuestiones técnicas. Este tipo de reuniones, que carecen de una agenda clara y de un mecanismo de toma de decisiones, provocan directamente una falta de rumbo en el equipo y una baja eficiencia.Cuando los miembros del equipo interpretan de forma diferente las conclusiones de la reunión y cada uno trabaja en una dirección distinta, el proyecto ya ha comenzado su camino hacia el fracaso. Los objetivos vagos sumen a los miembros del equipo en un atolladero de trabajo repetitivo y desviaciones de rumbo, lo que supone un desperdicio de valiosos recursos de desarrollo.

Aunque resulte contraintuitivo, un presupuesto excesivo a veces puede acelerar el fracaso de un proyecto. Un equipo pequeño con un presupuesto de entre 1 y 3 millones suele tener objetivos claros, una carga de trabajo equilibrada y una ejecución eficiente. Sin embargo, cuando el presupuesto se dispara hasta los 20 millones y el equipo crece, suele producirse un desequilibrio en la distribución de recursos, en el que unos están «sobrecargados de trabajo» y otros «sin nada que hacer».Este desequilibrio no solo provoca una disminución de la eficiencia, sino que también genera conflictos en el equipo. Cuando la distribución de recursos es inadecuada, las tareas clave pueden retrasarse por falta de recursos, mientras que las tareas no esenciales pueden acaparar recursos en exceso. En medio de este caos, los costes de comunicación del equipo se disparan y las excusas y las responsabilidades cruzadas sustituyen a la resolución conjunta de problemas.

Cuando los datos de las pruebas de un proyecto no son satisfactorios o los resultados comerciales no cumplen con las expectativas, el equipo tiende a caer en dos extremos: o bien abandonar precipitadamente el proyecto, o bien seguir adelante a toda costa. Muchos equipos carecen del valor necesario para abordar los problemas de fondo y prefieren realizar ajustes superficiales antes que afrontar los defectos fundamentales del proyecto.Un ajuste exitoso requiere que el equipo tenga «el valor de renovarse por completo» y «la paciencia y la minuciosidad necesarias para deconstruirlo todo». Cuando el juego no alcanza los resultados esperados, el equipo debe profundizar en su estructura interna y aclarar todos los marcos, funciones, relaciones, valores e interacciones.

Durante el proceso de modificación, un error habitual es intentar resolver todos los problemas a la vez: «añadir funciones», «completar contenidos» y «optimizar», todo a la vez. Este enfoque que pretende abarcarlo todo suele ser contraproducente.Las modificaciones deben tener unas prioridades claras. La tarea principal es optimizar la experiencia del jugador en los procesos fundamentales y generar retroalimentación positiva, con el fin de retener a los jugadores. Solo después se deben desarrollar funciones y añadir modalidades de juego basadas en esa experiencia. El diseño de los modelos de pago debe basarse en una buena retención de usuarios.

Además de los problemas fundamentales mencionados anteriormente, los proyectos de videojuegos pueden fracasar de muchas otras formas habituales; por ejemplo, los defectos técnicos son un «asesino invisible» para la explotación de un juego, y la estabilidad técnica es fundamental para los juegos que dependen de la interacción en tiempo real. Seguir ciegamente las modas y la falta de innovación son igualmente fatales.La confusión en las competencias, los flujos de trabajo poco razonables y la falta de compromiso del equipo con el proyecto son también causas habituales del fracaso de los proyectos. Cuando los miembros del equipo «ni siquiera quieren jugar a este tipo de juegos», el proyecto ya ha perdido su alma.

Un videojuego no es en absoluto una mezcla mecánica de diseño, programación y arte, sino un organismo que requiere de personas reales para su realización. Muchos directivos creen que basta con tomar decisiones a la ligera, leer artículos de los grandes nombres del sector y escuchar las fanfarronadas de los profesionales para descubrir oportunidades, y que luego, siguiendo el plan de diseño, se puede «llevar a cabo» el desarrollo del juego.Este error de razonamiento equivale a «creer que, por seguir una receta, uno es un gran chef capaz de preparar un manjar». ¿Cómo se miden «una pizca», «una cantidad adecuada» o «a gusto» en el desarrollo de un videojuego? ¿Cómo se controla el punto de cocción? Todo ello requiere experiencia e intuición.

Por último, no sé si debería decir esto, pero, en mi opinión, la mayoría de los responsables de la toma de decisiones en las empresas sufren una grave desconexión cognitiva con respecto al «campo de batalla» donde realmente se crea valor (es decir, el juego en sí) debido a la sobrecarga de información.

Los responsables de la toma de decisiones se enfrentan a diario a una enorme cantidad de noticias del sector, datos de mercado, opiniones de la competencia y análisis de los medios sociales. Esta información tiene valor en sí misma, pero el peligro radica en que es muy fácil que dé lugar a un mercado virtual abstracto e «idealizado», y que los responsables se obsesionen con realizar «simulaciones estratégicas» en ese plano abstracto.Hablan de «sectores del mundo 2D», «tendencias de los Party Games» o «modelos de compra de tráfico», pero pasan por alto que todos estos conceptos macroeconómicos deben plasmarse y materializarse, en última instancia, a través de un producto de juego concreto y entretenido.Cuando la base de la toma de decisiones proviene principalmente de informes de análisis externos y comunicados esporádicos, en lugar de una experiencia profunda y íntima con el propio producto, esa decisión es como construir un edificio sobre arena.

«Recorrer todo el proceso de principio a fin» es, precisamente, la forma más eficaz de desmontar esa burbuja cognitiva.Un directivo que nunca haya completado, como jugador habitual, todo el proceso —desde la descarga, pasando por el tutorial para principiantes y la mecánica principal, hasta llegar a los puntos de pago—, es incapaz de comprender en qué momento los jugadores se impacientan por unas cargas demasiado largas, en qué punto de una misión se atascan debido a un diseño poco razonable o en qué punto de pago abandonan definitivamente el juego por no percibir suficiente valor.Las instrucciones de modificación que dan suelen basarse en conceptos abstractos como «creo que», «los datos indican» o «a otros les ha funcionado», en lugar de en la experiencia real de «cuando llegué a ese punto del juego, yo también me sentí incómodo».Esto provoca una enorme brecha cognitiva entre el equipo de ejecución —que conoce a fondo los detalles del producto— y los responsables de la toma de decisiones —que se mueven en el ámbito de la información macro—, por lo que las instrucciones de modificación resultan, naturalmente, ineficaces o incluso contraproducentes.

¿Hay alguna forma de hacer frente a esto? Sí, amigos, la hay: consiste en desviar a la fuerza la atención de los responsables de la toma de decisiones de la fantasía de «riquezas desmesuradas» y del mar de información desordenada, para volver a los «principios fundamentales» más esenciales del juego: ¿es divertido? Esto exige que los responsables de la toma de decisiones se conviertan en los jugadores más exigentes y fieles de su propio producto.No solo deben jugar ellos mismos, sino también hacerlo junto con su equipo, organizando «Bug Bash» (sesiones de búsqueda de errores) y recopilando de forma anónima los comentarios más sinceros y contundentes que el personal de primera línea —especialmente el de atención al cliente y los responsables de la comunidad— haya recibido de los usuarios. La base de la toma de decisiones debe pasar de «los informes del sector dicen que…» a «anoche, cuando llegué al tercer nivel, descubrí que…».

Por último, la mayor parte de la responsabilidad recae, sin duda, en los propios productores, ya que todos estos problemas son cuestiones con las que me he topado en primera persona y que me han ocurrido a mí mismo. Pocos de los productores nacionales que he conocido juegan a sus propios juegos; la mayoría se limita a simular que juegan cuando llega el momento del lanzamiento, dando unas cuantas órdenes sin más.