Voy a contar el peor proyecto que acepté, sin adornarlo, porque las lecciones que me dejó son las que hoy protegen a mis clientes. No fue por el código. Fue por todo lo que no dije que no a tiempo.
Cómo empezó (y las señales que ignoré)
El cliente llegó con prisa, un presupuesto cerrado en la cabeza que no encajaba con lo que pedía, y la frase que debería haber sido una alarma: "es muy sencillo, solo es una cosita". Acepté porque necesitaba el trabajo y porque me convencí de que podría apañarlo sobre la marcha. La primera lección es que casi nunca es una cosita, y que cuando el alcance no está claro y el plazo ya está fijado, el que pierde es siempre el que construye.
Hubo más señales. No había una sola persona que pudiera decidir; cada semana cambiaba el criterio según con quién hablara. Y el proyecto dependía de un sistema antiguo del que nadie tenía documentación. Cada una de esas señales, por separado, es gestionable. Juntas, son una tormenta.
Lo que salió mal
Maquillé la estimación para que cupiera en el presupuesto del cliente, en lugar de decirle la verdad: que con ese alcance y ese plazo no salía. A mitad de proyecto, el coste real se comió el margen y parte de mi tiempo personal. Entregué algo que funcionaba a medias, el cliente quedó descontento con razón, y yo aprendí la lección más cara de mi carrera: una venta que se cierra rompiendo la honestidad sobre el alcance no es una venta, es una deuda.
Lo que cambié para siempre
Desde entonces, presupuesto cerrado antes de empezar y, si me equivoco con la estimación, la pérdida es mía, no del cliente. Eso me obliga a acotar bien el alcance antes de dar un número, que es exactamente lo que protege al cliente. Si un proyecto no encaja, lo digo antes de cobrar nada. Y si no tengo claro el estado de un sistema heredado, propongo una auditoría técnica de 190 € antes de comprometer un proyecto entero a ciegas.
También aprendí a decir que no. No a todos los proyectos, sino a los que tienen las señales de aquel: alcance difuso con plazo fijo, sin un interlocutor que decida, y dependencias que nadie controla. Decir que no a tiempo es la forma más honesta de cuidar tanto al cliente como a tu propio trabajo.
Qué deberías sacar de esto si vas a contratar
Si vas a contratar software, desconfía de quien te da un número sin haber entendido tu problema, y desconfía todavía más de quien acepta tu plazo y tu presupuesto sin matizar nada. El proveedor que te dice "esto no entra en ese presupuesto, pero esto sí" te está cuidando. El que dice a todo que sí te está vendiendo una deuda. Lee también nuestra guía sobre cómo elegir empresa de desarrollo de software.
Preguntas frecuentes
¿Por qué contar un proyecto que salió mal?
Porque las lecciones de un proyecto fallido protegen mejor a un cliente que cualquier argumentario de ventas. La honestidad sobre los errores propios es parte de cómo trabajamos.
¿Qué es lo más importante para que un proyecto no falle?
Acotar el alcance antes de fijar precio y plazo, tener un interlocutor que decida, y conocer el estado real de los sistemas de los que depende el proyecto. Cuando esas tres cosas están claras, casi todo lo demás se gestiona.
¿Cómo evitáis vosotros este tipo de proyecto?
Con presupuesto cerrado antes de empezar (si nos equivocamos, la pérdida es nuestra), diciendo que no cuando un proyecto no encaja, y proponiendo una auditoría técnica previa cuando hay sistemas heredados sin documentar.
