Problema acotado
Se define el primer proceso que debe funcionar de extremo a extremo antes de convertir la herramienta en un cajón de peticiones.
——
Herramientas web para procesos que ya no caben en una hoja de cálculo ni en un plugin genérico.
Una aplicación web debe reducir pasos y errores, no digitalizar el desorden existente.
Las aplicaciones web a medida ordenan un proceso que ya ha superado la hoja de cálculo o el plugin genérico. Se construyen alrededor de roles, tareas, datos y excepciones concretas para que el equipo trabaje con una misma versión de la información.
El alcance se define a partir de la decisión que debe facilitar la web, los datos que la sostienen y la operativa que el equipo quiere impulsar.
Se define el primer proceso que debe funcionar de extremo a extremo antes de convertir la herramienta en un cajón de peticiones.
Cada persona ve y puede hacer lo necesario para su tarea, con trazabilidad donde importa.
Se priorizan módulos que se pueden probar con usuarios reales y ajustar antes de ampliar el sistema.
La solución se ajusta a la situación de partida. Estas son las capas que se revisan para aportar valor al encargo.
La aplicación se construye alrededor de un proceso que ya consume tiempo en hojas, correos o sistemas desconectados. El primer alcance debe cerrar esa tarea de principio a fin antes de añadir módulos por costumbre.
Casi todas las aplicaciones a medida nacen sustituyendo un Excel que se ha vuelto crítico: lo usan seis personas, nadie sabe quién lo modificó por última vez y una fórmula rota puede costar dinero. La aplicación aporta control de acceso, historial y validación, que es exactamente lo que la hoja no da. Conviene empezar reproduciendo lo que ya funciona antes de añadir lo que se echaba en falta.
Quién ve qué y quién puede cambiar qué es una decisión de negocio que condiciona la arquitectura. Añadir roles a una aplicación que nació sin ellos es caro y suele quedar mal. Definirlos al principio, aunque solo haya dos perfiles, deja el sistema preparado para cuando aparezca el tercero, que aparece siempre.
La tentación en una herramienta interna es cubrir todos los casos desde el principio. El resultado habitual es una aplicación amplia y a medio hacer que la gente esquiva. Es preferible cerrar por completo el flujo principal —con sus errores, sus estados vacíos y su historial— y ampliar después con uso real delante, que es cuando se descubre qué faltaba de verdad.
Se evalúa primero. El desarrollo a medida se justifica cuando las restricciones, datos, integración o experiencia son parte de la ventaja operativa.
Sí. Un alcance inicial claro permite validar el núcleo y decidir con evidencia qué módulo tiene sentido desarrollar después.
Qué proceso se quiere resolver y quién lo hace hoy a mano. Ayuda ver el circuito real: dónde entra el dato, quién lo valida, dónde se pierde y qué sistema manda cuando dos dicen cosas distintas.
Empieza por los casos límite, no por el caso feliz. Qué pasa con un pedido incompleto, un cliente con tarifa especial o una sincronización que falla. Eso es lo que determina el trabajo real y el presupuesto.
Acceso a los sistemas implicados y una persona que conozca el proceso de verdad, no solo su versión documentada. Las integraciones se atascan casi siempre por permisos y por reglas de negocio no escritas.
Con datos reales en un entorno aparte y con los casos raros que ya han pasado alguna vez. Se prueba también qué ocurre cuando el otro sistema no responde, porque acabará no respondiendo.
En pasos que desaparecen y en errores que dejan de repetirse: pedidos que no hay que teclear dos veces, datos que ya no se persiguen por correo, tiempo que vuelve al equipo.
Se entrega documentado y con registro de lo que ocurre cuando algo falla, para que el problema se pueda diagnosticar sin llamar a quien lo programó. El soporte se define aparte y por escrito.
Los casos muestran cómo se traduce el trabajo en una situación real.
Una conversación breve permite concretar el encaje, las decisiones necesarias y el siguiente paso.
