Si alguna vez has encargado un proyecto de software y has visto la factura final superar el presupuesto inicial, formas parte de una gran mayoría. Los estudios sitúan sistemáticamente entre el cincuenta y el ochenta por ciento la tasa de proyectos de software que se pasan de presupuesto, según el tamaño y el sector. La explicación habitual de las agencias y los desarrolladores: el software es complejo, las estimaciones son por naturaleza inciertas, los requisitos evolucionan. Todo esto es verdad. Pero no es toda la historia.
La historia completa es que la mayoría de los desvíos son evitables. Provienen de causas específicas y recurrentes - y si las entiendes antes de firmar un contrato, puedes protegerte de la mayoría de ellas.
La causa real: el descubrimiento tardío
Todo proyecto de software comienza con un entendimiento compartido de lo que hay que construir. Ese entendimiento es siempre incompleto. No porque nadie sea descuidado, sino porque la complejidad total de un problema rara vez se revela hasta que empiezas a resolverlo.
A medida que avanza el desarrollo, aparecen requisitos ocultos. Una integración que parecía sencilla resulta depender de una API antigua sin documentación. Un flujo de trabajo que parecía simple tiene doce casos límite que nadie pensó en mencionar. Un requisito regulatorio surge en el tercer mes y cambia cómo deben almacenarse los datos.
Cada uno de estos descubrimientos es un cambio de alcance. Y los cambios de alcance cuestan dinero - el coste directo de construir el nuevo requisito, más el coste de rehacer lo que se había construido basándose en el entendimiento original e incompleto. Ninguno de estos costes estaba en la estimación inicial, porque ninguno era conocido entonces.
Este no es principalmente un problema de desarrolladores. Es un problema de descubrimiento. Cuanto más a fondo entienden ambas partes el problema antes de que empiece el trabajo, menos sorpresas aparecen durante el desarrollo, y más se acerca el coste final a la estimación inicial. Las agencias que invierten seriamente en descubrimiento antes de presupuestar dan estimaciones más precisas. No es magia - es información.
La segunda causa: cambiar de opinión
Los requisitos de negocio evolucionan. El producto que querías en el mes uno no es idéntico al que quieres en el mes tres. Llega nueva información. Las condiciones del mercado cambian. Un competidor lanza algo que modifica tus prioridades. Tu propio equipo prueba una versión inicial y se da cuenta de que el concepto original necesita replantearse.
Esto no es un fracaso - es normal. Pero cada cambio tiene un coste, y la mayoría de los clientes subestiman con qué rapidez se acumulan los pequeños cambios.
Una solicitud de modificación que parece menor - "¿podemos añadir un filtro aquí?" o "¿podemos mover este paso en el flujo?" - puede propagarse por el sistema de maneras no visibles desde fuera. Añadir un filtro puede requerir cambios en el esquema de base de datos, la API, el componente front-end y las pruebas. Lo que parece una petición de una hora puede llevar dos días cuando se tienen en cuenta todos los efectos en cadena.
La disciplina necesaria no es no cambiar nunca de opinión - es tomar decisiones lo antes posible, cuando los cambios son baratos, y tener un proceso claro y acordado para gestionar los cambios cuando ocurren a mitad de proyecto.
La tercera causa: incentivos desalineados
Algunas agencias infravaloran deliberadamente sus estimaciones para ganar contratos. Saben que la estimación es optimista. Planean recuperar la diferencia en órdenes de cambio, que se facturan a tarifas más altas y con menos presión de precio que el contrato original. El cliente firma porque el número en la portada parece razonable. La agencia gana porque ese número nunca fue pensado como el número final.
Esto no es universal. La mayoría de las agencias no operan así. Pero ocurre con suficiente frecuencia como para que un presupuesto que parece sospechosamente barato merezca ser examinado. Pregunta dónde están los supuestos. Pregunta qué no está incluido. Pregunta cuál es la tasa histórica de órdenes de cambio de la agencia.
Una agencia verdaderamente transparente debería poder responder todas estas preguntas con claridad. Una agencia que esquiva o se vuelve vaga cuando profundizas en la estructura de la estimación merece ser tratada con cautela.
Lo que realmente controla el coste
Los desvíos de presupuesto no son aleatorios. Son causados por condiciones específicas, y esas condiciones pueden abordarse.
Un descubrimiento profundo antes de que empiece el trabajo es el control de costes más eficaz. Cuanto más tiempo invierten ambas partes en entender el problema - a través de talleres, revisiones de procesos, entrevistas con interesados, auditorías técnicas - menos sorpresas hay durante el desarrollo. Este tiempo inicial tiene un coste, pero sistemáticamente se amortiza.
Una documentación clara del alcance también importa. Una especificación detallada y acordada por ambas partes crea un punto de referencia compartido. Cuando surge una pregunta a mitad de proyecto sobre si algo está dentro o fuera del alcance, la respuesta viene del documento, no de la memoria o la interpretación.
Un proceso definido para órdenes de cambio evita que la expansión del alcance se vuelva invisible. Cada cambio solicitado debe ser evaluado, presupuestado y aprobado antes de que empiece el trabajo - incluso si el cambio parece pequeño. Puede sonar burocrático, pero es el mecanismo que mantiene el coste visible y bajo control.
Revisiones periódicas antes de que los problemas se agraven mantienen a ambas partes alineadas. Una conversación semanal sobre el progreso, los bloqueos y las decisiones próximas cuesta una hora. Descubrir un problema significativo tres semanas después de que empezó cuesta mucho más.
Preguntas que hacer antes de firmar
Antes de comprometerte con cualquier proyecto de software, vale la pena hacer estas preguntas directamente a la agencia:
¿Cómo gestionáis los requisitos descubiertos a mitad de proyecto? Quieres escuchar que tienen un proceso claro - no que "ya lo resolveremos".
¿Cuál es vuestro proceso para las órdenes de cambio? Entiende cómo se identifican, presupuestan y aprueban los cambios. Si el proceso es vago, los costes también lo serán.
¿Podéis mostrarme un proyecto en el que el coste final coincidiera con la estimación inicial? No para encontrar un historial perfecto - los desvíos ocurren - sino para ver cómo habla la agencia de ello. ¿Asumen responsabilidad, explican lo que pasó y describen lo que aprendieron? ¿O culpan al cliente?
¿Qué incluye vuestra fase de descubrimiento? La profundidad y estructura del descubrimiento antes de presupuestar es una de las señales más fiables de cuán precisas son las estimaciones de una agencia.
¿En qué supuestos se basa vuestra estimación? Cada estimación tiene supuestos. Quieres conocerlos antes de firmar, no después.
Transparencia desde el principio
Los proyectos de software se pasan de presupuesto cuando el problema está mal entendido, cuando los requisitos evolucionan sin un proceso claro para gestionar el cambio, o cuando los incentivos entre agencia y cliente no están alineados. Las tres condiciones pueden abordarse antes de que empiece el trabajo.
Construimos transparencia en cada proyecto desde el principio - lo que significa una fase de descubrimiento real antes de cualquier presupuesto, documentación clara de lo que está y no está incluido, y un proceso estructurado para gestionar los cambios cuando surjan. Si quieres entender cómo es eso en tu situación concreta, contáctanos.