La función de una propuesta no es convencer, sino demostrar que ambas partes entienden lo mismo. Las propuestas que fallan en esto ganan el proyecto y lo pierden después. Los diez puntos siguientes son el esqueleto de cada propuesta que enviamos.
Estos mismos puntos también le sirven para comparar las propuestas que ya tiene sobre la mesa. Si en dos propuestas aparece «gestión de clientes, informes y panel de administración» y los precios son muy distintos, la diferencia suele venir del trabajo no definido que se esconde detrás de esos títulos.
Una propuesta que no indica qué queda fuera de alcance no es una propuesta; es una disputa aplazada.
01El problema, el alcance y lo que queda fuera
Una propuesta se abre con el problema, redactado con las propias palabras del cliente. Si lo parafraseamos con las nuestras, cualquier malentendido se hace visible de inmediato — lo cual es positivo, porque aparece antes del contrato.
Después viene el alcance, como una lista de elementos — cada uno un entregable, no una intención. El tercer punto es el que más se omite: qué queda fuera de alcance. «Sin aplicación móvil en esta versión», «la introducción de contenido corre a cargo del cliente», «licencias de integración de terceros no incluidas». Redactar esa lista resulta incómodo, y precisamente por eso es valiosa.
02Pregunte por el trabajo que hay detrás del mismo título
En lugar de «queremos un CRM», es mejor empezar diciendo «no sabemos a qué cliente hay que volver a llamar ni cuándo en el seguimiento de propuestas». Cuando el problema se concreta, también se concretan las pantallas y las notificaciones necesarias; así no tendrá que destinar presupuesto a módulos que no va a usar.
La frase «incluye informes» no basta por sí sola. ¿Qué datos, en qué intervalo de fechas y para qué usuario se mostrarán? ¿Hace falta exportación? Si se solicita conexión con su sistema de contabilidad, almacén, pago o ventas, la propuesta debe recoger no solo el nombre de la integración, sino también la dirección del flujo de datos, las condiciones técnicas de acceso y qué ocurre en caso de error.
03Calendario, hitos y responsabilidades del cliente
Expresamos el calendario en hitos en lugar de números de semana: aprobación del diseño, publicación interna, pruebas de aceptación, salida a producción. Cada hito tiene un entregable y un responsable de aprobación con nombre. Las fechas dependen de los hitos, no al revés.
El quinto punto son las responsabilidades del cliente, origen de la mayoría de los retrasos: archivos de marca, acceso al dominio, credenciales para la integración contable, textos de contenido, datos de prueba realistas. Incluir esto en la propuesta con fechas no busca repartir culpas; permite que ambas partes planifiquen.
04Pregunte por la primera versión funcional en una entrega por fases
Pregunte qué trabajo podrá realizar con la primera versión funcional. Por ejemplo, una empresa de servicios podría empezar usando la creación de órdenes de trabajo, la asignación de técnicos y el seguimiento del estado; los análisis más completos pueden abordarse en una fase posterior. Este es un ejemplo representativo; el orden correcto lo determinan las prioridades de su negocio. Explicamos cómo mantener pequeña y completa la primera versión en nuestro artículo cómo lanzar una idea de software con un MVP.
La propuesta también debe recoger cómo se gestionarán los cambios. Es natural que surjan nuevas ideas durante el desarrollo, pero añadir cada nueva petición de forma invisible dentro del plazo existente no es fiable. Debe mostrarse el efecto del cambio sobre el coste, el plazo y el resto de funciones.
05Condiciones de datos, permisos y código fuente
El personal, los administradores y los clientes no deben ver la misma información. La transferencia y las copias de seguridad de los datos, la entrega del código fuente y las licencias de terceros deben hablarse con claridad. Es importante saber de antemano qué archivos y accesos se entregarán al finalizar el proyecto; detallamos cómo lo hacemos en nuestro artículo qué incluye el paquete de entrega de software llave en mano.
06Precio, plan de pagos, garantía y entrega
El precio va acompañado de un plan de pagos ligado a hitos, no al calendario. La moneda, el tratamiento del IVA y la fecha en que se fija el tipo de cambio se indican explícitamente — para clientes de la UE, esa sola línea elimina la mitad de la correspondencia posterior.
Los tres últimos puntos: el periodo de garantía y lo que cubre, el contenido del paquete de entrega, y la fecha de caducidad de la propuesta. Esa caducidad no es una táctica de presión — nos permite responder con honestidad cuando, tres meses después, alguien pregunta si sigue vigente.
La corrección de errores, el desarrollo de nuevas funciones y el mantenimiento son trabajos distintos. En lugar de una frase amplia como «soporte incluido», pida que se defina el alcance y la forma de comunicación. En nuestro alcance llave en mano, instalamos el software acordado en un servidor que cumpla los requisitos técnicos, lo probamos y lo entregamos en funcionamiento. Ofrecemos una garantía de corrección de errores de 12 meses desde la entrega; las nuevas funciones se evalúan por separado. El soporte estándar se presta en horario laboral; un paquete de soporte de 24 horas y un contrato de mantenimiento anual, ambos independientes, pueden evaluarse de forma opcional. Ofrecemos nuestro servicio de desarrollo de software a medida con este alcance.
07Al comparar propuestas, busque estos siete puntos
- Que el problema por resolver esté escrito antes que la lista de módulos que se van a comprar
- Que los escenarios de usuario incluidos en el alcance estén definidos con datos, intervalo de fechas y permisos
- Que las integraciones se expliquen con su dirección, su acceso y qué ocurre en caso de error
- Que se indique qué trabajo se completará en la primera versión funcional y cuál es el criterio de aceptación
- Que la transferencia de datos, los permisos, la entrega del código fuente y las licencias estén especificados con claridad
- Cómo se mostrará el efecto de las solicitudes de cambio sobre el coste y el plazo
- Que la garantía, el soporte y el mantenimiento estén definidos por separado
Escrito por
El equipo de Paradigma7
Producto, ingeniería y operaciones
Somos un equipo con sede en Ankara que construye software para Europa. Nada aquí es teoría: estos son los procesos que realmente ejecutamos en proyectos de clientes.
Sobre nosotros