Dos conversaciones este mes no tenían nada que ver entre sí, al menos en apariencia. Una ocurrió en una reunión comercial sobre una iniciativa de IA. La otra, mientras un product owner presentaba un sistema nuevo a un grupo de usuarios. Ambas me dejaron la misma observación: llegar rápido a una respuesta no sirve de nada si la pregunta de base está mal planteada.
La primera conversación. Un cliente potencial quería hablar sobre cómo las herramientas de IA podían aumentar drásticamente la velocidad de entrega de su equipo. Había leído las promesas, visto las demos, y quería saber qué tan rápido podía adoptarlas su organización.
Le pregunté qué problema estaba tratando de resolver. Describió un backlog que seguía creciendo a pesar de que el equipo entregaba constantemente.
“Entonces el equipo es rápido”, le dije. “¿Está construyendo lo correcto?”
Se quedó en silencio. No lo sabía. Nadie se había hecho esa pregunta en meses, porque la conversación sobre IA había absorbido toda la atención que debería haber ido hacia definir qué era realmente importante construir.
Ningún modelo de IA, por más capaz que sea, reemplaza la disciplina de establecer el problema correcto antes de optimizar la velocidad para resolverlo. Un equipo puede generar código, tests y despliegues a una velocidad extraordinaria y aun así estar alejándose del valor con cada sprint. La productividad técnica y el valor de negocio están en ejes distintos, y confundirlos es un error viejo disfrazado de herramienta nueva.
Conversaciones llega una vez al mes, directo desde la sala. Intercambios reales con clientes y prospectos, anonimizados, cada uno construido alrededor de un momento en el que escuchar cambió el resultado.
La segunda conversación. Esta ocurrió en una sala, no en una venta. Un product owner presentaba un sistema nuevo a sus futuros usuarios. Uno por uno, los usuarios planteaban casos límite: situaciones que el sistema no contemplaba, flujos que rompía, excepciones que ignoraba.
La respuesta del product owner, cada vez, era alguna variante de: “Entiendo, pero gerencia quiere que esto sea la norma.”
Los usuarios siguieron hablando. Poco a poco, sin que nadie lo dijera en voz alta, la comprensión de la sala cambió. Los “casos límite” no eran casos límite. Eran la forma real del trabajo, y el sistema se había construido para una versión simplificada de ese trabajo que no existía en el terreno.
Reconozco este patrón de suficientes salas como para tener certeza: una respuesta de política que se impone sobre una respuesta de realidad, seguida de esa realidad reafirmándose de todos modos, casi siempre en un momento peor que el de una presentación.
Ambas conversaciones apuntan a la misma lección de fondo. Ningún nivel de sofisticación en IA, ni ninguna convicción de gerencia, sustituye escuchar a quienes están más cerca del problema antes de decidir qué tan rápido avanzar con la solución. La velocidad importa. Simplemente no es la primera pregunta.
Esta es la primera entrega de Conversaciones, una nueva serie basada en intercambios reales con clientes y prospectos — anonimizados, cada uno construido alrededor de un momento en el que escuchar cambió el resultado.
Si alguna de estas dos conversaciones te resulta familiar en tu propia organización, hablemos sobre cómo asegurarte de que tu equipo esté resolviendo el problema correcto antes de optimizar la velocidad. Escribime hoy, y arrancamos por lo que realmente está pasando en el terreno.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
