Saltar al contenido principal

Risk Management

MUSCLEMATE

Musclemate, Grupo 3, WPL

Historial de Versiones

VersiónFechaAutorDescripción
v1.02024-02-19Alejandro SosaCreación del documento
v2.02024-03-18Luis GarcíaActualización del documento
v3.02024-04-21Juan JesúsAñadido a Docusaurus

Riesgos

IDRiesgoProb. de ocurrenciaImpactoFactor (Prob x Impacto)Nivel de peligro
R1Ocurrencia de nueva característica post-planificaciónBajoMedio15Medio
R2Característica de el producto poco detalladaBajoAlto21Importante
R3Miembro del equipo no trabaja tanto como se comprometióMedioAlto35Catastrófico
R4Testing demuestra que el producto no supera el estándar de calidadBajoAlto21Importante
R5Disputa interna entre miembros del equipoAltoMuy bajo7Pequeño
R6Miembro del equipo desconoce una de las tecnologías a utilizarMuy bajoMedio5Pequeño
R7El equipo de un miembro del equipo se averíaBajoMuy alto27Importante
R8Ausencia notable de miembros en el equipo de front-end/back-endMuy bajoMuy alto9Pequeño
R9Miembros del equipo pierden la dirección del trabajoBajoMedio15Medio
R10El equipo de trabajo se queda sin tiempo debido a una fecha límiteBajoMuy alto21Importante
R11Aumento de precio de la licencia de un producto que utilicemosMuy bajoAlto7Pequeño
R12Falta de usuarios piloto por parte de los gimnasiosMedioMuy alto45Catastrófico
R13Caída de el servicio en el que hosteemos nuestra aplicaciónMuy bajoMuy alto9Pequeño
R14La competencia lanza un producto similar a el nuestro antes de nuestro lanzamientoBajoMuy alto27Importante
R15Comunicación ineficiente interna en el equipoBajoMedio15Medio
R16Los usuarios piloto dejan de comunicarse con los desarrolladoresBajoAlto21Importante
R17Menor uso del esperado de recursosMuy bajoMedio5Positivo
R18Hallazgo de una librería que agilice el desarrolloBajoAlto21Positivo
R19Equipo de trabajo finaliza sus tareas en menos tiempo del planificadoMuy bajoAlto7Positivo

Traducciones numéricas

  • Muy bajo = 1
  • Bajo = 3
  • Medio = 5
  • Alto = 7
  • Muy alto = 9

Plan de Contingencia (riesgos negativos)

IDPlan de Contingencia
R1Se analiza el tiempo que supondría implementar esta característica y si es viable, se puede implementar, añadiendo valor al producto.
R2El miembro del equipo que se encargue de implementar esta característica puede preguntar a el coordinador de su equipo (front-end/back-end) por más detalles.
R3Se avisará al miembro del equipo en cuestión de esta falta de trabajo. Si esta no se corrige y el miembro no dispone de un justificante tendrá una menor puntuación en la evaluación individual de rendimiento y tendrá que recuperar las horas no trabajadas en la siguiente semana. otro miembro de el equipo de trabajo deberá completar su parte.
R4El miembro del equipo que implementó la característica problemática deberá pulir la parte del código en la que se encuentra, ya que dicho miembro es el que mejor entiende el código.
R5El coordinador del equipo de trabajo (front-end/back-end) hará de mediador e intentará encontrar un punto medio en la discusión entre los miembros.
R6El miembro del equipo deberá dedicar tiempo a aprender la tecnología, ya sea mediante tutoriales o experimentando con esta. A poder ser se le asignarán tareas que no dependan de esta tecnología o se le cambiará a otro equipo de trabajo (de front-end a back-end o viceversa).
R7El miembro del equipo deberá encontrar un método alternativo para poder trabajar en sus partes asignadas. De mientras, otros miembros del equipo de trabajo con menos carga asignada deberán encargarse del trabajo de dicho miembro. No habrá penalización en la evaluación individual.
R8Miembros del equipo contrario (del equipo de front-end en el caso de back-end y viceversa) con menos trabajo asignado deberán apoyar a el equipo de trabajo para poder así acabar el trabajo de el sprint a tiempo.
R9Se realizará una reunión general en la que se discutirá el rumbo del proyecto para recordar a todos los miembros del equipo el rumbo de este, las tareas por realizar y las características aún por implementar en el producto.
R10Los miembros del equipo de trabajo deberán emplear más de sus 6 horas semanales a la asignatura para así poder asegurar que todas las tareas del sprint sean realizadas a tiempo. No se aceptará entregar tarde un elemento entregable del proyecto.
R11Si este aumento de precio es bajo, continuaremos haciendo uso de la misma tecnología, no obstante, si es notable y no podemos asumirlo, haremos una búsqueda exhaustiva de alternativas similares.
R12Deberemos pedir a nuestro grupo piloto (grupo 9) que centren sus esfuerzos en probar la parte de gimnasio de nuestra aplicación, ya que es aquella que realmente atraerá a los clientes que pagarán nuestro servicio.
R13Si la caída es corta y aislada, se continuará utilizando el mismo servicio. No obstante, si es larga o repetida, se comenzarán a investigar alternativas para el hosting.
R14Los equipos de trabajo analizarán este nuevo producto para discernir si realmente hace competencia a el nuestro y si es así, ver qué hace bien y qué hace mal para aplicar estas lecciones en nuestro producto.
R15Si esta comunicación ineficiente es exclusiva de un miembro, se realizará una llamada de atención y si el problema continúa, afectará negativamente a su evaluación individual. No obstante, si es común a un grupo de trabajo completo, se realizará una reunión donde se discutirá el problema y se tratará de hallar una solución.
R16Los equipos de trabajo tendrán que dedicar tiempo extra a encontrar nuevos usuarios piloto o a probar más la aplicación para encontrar los fallos que dichos usuarios piloto hubieran encontrado.