Amateur Killers. Por qué acaban los proyectos

He aquí una lista con algunos de los que considero los “Amateur Killers” más peligrosos, que provocan gran parte de los fracasos en grupos amateurs. La idea es que pueda servir un poco como un “bestiario”, a tener en cuenta de antemano si se está pensando en organizar un grupo amateur y hacer un videojuego:

Tecnología y proyecto:

• Subestimar la complejidad: Por falta de experiencia con la tecnología, se subestima el tiempo que se tardará en el desarrollo y se desconocen los problemas que pueden surgir y como afrontarlos. Cuando, más adelante, se da esa situación, el sentimiento de estar en un túnel sin salida provoca frustración. Probablemente el #1 Amateur Killer de todos los tiempos.
• Featuritis: Intentar añadir todas las características técnicas que están de moda en la mayoría de juegos, solo por el placer de añadirlas, sin que estas aporten nada significativo al resto del juego. Alarga el tiempo de desarrollo, provoca problemas de complejidad, etc…
• Falta de experiencia con herramientas: La mayoría de integrantes de grupos amateurs aún están aprendiendo a manejar sus respectivas herramientas, por lo que su trabajo es mas lento y de menor calidad que el de un profesional, lo que lleva a desarrollos más largos y tortuosos.
• Complejidad creciente: En un punto del proyecto, la complejidad para añadir nuevas características se dispara. Normalmente debido a una mala decisión en la fase de diseño que no se detecta hasta que es demasiado tarde.
• Bloqueos en las “pipelines”: El proceso de producción de contenidos no está bien definido. Se producen problemas al tratar de incorporar esos contenidos al juego, lo que a su vez provoca más trabajo, correcciones, retrasos, y frustración en el grafista que tiene que volver a hacer un modelo desde cero.
• Falta de especificación de tareas: Las tareas que se encargan a un miembro del grupo no están bien especificadas, obligando a la persona a asumir e interpretar lo que tiene que hacer. Usualmente lo que acaba realizando no es lo mismo que lo que el coordinador del grupo tenía en mente.
• Falta de diseño: No se realiza un diseño correcto antes de empezar el desarrollo. Puede ser tanto del juego, como de la arquitectura de la aplicación. Suele resultar en problemas de falta de especificación de tareas, falta de comunicación, complejidad creciente, etc…
• Falta de planificación: La planificación de tareas fue errónea, o no hubo ninguna. Ej: un programador tiene que esperar a que otro termine una tarea que se supone tendría que haberse hecho más tarde, pero que después se descubre que era fundamental desde el principio.

Personales, de grupos, y de comunicación:

• Cambio de interés: En un desarrollo largo, es probable que los intereses personales cambien a lo largo del tiempo, y se prefiera invertir el tiempo libre en otro hobby distinto (o en otro proyecto que suena más interesante). Eso, unido a falta de motivación, puede hacer que una persona decida abandonar el barco.
• Interferencia de la vida real: Si por razones ajenas al proyecto (enfermedad, trabajo, etc…) una persona no puede dedicarle mucho tiempo, o tiene que abandonarlo completamente, puede afectar al resto del grupo.
• Falta de comunicación: Los miembros del grupo no conocen el estado completo del proyecto, las tareas no están suficientemente detalladas, el coordinador no conoce los progresos del trabajo de cada uno, etc…
• Discusiones: Común en grupos grandes, con personas jóvenes, o no muy bien organizados. Cada miembro tiene una opinión propia sobre un tema en concreto y no acepta que se actue de otra forma.
• Persona desmotivada: Una persona desmotivada dentro del grupo rompe el ciclo de reciprocidad, y puede desmotivar a los demás. Se detectan porque no aportan nada al proyecto, no se interesan por su estado, no entregan trabajos a tiempo, o no responden a mails, etc…
• Entropía: Normalmente en grupos demasiado grandes. El esfuerzo extra asociado a la comunicación y coordinación del equipo se hace tan grande que empieza a afectar negativamente a la productividad.
• Cargos no necesarios: Tener dos escritores del guión del juego, cuando el juego es un arcade, y no se tiene aún ningún grafista. Suele venir por falta de experiencia y desconocimiento de qué va a ser necesario realmente durante el desarrollo. Provoca tener grupos demasiado grandes, con todos los problemas asociados.
• Falta de feedback: Los integrantes del grupo no ven que su trabajo sirva para algo. No hay resultados visibles que indiquen un progreso. Los grafistas no ven sus modelos en el juego, los diseñadores no ven sus ideas implementadas, etc… Normalmente causado por problemas de complejidad, retrasos, y similares.
• Incapacidad de adaptarse a la “velocidad de crucero”: Al empezar un desarrollo, todo el mundo está ilusionado con el proyecto. Al pasar el tiempo, esa ilusión decae y se entra en la “velocidad de crucero” que se mantendrá durante el resto del desarrollo. La ilusión inicial debe suplirse con mecanismos de comunicación, feedback, etc… Si no, la motivación puede seguir cayendo.
• Grupo desorganizado: No existe una jerarquía interna clara. No se sabe bien con quién se debe hablar cuando aparece un problema, o no se comprende la especificación de algo. No se sabe quien tiene la última palabra en tomar una decisión. Provoca falta de comunicación y discusiones.
• Democracia: Se entiende que todos los miembros del grupo tienen la misma importancia a la hora de tomar una decisión, y todos pueden opinar. Funciona en grupos pequeños, pero en grupos grandes provoca lentitud de comunicación, desorganización, y discusiones sobre detalles que no tienen importancia real.
• Falta de liderazgo: No se cuenta con una persona (o varias) con experiencia suficiente como para actuar como coordinadores, tomar las decisiones, y ayudar a los demás miembros del grupo con los problemas que puedan aparecer.

Desde luego estos no son todos los existentes, solo los que he considerado más comunes en la mayoría de casos (y aun así, seguro que me dejo varios). Algunos de ellos, como la interferencia de la vida real, no pueden ser simplemente evitados, sino que lo único que se puede hacer es intentar reducir su efecto en el caso de que ocurran, o intentar reducir las probabilidades de ello.

La mayoría de estos riesgos están provocados por la falta de experiencia, y la única manera de poder evitarlos por lo tanto es tener experiencia, que solo se gana a costa de caerse unas cuantas veces y aprender a base de los golpes donde están esos obstáculos y como evitarlos. Por eso incluso los primeros proyectos fracasados que todos tenemos sirven como aprendizaje para el futuro.

O si no, que levante la mano quien no haya intentado hacer un Doom, Quake, MMORPG, o cualquier otro juego de moda en el momento en que empezara en el mundillo

 

———————–
FUENTE: DevZing

Advertisement