La parte más cara de corregir un error no es en realidad corregirlo

Seguimos hablando de la productividad del desarrollador. Pero estamos optimizando lo incorrecto.

Durante los últimos años, he trabajado de cerca con equipos de soporte al cliente en diferentes empresas. Diferentes productos. Diferentes industrias. Diferentes etapas de crecimiento. Y una cosa me ha sorprendido más que cualquier otra. No importa cuán moderno fuera el stack de ingeniería, el proceso de manejar informes de errores parecía casi idéntico. Las empresas invierten mucho en hacer que los desarrolladores sean más rápidos. La IA escribe código, revisa solicitudes de extracción, genera pruebas y explica bases de código desconocidas. Los equipos de ingeniería se están volviendo drásticamente más productivos.

Sin embargo, uno de los flujos de trabajo más comunes en el desarrollo de software todavía comienza con algo tan simple como:

"La aplicación se bloqueó."

Lo que sucede después rara vez es eficiente.

El error no es el cuello de botella. El contexto lo es.

Alguien informa de un error. No un informe de error detallado. Solo un mensaje.

"Las notificaciones no funcionan."

"No puedo iniciar sesión."

"La aplicación se bloqueó."

En ese momento, parece que ingeniería tiene trabajo que hacer. Pero cuanto más tiempo pasaba trabajando con equipos de soporte, más me daba cuenta de que el error en sí no es lo que ralentiza a las empresas. Es todo lo que sucede después. Soporte pide capturas de pantalla. El cliente no recuerda exactamente lo que pasó, alguien pregunta qué versión de la aplicación están usando, ingeniería se une a la conversación y pide registros, producto crea una tarea, QA pregunta si alguien puede reproducir el problema, alguien copia la conversación en Jira, alguien pega capturas de pantalla en Slack, alguien abre el panel de monitoreo para buscar registros. Para cuando un desarrollador finalmente comienza a investigar el problema, ya se han gastado veinte o treinta minutos, no resolviendo el problema, sino simplemente recopilando suficiente contexto para entenderlo.

He visto este flujo de trabajo tanto en startups como en grandes organizaciones. Las herramientas cambian. El proceso rara vez lo hace.

Los humanos se han convertido en la capa de integración

Lo que más me sorprendió es que hemos automatizado gran parte del desarrollo de software, pero no el traspaso entre equipos. Soporte mueve las conversaciones a tickets, producto mueve los tickets a los tableros de desarrollo, los ingenieros buscan en plataformas de monitoreo, QA reconstruye los pasos de reproducción. Todos dedican tiempo a mover información en lugar de usarla. Cuanto más lo pienso, más me convenzo de que el verdadero cuello de botella no es corregir errores. Es reconstruir el contexto. Es un trabajo que nadie quiere hacer. Y es un trabajo en el que las máquinas son extraordinariamente buenas. Imagine que un cliente simplemente escribe:

"Las notificaciones no funcionan."

En cuestión de segundos, reciben una respuesta confirmando que el problema está siendo investigado. Entre bastidores, el sistema automáticamente recopila registros, identifica la versión de la aplicación, busca incidentes similares, crea un ticket y prepara un resumen estructurado para ingeniería. Para cuando un desarrollador abre la tarea, ya sabe qué pasó, dónde buscar y qué información está disponible. Sin trabajo de detective. Sin copiar y pegar entre herramientas. Sin hacer las mismas preguntas una y otra vez.

Más informes de errores pueden ser en realidad una buena señal

Una consecuencia de este enfoque es algo que muchos equipos ven inicialmente como un problema. De repente, se informan más errores. A primera vista, eso parece un fracaso. En realidad, a menudo es lo contrario. Cuando informar de un problema se vuelve sencillo, la gente deja de decidir si algo es "lo suficientemente importante" como para mencionarlo. Simplemente lo informan. El número de tickets crece, pero también lo hace su visibilidad de lo que realmente está sucediendo dentro de su producto. No está creando más errores. Está descubriendo los que ya estaban allí. Personalmente, preferiría saber sobre cada problema que experimentan mis usuarios que informar con orgullo que los tickets de soporte han disminuido mientras los problemas pasan desapercibidos.

La IA no debería reemplazar el soporte. Debería eliminar el trabajo invisible.

No creo que el futuro de la IA en el soporte al cliente sea sobre escribir respuestas más amigables o reemplazar a los agentes de soporte. Se trata de eliminar el trabajo invisible que ocurre entre soporte, producto, ingeniería y QA. Porque el objetivo no es simplemente responder más rápido a los clientes. El objetivo es asegurarse de que cuando un ingeniero finalmente abre un informe de error, pueda comenzar a resolver el problema de inmediato, en lugar de pasar los primeros treinta minutos averiguando qué sucedió realmente. Ahí es donde creo que la IA se vuelve verdaderamente valiosa. No cuando se comporta como un compañero de equipo más. Sino cuando se encarga silenciosamente del trabajo que la gente no debería haber estado haciendo en primer lugar. Este es exactamente el tipo de flujo de trabajo que hemos estado explorando en BridgeApp: no solo ayudar a los equipos a responder más rápido, sino asegurarse de que cada error llegue a ingeniería con el contexto ya adjunto.