(Sobre ritmo, compás, y por qué acelerar un área de la empresa sin acompasar al resto te sale más caro que no acelerar nada)
Una empresa no es un único motor. Es una cadena de sectores que se pasan trabajo unos a otros, y la velocidad real del conjunto la define siempre el sector más lento. Esto, que suena obvio escrito, lo olvidamos sistemáticamente cada vez que aparece una herramienta nueva que acelera a uno de los eslabones. Lo vivimos con la llegada de los frameworks ágiles, con la nube, con DevOps. Y ahora lo estamos viviendo, en vivo y en directo, con la adopción de IA.
El patrón es siempre el mismo: un sector aprende a correr, los demás siguen al ritmo de antes, y en vez de mirar el sistema entero como un problema de compás, miramos al sector que se aceleró y pensamos "ahora sobra gente acá". Esa lectura es la que nos lleva al péndulo más caro que existe en una organización: achicar lo que parece sobrar y, seis meses después, intentar reconstruirlo cuando el cuello de botella se mudó.
Para verlo más claro, una imagen: pensá en un restaurante que se puso de moda. La cocina ajustó procesos, sumó un par de manos y aprendió a usar bien la plancha. Empieza a sacar platos al doble de velocidad. Hermoso. Solo que los mozos siguen siendo los mismos, el salón tiene las mismas mesas, y la sobremesa del cliente dura lo mismo de siempre. Los platos salen calientes del pase, esperan, esperan, y llegan tibios. La cocina mira al salón con bronca. El salón a la cocina. Y el dueño, en vez de mirar el sistema entero, piensa en achicar la cocina. Cambialo por sectores de empresa y tenés exactamente lo que está pasando con la IA.
Lo que pasó en sistemas
Conseguimos algo de adopción de IA, y claro que el primer lugar donde explotó fue en desarrollo. Era esperable: el código es texto, los tests son texto, la documentación es texto, y los modelos son muy buenos masticando texto. Un desarrollador aumentado mastica y escupe tickets con una velocidad y una calidad que, hace dos años, hubiéramos calificado de ciencia ficción. Refactors que llevaban un sprint se resuelven en una tarde. PRs que pedían tres rondas de review pasan en una. La velocidad real, medible, no es marketing: es una mejora honesta.
Y entonces aparece el reflejo gerencial clásico: si producen el doble, necesito la mitad. Mala lectura. Lo que produce el doble es el último eslabón de una cadena que sigue teniendo el mismo largo. Lo que pasó no es que sobre gente de desarrollo. Lo que pasó es que el cuello de botella se mudó de oficina.
La nueva cola está en producto
Ahora los devs aumentados terminan los tickets antes de que producto los pueda escribir bien. Y los PMs, por más que ellos también se "aumenten" con sus propias herramientas, chocan contra una pared que la IA no rompe: la relación humana con clientes y partners no escala al ritmo de un modelo. Una conversación con un cliente clave sigue durando lo que dura. Un descubrimiento de necesidad real sigue pidiendo escucha, contexto, paciencia, idas y vueltas. No hay manual de estilo único para tratar con un humano que está decidiendo si te paga o no.
Entonces nos encontramos con una sopa de letras: tickets a medio definir, especificaciones que se escriben mientras se construyen, prioridades que cambian porque nadie tuvo tiempo de verificar si lo que viene era realmente lo que el cliente necesitaba. La velocidad de la cocina no se traduce en mejor experiencia del comensal. Se traduce en platos tibios.
Y mientras tanto, la próxima idea ya parece mejor que la que todavía no presentamos. Tan veloces que no llegamos a realizar lo que pensamos, porque la siguiente ocurrencia es tan brillante que la actual —la que aún no salió a la calle— ya nos parece vieja. El ritmo de pensar superó el ritmo de hacer, y el ritmo de hacer superó el ritmo de decidir qué vale la pena hacer.
El error del "achiquemos"
La tentación, repito, es achicar el sector que parece sobrar. Achicamos desarrollo. Y al toque descubrimos que el cuello de botella se vuelve a mover: ahora es diseño, o data, o el equipo de implementación con el cliente. Entonces achicamos otro sector. Y cuando finalmente destrabamos ese, queremos volver a agrandar lo primero, pero ya sacamos de ahí gente que nos costó mucho esfuerzo y tiempo entrenar, y ahora, reconstruir capacidad cuesta el triple de lo que costó perderla.
Es el péndulo más caro que existe en una organización: achicar y volver a agrandar al ritmo de cuál fila parece más larga este trimestre. Cada movimiento te cuesta talento, conocimiento de dominio y confianza interna. Y todo por no haber visto que el sistema se mueve como un acordeón: cuando un sector se acelera, el cuello aparece en otro lado, no desaparece.
Lo que sí podemos hacer: pensar en una orquesta
Acá conviene cambiar de metáfora. No somos una cocina con un salón —eso lo usé para describir el síntoma—. Somos una orquesta que está aprendiendo a tocar más rápido por secciones. Si los violines aceleran y los vientos no, no obtenemos una sinfonía rápida: obtenemos ruido. Y la respuesta no es echar vientos. La respuesta es repensar la partitura entera, el tempo del director, y quizás —ahí viene lo incómodo— pedirle a cada músico que aprenda a leer un poco la partitura de los demás.
Tiro algunas estructuras posibles, no como recetas sino como direcciones a explorar:
1. Aumentar de a poco y de forma acompasada, no por sector. Un plan donde cada vez que aumentamos la capacidad de un área, planeamos en paralelo cómo aumenta la siguiente que va a recibir el flujo. Si los devs van a producir 30% más, producto necesita 30% más de capacidad de descubrimiento antes de que ese 30% extra se convierta en backlog vacío. Esto es más aburrido que comprar la herramienta de moda, pero es lo que evita el péndulo.
2. Cultura más generalista en los bordes. Que el PM tenga más conocimiento de sistemas. Que el diseñador entienda restricciones técnicas sin necesidad de un traductor. Que el desarrollador tenga criterio de producto y de diseño suficiente como para no necesitar que le definan cada pixel. Esto no significa borrar especialistas —los seguimos necesitando— sino ensanchar la zona de superposición entre roles. Cuando los bordes se tocan, la información fluye sin tantos handoffs, y los handoffs son la mitad del cuello de botella.
Curiosidad histórica: esto nos lleva un poco al pasado, a aquella época en que recibíamos un archivo de Photoshop —a veces ya cortado, a veces no— con un "esto es lo que quiero", y el desarrollador generalista se encargaba del resto. No es que aquella época fuera mejor; era peor en muchas cosas. Pero tenía una virtud: la cadena era corta. Quizás la IA nos esté empujando, sin que nos demos cuenta, a recuperar esa cadena corta con otras herramientas.
3. Equipos chicos y completos antes que sectores grandes y especializados. En vez de un departamento de devs, un departamento de PMs y un departamento de diseño, células de 4 a 6 personas con todas las disciplinas adentro. La IA premia mucho esta forma porque cada célula puede ir end-to-end sin tener que pasar la pelota tres oficinas para allá. El trade-off es que se vuelve más difícil hacer crecer especialistas profundos. Hay que decidir caso por caso si te conviene.
4. Invertir el reflejo: medir el sistema, no los sectores. Si tu métrica es "tickets cerrados por dev", vas a optimizar la cocina para siempre. Si tu métrica es "tiempo entre que un cliente menciona un problema y lo tiene resuelto en producción", vas a ver el embudo entero, y vas a saber dónde está el cuello hoy y dónde va a estar el mes que viene.
Y entonces
La pregunta que me viene dando vueltas, y que te dejo abierta, es esta: ¿estamos diseñando organizaciones que sepan moverse cuando el cuello de botella cambia de lado, o seguimos construyendo organigramas pensados para un cuello que ya se mudó?
Porque la IA no nos sacó cuellos de botella. Nos los hizo más móviles. Y las estructuras rígidas, frente a un cuello móvil, no aguantan. Vibran hasta romperse, como un motor con un solo pistón acelerado.
Mi sospecha es que los próximos dos años no los van a ganar las empresas que más rápido adoptaron IA en desarrollo. Los van a ganar las que entendieron que adoptarla en una sola sección de la orquesta era apenas el primer movimiento de la sinfonía.
Autor: Fabi Mesaglio
No hay comentarios:
Publicar un comentario