Cómo comparar propuestas de desarrollo de software

Una buena propuesta dice qué se va a construir con el detalle suficiente para que puedas verificarlo al final:

• Las funcionalidades de la primera versión, descritas desde lo que el usuario puede hacer.
• Los supuestos: qué se asume que ya existe o que tú vas a proporcionar.
• Las exclusiones: qué queda explícitamente fuera.

Si una propuesta no tiene exclusiones, no significa que incluya todo: significa que todavía no se habló de ello.

• Cómo se acepta cada entrega: quién la revisa y con qué criterios.
• Si hay un entorno de pruebas además de producción.
• Qué pruebas se hacen antes de entregar.
• Si la entrega incluye el despliegue en producción o sólo el código.

Pregunta a nombre de quién queda el repositorio, en qué cuentas se despliega y qué documentación se entrega al final. Lo explicamos con detalle en la guía sobre quién debe ser dueño del código fuente.

En casi todos los proyectos algo cambia a mitad de camino. Conviene saber de antemano:

• Cómo se cotiza un cambio de alcance y quién lo aprueba.
• Si un cambio mueve la fecha de entrega y cómo se comunica.
• Qué pasa con el trabajo ya hecho si algo se descarta.

• Cada cuánto vas a ver software funcionando, no sólo reportes.
• Si tienes acceso al repositorio y a un entorno de pruebas durante el proyecto.
• Quién es tu contacto y quién hace el trabajo.

• Si hay un periodo para corregir errores sin costo, y cuánto dura.
• Cómo se cotiza el mantenimiento o las mejoras posteriores.
• Qué pasa si decides que otro equipo continúe el proyecto.

Antes de proponer, entendemos qué debe hacer el software, qué existe hoy y qué entra en la primera versión. La propuesta llega por escrito con alcance, entregables y costo, sin compromiso, y el repositorio queda a tu nombre desde el primer commit.