Esta reunión podría haber sido un video

Media hora de reunión para revisar un cambio. Alguien comparte pantalla, carga datos de prueba, explica por qué ese campo va ahí. Es la tercera vez esta semana que lo explica.

Conseguir esa media hora suele costar más que la media hora. El cambio ya está terminado y espera a que coincidan cuatro agendas.

Y cuando lo que hay que mostrar no es una pantalla sino un recorrido entero —varios pasos, datos que se cargan en cierto orden, pantallas intermedias— la reunión parece inevitable: nadie valida eso mirando una captura.

En Kleer probamos otra cosa. En vez de reunirnos para mostrar un cambio, un script recorre la aplicación como lo haría un usuario y graba el video. Cada uno lo mira cuando puede. Y como el script tiene que completar el recorrido entero, empezaron a aparecer errores que nadie estaba buscando.

¿Por qué las reuniones de revisión frenan la entrega?

Cuando un cambio no es una pantalla aislada sino parte de un recorrido largo, mostrarlo en vivo tiene un costo que se paga varias veces:

• Encontrar un horario en común retrasa la validación de un cambio que ya está terminado.
• Quien lo desarrolló repite la misma explicación tantas veces como reuniones necesita.
• La revisión queda atada al ritmo de quien mira, no al de quien la generó.
• El conocimiento del flujo completo (qué pantallas, en qué orden, con qué datos) vive en la cabeza de quien lo mostró, no en ningún lado más.

Hace poco me tocó migrar el mecanismo de seguridad de un conjunto de APIs dentro de una aplicación con años de desarrollo encima. El problema no era la API en sí, sino que formaba parte de un flujo mucho más largo: pantallas, carga de datos, pasos intermedios. Mi contraparte me pidió, con toda razón, que probara el recorrido completo antes de dar el cambio por terminado. Hacerlo a mano, clic por clic, dato por dato, atrasaba cada entrega.

Grabar el flujo en vez de explicarlo

La alternativa fue automatizar ese recorrido: un script recorre la aplicación imitando a un usuario real, ejecuta la lógica de negocio como la ejecutaría una persona, y narra cada paso con una voz generada. El resultado es un video corto (tres o cuatro minutos) que cualquiera puede mirar cuando le sirve, a su propio ritmo, sin coordinar nada con nadie.

No es solo una grabación de pantalla. El script también captura el detalle técnico de cada paso: qué API se llamó, con qué datos y qué respuesta devolvió. Así, el video sirve tanto para quien necesita entender el negocio como para quien necesita entender la implementación.

Lo que un video muestra y una reunión no

Forzar el recorrido completo, con datos reales y en el orden en que lo haría un usuario, saca a la luz problemas que un chequeo manual suele pasar por alto:

• Pantallas sin paginado que se vuelven inmanejables con más datos.
• Listas que, una vez paginadas, pierden el orden y esconden el registro más nuevo.
• Errores que se capturan pero nunca llegan a mostrarse al usuario, fallando en silencio.
• Casos donde falta contexto de negocio que el agente que ejecuta el flujo no puede resolver solo: nos señala exactamente qué conocimiento del dominio todavía no está documentado y necesitamos explicarle.

Esto no aplica solo al trabajo entre personas. Cuando dejamos una tarea a un agente de IA, revisar el resultado mirando un video corto es más rápido que entrar a la aplicación y repetir los pasos a mano para confirmar que hizo lo esperado (o que se desvió sin avisar).

Un mismo video, muchos usos

Lo interesante es que el mismo mecanismo sirve para más que la revisión de un cambio puntual:

• Comunicación interna: llegar a la reunión habiendo visto el video, para usar el tiempo en discutir la decisión en vez de en explicar paso a paso cómo funciona.
• Release notes: en vez de un documento largo, un video que explica qué cambió y por qué.
• Guías de usuario y preguntas frecuentes: se regeneran automáticamente cuando la funcionalidad cambia, así nunca quedan desactualizadas.
• Demos para clientes: recorrer la funcionalidad apoyándose en el video durante la reunión, sin perder tiempo cargando datos en vivo para llegar a la parte que importa.
• Demo permanente del producto: un video vivo en el sitio, mostrando una funcionalidad específica en cualquier momento.

Probarlo en tu propio producto

El generador es un plugin de código abierto para Claude Code. Para sumarlo a un chat, dos líneas:


/plugin marketplace add kleer-la/claude-plugins
/plugin install e2e-video-doc@kleer-la


Después alcanza con pedirle el video del flujo que quieras documentar. El plugin detecta si el proyecto usa Playwright o Capybara y escribe el recorrido en el stack que ya tienes; la primera vez conviene revisar las capturas antes de generar la voz. Necesita ffmpeg, edge-tts, jq y python3 en la máquina que arma el video, y trae un chequeo que dice cuáles faltan antes de empezar.

Este plugin nació de los aprendizajes de nuestros propios desarrollos de productos digitales. Si quieres saber más sobre lo que hacemos, visita Kleer Lab.

Lo que queda después de esta práctica

Tres aprendizajes se repiten cada vez que aplicamos esto: primero, gran parte de la fricción en equipos de producto no es técnica, es de coordinación, y a veces alcanza con eliminar la necesidad de estar todos disponibles al mismo tiempo. Segundo, forzar un recorrido automatizado y completo encuentra errores que las pruebas parciales no ven. Tercero, ese mismo material, generado una sola vez, puede reutilizarse para públicos completamente distintos: el equipo técnico, la mesa de ayuda, el cliente final.

¿Cuánto de lo que hoy se explica en una reunión en tu equipo podría, en cambio, quedar grabado? ¿Qué conocimiento operativo de tus flujos completos vive solo en la cabeza de alguien, y no en ningún otro lado?

Cuando lo que hace falta es un equipo capaz de encontrar y sostener este tipo de prácticas dentro de la organización, lo trabajamos con Innovation Team.

Si en tu organización la adopción de IA todavía depende de pocas personas o de pilotos sueltos que no escalan, conoce la Membresía IA de Kleer.

Ver todos los artículos