Cómo trabajo: el método en 7 pasos

Antes de cambiar una configuración se mira cómo funciona hoy. Qué entra, qué sale, quién lo usa y qué pasa cuando falla.

El diagnóstico no es una reunión protocolar: es la lista de lo que existe, incluido lo que nadie documentó. Si esa lista no se puede armar, el primer trabajo es armarla, y eso ya es parte del proyecto.

Qué evita: arreglar el síntoma equivocado. La mitad de los problemas que parecen técnicos son de proceso, y se ven mejor antes de abrir el editor.

Cada sesión arranca con una frase: al final de esta hora, esto tiene que funcionar. No es un tema, es un resultado verificable.

Si aparece otro asunto, se anota y se deja para la próxima. Cambiar de rumbo a mitad de sesión es la forma más rápida de no cerrar nada y de que la hora se vaya en conversación.

Qué evita: la clase entretenida que no deja nada funcionando. El objetivo escrito al principio también sirve para saber cuándo parar.

La primera fase es la versión mínima que ya resuelve algo. No la versión incompleta: la versión chica que se puede usar.

Cada fase tiene horas estimadas y un resultado que se puede probar. Si una fase no se puede probar sola, está mal cortada y conviene partirla de nuevo.

Qué evita: el proyecto grande que se construye durante meses y se prueba el día que se publica. Con fases, cada tramo entrega algo que ya sirve.

Cada fase termina en una puerta de salida: se puede parar ahí y lo hecho sigue funcionando. Parar no es fracasar.

Esa puerta es la prueba de que la fase anterior estaba bien cortada. Si detenerse deja el sistema a medias y sin uso, el problema es el corte, no la decisión de parar.

Qué evita: quedar atrapado en un proyecto a medias, sin nada usable y sin forma de salir sin perder lo invertido.

Se prueba el camino completo, con datos reales y con el caso borde: zona horaria, duplicados, formato de fecha, servicio externo que no responde.

Una prueba que solo recorre el caso feliz no prueba nada. El caso feliz ya funcionaba antes de empezar; lo que hay que ver es qué pasa cuando el dato viene raro o cuando el otro servicio se cae.

Qué evita: descubrir en producción lo que se podía ver en la sesión. Probar es la parte del trabajo que más se saltea cuando hay apuro.

Al final queda un resumen escrito: qué se hizo, qué decisiones se tomaron y por qué, y qué revisar si algo deja de andar.

La documentación es del alumno, no mía. La prueba de que el trabajo terminó es que el sistema se puede mantener sin depender de la persona que lo construyó.

Qué evita: el sistema que solo entiende quien lo escribió. Un proyecto sin documentación se vuelve un problema para el que venga después, aunque funcione hoy.

No convierte un problema de negocio en un problema técnico. Si el proceso no está definido, ninguna automatización lo arregla.

No promete resultados de negocio. El método ordena el trabajo y hace visible el avance; no garantiza ventas, ahorro ni plazos.

No reemplaza a un equipo. Si hay gente trabajando en el sistema, el método se adapta a lo que ya hacen y no les pisa el proceso.

Tampoco es un trámite que haya que completar antes de empezar a construir. Los siete pasos se aplican en una clase de una hora y en un proyecto de varias semanas: lo que cambia es la escala, no el orden.

El mismo criterio se usa en una clase de n8n online, en una clase de programación y en un diagnóstico técnico. En el diagnóstico se aplica la primera mitad: mapa, riesgos y plan por fases, sin tocar nada.

Si querés ver si el método encaja con tu caso, la llamada de 25 minutos es el punto de partida. Está en contacto.