Cómo evaluar una cotización de desarrollo de software
Una cotización de software se evalúa por lo que no dice: supuestos, exclusiones y quién asume el riesgo. Cuatro cifras que debe pedir siempre y las señales de que el precio se va a mover.
Read in English →Una cotización de desarrollo no se evalúa comparando el total contra otro total. Se evalúa por lo que la propuesta no dice: qué supuestos hizo el proveedor para llegar a ese número, qué quedó fuera del alcance y quién paga cuando la realidad no coincida con el supuesto.
Esta es la revisión que hacemos antes de que un cliente firme. Sirve igual si la hace usted mismo.
Las cuatro cifras que debe pedir siempre
Un total no es información. Pida que la propuesta se abra en cuatro dimensiones, porque cada una revela un tipo distinto de riesgo:
- Horas por rol y por fase. No “400 horas de desarrollo”, sino cuántas de arquitectura, cuántas de implementación, cuántas de pruebas y cuántas de despliegue. Si las pruebas son menos del 20% del total, o el proveedor las hace en su cabeza o no las va a hacer.
- Costo de infraestructura mensual estimado. Separado del desarrollo. Un sistema puede costar 80 millones de pesos construirlo y 12 millones anuales mantenerlo prendido, y esa segunda cifra casi nunca aparece en la propuesta.
- Costo de los cambios. La tarifa hora de un requerimiento nuevo una vez arrancado el proyecto. Si no está escrita, se negocia cuando usted ya no tiene poder de negociación.
- Costo de salida. Qué pasa si termina la relación en el mes seis: quién se queda con el código, en qué repositorio vive, quién tiene las credenciales de producción.
La cuarta es la que más se omite y la más cara de descubrir tarde.
El alcance se lee en las exclusiones
En una propuesta bien hecha, la sección de exclusiones es tan larga como la de entregables. Cuando no existe esa sección, no significa que todo esté incluido: significa que la discusión se aplazó.
Busque específicamente si están dentro o fuera:
- Migración de los datos que ya existen (casi siempre subestimada; suele ser el 15–30% de un proyecto de reemplazo).
- Integraciones con sistemas de terceros, incluyendo el tiempo de espera por credenciales y ambientes de prueba ajenos.
- Capacitación a usuarios y documentación de operación.
- Corrección de defectos después de la salida a producción, y por cuánto tiempo.
- Ambientes: ¿la propuesta incluye desarrollo, pruebas y producción, o solo producción?
Señales de que el precio se va a mover
| Señal en la propuesta | Lo que suele significar |
|---|---|
| Estimación en números redondos (100, 200, 500 horas) | No se descompuso el trabajo; el número es una intuición |
| No hay supuestos escritos | Cualquier hallazgo será un cambio facturable |
| El equipo se describe por perfiles, no por personas | No hay nadie asignado todavía; la disponibilidad es una promesa |
| El plazo es exactamente el que usted pidió | Se ajustó la estimación al deseo, no al trabajo |
| “Metodología ágil” sin definir cadencia ni entregables por sprint | Ágil como excusa para no comprometer alcance |
| Un solo hito de pago al final | Suena bien para usted, pero implica que el proveedor financia el proyecto: o el precio lo incluye, o el flujo de caja lo va a apretar |
Ninguna de estas señales invalida una propuesta por sí sola. Tres o más juntas sí: significan que el número no está soportado por un análisis, y un número sin análisis se mueve.
Las preguntas que cambian la conversación
Estas cuatro preguntas, hechas por escrito, reordenan cualquier negociación:
“¿Qué supuestos hizo para llegar a esta estimación?” Obliga a explicitar lo que estaba implícito. Las respuestas que empiezan con “asumimos que ustedes van a…” son las que hay que revisar con su equipo interno, porque son compromisos suyos que todavía no sabía que había adquirido.
“¿Qué parte de este alcance es la que más incertidumbre tiene?” Un proveedor con experiencia responde en diez segundos y con precisión. Uno que responde “todo está claro” no ha analizado el problema, o no quiere decirle dónde está el riesgo.
“Si tuviera que entregar en la mitad del tiempo, ¿qué quitaría?” La respuesta le muestra qué considera el proveedor esencial y qué considera relleno. A veces descubre que el 40% del alcance era relleno para justificar el precio.
“¿Quién específicamente va a trabajar en esto y en qué más está esa persona?” La diferencia entre un equipo dedicado y uno compartido son semanas de calendario que nadie coloca en la propuesta.
Qué hacer con las respuestas
Si el proveedor responde las cuatro con precisión y por escrito, la propuesta probablemente esté bien construida aunque el precio sea alto — y un precio alto bien soportado es más barato que un precio bajo que se va a mover.
Si evade dos o más, el problema no es el precio: es que no hay un análisis detrás, y usted estaría firmando una intención.
Lo que no recomendamos nunca es negociar el total hacia abajo sin cambiar el alcance. El proveedor va a aceptar y va a recuperar la diferencia en algún lado: menos pruebas, un perfil más junior, o la primera solicitud de cambio. El precio bajó en el papel y el riesgo subió en la realidad.
Si tiene una propuesta sobre la mesa y quiere una segunda lectura antes de firmar, escríbanos. No ejecutamos desarrollo, así que no tenemos un proyecto que venderle en reemplazo.
Preguntas frecuentes
- ¿Cuánto debería costar un proyecto de software?
- No existe un precio de referencia por tipo de proyecto: dos propuestas para el mismo sistema pueden diferir tres veces y ambas ser razonables, porque cotizan alcances distintos. Lo que sí se puede evaluar es la coherencia interna de una propuesta: si las horas estimadas corresponden al alcance descrito, si el equipo propuesto puede ejecutarlas en el plazo ofrecido, y si los supuestos están escritos.
- ¿Es mala señal que una cotización sea mucho más barata que las otras?
- No siempre, pero obliga a preguntar por qué. Las tres razones habituales son: el alcance entendido es menor, el proveedor está comprando el contrato para recuperar el margen en los cambios, o hay una subestimación real por falta de experiencia en ese dominio. La primera se resuelve alineando el alcance; las otras dos terminan costando más que la propuesta cara.
- ¿Qué diferencia hay entre precio fijo y bolsa de horas?
- El precio fijo traslada el riesgo de estimación al proveedor y por eso incluye un margen de contingencia; funciona cuando el alcance está cerrado. La bolsa de horas deja ese riesgo en el cliente y funciona cuando el alcance va a cambiar. El error caro es firmar precio fijo sobre un alcance que todavía se está descubriendo: cada hallazgo se convierte en un cambio facturado.