Volver
El cuello de botella cambió de lugar
Última modificación el
Tabla de contenido
Las organizaciones están invirtiendo en IA para desarrollo, los equipos producen código más rápido (mucho más rápido). Sin embargo, los resultados de negocio no se mueven al mismo ritmo. Los proyectos siguen llegando tarde, siguen sin resolver lo que el negocio necesita, la satisfacción del usuario final no mejora a pesar de la velocidad técnica.
Si la construcción es más rápida, ¿por qué los resultados no?
Durante décadas, el cuello de botella de la industria del software fue la construcción. Incertidumbre en los tiempos, demoras, errores introducidos al modificar software que funcionaba, dificultad para mantener el código existente. Las disciplinas más exitosas de los últimos 40 años (metodologías, frameworks, prácticas, herramientas) se construyeron alrededor de ese problema.
La adopción de estas buenas prácticas, en general, fue mucho más efectiva en la construcción que en otras etapas igualmente necesarias: entender el problema del usuario, validar la solución en uso real, simplificar lo que no aporta valor, operar y dar soporte al producto.
Y este es el punto clave: aunque el proceso completo seguía teniendo fallas en muchos puntos, siempre las críticas se las llevaba la programación.
Ahora estamos ante una realidad bien diferente; la inteligencia artificial ha cambiado para siempre la construcción de software. El proceso de diseño, programación y aseguramiento de calidad asistido por agentes ahora es mucho más rápido y predecible (siempre y cuando sean supervisados por profesionales experimentados).
Sin embargo, esto ha resuelto sólo una parte del proceso, dejando en evidencia otras falencias antes no tan evidentes.
El cuello de botella cambió de lugar
La IA generativa movió el cuello de botella a otro punto del proceso de construcción de un producto o servicio que resuelve un problema de negocio.
Construir es mucho más rápido y barato. Mejorar el diseño, hacerlo más simple, también es más predecible. Probar las nuevas funcionalidades y que no se haya roto nada, también. Esa parte de la cadena de valor está, por primera vez en décadas, dejando de ser el limitante.
Esto tiene una consecuencia incómoda e interesante: si la construcción ya no es el cuello de botella, entonces el cuello de botella está en otra parte. Probablemente la ineficiencia siempre estuvo ahí, pero quedaba oculta detrás del problema más grande.
La construcción de software no es un fin en sí mismo, se construye para habilitar un proceso, para construir un producto, para resolver un problema interno o de un segmento del mercado. Esto implica entender ese proceso, la necesidad que cubre el producto, el usuario interno o el segmento de mercado al que apunta.
Es un proceso exploratorio que requiere la participación activa del usuario final, de los ingenieros que construyen la solución y de los que la operan. Y es en esas etapas donde estamos empezando a ver aparecer un nuevo cuello de botella. Nuevo no porque la problemática no existiera antes sino porque ahora es la que está poniendo el límite a la consecución de los resultados.
El costo de explorar también se ha reducido, ahora es posible explorar una cantidad mucho mayor de soluciones posibles y en menor cantidad de tiempo. También es menos costosa la decisión sobre la mejor solución porque también es más simple cambiarla luego de ponerla en marcha. Bajó también el costo del cambio, una excelente noticia para el desarrollo iterativo e incremental de la solución.
La nueva restricción
La forma de responder a un cuello de botella que ha dejado de serlo es aplicar la técnica que aplican los expertos en mejora de procesos desde hace años: identificar el nuevo cuello de botella y enfocarse en él hasta que deje de serlo.
Entender el problema del negocio. Identificar qué automatizar y qué no. Decidir qué construir y qué descartar. Conversar directamente con el usuario final de forma que participe en el diseño de la solución. Iterar sobre la definición del problema mientras se construye.
El equipo que resuelve problemas construyendo software ahora es más pequeño en número (porque la IA generativa amplifica el conocimiento disponible) y es mucho más importante que el desarrollador se conecte con el usuario final y con el problema que ambos desean resolver.
Durante 40 años fue tolerable que esta parte fuera imprecisa porque "después en construcción se acomodaba". Ya no. Si la construcción es rápida y barata, los malentendidos o errores por desconexión se convierten en el costo dominante (en tiempo y en dinero).
Una observación y una pregunta
Nuestra observación es que la mayoría de las organizaciones siguen equipadas para un mundo donde el cuello de botella era construir. Sus procesos de aprobación, sus métricas de productividad, sus estructuras de equipo, sus presupuestos y hasta sus KPIs fueron diseñados para gestionar un problema que cada vez pesa menos.
Mientras tanto, el problema que sí pesa cada vez más (entender al usuario, decidir qué construir, validar en campo, iterar sobre la definición misma de la solución) sigue atendido con las prácticas e ideas de siempre.
La pregunta que proponemos es: ¿dónde está hoy el verdadero cuello de botella de su organización? ¿Lo está midiendo? ¿Está poniendo ahí a sus mejores personas y su tiempo, o sigue optimizando el lugar donde dolía hace diez años?
Adaptarse a este cambio no es adoptar herramientas de IA. Es repensar dónde vive la complejidad del problema y, en consecuencia, dónde conviene poner el talento, la atención y el presupuesto.
