Qué debe incluir una propuesta de desarrollo de software

Casi todos los proyectos de software que salen mal ya estaban mal en la propuesta. No por el código, sino porque el papel que se firmó decía «sistema de gestión con inventario y ventas» y cada parte entendía algo distinto. Tres meses después, el cliente espera una función que nunca se cotizó y el proveedor cobra un cambio que el cliente creía incluido.

Una buena propuesta no es un folleto ni un presupuesto con una cifra al final. Es el documento que permite que dos partes que no se conocen trabajen juntas sin sorpresas. Este artículo cuenta qué debe tener, con la estructura que usamos en nuestras propias propuestas.

1. El alcance: qué problema se resuelve, no qué pantallas se dibujan

El alcance abre la propuesta y responde una sola pregunta: qué va a poder hacer tu equipo cuando el sistema esté terminado. No «módulo de ventas», sino «el vendedor registra una venta al contado, a crédito o por mayor, lee el código de barras y el stock se descuenta de la sucursal correcta».

Escrito así, cualquiera puede comprobar al final si se cumplió. Escrito como lista de nombres de módulos, nadie puede.

Un buen alcance también dice para quién es cada parte: quién usa el punto de venta, quién mueve el stock, quién mira los reportes y qué puede ver cada uno.

2. Lo que queda fuera (la parte que casi nadie escribe)

Es la sección más útil y la que más se omite. Una propuesta seria dice con todas las letras lo que no incluye: la migración de datos antiguos, la app nativa además de la web, la integración con el sistema contable, la carga del catálogo, la capacitación de más de un grupo…

Cada línea de esta sección es una discusión que no vas a tener dentro de tres meses. Si una propuesta no tiene esta parte, pide que la agreguen antes de firmar.

3. Los módulos, uno por uno, con su inversión

Después del alcance viene el desglose: cada módulo con lo que hace y lo que cuesta. En una propuesta reciente para el sistema de una importadora, por ejemplo, fueron cuatro bloques: inventarios, ventas, clientes e importaciones, e infraestructura para trabajar desde varias sedes.

Desglosar tiene dos ventajas para ti:

• Puedes ajustar el alcance quitando o dejando para después un módulo, sin rehacer toda la propuesta.
• Ves dónde está el esfuerzo. Si un módulo pequeño cuesta tanto como uno grande, hay una pregunta que hacer.

4. Servidores y alojamiento: dónde va a vivir y quién paga qué

Es la parte que más se olvida y la que más sorprende después. La propuesta debe decir dónde se aloja el sistema, a nombre de quién quedan las cuentas (lo sano es que queden a nombre del cliente), cuánto cuesta el alojamiento cada mes o cada año, y quién lo paga.

También debe decir qué pasa con el dominio, los correos y las copias de seguridad. Un sistema que funciona pero vive en la cuenta personal del programador es un riesgo que no se ve hasta el día que hace falta.

5. El calendario por entregas, no una fecha final

Una fecha de entrega única («listo en tres meses») no te dice nada hasta que llega y no está listo. Un calendario por fases sí: en la propuesta de la importadora fueron ocho semanas en tres fases, con análisis y arquitectura al principio, el desarrollo de los módulos en el medio y las pruebas y la entrega al final.

Lo importante es que cada fase termine en algo que puedas ver y probar: un diagrama que apruebas, un módulo que usas con datos de prueba, una versión que tu equipo maneja antes del lanzamiento. Así corriges el rumbo cuando todavía es barato hacerlo. Es la forma en que trabajamos con cada cliente, y está contada paso a paso en cómo trabajamos.

6. El resumen económico y las condiciones

Al final, el total y cómo se paga. Las condiciones comerciales que conviene ver escritas:

• Forma de pago, idealmente ligada a las entregas y no todo por adelantado.
• Qué incluye el precio y qué se cobra aparte (alojamiento, licencias, cambios).
• Cómo se cotizan los cambios que pidas a mitad del proyecto.
• La garantía: cuánto tiempo se corrigen sin costo los errores de lo entregado.
• La propiedad: el código, los accesos y la documentación pasan a ser tuyos al terminar.
• La confidencialidad, y si tu proyecto lo necesita, un acuerdo de confidencialidad antes de compartir información sensible.

Cómo leer una propuesta antes de firmarla

Tres preguntas rápidas:

1. ¿Podría comprobar al final si se cumplió cada punto del alcance? Si la respuesta es «depende», el alcance está mal escrito.
2. ¿Sé qué no está incluido? Si no hay una sección de exclusiones, pídela.
3. ¿Cuándo veo algo funcionando por primera vez? Si la respuesta es «al final», el riesgo es todo tuyo.

Una propuesta que pasa estas tres preguntas no garantiza un buen proyecto, pero una que no las pasa casi garantiza uno malo.

Si tienes un proyecto en mente y quieres una propuesta con estas seis partes, cuéntanos qué necesitas: te respondemos en un día hábil.