1. Definir el objetivo y sus límites
La primera etapa averigua qué problema debe resolver el cambio y quién lo sufre hoy. Un mapa del proceso incluye usuarios, objetivos, pasos fuera de la pantalla, fuentes de datos y situaciones en las que falla el recorrido habitual. También distingue lo que está respaldado por observaciones de lo que sigue siendo una hipótesis. Sin esa distinción, una estimación de coste puede convertirse en una promesa sin pruebas. La medición inicial puede ser sencilla, pero su método debe poder repetirse.
El análisis inicial debe terminar con una decisión sobre el siguiente paso. Puede ser un prototipo del recorrido crítico, una prueba de la interfaz de un tercero o una evaluación de los datos que habría que migrar. Recomendar un producto existente o cambiar el proceso es legítimo si no hace falta software a medida. Los resultados útiles son breves y concretos: objetivo, roles, mapa de datos, riesgos principales, opciones y criterios para elegir la primera etapa.
2. Diseñar la arquitectura y sus pruebas
La arquitectura empieza por los límites de responsabilidad. ¿Qué sistema es dueño de un dato, quién puede cambiar un estado y cómo pasa el resultado a la siguiente parte del proceso? Las respuestas se recogen en contratos de interfaz, un modelo de permisos y algunos escenarios descritos. Además del recorrido ideal se diseñan esperas agotadas, duplicados, fallos parciales y reversión. Sin estos casos, un diagrama puede ser elegante pero difícil de operar.
La prueba debe corresponder al riesgo mayor. Una API desconocida pide un experimento de integración; un flujo muy utilizado, mediciones con datos representativos; una usabilidad incierta, un prototipo con usuarios reales. No todos los sistemas necesitan microservicios o una plataforma distribuida. Una aplicación modular y comprensible puede simplificar la entrega y la operación. Una separación más compleja se justifica solo cuando requisitos concretos superan los costes añadidos de comunicación, pruebas y observación.
3. Entregar incrementos verificables
El desarrollo se divide por resultados que se puedan comprobar. El primer recorrido completo debería conectar interfaz, reglas, datos y observación en un entorno operativo, aunque sea pequeño. Así aparecen los problemas en las fronteras antes que cuando se terminan pantallas o servicios por separado. Las prioridades siguientes cambian según lo aprendido, no solo por el orden inicial del backlog. El responsable del producto debe ver lo terminado, lo incierto y el efecto de cada decisión en el alcance.
Con requisitos estables es posible detallar más los criterios de aceptación. En un entorno desconocido resulta más honesto dar un intervalo y explicar cómo se afinará la estimación. En ambos casos se mantienen el código, las razones de decisiones importantes, los procedimientos de migración y controles automáticos de reglas críticas durante el trabajo. La calidad no es una última fase: pertenece a cada entrega. La deuda técnica debe registrarse con su efecto para poder decidir sobre ella conscientemente.
4. Probar los riesgos importantes
Las pruebas deben proteger el comportamiento cuyo fallo perjudicaría al usuario o a la operación. En un flujo financiero puede ser evitar una operación duplicada; al migrar datos, conservar el significado de cada registro; en la IA interna, excluir fuentes a las que el usuario no tiene acceso. Los controles automáticos se complementan con accesibilidad, mensajes de error comprensibles y comportamiento móvil. Los datos de prueba deben representar excepciones y no solo el caso exitoso más cómodo.
La revisión de seguridad parte de los activos y roles reales. ¿Quién puede leer datos personales, quién cambia la configuración, dónde se guardan los secretos y qué llega a los registros? Se actualizan dependencias críticas y se revisan cambios. Una auditoría externa puede formar parte del proyecto, pero su alcance y realización deben demostrarse; una explicación general del sitio no la sustituye. Tampoco una puntuación automática de accesibilidad prueba que una persona complete su tarea real.
5. Publicar y transferir
Antes de una publicación debe quedar claro cómo cambian los datos, cómo se verifica la versión y quién decide volver atrás. Una migración de datos suele ser menos reversible que el código y merece su propio plan. Una copia de seguridad solo vale si permite recuperar un servicio utilizable en un tiempo aceptable. La monitorización debe observar no solo si funciona el servidor, sino también los procesos importantes, peticiones fallidas, integraciones retrasadas y excepciones pendientes de intervención humana.
La transferencia incluye acceso al código fuente, instrucciones de despliegue, propietario de la configuración, dependencias y procedimiento de incidentes. El usuario debe saber cómo obtener ayuda y qué ocurre con su información. El cliente debe entender las decisiones arquitectónicas relevantes y no depender de una sola persona. La documentación ha de ser compacta, pero útil cuando algo falla o un nuevo equipo asume el mantenimiento.
6. Medir y decidir el siguiente cambio
Después del lanzamiento se comparan los resultados reales con la situación inicial. Un trámite más rápido solo ayuda si no aumentan los errores o los costes de corrección. Otros productos pueden necesitar otras medidas: finalización de tareas, calidad de datos, intervenciones manuales o disponibilidad del recorrido crítico. Cada métrica necesita un responsable y una pregunta que ayude a responder. Un panel sin decisión asociada no crea valor por sí mismo.
La operación puede revelar que una elección arquitectónica ya no basta, o confirmar que no hace falta mayor complejidad. La etapa siguiente debe apoyarse en esas pruebas. Desarrollar un sistema no significa añadir funciones eternamente; también puede consistir en eliminar obstáculos, simplificar un flujo o retirar un componente sin uso. Cuando las responsabilidades y razones son rastreables, el producto puede evolucionar sin volver a empezar cada vez.