Un registro RAID mantiene separadas cuatro clases de información: riesgos, supuestos, problemas y dependencias. En una pizarra compartida se convierte en un mapa que puede revisarse, no en otra hoja interminable. El equipo ve qué cambió, quién coordina la respuesta y cuándo volver a revisarlo.
Al planificar un proyecto en Boardmix, sitúa los cuatro registros junto al hito al que afectan. Consulta la guía de matriz de riesgos cuando necesites valorar probabilidad e impacto. Las cuatro categorías se complementan y no todo supuesto es un riesgo rojo.
Define los cuatro registros RAID
Un riesgo es un evento futuro posible; un supuesto es algo que el plan trata como cierto; un problema ya está ocurriendo; una dependencia es una condición o entrega externa. Si la evidencia contradice un supuesto, registra el problema resultante y vincúlalo con el supuesto original.
| Registro | Ejemplo | Primera pregunta |
|---|---|---|
| Riesgo | La revisión de seguridad podría retrasar la versión candidata. | ¿Qué respuesta lo reduce? |
| Supuesto | El formato de exportación actual bastará para el piloto. | ¿Qué evidencia lo confirmaría? |
| Problema | Dos cuentas de prueba no acceden al tablero. | ¿Quién coordina la solución? |
| Dependencia | Otro equipo debe publicar el esquema de API. | ¿Qué entrega y fecha hacen falta? |
Usa un formato de tarjeta consistente
Registra una frase breve, la evidencia, la persona que coordina, el estado, la respuesta y la fecha de revisión. «La exportación está bloqueada» es menos útil que «El piloto necesita CSV, pero el archivo exportado no contiene cabeceras». El contexto permite decidir si debe cambiar la categoría o el estado. La persona responsable coordina el siguiente paso; no tiene que resolverlo todo por sí sola.
Copia estos campos en cada tarjeta: ID y categoría · descripción · evidencia o fuente · responsable · estado · siguiente acción · fecha de revisión · elementos relacionados. Marca los datos desconocidos como «por confirmar» y asigna su comprobación. Un espacio vacío no permite saber si falta información o si alguien olvidó rellenarlo.
Conecta los elementos con el plan
Coloca cada elemento junto al hito, historia o decisión que puede afectar. Traza conectores solo cuando la relación sea directa y añade una etiqueta. Si un riesgo se convierte en problema, conserva la frase original y añade la evidencia observada. Cuando se valide un supuesto, guarda la evidencia antes de retirarlo del registro activo.
El ejemplo muestra un portal de informes preparado para cinco clientes piloto. A1 supone que CSV se ajustará a su trabajo. Una exportación de prueba revela I2: faltan las cabeceras de las columnas. Ese defecto no demuestra por sí solo que CSV sea un formato inadecuado. Mantén A1 pendiente hasta que un cliente revise una muestra corregida y usa I2 para seguir el defecto observado.
| Elemento | Evidencia y estado | Responsable y siguiente comprobación | Condición de cierre |
|---|---|---|---|
| R1 — La revisión de seguridad podría superar el 18 de mayo | La cita aún no está confirmada; el retraso no se ha producido. | Coordinación de la entrega: reservar la revisión y comprobar su estado en la próxima reunión. | Se confirman la fecha y la persona revisora, o se modifica el plan. |
| A1 — CSV sirve para el piloto | Pendiente de que un cliente compruebe una muestra utilizable. | Coordinación del piloto: organizar la revisión de la muestra tras corregir I2. | El cliente puede usar la muestra para la tarea prevista. |
| I2 — El CSV exportado no tiene cabeceras | El archivo de prueba muestra el defecto; el problema sigue abierto. | Priya: coordinar la corrección y repetir la prueba con el esquema D2. | Una nueva muestra incluye las cabeceras esperadas y queda adjunta al registro. |
| D2 — El equipo de plataforma entrega el esquema | La corrección depende de un esquema acordado. | Contacto de plataforma: confirmar la versión y la fecha de entrega antes de repetir la exportación. | La muestra exportada coincide con el esquema acordado. |
Etiqueta la conexión de D2 a I2 como «esquema necesario para corregir» y la de I2 a A1 como «muestra corregida necesaria para validar». Antes de utilizar el tablero, añade las personas y fechas reales. Que una fecha de revisión haya pasado exige comprobar el estado; no significa que el elemento esté resuelto.
Realiza una revisión RAID enfocada
- Lee el resultado del proyecto y el periodo.
- Revisa primero los problemas nuevos.
- Comprueba las dependencias con entregas próximas.
- Contrasta los supuestos con evidencia reciente.
- Elige una respuesta o comprobación para cada riesgo.
- Confirma responsable, fecha y decisiones abiertas.
Usa los comentarios para preguntas sobre una tarjeta y el texto o las notas para mantener el registro actual. En Boardmix puedes organizar las cuatro áreas con formas y conectar los elementos relacionados. El equipo decide y actualiza los estados; una conexión dibujada no los cambia automáticamente.
Mantén útil el registro
Archiva lo resuelto sin borrar la razón importante. Si un elemento reaparece, cambia la respuesta o revisa su categoría.
Abre un tablero de Boardmix, crea las cuatro áreas y copia los campos de la tarjeta. En el portal del ejemplo, la siguiente revisión debe recoger el esquema acordado, el archivo corregido por Priya y la comprobación del cliente. Cierra I2 cuando se solucione el defecto y A1 solo cuando termine su validación.
