Cuando el proyecto ya estaba perdido antes de empezar

Me acuerdo de una frase concreta que dijo el cliente final en la primera reunión que tuvimos con él.

No fue algo técnico. Fue algo muy sencillo: nos explicó lo que quería hacer con el sistema y, mientras lo hacía, quedó claro que lo que estábamos construyendo resolvía otro problema completamente distinto. No el suyo.

En ese momento entendí dos cosas. La primera: que nuestro cliente nunca había tenido esta conversación con él. La segunda: que el proyecto ya estaba comprometido antes de escribir la primera línea de código.

La cadena que nadie dibujó

Este proyecto funcionaba con tres niveles. Nosotros éramos el equipo de desarrollo. Nuestro cliente era una empresa que, a su vez, tenía su propio cliente: el usuario final del producto que íbamos a construir.

Esta estructura existe en muchos proyectos y puede funcionar bien. El problema es que, cuantos más eslabones hay en una cadena, más se distorsiona lo que se transmite de un extremo al otro. Cada eslabón interpreta, simplifica, prioriza según sus propios intereses. Lo que llega al final se parece poco a lo que había al principio.

En nuestro caso, el proyecto había sido vendido por nuestro cliente a su usuario final como algo sencillo. Sin lógica de negocio compleja, sin grandes ambigüedades. Una solución directa. Y eso mismo nos había llegado a nosotros: un proyecto básico, precio cerrado, plazo definido.

Lo que nadie había hecho era sentarse con el cliente final a preguntarle qué necesitaba de verdad.

El correo que no quería escribir

Antes de que el proyecto se firmara, lo que llegó a nuestras manos ya olía raro.

Los requisitos tenían huecos. No eran imprecisiones menores, eran zonas enteras sin definir donde la lógica de negocio brillaba por su ausencia. Eso, en un proyecto de precio cerrado, es una trampa: cualquier cosa que no esté escrita puede convertirse en una exigencia legítima del cliente, y el coste de resolverla lo asumes tú.

Lo trasladé al PM. Le dije que el proyecto estaba valorado sobre unos requisitos incompletos y que eso nos exponía a situaciones donde nuestro cliente podría pedirnos cosas que, técnicamente, no estaban excluidas del alcance. La respuesta fue seguir adelante. El cliente había firmado, el negocio estaba hecho.

Lo entendí. No era una decisión irracional. Pero mandé el correo igualmente.

No para crear ruido ni para cubrirme las espaldas, aunque también sirvió para eso. Lo mandé porque si no quedaba por escrito que esas zonas grises existían, nadie las iba a ver hasta que se convirtieran en un problema. Y para entonces ya sería tarde para tener la conversación que habría que haber tenido antes.

Esa es una de las incomodidades del trabajo técnico que nadie menciona: a veces lo más útil que puedes hacer es escribir algo que sabes que no va a gustar.

Construir el paracaídas mientras caes

El proyecto se firmó. No había marcha atrás.

Lo primero que hice fue asumir que el desorden externo no podía filtrarse hacia dentro. Si los requisitos eran un caos, la respuesta no era trabajar en caos. La respuesta era exactamente la contraria: más orden, más detalle, más trazabilidad.

Organicé el trabajo en sprints con historias de usuario lo más exhaustivas posible. No para cumplir un proceso, sino porque una historia de usuario bien escrita es también un límite: define qué entra y qué no, y cuando nuestro cliente pide algo que no está contemplado, tiene un nombre y una referencia. Das las funcionalidades que se nos pedían como “si se puede” las documenté por escrito como lo que eran: peticiones fuera de alcance, comunicadas y registradas. No rechazadas con mala educación, sino declinadas con criterio y dejando rastro.

También hice algo que no siempre me permito: parar un momento antes de empezar a construir e invertir tiempo en buscar herramientas ya hechas que cubrieran partes del problema. No era el momento de reinventar nada. Era el momento de ir rápido siendo listo, no siendo heroico.

Aun así, cuando terminé de estimar todo lo que había que hacer, la conclusión fue incómoda: no cabía ni una cuarta parte del trabajo real dentro del tiempo que se había vendido. Eso también lo documenté. No para levantar una queja, sino porque si en algún momento había que tomar decisiones sobre qué recortar, que fuera una decisión informada y no una sorpresa.

Lo único que no toqué

Recorté en muchos sitios. Fue necesario y fue consciente.

