Cómo leer una propuesta de desarrollo

Una propuesta de desarrollo convierte su brief en compromisos: qué se va a construir, para cuándo, por cuánto y qué pasa cuando algo cambia.

La regla práctica es simple: si un detalle no está escrito, dé por hecho que no está incluido.

Un buen alcance describe qué puede hacer un usuario, no solo los nombres de las pantallas. «El usuario puede registrarse con correo o con Google y recuperar su contraseña» se puede verificar. «Módulo de autenticación», no.

Busque que los roles de usuario, los flujos principales y las herramientas de administración estén listados por separado. Los paneles de administración son fáciles de olvidar en un brief y caros de agregar después.

Una propuesta clara enumera qué no está incluido: por ejemplo, la redacción de textos, las traducciones, la publicación en las tiendas de apps, las suscripciones a servicios de terceros o el alojamiento después del lanzamiento.

Si no hay una sección de exclusiones, pídala. Todo lo que usted daba por incluido y no lo estaba va a volver más adelante como un pedido de cambio.

No hace falta ser desarrollador, pero después de leer debería poder responder esto:

¿Con qué se va a construir y por qué ese stack para su producto en particular?

¿De quién son el código y las cuentas: alojamiento, dominio, tiendas de apps, analítica?

¿Dónde va a estar alojado y cuánto costará aproximadamente por mes después del lanzamiento?

¿El código va a quedar lo bastante documentado como para que otro desarrollador lo retome?

Una buena agencia explica sus decisiones en lenguaje claro. «Es lo que usamos siempre» no es una razón.

Una sola fecha de entrega dice muy poco. Busque hitos con algo para ver en cada uno: diseños aprobados, una versión funcionando en un enlace de prueba, una versión lista para lanzar.

Pregunte con qué frecuencia va a ver avances. Una reunión semanal es un mínimo razonable; una única demostración al final es un riesgo.

Revise si la propuesta menciona pruebas, rendimiento y accesibilidad, o solo funciones.

Busque detalles concretos: qué navegadores y dispositivos se soportan, qué rendimiento debería alcanzar el producto y quién lo prueba antes del lanzamiento.

Confirme qué cubre exactamente el precio y cómo se reparten los pagos. Un anticipo más pagos atados a hitos es lo habitual; el 100% por adelantado no lo es.

Busque el proceso de cambios. Debería explicar cómo se estiman y se aprueban los pedidos nuevos antes de que alguien empiece a trabajar en ellos.

Muchas propuestas terminan el día del lanzamiento. Pregunte qué pasa después: si hay un período de soporte para errores, cuánto dura y cómo se cobra el trabajo posterior.

Un lanzamiento sin plan para correcciones y actualizaciones es justo el lugar donde muchos productos se quedan quietos en silencio.

¿Qué queda excluido exactamente?

¿Quién va a trabajar en el proyecto en el día a día?

¿Qué pasa si necesitamos cambiar el alcance?

¿De quién son el código y todas las cuentas al final?

¿Qué soporte está incluido después del lanzamiento?