- El ejemplo de cómo arranca un proyecto de software fallido
Un proyecto que nace de una idea brillante
Todo comenzó con una idea brillante. O al menos, eso parecía.
Una de esas ideas que se presentan con solemnidad en salas de reuniones con luz tenue, donde los términos como disrupción, plataforma integral o tecnología exponencial flotan en el aire como si ya fueran producto. En esta ocasión, se trataba de construir un sistema digital avanzado para la gestión inteligente de rutas farmacéuticas: una solución capaz de coordinar envíos, certificar temperaturas, asegurar trazabilidad y generar evidencia de cumplimiento regulatorio en tiempo real.
Patrocinadores y promotores del proyecto
Saúl, el ideólogo
Era un proyecto ambicioso. Y la idea tenía un rostro: Saúl Sánchez.
Saúl era un comunicador brillante. Cosmopolita, elocuente y con una historia vital poco convencional, sabía cómo presentar una visión envolvente. Conocía bien los pasillos de las instituciones públicas, los entresijos de los consorcios empresariales, y tenía el raro talento de prometer futuro como si ya estuviera listo para su lanzamiento.
—Esto ya está vendido. Solo falta que lo montemos —decía con una sonrisa confiada.
Manuel, el ejecutor decidido
Junto a Saúl, en un rol menos visible, pero determinante, se encontraba Manuel Ortega. Director operativo en la consultora, inversor en la startup, y designado como máximo responsable del producto. Tenía carácter fuerte, muchas horas de vuelo gestionando entornos críticos y un estilo directo que imponía respeto. No era partidario de metodologías ni de discusiones técnicas extensas:
—No me vengas con historias técnicas. Dime si va a estar o no va a estar —solía decir.
Aunque no tenía experiencia real en desarrollo de software, su convicción y posición le daban autoridad. Yo había trabajado con él y, pese a su dureza, le respetaba. En su estilo había coherencia, pero también rigidez. Esta vez, sin embargo, las reglas eran distintas: Manuel se convirtió en parte interesada. Tenía un 15% de la startup y eso lo colocaba en una posición delicada. La empresa lo sabía:
Manuel, pretendes facturar con una mano y cobrar con la otra. Podemos hacer la vista gorda hasta un punto. A partir de ahí, eres responsable de todo lo que se desencadene.
Aceptó. Operaría desde la sombra, delegando en una figura visible, sin poder real.
Ejecutores de la idea
Para la consultora, este proyecto era algo más que una cuenta importante. Era la oportunidad de posicionarse como creadora de productos propios, más allá del rol de proveedor. Una startup externa, una idea con potencial, y la posibilidad de firmar como arquitectos del cambio.
Corría el mes de enero. Las presentaciones comerciales estaban listas. La idea se envolvía con términos potentes: blockchain, interoperabilidad, trazabilidad. El roadmap parecía claro:
- Inicio inmediato en febrero.
- Entrega funcional en octubre (onboarding de usuarios).
- Desarrollo completo: 24 meses.
Pero había algo revelador: no existía MVP. No se planteaba validación progresiva. No había entregas intermedias para recoger feedback. El éxito se daba por hecho. Se asumía que los actores clave adoptarían la solución por obligación institucional.
Desde fuera, todo parecía cuadrar. El discurso era impecable. Las cifras, convincentes. Pero nadie con experiencia técnica había validado la viabilidad real. Nadie había mapeado el ecosistema con rigor.
Yo como observador imparcial
En ese momento, yo solo observaba. Estaba asignado a otro proyecto y apenas conocía detalles. Revisé las presentaciones. Escuché el discurso. Todo era atractivo… y superficial. No formaba parte del equipo, y sinceramente, no lo deseaba. Pero lo que no sabía era que, pocos meses después, estaría en el centro mismo de la tormenta de este proyecto de software fallido.
Una promesa que no arrancaba
Febrero llegó. El proyecto, oficialmente, estaba en marcha. Pero en la práctica, todo estaba detenido. La startup no había conseguido cerrar la ronda de inversión y no había fondos para activar los equipos. Las fechas seguían fijas. Nadie se atrevía a tocarlas.
Desde dentro de la consultora, pocos sabían que el proyecto estrella estaba congelado. Se asumía que la inversión llegaría en cualquier momento. Pero el tiempo pasaba.
En abril, mi nombre apareció en el tablero. Me comunicaron informalmente que, una vez finalizara mi proyecto actual, pasaría al equipo backend. El arranque se fijó para el 15 de mayo.
La consultora no reprogramó el roadmap. Las fechas de entrega eran inamovibles. Y Manuel tenía un as en la manga.
El as en la manga de Manuel
Ante el retraso evidente y el peligro de incumplir el calendario, Manuel decidió actuar. Detectó un software en el mercado, basado en blockchain y pensado para logística. Lo analizó superficialmente, y con su autoridad, lo compró.
Su lógica era simple:
- Integrar este software como capa de trazabilidad.
- Evitar desarrollar una red blockchain propia.
- Sustituirlo en el futuro, cuando hubiese más tiempo.
La idea tenía sentido para evitar que todo resultase en un proyecto de software fallido. Pero se tomó sin participación técnica, sin análisis de compatibilidad, sin comprobar documentación ni capacidades reales del producto adquirido. Se destinó una parte importante del presupuesto inicial a esta apuesta.
El proveedor asignó un comercial, no un técnico. Las dudas se apilaban: ¿qué acceso tendríamos? ¿Qué documentación había? Las respuestas eran vagas.
Finalmente arranca el proyecto
En la segunda quincena de mayo, el proyecto arrancó. Se presentaron documentos, se hicieron reuniones introductorias, se analizaron flujos preliminares.
El equipo tenía ilusión. Las intenciones eran buenas. Pero en dos semanas, todo cambió.
Una nueva reunión fue anunciada para el 21 de junio. Saúl quería ver avances. Inversores pedían tangibles. Y Manuel no pensaba modificar la fecha de entrega. La presión se hizo sentir.
Se canceló la fase de descubrimiento.
—Olvidaos de tanto análisis. Lo que hace falta es empezar a construir.
Con esa frase, todo cambió. Sin arquitectura, sin modelo de datos, sin backlog validado, se dio la orden de empezar a desarrollar. Había que mostrar algo. Cualquier cosa. Se estaban empezando a conjugar todos los elementos necesarios para que el producto no pasase de ser un proyecto de software fallido más.
Y entonces… me incorporo al proyecto
No fue un aterrizaje suave. Más bien fue como saltar a un tren en marcha, sin saber muy bien hacia dónde iba, ni quién lo conducía realmente.
Lo que encontré no era una base sólida esperando manos para construir. Era una mezcla de promesas vendidas, tecnologías impuestas y decisiones tomadas mucho antes de entender el problema.
Las pantallas ya estaban en marcha. Las fechas, esculpidas en piedra. Y el software que supuestamente nos ahorraría tiempo… apenas tenía documentación.
En aquel momento, aún no lo sabía, pero cada línea de código que empezáramos a escribir iba a ser —literalmente— una apuesta a ciegas.
Solo tenía claro una cosa: el producto no estaba definido, pero el reloj ya había empezado a correr.
Y lo peor estaba por llegar.