Riesgos y planes de contingencia¶
| Proyecto | SuiteSET3 |
| Descripción | Plantilla para proyectos basada en ReadySET y Métrica 3. |
| Desarrollo | project:suiteset3-dev versión suiteset3-dev:version#1 |
| Plazos vigentes | FECHA INICIO - FECHA FINALIZACIÓN |
| Fecha edición | 21/11/2024 |
| Relacionados | |
| Referencias |
|
- Tabla de contenidos
- Riesgos y planes de contingencia
- Lista de comprobación de riesgos
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?
Sí
No, todo depende del estado de alerta y la fuerza de carácter del gerente del proyecto.