Planificación de los riesgos

167 6.3.5 Disponibilidad del equipo

168

Riesgo Tipo de riesgo Impacto Probabilidad Valoración del riesgo

Feature creep Construcción Muy Alto Muy Alta 0.64

Ambiente de desarrollo Construcción Muy Alto Muy Alta 0.64

Nuevos integrantes Entorno Muy Alto Alta 0.40

No adaptarse a UE 5 Entorno Muy Alto Baja 0.20

Estimación realizada incorrectamente

Construcción Alto Alta 0.20

Falta de dedicación Entorno Alto Alta 0.20

Interdisciplinaridad del equipo

Entorno Moderado Muy Alta 0.16

Mala comunicación con el tutor

Entorno Alto Moderada 0.12

No alcanzar un standard de jugabilidad aceptable al finalizar el proyecto

Construcción Muy Bajo Alta 0.04

Tabla 54 Ranking de riesgos

Para facilitar el estudio de los riesgos, los categorizaremos como: de entorno, de construcción e inherentes a este tipo de proyecto.

Como riesgos del entorno, identificamos varios que describiremos a continuación. En primer lugar, la interdisciplinaridad de los integrantes del equipo y el no conocimiento previo de los mismos. Si bien es de orden contar con diferentes conocimientos previos y experiencia en equipos de desarrollo de videojuegos, esta es la primera experiencia de trabajo entre FCD y FI de la facultad ORT, en la que los equipos se conforman con estudiantes de las distintas licenciaturas y cada integrante asume un rol específico en el equipo. Los integrantes conformaron un sólo equipo que trabajó con el mismo plan de proyecto y un objetivo común.

Otro riesgo del entorno es la falta de experiencia en programación de videojuegos y UE5 por parte de los desarrolladores. Esto representaba una curva de aprendizaje empinada para ponerse a tiro y generar la productividad necesaria y además, poder cumplir con los plazos establecidos en el proyecto.

169 Por otro lado, otro riesgo es que un compañero de la FCD se sumó luego de iniciado el proyecto y por lo tanto se tuvo que actualizar para poder integrarse.

Como último riesgo del entorno identificamos lo posibilidad de conflictos que puedan surgir tanto con los tutores como con nuestros compañeros de equipo. Estos conflictos personales pueden afectar negativamente al trabajo en equipo y hay que planificar tanto estrategias de mitigación como estar alerta a las señales que se evidencian.

Para superar estos desafíos del entorno planificamos las siguientes actividades. En primer lugar, los desarrolladores se unieron a las clases de FCD desde una etapa temprana para por un lado poder generar un acercamiento al grupo y luego participar de la etapa de diseño de la narrativa y el plan del videojuego. Asistir a estas clases sirvieron además para empaparse de la terminología, los procesos de diseño y los desafíos que se van planteando en el proceso creativo. Asimismo, se estableció un plan de comunicación entre los integrantes del equipo que se describirá más adelante. Por otro lado, los desarrolladores establecieron un plan de capacitación sobre la programación en UE5 mediante tutoriales y documentación propia de Epic Games, además de otros “mini-cursos” ofrecidos por YouTube. Si bien lleva un tiempo considerable, es vasta la documentación y los tutoriales disponibles. Por último, el compañero que se sumó más tarde al equipo, ha participado activamente de todas las clases por lo que tiene conocimientos sobre el plan del videojuego a realizarse y además fue rápidamente incorporado al equipo.

Para mitigar los problemas de comunicación con nuestra tutora, además de tener nuestras reuniones semanales, mantendremos un canal de comunicación fluido mediante el chat de la plataforma Microsoft Teams. Cualquier consulta será enviada vía chat, para disminuir malos entendidos. Con el tutor de FCD, además de las clases de los miércoles, se tiene comunicación fluida por Discord. Con respecto a la mala comunicación con los otros integrantes, además del plan de comunicación que detallaremos más adelante, se tuvo una reunión para unificar criterios, establecer reglas de trabajo y expectativas de productividad.

Un riesgo que puede tener un alto impacto es la falta de dedicación de los integrantes del equipo al trabajo del proyecto. Al ser tan pocos integrantes y los plazos tan

170 reducidos, donde alguno de los participantes no cumpla con su objetivo de 20hs semanales va a impactar en la planificación. Para amortiguar este tipo de riesgo, se realizarán controles de evolución en reuniones diarias (dailies) donde se podrá ver el avance de cada miembro del equipo. Se realizaron charlas para incentivar el no ocultamiento de problemas personales y situaciones ajenas, que pueda afectar la dedicación horaria, creando un clima de confianza y transparencia en el equipo. De todas maneras, siempre surgen imprevistos que pueden imposibilitar la dedicación de algún miembro, para este caso, se definió que el resto de los miembros del equipo sumaran de forma equitativa horas semanales adicionales, para compensar las horas de aquel integrante no pueda cumplir. De esta forma la cantidad de horas dedicadas no tendrá desvíos respecto a la planificación inicial.

Como riesgos de construcción identificamos primeramente el riesgo de la disociación que existe entre la programación y el diseño en este tipo de proyectos. Los animadores, texturizadores y diseñadores estarán utilizando herramientas externas a UE5 para realizar sus diseños. Igualmente, una vez estos diseños sean cargados a UE5 debieron combinarse con el código preparado para los programadores. Sin embargo, los diseñadores también utilizaron UE5 para terminar de ajustar sus diseños por lo que debimos trabajar todos dentro del mismo proyecto. Para esto, se decidió utilizar Github como gestor de versiones de documentación y código, además de las actividades del plan de comunicación que aseguraron un trabajo en conjunto y coordinado durante todo el proyecto.

Otro riesgo fue codificar en un lenguaje de programación de bajo nivel como lo es C++ y el manejo de memoria que conlleva su uso. Sin embargo, UE5 provee la posibilidad de programar utilizando blueprints. Este tipo de programación nodular permitió al equipo no sólo adaptarse más fácilmente a la programación 3D, sino también lograr resultados visibles más rápidamente. También el programar en blueprints tiene la ventaja de que permitió una comunicación más fluida con el resto del equipo que no sabe de lenguajes de programación, pero puede entender más fácilmente el mapa generado con blueprints.

171 Teniendo en cuenta ahora del tema de las plataformas de desarrollo y sus lenguajes, también consideramos el riesgo de realizar estimaciones erróneas por nuestra falta de experiencia en este sector de videojuegos. Para poder controlar este riesgo, de forma semanal se fueron controlando las actividades previstas para esa semana, con el objetivo de obtener de forma anticipada una métrica de evolución del proyecto, e identificar de forma temprana desvíos en la planificación y estimación de tareas.

Y para finalizar identificamos un riesgo sobre el resultado obtenido y fue que este no alcance el standard de jugabilidad aceptable para el proyecto. Para este riesgo, se definió un plan de lanzamientos “beta” en cada release del juego, para que algunas personas puedan jugar y brindar un feedback sobre el juego. Este feedback fue analizado y se ajustaron aquellos aspectos que no cambiaban el CORE del juego o su narrativa inicial, pero que si eran valiosos para los usuarios.