En una prueba del catálogo, un código que empieza con cero aparece cambiado al abrir el archivo. La carga definitiva todavía no se ha hecho. Ese es un buen momento para avisar de un riesgo en un proyecto: hay un hecho que mostrar y margen para pedir una prueba antes de decidir.
Distingue un riesgo de un problema que ya ocurrió
El cero que desapareció en la prueba es un problema observado en esa prueba. Que ocurra lo mismo el jueves, con el catálogo completo y la configuración prevista, es el riesgo. Esa distinción te permite contar lo que sabes sin dar por hecho que la entrega se retrasará.
La misma situación puede cambiar de estado. Si la carga ya se hizo y el catálogo muestra códigos incorrectos, hay una incidencia que atender. Si todavía estás preparando el archivo, puedes comprobar el comportamiento y acordar una condición para seguir. Anota en qué versión apareció el problema: quien revise el caso necesitará repetir la prueba sobre el mismo archivo o saber qué cambió desde entonces.
Describe qué observaste y qué podría pasar
El hecho que puedes mostrar
En este ejemplo ficticio, el archivo de origen contiene el código «00452». Al abrir una copia de trabajo, una de las herramientas lo muestra como «452». Guarda ambos ejemplos y apunta el paso en el que viste la diferencia. Si aún no sabes dónde se cambió el valor, dilo así. Eso permite investigar sin culpar al equipo que preparó el archivo.
El impacto y la señal para actuar
Si la carga usa el código recortado para identificar productos, podría omitir una ficha o vincularla a otra. El impacto depende de cómo se comparen los códigos en el destino. Por eso conviene pedir a quien administra la carga que revise el valor guardado, además de lo que se ve en pantalla.
La señal para detener la preparación sería que la prueba vuelva a producir códigos distintos a los de origen o que queden fichas sin correspondencia. Una prueba satisfactoria da evidencia para decidir, dentro de las condiciones que realmente se probaron.
Ejemplo de aviso antes de la carga de un catálogo
En la prueba de hoy, el código 00452 se mostró como 452 al abrir la copia para carga. El archivo de origen conserva los ceros. Si el valor recortado llega al catálogo, podríamos perder la relación con la ficha correcta. ¿Podemos probar mañana en el entorno de prueba con códigos que empiezan con cero y con un par que ya funcionan? Necesito que quien valida la carga confirme antes del mediodía si podemos mantener la fecha del jueves o debemos moverla.
El mensaje dice qué ocurrió, por qué afecta a otra tarea y quién tiene que decidir. En el registro, agrega el enlace interno al archivo de prueba y anota la versión. Si hace falta compartir una captura, muestra los campos necesarios para reproducir el caso y deja fuera datos que el destinatario no necesita.
Propón una decisión y un punto de revisión
Antes de escribir «hay que retrasar el catálogo», presenta opciones que quien decide pueda comparar:
- Conservar la fecha si se valida el archivo. El equipo comprueba que los códigos se mantienen idénticos desde el origen hasta el destino y registra el resultado antes del corte.
- Separar una entrega parcial si el flujo lo permite. El responsable de la entrega confirma si un grupo de fichas puede publicarse por separado, cómo se identificará y cuándo revisará el resto.
- Mover la carga si persiste la duda. El equipo informa qué sigue sin verificar y propone una nueva fecha después de acordar cómo probarlo.
Evita arreglar el archivo quitando ceros sin consultar. El código identifica una ficha y cambiarlo podría crear una coincidencia incorrecta. Si el equipo decide modificar la importación, repite la prueba sobre la versión que se usará para la carga.
Actualiza o cierra el aviso cuando cambie la evidencia
Si la prueba reproduce el fallo, actualiza el registro con los códigos afectados y pide una decisión sobre la carga. Si el equipo corrige el formato, revisa que la corrección mantenga los valores originales. También conviene probar un caso que antes funcionaba para detectar efectos inesperados.
Si la prueba pasa, registra las condiciones verificadas, quién confirmó el resultado y qué decidió sobre la fecha. Si queda un tipo de ficha sin probar, déjalo visible en el registro. Puedes cerrar el aviso cuando la persona a cargo confirma que se cumplieron las comprobaciones acordadas y el equipo ya sabe qué sigue.
Para llevarlo a una hoja de seguimiento, usa estos campos: observación, consecuencia posible, prueba propuesta, responsable, momento de decisión y estado. Si el estado cambia, actualiza esa fila y avisa a quienes necesitan modificar su plan.
Referencias y lecturas relacionadas
La guía británica de revisión de entregas recomienda distinguir los riesgos de los problemas y documentar cómo se atenderán. Ver la fuente.
El ejercicio de premortem de Atlassian parte de imaginar qué podría fallar. Aquí lo puedes usar para elegir qué caso reproducir en una prueba pequeña. Ver la fuente.
También puedes consultar cómo informar un retraso en el trabajo.
