Qué debe incluir un presupuesto de desarrollo de una app

Pide que las funciones describan qué puede hacer cada tipo de usuario. Un apartado llamado reservas puede incluir consultar disponibilidad, crear una petición, confirmarla, modificarla o cancelarla. Cada acción tiene reglas y situaciones particulares. La propuesta debe indicar cuáles cubre y quién interviene cuando la petición necesita una revisión manual.

Anota las exclusiones con la misma claridad. Si la primera versión tiene un solo idioma o no permite editar un registro después de enviarlo, esa decisión debe ser visible. Identifica qué se da por supuesto y qué sigue pendiente de definición. Las propuestas se pueden comparar cuando describen un producto equivalente y dejan a la vista las diferencias.

El diseño incluye el recorrido, la jerarquía y los estados de la interfaz. Hay que prever una lista vacía, una carga lenta, un error de formulario y una acción que todavía no se ha confirmado. Pregunta en qué dispositivos se revisará el diseño y cómo se tratarán textos largos, controles accesibles y mensajes que el usuario necesita entender para continuar.

Comprueba si la propuesta incluye investigación, prototipo, pruebas de comprensión, identidad visual o solo la aplicación de una marca existente. También debe quedar claro quién redacta los textos y quién prepara imágenes y traducciones. Un prototipo puede servir para validar el recorrido, pero hay que especificar qué partes se convertirán en una aplicación funcional y con qué comportamientos.

Pregunta dónde se gestionarán los registros y quién podrá consultarlos o corregirlos. Si tu equipo necesita aprobar contenido, atender incidencias o administrar usuarios, esas tareas deben tener una solución prevista. Un panel de gestión tiene sus recorridos y permisos; no debe darse por incluido solo porque la propuesta hable de una app.

Para cada integración, identifica el sistema externo, la información que se intercambia y la persona que facilitará el acceso. Acuerda qué ocurrirá si el servicio no responde o envía datos incompletos. Si aún no se ha comprobado la conexión, la propuesta debe reflejar esa duda y el trabajo necesario para aclararla. Incluye cualquier migración de datos que requiera el lanzamiento.

Define cómo sabréis que cada recorrido está completo. Por ejemplo, una reserva puede considerarse validada cuando el usuario recibe confirmación, el registro aparece en el panel y un cambio se refleja en ambos lugares. Estos criterios permiten revisar el funcionamiento con casos concretos. Añade las situaciones de error y las combinaciones de dispositivos que sean relevantes.

La propuesta debe asignar tiempo y responsables para preparar datos de prueba, revisar resultados y corregir incidencias. Distingue un error respecto al comportamiento acordado de una función nueva que surge durante la revisión. Define cómo se documentará la petición y cómo se decidirá si entra en esa entrega o en una fase posterior.

Revisa quién creará y gestionará las cuentas necesarias, preparará los materiales de publicación y atenderá las comprobaciones del canal elegido. En una distribución mediante tiendas, separa la preparación del envío y la disponibilidad final. La propuesta debe explicar las tareas del equipo sin presentar como controlable una decisión que corresponde a terceros.

La entrega debe especificar repositorio, archivos de diseño, documentación y procedimiento para continuar el trabajo. Acuerda cómo se gestionarán incidencias, actualizaciones, copias de seguridad y dependencias externas después del lanzamiento. Identifica quién tendrá cada responsabilidad. Acceder a los archivos resulta útil, pero el equipo que los recibe también debe saber cómo poner el sistema en funcionamiento.

Envía las mismas dudas a cada proveedor y pide que las respuestas se incorporen a la propuesta. Repasa especialmente las partes que dependen de tu equipo: contenidos, accesos, validaciones y disponibilidad para probar. Una fecha de entrega debe tener esas dependencias asociadas.

• ¿Qué recorridos y excepciones incluye la primera versión?
• ¿Quién prepara contenidos y quién administra el producto?
• ¿Qué integraciones están comprobadas y cuáles no?
• ¿Con qué pruebas se aceptará la entrega?
• ¿Qué cuentas, archivos y documentos recibiré?
• ¿Quién atenderá las incidencias después de publicar?