Imagina una actualización de catálogo que salió a tiempo: pero el equipo tuvo que rehacer parte de la carga porque recibió precios en dos formatos. Una retrospectiva de proyecto sirve para entender dónde se duplicó el trabajo y elegir un ajuste que el equipo pueda probar en la siguiente entrega.
Recoge hechos antes de la reunión
Antes de reunir al equipo, dedica tiempo a documentar qué pasó realmente. Esto reduce discusiones sobre la memoria y permite que la conversación se enfoque en por qué ocurrió y qué cambiar.
Busca documentos que ya existen: correos de cambios de alcance, reportes de estado, registros de entregas, listas de tareas completadas, registros de reuniones con clientes, cambios en presupuesto o cronograma. Si usas herramientas de gestión de proyectos, extrae un resumen de hitos, fechas reales versus planeadas y tareas bloqueadas. Si trabajas con hojas de cálculo, reúne las versiones finales que muestren qué se entregó.
No necesitas todo perfecto. Un acta de reunión donde quedó registrado un cambio, un correo de confirmación de entrega o una captura de pantalla de un problema resuelto son suficientes.
Escribe lo que pasó, no lo que crees que pasó. «El cliente pidió cambios en el diseño el 15 de mayo» es un hecho. «El cliente no sabía lo que quería» es una interpretación. Cuando escribas, separa claramente:
- Qué se planeó (fecha, alcance, recursos)
- Qué cambió durante la ejecución (fechas, alcance, personas, herramientas)
- Qué se entregó (fecha, calidad, conformidad con el plan)
- Qué problemas surgieron (bloqueos, dependencias, recursos faltantes)
Usa fechas exactas, números y nombres de tareas o entregables. Evita palabras como «siempre», «nunca» o «todos». Esto ayuda a que la reunión no se convierta en un debate sobre percepciones.
Haz preguntas sobre el proceso y sus resultados
Durante la retrospectiva, tu rol es facilitar, no acusar. Las preguntas abiertas permiten que el equipo reflexione sin ponerse a la defensiva.
Diferencia entre hechos, hipótesis y efectos
Empieza con lo que documentaste:
- Hecho: «Recibimos los precios en dos formatos diferentes: algunos en PDF y otros en hojas de cálculo.»
- Hipótesis: «Pensamos que pasó porque el proveedor cambió de sistema o no recibió las instrucciones claras.»
- Efecto: «Tardamos dos días extra comparando y consolidando los datos antes de cargar el catálogo.»
Pregunta al equipo: ¿Por qué creen que pasó esto? ¿Qué señales nos faltaron? ¿Quién más se vio afectado? No busques quién cometió el error. Busca qué en el proceso permitió que el error ocurriera.
Ejemplo de retrospectiva tras actualizar un catálogo
Siguiendo el ejemplo del catálogo, Operaciones actualizó el catálogo interno con los precios que Comercial había recopilado.
El plan era recibir los precios del proveedor en un archivo estándar, validarlos y cargarlos al sistema. Pero cuando llegó el archivo, la mitad de los precios venía en un PDF escaneado y la otra mitad en una hoja de cálculo. Nadie había pedido un formato específico al proveedor ni había un paso de revisión antes de cargar.
El equipo pasó dos días manualmente consolidando los datos. El equipo mantuvo la fecha de carga usando el margen que había reservado para pruebas. En la retrospectiva revisó cómo recuperar ese margen para la próxima entrega.
En la reunión, preguntas:
- ¿Cómo llegó el archivo al equipo en dos formatos? (Respuesta: el proveedor envió un PDF porque fue más rápido, y una hoja de cálculo porque otra persona del proveedor usaba esa herramienta.)
- ¿Había un paso donde alguien debería haber validado el formato antes de que llegara al equipo? (Respuesta: no, no estaba documentado.)
- ¿Qué señal nos habría alertado antes? (Respuesta: si el proveedor hubiera confirmado el formato con anticipación, o si hubiera un correo de confirmación de cómo enviar los datos.)
Ahora tienes un hallazgo claro: faltó una comunicación escrita con el proveedor sobre el formato esperado y un paso de validación antes de que los datos llegaran al equipo técnico.
Convierte un hallazgo en un experimento
En lugar de decir «el próximo proyecto usaremos un formato estándar», diseña un cambio específico que puedas medir.
Primero, decide qué funcionó. Tal vez el equipo se comunicó rápido, o la herramienta de seguimiento fue útil, o los cambios se documentaron bien. Nombra eso explícitamente y comprométete a mantenerlo. «Seguiremos usando el correo de confirmación de cambios porque permite que todos vean el historial.»
Diseña un cambio medible con dueño y fecha
Ahora el experimento:
- Cambio: El referente de Comercial enviará una plantilla con el formato acordado y pedirá una muestra antes de recibir el archivo completo.
- Dueño: El referente de Comercial confirma la muestra y Operaciones anota el resultado de la prueba.
- Señal observable: Antes de recibir el archivo completo, Operaciones podrá importar una muestra en el formato acordado. En la entrega siguiente se anotará si hizo falta convertir otro archivo a mano.
- Fecha de revisión: En el próximo proyecto similar, revisamos si esto funcionó.
No es una regla permanente ni una obligación. Es un experimento. Si funciona, lo mantienes. Si no, pruebas otra cosa.
Revisa en la siguiente entrega si el cambio ayudó
Dos semanas después, cuando el equipo reciba datos del proveedor nuevamente, observa:
- ¿Llegó el archivo en el formato esperado?
- ¿Cuánto tiempo tardó el equipo en validar y cargar?
- ¿Hubo preguntas del proveedor que la plantilla de correo respondió?
- ¿Surgieron otros problemas que no anticipaste?
Documenta los resultados en la siguiente retrospectiva. Si la plantilla resolvió la dificultad, propón mantenerla para la siguiente actualización del catálogo. Si no, pregunta por qué: ¿el proveedor no la leyó? ¿Necesitaba más detalles? ¿Otro factor bloqueó el proceso?
Cómo dejar constancia del experimento
En las notas, registra el hallazgo, el cambio que van a probar, quién lo coordina y cuándo revisarán el resultado. Si hay que formalizar la aceptación del catálogo, usa el registro de entrega y deja las observaciones de la retrospectiva en las notas del equipo.
Una agenda de 45 minutos para conducir la conversación
Si es la primera retrospectiva del equipo, puedes usar esta distribución como punto de partida. Reserva cinco minutos para recordar la entrega que van a revisar y las reglas de participación; diez para reunir observaciones; quince para analizar un problema; diez para acordar una prueba y cinco para confirmar responsables y seguimiento. Ajusta los tiempos al tamaño del grupo. Una incidencia que requiere una investigación propia no se resuelve alargando indefinidamente esta reunión.
Antes de abrir el debate, deja unos minutos de escritura individual. Pide a cada persona que anote algo que ayudó, una dificultad y una pregunta pendiente. Después, agrupa las observaciones relacionadas. Así evitas que la primera opinión determine toda la conversación y das espacio a quienes necesitan ordenar sus ideas antes de intervenir.
Cuando haya varios problemas, elige uno considerando su efecto sobre el trabajo, la frecuencia con que aparece y la posibilidad de cambiarlo. Una molestia muy comentada puede tener menos impacto que una aprobación que retrasa todas las entregas. Si el cambio depende de otra área, registra quién consultará con ella y qué respuesta necesitan antes de comprometer una fecha.
Cómo salir de una discusión sin acuerdos
Si alguien dice que «Comercial siempre entrega tarde», pide una entrega concreta, su fecha acordada y la fecha en que estuvo disponible. Pregunta también qué necesitaba Comercial para cumplir. El propósito es reconstruir la secuencia: un retraso puede empezar en una autorización anterior, en un requisito ambiguo o en una dependencia que nadie había registrado.
Si dos personas recuerdan hechos distintos, anota ambas versiones y el documento que permitiría contrastarlas. No conviertas una votación en una prueba de lo ocurrido. Puedes avanzar con otro punto mientras una persona comprueba el registro. Cuando falten datos, el primer acuerdo puede ser empezar a recogerlos en la siguiente entrega.
Evita cerrar con una lista de diez mejoras sin tiempo asignado. Es preferible probar un cambio pequeño, acordar quién lo hará y dejar claro qué tarea se ajustará para que tenga espacio. Pregunta al responsable si puede asumirlo y qué apoyo necesita. Si no hay capacidad, reduce la prueba o posponla con una fecha de revisión.
Registro breve para dar seguimiento
Copia estos campos en el documento del proyecto: problema observado, evidencia disponible, cambio propuesto, responsable, apoyo necesario, primera entrega donde se probará y fecha de revisión. Añade después el resultado y la decisión: mantener, ajustar o abandonar. Este registro permite que quien no estuvo en la reunión entienda por qué se acordó el cambio.
Al revisar el resultado, compara entregas similares. Procesar menos filas o trabajar con un proveedor distinto puede explicar una mejora aparente. Anota esas diferencias antes de atribuir todo al nuevo procedimiento. Si la prueba no ayudó, conserva el aprendizaje: qué se intentó, qué ocurrió y qué harían diferente. La retrospectiva resulta útil cuando cambia una decisión del trabajo siguiente.
Referencias y lecturas relacionadas
El ejercicio de retrospectiva de Atlassian propone revisar lo ocurrido y decidir mejoras para el siguiente trabajo. Ver la fuente.
La guía británica de revisión de entregas distingue hechos que ya requieren atención de riesgos futuros. Esa separación ayuda a ordenar lo que el equipo trae a la conversación. Ver la fuente.
También puedes consultar cómo redactar un acta de reunión.
