EJEMPLO INTERACTIVO
DEL PROBLEMA AL SISTEMA.
No solo
construir.
Comprobar.
Sigamos una solicitud, a modo de ejemplo.
La misma necesidad nos acompaña: definimos cómo debe atenderse este tipo de solicitud, desde el problema hasta su operación.
DESCUBRIR EVOLUCIONAR
Una solicitud.Un criterio compartido.
01 / Descubrir
Primero, encontrar el problema.
Antes de elegir una solución, revisamos dónde se pierde la responsabilidad y qué información hace falta.
No está claro quién debe responder.
Que tenga una respuesta y alguien a cargo.Activa el ejemplo para observar el resultado.
02 / Definir
El acuerdo tiene límites.
Solo se resuelve con información completa; si falta, queda pendiente con responsable y motivo.
Responsabilidad · alcance · criterio
Una persona responsable. Un alcance explícito.Activa el ejemplo para observar el resultado.
03 / Diseñar
Dos condiciones. Un criterio.
Definimos qué debe ocurrir en ambos casos.
Información completa
Falta información necesariaCon responsable y respuesta registrada.
Conserva responsable y muestra qué información falta. No se cierra la solicitud.
Activa el ejemplo para observar el resultado.
04 / Construir
Hacer visible el comportamiento.
Esto demuestra el caso habitual, no que el sistema esté listo para cualquier condición.
Solicitud con información completa
Resuelta, con responsable y respuesta registrada.Activa el ejemplo para observar el resultado.
05 / Validar
Sigue pendiente. El criterio sí se cumple.
No se resolvió sin información completa: conserva responsable y explica qué falta.
Comparar lo esperado con lo observado
2 de 2 condiciones ilustrativas verificadasCon responsable y respuesta registrada.
Conserva responsable y muestra qué información falta. No se cierra la solicitud.
La decisión requiere información, responsable y motivo.
Activa el ejemplo para observar el resultado.
06 / Desplegar
Lo verificado se convierte en base.
La persona a cargo atiende las solicitudes; se acuerda quién mantiene el sistema.
Alcance verificado
Información requerida, permisos y comportamiento verificado, configurados en el entorno de producción según el alcance.El registro conserva el contexto.
Activa el ejemplo para observar el resultado.
07 / Evolucionar
Un cambio no borra el acuerdo.
Evaluamos su necesidad y efecto sobre las solicitudes pendientes. Solo se incorpora si se justifica, se acuerda y se valida.
Se conserva el alcance verificado y su criterio.
Fuera de la base actual. Aún no acordado ni incorporado.Pedir un dato adicional para resolver este tipo de solicitud.
AÚN NO INCORPORADOActiva el ejemplo para observar el resultado.
Un criterio.
Dos resultados.
SOLICITUDAtender una solicitud.
CASO HABITUALRESUELTA / CON RESPUESTA
CASO EXCEPCIONALPENDIENTE / CON RESPONSABLE Y MOTIVO
CRITERIOSolo se resuelve con información completa; si falta, queda pendiente con responsable y motivo.
EVOLUCIÓNFuera de la base actual. Aún no acordado ni incorporado.
RECORRIDO ILUSTRATIVO · 7 DE 7 ETAPAS
Sigue pendiente. El criterio sí se cumple.
La ilustración demuestra solo las condiciones mostradas.
VERIFICADO
EJEMPLO S–01
Leer la metodología completa
Lectura de apoyo
El ejemplo muestra la lógica. La profundidad del trabajo depende del problema y del alcance acordado.
¿Qué necesitamos entender y delimitar?
Entender el problema antes de proponer la solución. Revisamos: contexto del negocio, usuarios, proceso actual, herramientas existentes, fricciones, información disponible, restricciones, dependencias, objetivo esperado.
El resultado no es todavía “vamos a usar X tecnología”.
Decidir qué vale la pena construir. Convertimos lo aprendido en: alcance, prioridades, funcionalidades, riesgos, dependencias, requerimientos, fases, criterios de éxito.
También identificamos qué NO conviene construir. Eso es igual de importante.
¿Cómo se convierte lo definido en algo comprobable?
Diseñar el sistema antes de desarrollarlo. Dependiendo del proyecto, podemos trabajar: flujos de usuario, flujos de proceso, arquitectura, arquitectura de información, esquemas de interfaz, interfaces, integraciones, lógica de automatización.
Aquí empieza a aparecer el sistema.
Convertir el diseño en una solución funcional. Desarrollamos e integramos de forma incremental. Siempre que sea posible: entorno de pruebas, revisiones, hitos, validaciones frecuentes.
No esperamos hasta el final para mostrar todo.
Probar cómo funciona en condiciones reales. Revisamos: funcionalidad, adaptación a distintos dispositivos, casos límite, errores, integraciones, datos, permisos, accesibilidad cuando corresponda, rendimiento.
Un proyecto no está terminado porque “compila”. Está terminado cuando cumple los criterios acordados.
¿Qué implica ponerlo en operación y darle continuidad?
Llevar el sistema a producción. Incluye, según alcance: despliegue, DNS, configuración de entornos, migración, analítica, monitoreo, verificaciones finales.
Después del lanzamiento, el negocio sigue cambiando. Podemos continuar mediante: mantenimiento, soporte, mejoras, nuevas integraciones, nuevas funciones, optimización.
No todos los proyectos necesitan una relación recurrente. Pero los sistemas que siguen evolucionando necesitan una forma responsable de hacerlo.
El diagnóstico no es una reunión de ventas. Es trabajo.
En proyectos con suficiente complejidad, el diagnóstico puede convertirse en una fase contratada antes del desarrollo.
Puede incluir entrevistas, mapeo de procesos, análisis técnico, revisión de herramientas, definición de alcance, riesgos, arquitectura recomendada, estimación inicial y plan de trabajo.
Cuándo recomendamos un diagnóstico técnico
- Hay sistemas heredados.
- Varias plataformas deben integrarse.
- Desconocemos cómo obtener ciertos datos.
- Existen dependencias externas.
- El proyecto involucra equipos físicos.
- El alcance todavía es ambiguo.
- Un error de arquitectura puede salir caro.
No presentamos incertidumbre como certeza.
Cómo trabajamos
- Transparencia
- Si aparece un riesgo, se comunica.
- Iteración
- Preferimos validar pronto.
- Documentación
- Lo importante debe quedar documentado.
- Disciplina de alcance
- Los cambios se gestionan.
- Honestidad técnica
- No presentamos incertidumbre como certeza.
Modelos de proyecto
- Alcance definido
- Adecuado cuando el problema y alcance están suficientemente definidos.
- Diagnóstico + construcción
- Recomendado para proyectos complejos.
- Desarrollo iterativo
- Para sistemas que evolucionan por fases.
- Mantenimiento / evolución
- Para continuidad posterior al lanzamiento. No todo debe venderse como contrato recurrente.
¿Todavía no sabes exactamente qué necesitas construir?
Ese es precisamente uno de los problemas que el diagnóstico puede resolver.