Gestión de expectativas

Llevo meses oyendo la misma frase en reuniones, correos y llamadas con clientes:

«Con la IA esto lo tenéis hecho en una semana».

No es broma. No lo digo para dramatizar. Es literal lo que me han pedido, con esa sonrisa de quien acaba de descubrir el fuego. Y cada vez que pasa siento la misma sensación: no puedo discutirles los datos, porque no tienen ninguno; solo tienen una expectativa. Y las expectativas, a diferencia de los requisitos, no se pueden refutar con pruebas.

Así que me toca hacer lo que nadie quiere hacer en una reunión: explicar, con paciencia y sin humillar a nadie, por qué esa semana es una fantasía. Te cuento cómo lo hago, porque creo que se puede hacer bien y sin pelearse.

Lo que de verdad están viendo

Cuando alguien dice «con la IA en una semana», casi nunca está hablando del proyecto entero. Está hablando de una prueba de concepto: un demo, un prototipo, una pantalla que funciona y que se puede enseñar a la junta directiva el viernes.

Y aquí viene el error, que es el corazón de todo esto: una prueba de concepto rápida no es un producto en producción rápido. Son dos cosas completamente distintas que la gente confunde porque las ve en el mismo ordenador y con la misma herramienta.

• Una prueba de concepto demuestra que una idea puede funcionar. Se puede hacer deprisa, se puede romper, se puede tirar a la basura sin consecuencias. Nadie depende de ella.
• Un producto en producción tiene que aguantar usuarios reales, picos de carga, fallos, seguridad, auditorías, soporte, actualizaciones y una responsabilidad legal por si falla. Cada uno de esos puntos cuesta tiempo, y ningún modelo de lenguaje lo elimina.

La IA acelera la primera parte de forma legítima. Lo que no hace es borrar la segunda. Y ese «no» es exactamente lo que hay que conseguir que entiendan.

Por qué cuesta explicarlo: el desconocimiento no se ve desde dentro

El problema no es que tus clientes sean tontos. Es que nadie les ha enseñado cómo funciona la ingeniería por dentro, y sin ese mapa no pueden distinguir entre «programar» y «poner algo en producción».

Para ellos, escribir código es lo que ves: una persona tecleando (o un chat bot escupiendo líneas). No ven el resto del iceberg:

• El análisis de requisitos real, que es donde se decide si el proyecto va a servir para algo o no.
• El diseño de arquitectura, que condiciona todo lo que viene después.
• Las pruebas, la integración, los entornos, el despliegue, el monitorizado.
• La deuda técnica, que se paga siempre, solo cambia quién y cuándo.

Si no saben que esas capas existen, no pueden entender por qué una cosa lleva tres meses y otra, «que es casi lo mismo», no lleva tres días. No están pidiendo magia; están pidiendo algo que creen que ya está hecho. Y ahí es donde tienes que intervenir tú, sin sonar a profesor ni a defensivo.

El IA-bro: el perfil más peligroso de la sala

Sí, lo he bautizado yo, y sí, es un homenaje a los crypto bros que ya conocemos bien. El IA-bro es casi siempre un técnico con poca experiencia que ha descubierto que puede escribir código que funciona sin entender del todo por qué funciona, y eso le ha producido una certeza absoluta: la ingeniería ya no hace falta. Todo se soluciona con IA, y quien diga lo contrario es que no sabe usar las herramientas.

Su argumento es imbatible en una reunión porque viene con demo:

• Productos de dos noches. Te muestra una aplicación completa que ha hecho «en un fin de semana», sin pruebas, sin arquitectura, sin proceso. Y la presenta como si el siguiente paso fuera el despliegue, no la reescritura.
• La funcionalidad de la reunión. En una llamada comercial alguien dice «ojalá tuviéramos X» y esa misma tarde el IA-bro tiene X corriendo en su aplicación vibecodeada. Aplausos. Nadie le pregunta quién lo va a mantener, qué pasa cuando falla a las tres de la mañana, ni si lo que ha hecho era siquiera lo que el cliente quería.
• Cero deuda visible. Como no hay ingeniería detrás, no hay nadie que sepa dónde están las minas. El código funciona… hasta que deja de funcionar, y entonces ya no hay nadie capaz de decir por qué.

Y aquí viene lo peligroso, porque el IA-bro no solo tiene expectativas equivocadas: las fabrica. Cada demo de dos noches sube la vara un poco más. Lo que ayer era «una semana es mucho» pasa a ser «si él lo hizo en una tarde, ¿por qué nosotros no?». La petición puntual de velocidad se convierte en aceleración constante, y el equipo empieza a correr para no quedar obsoleto.

El final siempre es el mismo. El paso a producción fracasa estrepitosamente: fallos, seguridad, rendimiento, datos por los suelos. Y entonces el IA-bro hace lo que mejor sabe hacer además de vibecodear: poner la culpa en otro. En el equipo «que no sabe usar las herramientas», en los procesos «lentos y anticuados», en la deuda técnica «de los otros». Nunca en sus dos noches.

