Project

General

Profile

Riesgos y planes de contingencia

Proyecto SuiteSET3
Descripción Plantilla para proyectos basada en ReadySET y Métrica 3.
Desarrollo SuiteSET3 (desarrollo) versión 2.0.x
Plazos vigentes FECHA INICIO - FECHA FINALIZACIÓN
Fecha edición 25/06/2022

Relacionados
Referencias

Planes generales de contingencia

Riesgos catastroficos

Si ocurre un riesgo catastrófico, haremos una reevaluación honesta de la viabilidad del proyecto e involucraremos a las partes interesadas relevantes del proyecto.

Si ocurre un riesgo catastrófico cancelaremos el proyecto. Retiraremos nuestras lecciones aprendidas y cualquier producto derivado del proyecto.

No reconocemos ningún riesgo catastrófico. Si ocurre uno, fingiremos que todo está bien y esperamos que ninguna de las partes interesadas se dé cuenta.

Riesgos que consumen recursos de desarrollo.

El proyecto tiene un plazo fijo. Los requisitos son priorizados. Si perdemos tiempo, reduciremos el alcance del proyecto.

Las características especificadas son todas esenciales. Si perdemos tiempo, retrasaremos la entrega.

Si perdemos tiempo, haremos estimaciones de tiempo para las funciones restantes y nos reuniremos con los clientes para reconsiderar el alcance y la fecha de entrega.

OTRO TIPO DE RIESGO

OTRO PLAN DE CONTINGENCIA

Riesgos mayores

Nombre Descripción Probabilidad Impacto Plan Estado Propietario
Requerimientos Los requisitos solo se conocen parcialmente al inicio del proyecto. Los clientes no pueden asignar recursos suficientes para explorar los requisitos. Media Crítico para catastrófico Los requisitos se detallarán primero para los objetivos de mayor prioridad. Indicador: seguimiento de la velocidad a la que se descubren los requisitos. Contingencia: solicitar mayor esfuerzo del cliente. Ámbar Requisitos de plomo
Metas Los objetivos de los interesados ​​pueden entrar en conflicto. Media Crítico Mantenga una lista explícita de los objetivos de las partes interesadas. El gerente del proyecto reportará el progreso a cada meta declarada. Verde Clientes
Comunicación Problemas de comunicación en el equipo de desarrollo. Están dispersos entre varios sitios y no han trabajado juntos antes. Media Crítico Utilice estas herramientas para ayudar a la comunicación. El principal indicador de falta de comunicación serán los defectos de software detectados por nuestra actividad de control de calidad . Verde QA plomo
Aceptación El cliente puede aceptar la entrega del sistema aunque realmente no cumpla con sus objetivos. Media Crítico Se solicita a los clientes que declaren los criterios de aceptación a medida que se planifica cada lanzamiento. Verde Clientes
Alcance Las características totales solicitadas pueden ir más allá de lo que el equipo de desarrollo puede ofrecer en el tiempo disponible. Alta Marginal Asignar niveles de importancia a los casos de uso. Haga la primera revisión del alcance del proyecto después de 12 meses. Verde Clientes

Riesgos menores

