Qué debe incluir una propuesta de desarrollo de software

Una propuesta de desarrollo no es una cotización con más hojas. Es el documento que va a definir qué se construye, qué pasa cuando algo cambia y qué queda tuyo al final.

Estas son las secciones que conviene exigir, y por qué cada una importa.

Las nueve secciones

1. El problema, contado por quien propone

Debe estar escrito con sus palabras, no copiado de tu correo. Es la única forma de saber si entendió, y es donde aparecen las diferencias entre propuestas que después explican las diferencias de precio.

2. El alcance, con lo que queda fuera

La lista de lo que se construye y, explícitamente, la lista de lo que no. La segunda es más útil que la primera: un alcance se entiende mejor por sus límites.

Si la propuesta dice «módulo de gestión» sin detallar qué contiene, ahí hay una conversación pendiente que va a ocurrir cuando ya estés comprometido.

3. Los supuestos

Qué está dando por hecho: que los datos vienen limpios, que el sistema externo tiene documentación, que tú entregas los textos, que hay una persona disponible para responder dudas.

Los supuestos son las condiciones bajo las cuales el precio es válido. Sin ellos escritos, cualquier desvío es una discusión.

4. Las etapas y qué se entrega en cada una

Con fechas relativas al inicio, no absolutas, porque la fecha de inicio depende de la firma. Y con algo concreto al final de cada etapa que puedas abrir y probar.

Una propuesta que solo entrega al final es una propuesta donde los malentendidos se descubren tarde.

5. El precio, separado por etapa

No un número único. Separado permite ver dónde está el peso del proyecto y, si hace falta, recortar una etapa sin renegociar todo.

Debe decir también qué incluye y qué se factura aparte: infraestructura, licencias, cuentas de tiendas.

6. Cómo se manejan los cambios

Todos los proyectos tienen cambios. Lo que distingue a una propuesta seria es que diga de antemano cómo se cotizan y quién los aprueba, no que prometa que no habrá.

7. Propiedad del código y la infraestructura

Debe decir que el código es tuyo, que las cuentas van a tu nombre y qué se entrega al terminar. Si el proveedor usa componentes propios previos, debe decir bajo qué licencia te los deja. Está desarrollado en quién debe ser propietario del código.

8. Qué pasa después de la entrega

Cuánto tiempo de garantía hay para corregir errores, qué se considera error y qué se considera mejora, y qué cuesta la mantención después.

La distinción entre error y mejora es la que más discusiones evita.

9. Qué pasa si el proyecto se detiene

Por cualquiera de las dos partes. Qué se entrega, en qué estado, y cómo se liquida lo pagado.

Señales de una propuesta incompleta

• Un precio único sin desglose.
• Ninguna sección de exclusiones.
• Ningún riesgo ni supuesto mencionado.
• Plazos que no cambian aunque el alcance sí.
• No dice de quién es el código.
• Es idéntica a la que le enviarían a cualquier otro cliente.

Ninguna descarta a nadie por sí sola. Todas son motivo para pedir que se complete antes de firmar, y la respuesta a esa petición dice bastante.

Sobre las propuestas muy cortas

Una propuesta breve no es necesariamente mala, y una larga no es necesariamente completa. Hay documentos de treinta páginas que no dicen qué queda fuera.

La prueba es concreta: con esta propuesta en la mano, ¿podría un tercero saber si lo entregado corresponde a lo acordado? Si la respuesta es no, falta información, independientemente del largo.

Si quieres una revisión independiente

Revisar propuestas ajenas es uno de los usos más frecuentes de la consultoría tecnológica: qué está incluido, qué quedó fuera sin decirlo, si el plazo es realista y si la tecnología propuesta te deja atado. Antes de eso conviene tener listo lo que hay que preparar para pedir cotizaciones.