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, 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.
Elige a quién avisar y qué respuesta necesitas
El primer destinatario debería poder investigar el riesgo o decidir sobre la entrega. Copiar a todo el equipo no garantiza una respuesta y puede hacer que cada persona suponga que otra se encargará. En el caso del catálogo, quien administra la carga puede reproducir el error, mientras que quien coordina la publicación decide si la fecha sigue siendo viable. Son responsabilidades diferentes.
Incluye a las personas cuyo trabajo cambiaría si se confirma el riesgo. Si Comercial espera anunciar el catálogo, necesita conocer el punto de decisión, aunque no participe en la prueba técnica. No necesita recibir cada mensaje de investigación: basta con saber cuándo habrá una respuesta y quién se la comunicará.
El asunto del correo puede ser «Catálogo del jueves: validar códigos antes del miércoles a las 12». En el cuerpo, coloca primero la decisión solicitada y después la evidencia. Evita asuntos como «URGENTE» sin contexto o «problema grave» cuando aún no conoces el alcance. La urgencia debe corresponder al tiempo disponible para actuar, no a la intensidad de la preocupación.
Valora la prioridad sin inventar porcentajes
No hace falta afirmar que hay un 80 % de probabilidad de retraso si no tienes datos para sostenerlo. Explica qué se observó, cuántos casos se revisaron y qué falta comprobar. «Falló uno de los tres códigos probados; aún no conocemos cuántos registros comparten ese formato» aporta más información que una cifra aparentemente precisa.
Para decidir cuándo actuar, combina tres preguntas: ¿qué pasaría si se confirma?, ¿cuándo deja de ser reversible la decisión?, ¿qué evidencia tenemos? Un error de identificación que puede llegar a cientos de fichas merece atención antes de la carga, aunque solo haya aparecido en una prueba. Una errata en una nota interna puede corregirse en el flujo habitual si no afecta la operación.
Utiliza las categorías de riesgo que ya tenga tu organización. Si no existen, describe el efecto con palabras concretas: trabajo que habría que repetir, entrega que quedaría detenida o personas que recibirían datos incorrectos. No sumes puntuaciones elegidas al azar para producir una falsa sensación de exactitud.
Si nadie responde antes del punto de decisión
Prepara el siguiente paso antes de que venza el plazo. En el mensaje inicial puedes señalar: «Si al mediodía no tenemos la validación, llevaré la decisión al responsable de la publicación para que confirme cómo seguimos». Eso evita que el escalamiento parezca una sorpresa o una acusación personal.
Cuando llegue ese momento, resume la evidencia disponible, las consultas realizadas y la consecuencia de esperar. No escribas que la otra área «nos está retrasando» si todavía desconoces la causa. Una petición útil sería: «La prueba sigue pendiente y la carga está prevista para mañana. Necesitamos decidir entre reservar otra ventana o mantenerla condicionada a una validación previa». No cambies por tu cuenta una fecha que no puedes autorizar.
Después de la decisión, comunica el resultado al mismo grupo que recibió el aviso. Si el riesgo se descarta, dilo con el mismo cuidado con que lo planteaste. Dejar una alerta abierta en el correo mientras el registro ya está cerrado puede provocar consultas y cambios de plan innecesarios.
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.