Nombre Descripción Probabilidad Impacto Estrategia de mitigación Estado Propietario
Estimar Es posible que el equipo de desarrollo no pueda estimar el tiempo de trabajo, lo que impide que los clientes decidan las prioridades de manera efectiva. Media Marginal El equipo de desarrollo adquirirá experiencia en la estimación del trabajo y entregará las primeras estimaciones después de 12 meses. Compararemos el trabajo estimado con el trabajo real. Verde Gerente de proyecto
Retencion Algunos desarrolladores pueden dejar el proyecto antes de que termine. Media Marginal Las ubicaciones de empleo deben proporcionar apoyo para el desarrollo profesional continuo. El gerente del proyecto discutirá los objetivos de la carrera con cada desarrollador e intentará asignar las tareas de manera adecuada.  Verde Gerente de proyecto
Exactitud El sistema tal como se entregó puede tener un bajo uso debido a la falta de confianza en su corrección. Baja Catastrófico Actividad de control de calidad del estado del arte . Contingencia: detenga el desarrollo de nuevas instalaciones hasta que se garantice la calidad del código existente. Verde QA Lead
Usabilidad El sistema tal como se entregó puede tener un bajo aprovechamiento debido a la poca facilidad de uso.  Baja Crítico Tendremos una guía de estilo UI. La mayor parte del desarrollo de la interfaz estará en estrecho contacto con los clientes. Revisaremos la usabilidad más adelante en el proyecto. Verde Diseño de interfaz de usuario
Deseo Es posible que los requisitos establecidos no coincidan con los deseos y ambiciones de los clientes para el sistema. Baja Crítico La entrega incremental de versiones proporcionará experiencia en el uso del sistema, lo que ayudará a los clientes a identificar los requisitos reales. Indicador: un desarrollador que dice "Creo que quieren decir ...", un cliente que dice "Ellos saben lo que quiero decir". Contingencia: solicitar al cliente la revisión de los requisitos. Verde Clientes
Cambios Una vez que los requisitos se han documentado y acordado, las actividades de desarrollo comienzan a basarse en ellos, primero el diseño y luego la implementación. Si los requisitos cambian más tarde, entonces el esfuerzo se desperdicia.  Baja Crítico Se requiere un procedimiento de control de cambios, por lo que los cambios solo se realizan cuando el costo vale la pena. Indicador: comparar costo de cambio a nuevo desarrollo. Contingencia: solicitar al cliente la revisión de los requisitos.  Verde Gerente de proyecto
Proceso Algunos desarrolladores pueden no cooperar en estándares y procesos comunes. Baja Crítico Control de calidad para verificar el cumplimiento, luego discusiones en las reuniones del equipo de desarrollo para cambiar el estándar o la práctica real según corresponda. Verde QA Lead
Mantenibilidad El sistema tal como se entregó puede ser difícil de mantener. Baja Marginal Revisaremos el código de mantenibilidad.  Verde Desarrollador principal
RIESGO DE UNO A TRES PÁRRAFOS PROBABILIDAD IMPACTO DE UNO A TRES PÁRRAFOS ESTADO PERSONA

Valores posibles para "Probabilidad"

  • Baja: ...
  • Media: ...
  • Alta: ...

Valores posibles para "Impacto"

  • Insignificante: ...
  • Marginal: ...
  • Crítico: ...
  • Catastrófico: ...

Valores posibles para "Estado"

  • Rojo: Proyecto activo e impactante.
  • Amarillo: Activo pero contenido sin impacto al alcance o tiempo de entrega.
  • Verde: Aún no activo.

Gestión de riesgos

Esto viene originalmente del plan de proyecto (hay que revisarlo y adaptarlo a este formato):

# RIESGO ACCIONES PARA EVITARLO/RESOLVERLO
1

Existe un conflicto potencial entre los objetivos de una apariencia con calidad y otra completamente personalizable.

Solo podemos tener éxito si los jugadores encuentran atractivo el sitio web, y los proveedores de juegos pueden personalizarlo sin más esfuerzo del necesario. Ya tenemos un diseño en mente que permitirá resolver este problema y lo revisaremos con un diseñador con experiencia en sitios para juegos.

2

Existen importantes dificultades técnicas para construir un sitio web y una aplicación web. Esto se debe a que sólo una persona de nuestro equipo es la que tiene experiencia en herramientas y tecnologías relevantes. Aunque el resto aprenda seguramente cometerán errores.

Resolveremos esto analizando el proyecto para tener una ventana de tiempo lo suficientemente grande para revisar y corregir el diseño y la implementación.

3

El tiempo con el que se cuenta es poco.

Manejaremos este problema planificando un core funcional en el tiempo marcado y se añadirán otras funcionalidades en futuras versiones si es necesario.

4

El rendimiento del sistema se verá significativamente afectado por las decisiones tomadas durante la tarea de diseño de la base de datos. Ninguno de los miembros de nuestro equipo actual tiene experiencia con la optimización de bases de datos.