El resultado para la empresa es una espiral: productos defectuosos saliendo a una velocidad de vértigo, clientes que ven errores donde antes veían estabilidad, y equipos quemados apagando incendios cada semana. Y lo peor de todo: cuando la dirección mira atrás no ve un problema de expectativas mal gestionadas; ve «la IA fallando», y empieza a dudar de la herramienta en lugar del método. Es decir, el IA-bro acaba contaminando hasta la conversación que yo vengo intentando tener.

Si tienes un IA-bro en tu organización, no es un problema de talento: es un problema de expectativas sin gestionar dos veces —la suya y la de quienes le aplauden. Y se trata igual que el resto del artículo: separar prototipo de producto, hablar en capas, poner nombre al riesgo. La única diferencia es que con él hay que hacerlo antes, porque su demo ya está en la sala.

Cómo educar sin romper la relación

Esto es lo importante. Puedes corregir una expectativa equivocada sin convertirte en el villano de la reunión. Estas son las cosas que me han funcionado:

• Separa la prueba del producto desde el minuto uno. Propón tú mismo: «hagamos primero un prototipo rápido para validar la idea, y después hablamos de producción». Así les das lo que quieren ver (algo rápido) sin comprometer la fecha real. Ellos ven movimiento; tú conservas el calendario honesto.
• Habla en capas, no en horas. En lugar de «esto son 900 horas», explica qué hay detrás: requisitos, diseño, pruebas, despliegue. Cuando entienden las capas, entienden por qué cada una cuesta lo que cuesta. La cifra deja de ser un número arbitrario y se vuelve consecuencia.
• Muestra el coste del atajo, no solo su precio. Si quieren saltarse las pruebas o la arquitectura para ir rápido, cuéntales qué pasa cuando falla en producción: incidentes, reputación, dinero. La velocidad barata hoy es un problema caro mañana, y eso sí que lo entienden.
• Ponle nombre al riesgo. «Si lo ponemos en producción sin X, el riesgo es Y». Un riesgo con nombre y consecuencia concreta pesa más que cualquier argumento técnico abstracto.
• Dales un compromiso verificable. En vez de prometer la fecha imposible, ofrece hitos: prototipo en dos semanas, validación en un mes, producción cuando se cumplan estas condiciones. Los hitos son negociables; las fechas mágicas no lo son.

El error que yo mismo he cometido

Ser honesto: durante un tiempo yo también alimenté esa expectativa. Cuando me pedían algo rápido, a veces daba el sí fácil para no perder la reunión, y luego me comía los meses intentando cumplir una fecha que desde el principio sabía que era inviable. Eso no educa a nadie; solo genera desconfianza cuando al final sale tarde.

Lo que he aprendido es que la expectativa equivocada se paga más cara cuanto antes la dejas pasar. Corregirla en la primera reunión cuesta una conversación incómoda. Corregirla en el mes tres, cuando ya llevas tres meses de retraso y el cliente está harto, cuesta la relación.

Lo que no se puede acelerar (y hay que decirlo)

Para terminar, lo claro: hay partes del trabajo que la IA hoy acelera mucho y otras que no toca casi. Y convendría ser honestos sobre cuál es cuál.

• Sí se acelera: escribir código repetitivo, generar pruebas, documentar, prototipar interfaces, refactorizar, encontrar errores evidentes.
• No se acelera (o casi): entender bien el problema de negocio, tomar decisiones de arquitectura, decidir qué es correcto para el usuario, asumir la responsabilidad de lo que falla en producción, y cualquier cosa que dependa de requisitos que nadie tiene claros todavía.

La IA multiplica la velocidad de las manos, no la de la cabeza. Y un proyecto se define con la cabeza antes de ejecutarse con las manos. Si el cliente cree que está comprando solo manos, ahí es donde hay que sentarse a hablar.

Cómo lo diría si tuviera que resumirlo

A un cliente o jefe que espera que la IA le entregue su producto en una semana, yo le diría esto:

«Con la IA te puedo tener un prototipo impresionante en días y te lo enseño. Pero un prototipo no es tu producto. Entre el prototipo y lo que tus clientes reales van a usar hay requisitos, diseño, pruebas, despliegue y responsabilidad, y eso lleva el tiempo que lleva. Lo que sí puedo hacer es empezar por el prototipo ahora mismo, para que veas con tus propios ojos la diferencia entre una idea funcionando y un producto en producción. Y cuando lo veas, sabremos juntos cuántos meses son de verdad, sin prometerte una fecha que luego no cumplo.»

No es un discurso bonito. Es decir la verdad sin perder al cliente. Y en mi experiencia, es la única forma de que la próxima vez que digan «con la IA en una semana» ya sepan a qué vienen.