Esta reunión podría haber sido un video

¿Cuántas veces revisaste un cambio en un producto digital en una reunión que terminó siendo media hora de alguien compartiendo pantalla y explicando lo mismo que podría haber quedado grabado en tres minutos? El costo no es solo el tiempo: es la fricción de encontrar un horario en el que todos estén disponibles, justo cuando el cambio ya está listo para avanzar.

En equipos de producto que trabajan con sistemas complejos, esa fricción se multiplica. Revisar un flujo completo (no una pantalla suelta, sino la secuencia entera que atraviesa un usuario real) exige sincronizar agendas, repetir explicaciones y, muchas veces, postergar la validación hasta que alguien tenga un hueco libre. En Kleer probamos una alternativa: en vez de reunirnos para mostrar un cambio, generamos automáticamente un video que lo recorre por nosotros. El resultado no es solo ahorro de tiempo: es una forma distinta de documentar, comunicar y hasta de encontrar errores antes de que lleguen a producción.

¿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.

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?

Descubrimos esta y otras mejoras participando en equipos de Kleer Lab, donde aplicamos y creamos prácticas concretas antes de llevarlas a organizaciones más grandes.

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

Ver todos los artículos