Para solucionar esto, programaremos una reunión para revisar el diseño con un administrador de bases de datos (DBA) con experiencia, o contrataremos un consultor del proveedor de la base de datos.

5 Podríamos estar subestimando algunas tareas conocidas. ¿CÓMO EVITARLO/RESOLVERLO?
6 Podríamos estar subestimando el impacto de algunas tareas desconocidas. ¿CÓMO EVITARLO/RESOLVERLO?
7 Podríamos estar subestimando las dependencias entre tareas. ¿CÓMO EVITARLO/RESOLVERLO?
8 Podríamos haber entendido mal los requerimientos del cliente. ¿CÓMO EVITARLO/RESOLVERLO?
9 El cliente podría cambiar los requerimientos. ¿CÓMO EVITARLO/RESOLVERLO?
10 Podríamos encontrarnos con dificultades importantes con la tecnología seleccionada para este proyecto. ¿CÓMO EVITARLO/RESOLVERLO?
11 Podríamos tener una calidad baja que necesite revisiones considerables. ¿CÓMO EVITARLO/RESOLVERLO?
12 Podríamos evaluar incorrectamente nuestro progreso hasta que sea demasiado tarde para reaccionar. ¿CÓMO EVITARLO/RESOLVERLO?
13

Podríamos perder recursos. Por ejemplo, los miembros del equipo podrían enfermar, dedicar tiempo a otros proyectos o renunciar.

¿CÓMO EVITARLO/RESOLVERLO?
14 Puede haber una desalineación entre los objetivos o expectativas de los interesados. ¿CÓMO EVITARLO/RESOLVERLO?

Lista de comprobación de riesgos

¿Los planes proporcionan un indicador para detectar cada uno de los riesgos que se activan?

Sí, si todas las actividades se llevan a cabo según lo planeado, sabremos si alguno de los riesgos se está convirtiendo en un problema.

No, algunos riesgos podrían acecharnos.

¿Se asignan los "propietarios de riesgo" correctos para monitorear los riesgos?

Sí, para cada riesgo, el propietario asignado puede detectar el indicador, puede iniciar el plan de contingencia y es la persona que sufrirá el riesgo.

No, en algunos casos, el propietario asignado puede no notificarlo o cuidarlo, o no tiene la autoridad suficiente.

¿Cada riesgo tiene una estrategia de mitigación o el riesgo es aceptable?

Sí, tenemos planes para controlar cada riesgo.

Sí, tenemos planes para controlar algunos riesgos y hemos aceptado otros.

No, este plan deja abiertos varios riesgos.

¿Cada riesgo tiene un plan de contingencia?

Sí, el tiempo de desarrollo de costos de la mayoría de los riesgos y el plan general se aplica, y para cada uno de los otros hay un plan de contingencia arriba.

No, hay algunos riesgos que aún tenemos que planificar.

¿Se ha comunicado este Plan de Control de Riesgos al equipo de desarrollo y otras partes interesadas?

Sí, este documento se está publicando en el sitio web del proyecto. También se discutirá en una reunión temprana del equipo y se discutirá con los clientes antes de comprometerse con el proyecto. Los comentarios son bienvenidos.

No, nuestra cultura no permite la discusión de riesgos.

¿Existe algún procedimiento para identificar nuevos riesgos y revisar los existentes?

TBD

A la luz de estos riesgos, ¿vale la pena realizar el proyecto?

Sí, es un proyecto de bajo riesgo.

No, otros proyectos pueden ofrecer tanto valor con menos riesgo.

Sí. Es un proyecto inusualmente arriesgado según los estándares comerciales, pero creemos que tenemos planes adecuados aquí, considerando el valor que el proyecto podría ofrecer.

¿Existe un canal de informes anónimos para permitir que los desarrolladores comuniquen sus inquietudes a la alta gerencia?

No, todo depende del estado de alerta y la fuerza de carácter del gerente del proyecto.