Entre bastidores de un panel de aplicación: mostrar que un producto funciona

Nuestro segundo probador movió cuatro etapas a mano en su tablero porque la aplicación ya no lo hacía. El 26 de agosto rehímos la forma en que Maestro muestra su trabajo: diez frentes, 43 defectos corregidos y una lección que vale para cualquier panel.

Lo que hay detrás de un panel de aplicación cabe en una jornada de trabajo: el 26 de agosto de 2026 retomamos el nuestro en diez frentes y corregimos 43 defectos antes de publicarlo (nuestras notas del día). El desencadenante: nuestro segundo probador había movido cuatro etapas a mano porque nada se movía solo.

El tablero no mentía, no sabía

El defecto original estaba en un atajo. Cuando nuestro probador lanzaba la construcción desde la conversación en lugar del tablero, la orden salía sin indicar sobre qué etapa trabajar. Los agentes construían algo, pero no se escribía ningún estado, no se preparaba ninguna verificación y el tablero se quedaba en el estado del día anterior. No mostraba una mentira, mostraba lo último que le habían dicho. Trasladamos la resolución del destino al motor, en un único lugar, para que ninguna puerta de entrada pudiera saltársela. Después apareció una segunda versión del mismo defecto: cuando la verificación devolvía un veredicto «a discutir», ese veredicto no se registraba en ningún sitio, la etapa seguía en curso y cada nuevo lanzamiento de «Desarrollar todo» volvía a la misma etapa. Un bucle visto desde fuera.

Una columna que se mueve no es una prueba

Un panel que muestra columnas limpias da una impresión de control y cuesta poco de fabricar. El trabajo empieza cuando preguntas a cada casilla de dónde saca su información. En nuestro caso, tres preguntas sirvieron de filtro para todas las pantallas: quién escribe ese valor, en qué momento y qué ocurre si nadie lo escribe. La tercera respuesta es la que importa porque una pantalla nunca dice «no he recibido la información»: conserva la anterior y calla. Añadimos una prueba de actividad, un rastro de lo último que hicieron los agentes, con la hora. Un cuadrado verde no demuestra nada; una línea fechada que dice lo que acaba de ocurrir demuestra que el motor sigue trabajando. Es la misma exigencia que habíamos planteado para las notificaciones que gritaban demasiado: mostrar lo que ocurre ahora, no todo lo que ocurrió.

La mañana en que todo estaba en verde y la pantalla no aparecía

La lección más cara llegó la mañana de esa publicación. Todas nuestras verificaciones automáticas estaban en verde y la aplicación mostraba «Algo se ha roto» al abrir cualquier proyecto. Ninguna de nuestras verificaciones DIBUJA la aplicación: leen el código, no miran la pantalla. Fueron los informes anónimos de errores, los que nos envían una categoría de fallo sin el contenido de ningún proyecto, los que identificaron el componente culpable en unos minutos. Devolvimos la versión anterior a todos los usuarios en treinta segundos, corregimos y volvimos a publicar esa mañana. Desde entonces, una verificación abre la aplicación y mira si aparece la pantalla. El principio es el que detallamos en todo está en verde y, aun así, está mal: un indicador solo vale por lo que ha observado él mismo.

Decidir en el tablero, mirar en la sala de control

La visita guiada del producto se reescribió inmediatamente después, en doce etapas, alrededor de una frase de trabajo: se decide en el tablero y se mira en la sala de control. Los dos lugares no sirven para el mismo gesto. El tablero lleva tus decisiones: qué etapas existen, cuál pasa a construcción y cuál validas con «Me parece bien». La sala de control lleva el estado de la máquina: qué está funcionando, qué espera, qué falló y por qué, cuánto costó. Mezclar ambos producía una pantalla donde el usuario ya no sabía si miraba su producto o nuestro motor. Esa división coincide con lo que nuestros probadores ya habían escrito en la segunda ronda de comentarios: la mitad de las peticiones apuntaba a capacidades presentes pero invisibles.

Lo que aprendimos sobre nuestras propias pantallas

Nos quedan tres reglas de esa jornada. Un valor mostrado debe nombrar a su autor y su hora; si no, envejece en silencio. Una entrada que evita el camino principal termina evitando también sus salvaguardas, así que la lógica se resuelve en un solo lugar. Y una verificación que no mira la pantalla no dice nada de lo que ve el usuario, sea cual sea su color. Contamos 43 defectos en esa ronda, encontrados por revisores a quienes pedimos atacar el trabajo en lugar de aprobarlo; nos interesa menos el número que su naturaleza: casi todos eran diferencias entre lo que mostraba la pantalla y lo que hacía la máquina.

Hacer la prueba en tu propio panel

Abre tu herramienta de seguimiento, toma la primera línea que te tranquilice y busca quién la escribe. Si nadie sabe responder, o si la respuesta es «alguien la actualiza a mano», tienes ahí una pantalla decorativa. Añade una fecha visible de última actualización antes de cualquier otra mejora: un valor fechado que sabes antiguo te protege mejor que un valor reciente del que no sabes nada.