Resultado de evaluación de riesgos

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.

172 búsqueda de materiales de referencia de calidad, foros de UE5 y tutoriales de confianza.

Además de eso, durante todo el proyecto se fueron incorporando nuevos contenidos y estudiando nuevas funcionalidades. Sin dudas, tal como lo habíamos anticipado en un principio, este tipo de proyectos implican una búsqueda constante de funcionalidades y métodos dentro del ambiente de desarrollo.

Nuevos integrantes

Este fue un riesgo que sobrestimamos en un inicio. Al participar de las clases de FCD en conjunto con el equipo original, el nuevo miembro no tuvo ningún inconveniente en integrarse al equipo y comenzó a trabajar como uno más inmediatamente. Como también conocía la historia, pudo incluso participar en los últimos retoques de la misma y realizarles algunos ajustes a detalles que los miembros del equipo no habían considerado. En conclusión, la incorporación fue muy positiva por lo que no representó un riesgo tan alto como habíamos considerado en un principio.

No adaptarse a UE5

Si bien este riesgo estuvo presente, consideramos que fue evaluado correctamente al inicio. Representó un riesgo de impacto muy alto, pero la probabilidad de producirse no era alta ya que tanto desarrolladores como artistas lograron adaptarse al ambiente de desarrollo. Se definió el riesgo era muy alto ya que de no haber sido así, hubiésemos tenido que optar por otro entorno y eso hubiese llevado a frustraciones además de un tiempo muy importante perdido en conocer un nuevo ambiente de trabajo. Los desarrolladores encontraron en UE5 un desafío de programar de una manera innovadora y desafiante que los mantuvo motivados desde el inicio al fin de la etapa de desarrollo.

Estimación realizada incorrectamente

En este aspecto, consideramos que el riesgo sí se cumplió y probablemente lo deberíamos haber considerado con una prioridad muy alta. Lamentablemente, vemos que tanto en este proyecto como en la industria de los videojuegos el tema de la estimación de los tiempos es un desafío. Por un lado, porque los artistas no están tan

173 acostumbrados a seguir procesos de desarrollo, metodologías ágiles y gestionar formalmente sus proyectos. Por el otro, porque más que trabajar con fechas y tiempos acordados, lo que finalmente marca las pautas es el alcance real del trabajo. Sin embargo, hacia el final del proyecto los compañeros de arte lograron definir el alcance del corte vertical (hasta el día 3) y acordar hasta dónde acordábamos seguir trabajando.

Esto facilitó bastante la última parte del proyecto ya que la fecha de entrega final era fija, limitándonos el tiempo de retrabajo.

Falta de dedicación

Se definió este riesgo ya que, en todo proyecto y en especial en proyectos académicos heterogéneos, la posibilidad de que distintos integrantes dediquen más o menos tiempo para el proyecto es una variable a tener en cuenta. Para mitigar este riesgo se definió un tiempo de dedicación mínimo semanal, y también se acordó entre todos los integrantes que, si uno dedicaba más tiempo en una semana porque tenía tiempo disponible, o porque le resultaba necesario para una actividad puntual, no iba a tomar eso en contra para los otros integrantes del equipo. Este pacto se estableció muy al inicio del proyecto y se buscó no sólo respetarlo individualmente, sino también ayudar al resto a respetarlo cuando no lo estaban haciendo.

Interdisciplinaridad del equipo

Si bien en algún momento se generó algún roce por la falta de entendimiento de lo que implicaba el trabajo de otro, estos fueron en contadas ocasiones, y dada la buena comunicación que establecimos al inicio, se resolvieron sin llegar a transformarse en problemas. Por otra parte, la diversidad en el equipo es una de las características que más nos motivó a seguir trabajando.

Mala comunicación con el tutor

La comunicación con Helena fue fluida y cálida en todo momento. Siempre nos apoyó con instrucciones claras y precisas además de feedback constructivo sobre nuestro trabajo.

No alcanzar un standard de jugabilidad aceptable al finalizar el proyecto

174 El no alcanzar un standard de jugabilidad aceptable puede tener consecuencias negativas en varios aspectos. A continuación, se detallan los problemas más importantes:

• La baja satisfacción del usuario: si los usuarios no disfrutan jugando el juego o encuentran frustrantes los controles, es poco probable que lo recomienden o vuelvan a jugarlo.

• La baja calificación en tiendas de aplicaciones: si el juego no cumple con las expectativas de los usuarios, es probable que reciba calificaciones bajas en las tiendas de aplicaciones, lo que dificultará su descubrimiento y descarga.

• Mala reputación: si el juego es de baja calidad, es probable que la reputación de la empresa (o grupo creador) se vea afectada, lo que puede hacer que los usuarios tengan menos confianza en sus futuros productos.

Mas allá de esto, se consideró que el impacto de este riesgo en nuestro proyecto, sería relativamente bajo, por ejemplo, porque el juego en una primera instancia no sería publicado en tiendas y, además, debido a que era nuestra primera experiencia en el desarrollo de videojuegos, era muy probable que el estándar de jugabilidad no se alcanzara.

Otros riesgos no considerados inicialmente

Un riesgo que no consideramos en un inicio fue el de cambios sugeridos por el profesor de arte. Aún en la recta final del proyecto, cuando estábamos en la etapa de pulido, seguían surgiendo cambios de algunas funcionalidades o mecánicas que estaban definidas y finalizadas desde etapas más tempranas del proyecto. Algunos de estos cambios impactaban en la lógica de la secuencia del juego y sin embargo se evaluó pertinente implementarlos. Como consecuencia, se aumentó el tiempo de retrabajo y se arriesgó el correcto funcionamiento del juego para la entrega final. Si bien se percibe que este tipo de práctica es habitual en los equipos de arte dada la dinámica natural con la que se trabaja, desde las buenas prácticas de la Ingeniería de Software no se recomiendan y se ven como altamente perjudiciales para la calidad del desarrollo. Una alternativa que el equipo propone (desde la experiencia en este único proyecto) es

175 evaluar y planificar la secuencia de cambios, que entendemos son necesarios, en el marco de un proceso definido.