Recorté en el tiempo de refinamiento de algunas funcionalidades. Recorté en el nivel de pulido de partes del sistema que el usuario final probablemente nunca vería. Acepté que algunas cosas iban a salir al 80% cuando podrían haber salido al 100% con más tiempo.

Pero no toqué la arquitectura.

Esto puede sonar a decisión de principios. En parte lo es. Pero también es una decisión de números: sacrificar la escalabilidad del sistema por ganar semanas en el corto plazo es precisamente el tipo de atajo que luego cuesta el doble de reparar. Lo explico con más detalle en otro artículo de este blog, pero la idea es simple: la deuda técnica a nivel de arquitectura no es un coste que aparezca al final del proyecto. Es un coste que se acumula en cada nuevo desarrollo que se hace encima de una base inestable.

El sistema tenía que poder crecer. No porque yo esperara que fuera a crecer de inmediato, sino porque construirlo para que no pudiera crecer era garantizar que el problema explotara más adelante, probablemente en el peor momento posible.

Gracias a eso, el proyecto no tuvo bugs relevantes. Con todo lo que había en contra, eso no es un detalle menor.

Preguntar al que nadie preguntaba

La reunión con el cliente final fue la que cambió el rumbo de lo que quedaba por construir.

Hasta ese momento, todo lo que sabíamos del usuario final nos había llegado filtrado a través de nuestro cliente. Y nuestro cliente, con toda la buena fe del mundo, había interpretado lo que su usuario necesitaba según lo que él entendía que era posible, razonable o prioritario. No es mala intención. Es lo que pasa cuando alguien habla por otro sin suficiente información.

Después de esa reunión, empujamos para que nuestro cliente hablara directamente con su usuario final antes de cada decisión relevante. No una vez, sino de forma sistemática. Que preguntara. Que no asumiera. Que volviera con respuestas concretas antes de darnos instrucciones.

Eso fue lo que permitió redirigir el desarrollo hacia algo que el cliente final iba a usar de verdad. Hubo funcionalidades que estaban en el plan inicial y que se descartaron porque, al preguntar, resultó que nadie las necesitaba. Y hubo otras que no estaban contempladas y que sí aportaban valor real. Ese intercambio de información, tarde pero presente, fue lo que salvó la utilidad del producto.

El cliente final terminó con una solución que le servía. Eso, en las circunstancias de este proyecto, no era el resultado esperado. Fue una sorpresa agradable.

Un fracaso que no fue un desastre

Este proyecto no fue rentable. Lo sabíamos antes de terminarlo y se confirmó al cerrarlo.

El fallo de raíz no estuvo en el equipo técnico ni en las decisiones que se tomaron durante el desarrollo. Estuvo antes: en la valoración inicial, en la firma de un precio cerrado sobre unos requisitos vagos, en no haber tenido la conversación con el cliente final antes de comprometerse a nada. Mi compañero que tomó los requisitos trabajó con lo que le dieron, que era poco y ambiguo. El problema no fue su análisis. Fue que nuestro cliente nunca tuvo suficiente información para dar.

Pero tampoco fue un desastre.

No lo fue porque las señales de alarma se comunicaron a tiempo, aunque no se escucharon. No lo fue porque el trabajo se organizó con suficiente detalle como para tomar decisiones con criterio cuando había que recortar. No lo fue porque la arquitectura se preservó y eso evitó bugs y deuda acumulada. Y no lo fue porque al final el usuario que tenía que usar el sistema obtuvo algo útil.

Hay proyectos que terminan mal en todos los sentidos. Este terminó mal en lo financiero y razonablemente bien en todo lo demás. Esa diferencia no fue casualidad.

Lo que aprendí no fue una lección técnica. Fue una lección sobre dónde se ganan y se pierden los proyectos. Se ganan o se pierden antes de que el equipo de desarrollo sepa que el proyecto existe: en la conversación con el cliente, en la valoración del alcance, en la decisión de firmar algo que todavía tiene demasiadas preguntas sin respuesta.

Cuando ese momento ya ha pasado y el proyecto está en marcha, lo que queda es gestionar el daño con la mayor inteligencia posible. Documentar, priorizar, preservar lo que no se puede sacrificar y comunicar todo lo demás por escrito.

No es lo mismo que haberlo hecho bien desde el principio. Pero es la diferencia entre un proyecto que termina mal y uno que termina en catástrofe.