Apps & SaaS

Seguimos un expediente desde su entrada hasta su salida: quién proporciona la información, quién la verifica, quién decide y qué documento se espera. Este recorrido revela roles, permisos y excepciones. Un prototipo luego permite a los usuarios probar las pantallas con un ejemplo suficientemente cercano al uso diario.

El desarrollo no es sistemáticamente la primera opción. Una herramienta existente puede satisfacer la necesidad tras configuración; una integración API puede ser suficiente para conectar dos softwares. El desarrollo a medida es pertinente cuando las reglas, cálculos o la experiencia solicitada no encajan en estas soluciones.

Para software interno, la primera versión debe permitir que un grupo identificado realice una tarea de principio a fin. Para un producto SaaS, también es necesario especificar para quién es el servicio, cómo se inicia una cuenta y qué puede lograr el usuario sin asistencia. Las funciones de administración y soporte forman parte de esta reflexión.

El mandato Fepi ofrece otro ángulo: una plataforma de informes debe reunir datos de varias fuentes antes de presentarlos. Una buena interfaz no reemplaza una definición clara de la información de referencia, su actualización y el manejo de errores. Estas restricciones forman parte del encuadre y las pruebas.

Definimos escenarios de validación: acceso autorizado o denegado, datos faltantes, importación para reanudar, integración no disponible. Un despliegue progresivo permite verificar el funcionamiento con un grupo piloto y planificar una reversión. Las necesidades fuera de línea o de aplicación móvil nativa se estudian por separado.

El presupuesto sigue roles, reglas comerciales, conexiones, migración y requisitos operativos. Distingue desarrollo, alojamiento, servicios de terceros y mantenimiento. El contrato especifica accesos entregados, documentación, condiciones de propiedad del código y licencias usadas, para que el producto pueda mantenerse después de la entrega.