Método de trabajo

Intento buenos proyectos, realistas y construidos en el tiempo: poco ruido, mucha observación y entregas que el equipo pueda usar mañana. No vendo teoría ágil; cuento cómo suelo moverme cuando el terreno es operaciones, backoffice, automatización, reporting, inventarios o procesos administrativos — no solo “producto software”.

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.

Cómo encaja con mi ciclo

Lo que hago encadena así: Observar → Ordenar → Priorizar → MVP operativo → Validar → Automatizar → Documentar → Escalar. No es un mantra; es el orden en el que suelo equivocarme menos.

  • No intento resolverlo todo de golpe.
  • Primero miro el proceso real, con incidencias, plazos y gente de por medio.
  • Defino un objetivo concreto y medible antes de crecer el alcance.
  • Priorizo lo que más alivia trabajo manual, error o incertidumbre.
  • Construyo un MVP operativo: pequeño, útil y funcional en el entorno real.
  • Lo valido con el equipo o usuario que lo va a vivir; recojo feedback y ajusto.
  • Itero y mejoro en ciclos cortos hasta que el flujo se sostiene solo.
  • Documento para que el proceso sea repetible y auditable.
  • Escala solo cuando el flujo ya es estable y asumido.

Las fases en detalle

Debajo, cada fase en una tarjeta. Si encaja con tu contexto, hablamos con calma por LinkedIn.

  1. Observar

    Miro el proceso real tal como ocurre: qué se hace a mano, dónde se rompe la trazabilidad, qué decisiones dependen de una sola persona o de un Excel frágil. No parto de un mapa ideal.

  2. Ordenar

    Pongo nombres, criterios mínimos y responsabilidades claras: qué es “correcto”, qué datos hacen falta y qué se puede medir. Sin eso, automatizar solo acelera el caos.

  3. Priorizar

    Elijo poco pero relevante: qué cambio alivia más carga, reduce error o da más confianza al dato. No intento resolverlo todo de golpe.

  4. MVP operativo

    Construyo algo pequeño, útil y usable en el día a día: un flujo, un informe, una validación, un cuadre. Tiene que funcionar en el entorno real, no en la presentación.

  5. Validar

    Lo pruebo con quien lo va a usar: si chirría, se ajusta. Ahí entra el feedback honesto y los ciclos cortos de mejora, sin teatro de reunión.

  6. Automatizar

    Cuando el flujo ya se sostiene, automatizo lo repetitivo con control: validaciones, logs, comprobaciones. La tecnología acompaña al proceso, no al revés.

  7. Documentar

    Dejo por escrito cómo se ejecuta y cómo se revisa, para que otro pueda continuar sin depender de memoria oral. Es lo que hace el cambio repetible.

  8. Escalar

    Solo amplío alcance o volumen cuando el flujo es estable y la gente lo reconoce como suyo. Escalar antes es asumir riesgo que no hace falta.