Cómo escribimos una propuesta de proyecto que el cliente entiende (y aprueba)

Hace un tiempo mandamos una propuesta de 40 páginas a un cliente. Diagramas, anexos, tres alternativas de arquitectura comparadas en detalle. Nunca nos respondieron. Dos semanas después mandamos una de 4 páginas a otro cliente, con el mismo alcance de fondo, y la aprobó el mismo día de la reunión.

La diferencia no era el precio ni la calidad técnica. Era que la segunda propuesta se podía leer, entender y defender delante de un jefe en cinco minutos. La primera necesitaba un traductor.

El problema de las propuestas técnicas típicas

La mayoría de propuestas que vemos —de otros proveedores, o las que nosotros mismos escribíamos hace años— cometen tres errores que las matan antes de que nadie decida nada:

• Demasiada jerga, cero contexto de negocio: hablan de "migración a arquitectura de microservicios con service mesh" cuando el cliente solo quiere saber si su web va a dejar de caerse los lunes.
• Alcance sin fin: "y cualquier otra tarea necesaria para el buen funcionamiento del proyecto" es la frase que convierte un presupuesto cerrado en una fuente infinita de conflictos.
• El precio escondido en la página 35: si el cliente tiene que buscar cuánto cuesta, ya has perdido media confianza antes de empezar.

Qué incluye una propuesta de Opsteam

Cada propuesta que enviamos tiene las mismas seis secciones, sin excepción:

1. Diagnóstico inicial: en una página, qué hemos visto en tu infraestructura o proceso actual y por qué duele.
2. Alcance y fases: qué vamos a hacer, dividido en fases con entregables propios —nunca un bloque monolítico de "proyecto completo".
3. Entregables concretos: no "mejoras en la infraestructura", sino "pipeline de CI/CD en GitHub Actions con despliegue automático a staging y aprobación manual a producción".
4. Timeline realista: con margen de contingencia explícito, no la fecha optimista que nadie cumple.
5. Inversión y modelo de facturación: en la primera página, no en un anexo.
6. Riesgos y supuestos: qué cosas asumimos que son verdad y qué puede hacer que el plan cambie.

De la conversación a la propuesta: nuestro proceso

Antes de escribir una sola línea de la propuesta, pasamos por un proceso fijo:

1. Llamada de diagnóstico (30-45 min): escuchamos el problema real, no el que viene en el brief. Casi nunca coinciden.
2. Documento de alcance interno: lo escribimos nosotros primero, sin filtro comercial, para tener claro qué es técnicamente razonable.
3. Propuesta formal por fases: la convertimos en el documento que llega al cliente, con las seis secciones de arriba.
4. Revisión conjunta: una llamada para repasarla juntos, no un email con el PDF adjunto y silencio después.
5. Ajuste y aprobación: casi ninguna propuesta se aprueba tal cual sale la primera vez, y eso está bien.

Fases típicas que proponemos

Errores que evitamos a propósito

• Precios ocultos o "a confirmar": si no sabemos el precio con certeza, lo decimos y explicamos qué falta por definir para darlo.
• Alcance infinito: cada fase tiene un "esto no incluye" explícito, para que ampliar el alcance sea una decisión consciente, no una sorpresa.
• Fechas sin contingencia: añadimos un margen realista y lo explicamos, en vez de prometer una fecha que sabemos que vamos a incumplir.
• Omitir los riesgos: si hay algo que puede salir mal —una dependencia externa, un acceso que no tenemos, una decisión pendiente del cliente— lo escribimos antes de que pase, no después.

Conclusión

Una buena propuesta no vende el proyecto. Lo explica tan bien que venderlo deja de ser necesario. El cliente no está comprando un PDF bonito, está comprando la confianza de que entendemos su problema y tenemos un plan concreto para resolverlo.

Una vez aprobada, el siguiente paso no es abrir la terminal: es el diseño de alto nivel (HLD), que convierte esa propuesta en una arquitectura concreta.