Método de trabajo
Intento proyectos realistas y útiles en el día a día: poco ruido, mucha observación y entregas que otra persona pueda retomar. No vendo teoría ágil; cuento cómo suelo moverme cuando el terreno es operaciones, backoffice, CRM, datos, automatización o procesos administrativos — no solo “producto software”.
Un proceso no está terminado cuando funciona una vez; está terminado cuando otra persona puede repetirlo, entenderlo y confiar en él.
Scrum como inspiración, no como dogma
Me inspiran ideas que mucha gente asocia a Scrum o a equipos de producto: objetivos claros, ciclos cortos, entregas incrementales, feedback, mejora continua, transparencia y adaptación. Me sirven como brújula.
No las aplico con etiquetas rígidas ni con el manual bajo el brazo. No hace falta hablar de roles de certificación ni de ceremonias vacías para decir algo simple: acorto el camino entre el problema y algo que funciona, lo muestro, lo ajusto con quien lo usa y vuelvo a dar un paso.
La diferencia está en el contexto: aquí el “producto” suele ser un flujo operativo fiable, un informe que cuadra, un inventario que no se pelea con la realidad o un CRM que deja de ser una isla. El espíritu es el mismo: aprender en corto y no apostar el mes entero a un gran diseño en el aire.
El flujo que suelo seguir
En la práctica encadeno así: Observar → Ordenar → Automatizar → Controlar → Acompañar. No es un contrato rígido: a veces se vuelve atrás un paso cuando aparece información nueva, pero ese orden suele ser el que menos sorpresas da.
- No intento resolverlo todo de golpe; primero veo el proceso con quien lo vive.
- Ordeno estados, roles y criterios antes de crecer el alcance o la herramienta.
- Automatizo cuando el flujo ya es razonablemente estable y la herramienta tiene sentido.
- Controlo con validaciones, permisos sensatos y evidencia, no solo con buena voluntad.
- Acompaño con documentación útil, formación breve y ajustes tras el uso real.
Los cinco pasos, con ejemplos
Cada tarjeta resume la intención del paso y una lista corta de situaciones típicas. Si encaja con tu contexto, hablamos con calma por LinkedIn o desde contacto.
-
Observar
Escuchar y mirar antes de nombrar soluciones: cómo fluye el trabajo hoy, dónde duele y qué se asume sin decirlo. Sin mapa ideal dibujado en una sala sin quien opera.
- Detectar tareas que siguen siendo manuales “porque siempre fue así”.
- Localizar datos dispersos entre hojas, correos y sistemas que no conversan.
- Identificar incidencias o errores que se repiten con el mismo patrón.
- Notar fricciones entre equipos (comercial, operaciones, TI, terceros) sin un hilo común.
-
Ordenar
Dar estructura mínima viable: que todos sepan qué significa “hecho”, quién toca qué y con qué datos se cierra un caso. Sin eso, el siguiente paso solo acelera el desorden.
- Definir estados del proceso o del pipeline con transiciones claras.
- Aclarar roles y responsabilidades sin organigramas de fantasía.
- Plantillas y checklists que el equipo acepta usar en el día a día.
- Nomenclaturas y convenciones que reducen preguntas repetidas.
- Criterios de cierre demostrables (qué hay que tener para dar por cerrado).
-
Automatizar
Elegir herramienta según estabilidad del flujo y cultura del equipo: automatizar lo repetible sin perder el hilo humano donde el riesgo lo merece.
- Google Sheets y Apps Script cuando el equipo vive en la hoja pero necesita validaciones y logs.
- Python cuando el volumen, los cruces o la repetición lo justifican.
- Power Query o Excel cuando ya es el sitio donde se decide.
- Make (u orquestación similar) para enlazar sistemas sin montar un proyecto eterno.
- El CRM como automatización de estados, tareas y visibilidad cuando el problema es de flujo, no solo de clic.
-
Controlar
Incorporar mecanismos que detecten fallos antes que el cliente o el cierre: trazabilidad, permisos sensatos y pruebas que no dependan de “confío en que fulano lo miró”.
- Logs o historiales de ejecución en scripts y automatizaciones.
- Validaciones en origen para evitar basura que viaja tres sistemas.
- Permisos alineados con el trabajo real (mínimo privilegio aplicado con pragmatismo).
- Reglas anti-duplicados donde el negocio lo pide.
- Evidencias (capturas, expedientes, versiones) que permitan auditar o retomar sin memoria oral.
-
Acompañar
El despliegue no termina en el primer día que “funciona”: hace falta que la gente confíe, sepa a quién acudir y pueda proponer mejoras sin miedo a romperlo todo.
- Documentar en el tono y el sitio que el equipo realmente usa.
- Formar con ejemplos reales del propio contexto, no solo manuales genéricos.
- Dar soporte mientras el hábito nuevo se asienta.
- Ajustar el proceso tras el uso real: lo que en prueba parecía obvio a veces chirría en producción.