Diagnóstico técnico: mapa, riesgos y plan

Es una sesión de 60 a 90 minutos por pantalla compartida para entender cómo está armado un sistema que ya existe. Se mira el código, la base, las integraciones y el deploy, y se sale con un mapa y un plan.

No es una clase. En una clase se construye algo nuevo; acá se levanta el estado de lo que ya está hecho y se decide qué hacer con eso.

Tampoco es una implementación. Durante la sesión no se cambia configuración, no se hace deploy y no se escribe código de producción.

• El sistema funciona y nadie sabe bien por qué. Hay piezas que se tocaron hace años y miedo de moverlas.
• Cada cambio rompe otra cosa. El equipo arregla un módulo y aparece un error en otro lado.
• Hay tres versiones del mismo dato. Una en la base, una en una planilla y una en la cabeza de alguien.
• El deploy depende de una persona. Si esa persona no está, no se publica.
• Se viene una decisión grande. Cambiar de proveedor, sumar un canal, migrar la base o contratar un equipo.
• Un proveedor se fue y no dejó documentación. Queda código funcionando y nadie que explique las decisiones.

Si te reconocés en dos o tres de estos puntos, el diagnóstico sirve. Si el problema es uno solo y está acotado, probablemente alcance con una clase.

• Un mapa del sistema. Qué componentes hay, cómo se hablan, dónde vive el dato y dónde están los puntos únicos de falla.
• Una lista de riesgos reales. Ordenada por impacto, no por miedo: qué se puede romper, qué ya está roto y qué es deuda que puede esperar.
• Un plan por fases con horas estimadas. Qué hacer primero, qué se puede dejar para después y cuánto trabajo implica cada tramo.
• Las preguntas que hay que responder antes de mover algo. Lo que no se puede decidir sin datos que hoy no están.

1. Preparación. Antes de la sesión se define qué sistema se mira y qué decisión está en juego. Sin eso, la sesión se va en recorrer archivos sin rumbo.
2. Recorrido en vivo. Se comparte pantalla y se recorre la estructura: repositorios, base, integraciones, variables de entorno y proceso de deploy.
3. Preguntas sobre el camino. Qué pasa si el servicio externo no responde, quién tiene acceso, cómo se prueba un cambio antes de publicarlo.
4. Cierre con el mapa. Los últimos minutos se ordenan los hallazgos y se acuerda qué queda escrito y en qué formato.

Se trabaja sobre lo que mostrás. No hace falta entregar credenciales ni dar acceso remoto: alcanza con compartir pantalla y abrir lo que haga falta en el momento.

No se modifica nada. No se instala, no se migra, no se despliega y no se corrige el bug que apareció de paso. Tampoco se escribe el código del plan: se estima.

Esa restricción no es una limitación del servicio, es lo que lo hace útil. Si se empieza a arreglar durante la revisión, se pierde la vista completa y el plan queda condicionado por la primera cosa que se tocó.

Si aparece un arreglo urgente, se anota y se decide después, con el mapa a la vista.

Con tres caminos posibles, y ninguno se decide en la sesión por vos.

• Lo ejecutás con tu equipo. Te quedás con el mapa, los riesgos y el plan, y lo llevás adelante con quien ya trabaja en el sistema.
• Lo hacés conmigo en clases. Si preferís aprender a ejecutarlo, el plan se convierte en sesiones de trabajo sobre tu proyecto.
• Lo hace DuodecimStudio. Si el trabajo es de implementación, eso es otra cosa y se conversa aparte. En la llamada te digo si corresponde.

El diagnóstico se cotiza según el alcance y se confirma en la llamada de 25 minutos, sin costo. No hay un precio publicado porque el alcance de una revisión cambia demasiado entre un sistema y otro.

La tarifa de las clases sí está publicada con su fecha en precio de las clases. El método que se usa para ordenar el plan está en cómo trabajo.