Cada vez que un proyecto de software se cae, la conversación termina siempre en el mismo lugar: que el equipo no funcionó, que el stack no era el adecuado, que apareció un bug crítico o que se corrió el plazo. Después de varios años sentado del lado del que contrata, estoy cada vez más convencido de lo contrario:
Los proyectos no se caen por el código. Se caen mucho antes... Se caen en el "para qué".
Me ha tocado verlo tantas veces que ya casi lo veo venir. Un proyecto parte definiendo qué se va a construir y con qué tecnología, cuando todavía nadie se ha sentado a preguntarse para qué: qué problema de negocio estamos resolviendo y cómo vamos a saber si lo resolvimos. Suena obvio, pero te sorprendería la cantidad de proyectos que arrancan sin esa conversación básica.
Ese primer paso en falso se paga caro. Se abre una distancia insalvable entre el negocio y la tecnología, y el equipo termina construyendo justo lo que se pidió… que no es lo mismo que lo que el negocio necesitaba. Como nunca se definió cómo se mide el valor, empezamos a medir lo único que se puede contar: tareas, features y sprints. Así es como llegamos al final con algo entregado, funcionando y "listo"… pero que no movió una sola aguja.
La frustración del desarrollo tradicional: ¿Con qué cicatrices llega el cliente?
Muchos de los clientes con los que hablo no llegan desde cero. Llegan con cicatrices de un proyecto anterior, y las historias se parecen bastante entre sí. Uno me dice que sintió que pagó por horas y no por resultados, que financió a un equipo que facturó tiempo sin hacerse cargo de si la solución funcionaba. Otro me cuenta que le entregaron algo que no podía usar; técnicamente terminado pero inservible para la operación, o bien quedó amarrado para siempre a un proveedor.
Casi todos coinciden en algo. La estrategia, la tecnología y los objetivos de negocio iban cada uno por su lado, sin nadie que los hiciera conversar.
Ahí está el error de fondo (y no lo digo desde un pedestal, porque también lo he visto de cerca): se trata a la tecnología como si fuera el objetivo principal, y no lo es. Los dolores siempre son de negocio. La tecnología está para resolverlos, no al revés. El día que se da vuelta esa relación, cuando la herramienta manda y el problema se acomoda a ella, el proyecto ya está perdido, aunque nadie lo note todavía.
El error recurrente en la era de la Inteligencia Artificial
Hoy se está repitiendo la misma historia con un nuevo nombre. Veo a muchas empresas sumando inteligencia artificial de la peor forma posible… Como un feature aislado que se pega al final del proceso. "Ya que estamos, metámosle IA".
Es exactamente el mismo desacierto de siempre: poner la tecnología antes que el problema, ahora con la palabra de moda y generando un nuevo dolor de cabeza para los CFO a nivel de costos e infraestructura (Token Revenue).
La IA no es una cajita de herramientas que se cuelga sobre un proceso que ya diseñaste. Es parte del diseño mismo del negocio y tiene que atravesar la operación completa desde el día cero. No hablo de hacer lo mismo un poco más rápido; hablo de repensar cómo funciona el negocio cuando la IA es parte de su estructura y no un parche. Esa diferencia entre sumarle IA y diseñar con IA es la que va a separar a las empresas que capturan valor real de las que solo gastan dinero para quedar bien en la foto.
3 consejos clave antes de financiar tu próximo desarrollo de software
Si me sentara cinco minutos con un líder de negocio antes de que firme su próximo proyecto, le diría tres cosas. No tengo una fórmula mágica, pero estas lecciones me las he ganado a golpes:
- Empieza desde el problema de negocio, no la tecnología: Antes de elegir stack o proveedor, ten claro dónde generas o capturas más valor y diseña para ir a buscarlo ahí. Si no sabes qué aguja quieres mover, ninguna tecnología la va a mover por ti.
- Busca un socio, no un proveedor de horas: Necesitas a alguien que se haga cargo del resultado y que te pare cuando te estés equivocando, no a alguien que te diga que sí a todo y siga facturando. La diferencia es simple: el socio se queda pensando en tu resultado cuando ya nadie está mirando.
- Mete la IA desde el día cero: No la dejes para el final. Llévala al centro del proceso y úsala para ganar velocidad rediseñando o reconstruyendo tu operación, no para maquillarla.
El modelo Raven: Construir software con impacto real
Al final, esta es la razón por la que en Raven trabajamos como trabajamos. No partimos por el código; partimos por entender el negocio y dónde está el valor. Construimos, sí, pero nos hacemos cargo de que lo que construimos se use y devuelva un retorno concreto, no solo de entregarlo. Ponemos la IA en el diseño mismo de la operación, porque es ahí donde deja de ser una promesa bonita y se vuelve una ventaja competitiva.
Un software que nadie usa es solo un gasto con buen marketing. Y nuestra labor, antes de escribir una sola línea de código, es asegurarnos de que eso no te pase.
