Cuando llegan tres propuestas en respuesta a un pliego, lo primero que pasa es que cada una está estructurada distinto. Una manda 12 páginas con metodología y currículum del equipo. Otra, una hoja Excel con horas y tarifas. La tercera, un PDF con diagramas, plan en fases y referencias. Compararlas leyéndolas en orden no funciona. Hace falta llevar las tres al mismo terreno antes de decidir.
Este es el método que usamos cuando un cliente nos pide ayuda para evaluar ofertas. No requiere conocimiento técnico profundo, pero sí pasar por una matriz de criterios y rellenarla con datos concretos.
La matriz de criterios
Los nueve bloques siguientes cubren el 90% de los riesgos en un proyecto de software a medida. Cada propuesta se puntúa de 0 a 3 en cada bloque, con anotaciones específicas. Un cero no significa "mala": significa "no se puede evaluar porque no hay información suficiente". Esa distinción es clave.
| Criterio | 0 (información ausente) | 1 (mínimo) | 2 (sólido) | 3 (excelente) |
|---|---|---|---|---|
| Comprensión del negocio | Solo describe la tecnología | Repite el pliego | Reformula con matices propios | Aporta entendimiento que el pliego no tenía |
| Alcance funcional | No se mapea contra el pliego | Cubre lo escrito | Cubre y aclara dudas | Cubre, aclara y propone mejoras justificadas |
| Arquitectura propuesta | No se describe | Stack mencionado | Diagrama y justificación breve | Diagrama, alternativas y justificación de la elegida |
| Plan de proyecto | Fechas globales | Fases con duración | Hitos por fase con entregables | Hitos, dependencias, riesgos identificados |
| Equipo asignado | Sin nombres ni perfiles | Roles genéricos | Roles con CV resumen | Personas concretas con dedicación clara |
| Coste y forma de pago | Solo total | Desglose por fase | Desglose por fase y partida | Desglose por fase, partida y supuestos |
| Garantía y soporte | No se menciona | Soporte de meses contado | Soporte con SLA y alcance | Soporte, SLA, alcance y exclusiones |
| Tecnologías y propiedad | Stack ambiguo | Stack claro | Stack claro y código entregado | Stack, código entregado y portabilidad |
| Riesgos identificados | No se mencionan | Genéricos | Específicos del proyecto | Específicos con plan de mitigación |
Se rellenan tres columnas (una por agencia) y se suman los totales. Una agencia con 18 puntos sobre 27 va sólida. Una con 9 hay que revisar antes de descartar (puede que tenga buen producto pero mala redacción de propuestas, o al revés).
Comentario por criterio
Comprensión del negocio. Es la parte que más distingue a una agencia que va a trabajar contigo durante meses de una que va a entregar y desaparecer. La agencia que llega y reformula el problema con sus propias palabras (a veces incluso corrigiendo cosas mal expresadas en el pliego original) está demostrando que ha pensado en el caso. La que copia y pega las primeras tres páginas del pliego en su propuesta solo está haciendo ruido.
Alcance funcional. El error típico aquí es que la agencia añade "fuera de alcance" como un párrafo al final con una lista vaga. La forma correcta es ir bloque por bloque del pliego diciendo qué incluye, qué da por entendido y qué deja explícitamente fuera. Si una propuesta no permite saber qué módulos están dentro y cuáles fuera al detalle, es imposible compararla con otra.
Arquitectura propuesta. No hace falta entender el detalle técnico, pero sí debe haber un diagrama de un nivel razonable. Si una agencia propone "una solución web moderna con base de datos" y otra propone "API REST en Node, frontend Next.js, base de datos PostgreSQL en RDS, despliegue en Kubernetes con observabilidad mediante Grafana", la segunda está demostrando que sabe lo que va a construir. La primera podría estar improvisando.
Plan de proyecto. Aquí se ven los riesgos. Una propuesta con "primera entrega a los dos meses, segunda a los cuatro, cierre a los seis" no es un plan, es un calendario. Un plan razonable identifica qué hito desbloquea al siguiente, qué pasa si una pieza se retrasa y dónde están los puntos de validación con el cliente. Si en el cronograma todo va seguido y nadie valida nada hasta el final, el riesgo es alto.
Equipo asignado. Una agencia que en propuesta cita "equipo senior de 8 personas" sin nombres ni perfiles está dejándose un margen de maniobra que no te conviene. La que dice "asignamos a Pedro como técnico líder, Marta como analista funcional y dos developers junior con dedicación X horas/semana" está comprometiéndose. La diferencia es enorme cuando empieza el proyecto y descubres que no es Pedro quien llega, sino un becario.
Coste y forma de pago. El total no es el único dato relevante. Importa el desglose: cuánto cuesta cada fase, qué partidas hay (desarrollo, integración, formación, soporte). También importan los supuestos del precio: si la propuesta dice "asumimos que las APIs externas tienen documentación", eso es un riesgo no cubierto. La forma de pago también: nadie debería pagar más del 30-40% al inicio sin haber visto entregables.
Garantía y soporte. Las garantías genéricas de "tres meses de bugfixing" no dicen mucho. Lo que dice es: ¿cuánto tiempo estás cubierto?, ¿cubre solo errores reproducibles del software entregado o también ajustes funcionales?, ¿qué tiempos de respuesta tiene la garantía?, ¿qué pasa cuando se acaba? Una propuesta sin estas respuestas te deja expuesto.
Tecnologías y propiedad. Se asume que el código es del cliente, pero conviene comprobarlo. ¿La agencia entrega el código fuente?, ¿bajo qué licencia?, ¿se puede llevar a otro proveedor?, ¿usa librerías propias de la agencia o todo es estándar abierto?, ¿hay dependencias de servicios cloud propietarios que solo la agencia gestiona? La portabilidad debería estar contestada antes de firmar.
Riesgos identificados. Las propuestas serias dedican una sección a riesgos. Los típicos son: dependencia de información que el cliente debe aportar, integración con sistemas legacy poco documentados, requisitos no funcionales ambiguos. Una agencia que escribe sobre los riesgos del proyecto está siendo honesta. Una que dice "no prevemos riesgos" está mintiendo o no ha leído el pliego.
Señales de alarma frecuentes
Independientemente de la matriz, hay frases que aparecen en propuestas problemáticas y conviene saber leer entre líneas.
"Estimación a refinar tras kick-off." Significa: el precio no es definitivo, lo subiremos cuando entendamos mejor. Si lees esto y vas a firmar un cierre cerrado, no lo es.
"Equipo senior con experiencia." Sin nombres concretos, esto es marketing. La asignación real puede ser otra muy distinta.
"Metodología ágil con sprints quincenales." En sí no es alarma, pero si esta es toda la información sobre el plan, hay un agujero. Ágil no significa "sin plan": significa que el plan se adapta. Necesitas saber cuál es el plan inicial.
"Garantía de calidad ISO 9001." Las certificaciones son un sello, no una garantía contractual concreta. Más vale una cláusula clara en el contrato que tres certificaciones impresas.
Propuesta más barata por mucho que la siguiente. Un descuento del 15-20% es normal por estrategia comercial. Un 50% por debajo del resto suele significar que están mirando el proyecto de forma distinta. Pregunta antes de elegir.
Plan donde todo va seguido sin validaciones. Las propuestas serias incluyen revisiones intermedias con el cliente. Las que no, suelen acabar con sorpresas en el lanzamiento.
Soporte como bloque vacío. Si la propuesta no detalla qué cubre el soporte ni durante cuánto tiempo, asume que vas a pagar todo lo que pase después de la entrega.
Cómo cerrar la decisión
Cuando tienes la matriz rellena y sumada, raramente la agencia ganadora es la más barata o la más cara: suele ser la del medio, la que ha equilibrado bien comprensión, plan, equipo y coste. Si la suma da empate o muy cerca, lo desempata el factor humano: con qué agencia preferirías hablar dos veces por semana durante seis meses cuando aparezcan los problemas inevitables.
La matriz no decide por ti. Hace visible qué estás contratando.