←︎ Volver a la bitácora

Elegir el método en vez de obedecerlo

Un método es una forma de organizar el trabajo para resolver un problema. Elegirlo exige entender qué necesitas conseguir, qué condiciones requiere y cuánto cuesta aplicarlo. La plantilla puede ayudarte a pensar; no debería sustituir tu criterio ni convertirse en la medida del éxito.

Incorporada el 6 min de lectura

Empieza por la decisión que necesitas tomar.

Aprender una herramienta produce una tentación comprensible: buscar enseguida un proyecto donde usarla. A veces funciona. Otras veces acabas organizando el problema para que encaje en la herramienta, dedicando más atención a completar pasos que a entender qué necesita el proyecto.

Una buena elección empieza en otra parte: qué decisión está bloqueada, qué incertidumbre importa y qué resultado debería producir el trabajo. Después puedes valorar si necesitas una conversación, un prototipo, una secuencia de entregas o una investigación más profunda.

El método añade estructura a esa intención. Puede repartir turnos, hacer visibles alternativas o forzar una prueba con usuarios. Su utilidad depende de conservar ese mecanismo, no de reproducir todos sus nombres en una presentación.

Dos recomendaciones que no encajan del todo.

En las notas de dos mentorías de diciembre de 2022 aparece una tensión interesante. Luis propone trabajar con el cliente mediante sprints, sin abandonar las ventas. Javi de Miguel insiste en ejecutar bien unas pocas hipótesis y deja registrada una frase de escepticismo hacia las metodologías ágiles.[1]

No tenemos una explicación completa de ese desacuerdo. Sería excesivo convertirlo en una disputa resuelta entre dos escuelas. Las notas recogen recomendaciones para un proyecto concreto, no una comparación controlada de métodos.

Hay además una reflexión anterior de Iván al estudiar SPRINT: consideró que el equipo estaba demasiado verde para aplicarlo a gran escala, aunque podía aprovechar algunas partes.[2] Esa observación sí muestra un criterio propio: valorar la preparación del equipo antes de adoptar un proceso entero.

La relación entre las mentorías fue señalada después al organizar la memoria. Aquí sirve como pregunta editorial: ¿cómo decides cuando dos personas con experiencia recomiendan enfoques distintos? La respuesta no puede depender solo de quién habla con más seguridad.

Mira sus condiciones y su mecanismo.

El Manifiesto Ágil nació en el desarrollo de software. Prioriza la interacción, la colaboración y la respuesta al cambio sin declarar inútiles los procesos, los contratos o los planes.[3] Por tanto, agilidad no significa ausencia de acuerdos ni seguir cualquier ritual etiquetado como ágil.

Conviene separar nombres que suelen mezclarse. Una prueba de prototipo, un intervalo de trabajo y un marco completo de coordinación no son automáticamente lo mismo. Si decís que vais a hacer un sprint, aclarad qué vais a producir, con quién y cómo se revisará. El nombre por sí solo no coordina.

Pregunta también qué necesita el método para funcionar. Quizá requiere acceso a usuarios, una persona que pueda decidir, tiempo concentrado o un problema suficientemente delimitado. Si falta una condición esencial, completar el calendario puede producir una apariencia de progreso.

Adaptar tiene sentido cuando entiendes qué estás conservando y qué pierdes. Si eliminas la prueba con usuarios de un proceso pensado para contrastar un prototipo, no puedes atribuirle el mismo aprendizaje. Si solo tomas una técnica de ideación, preséntala como tal.

Dos bloqueos, dos trabajos distintos.

Imagina dos proyectos de una misma team company. Es un ejemplo hipotético. El primero tiene pedidos confirmados pero entrega tarde porque nadie conoce el estado de los materiales. El segundo todavía duda de cómo debería funcionar su servicio de reservas.

Para el primero, reservar una semana completa a idear soluciones puede retrasar lo urgente. Quizá necesita hacer visible el flujo de pedidos, asignar responsables y detectar la dependencia que se atasca. La mejora se observará en la coordinación y en las entregas, no en el número de ideas generadas.

El segundo podría beneficiarse de representar una experiencia y enseñarla a posibles usuarios. Pero si no puede acceder a ninguno, conviene resolver esa condición antes de llenar el calendario de sesiones. Un prototipo que nadie utiliza deja abierta la pregunta principal.

Los dos equipos pueden aprender de una misma metodología, pero no tienen por qué aplicarla igual. El criterio de elección es la relación entre problema, condiciones y resultado. Tampoco hay que rediseñar todo desde cero: una práctica conocida puede bastar si resuelve el bloqueo con un coste razonable.

Problema, resultado, condiciones, adaptación y revisión como preguntas para elegir un método.
MAPA 01 · Elige el método con criterioAmpliar infografía →︎

Explica por qué este método, aquí y ahora.

Antes de proponer una dinámica, describe la decisión que debería facilitar. Evita objetivos como hacer un canvas o completar un sprint. Expresa qué podréis decidir o hacer después que ahora no podéis.

Comprueba las condiciones: información disponible, personas necesarias, capacidad de decisión y acceso a quienes probarán el resultado. Si algo falta, resuélvelo o elige una alternativa que no dependa de fingir que existe.

Conserva solo la complejidad que aporte valor, pero entiende los elementos que suprimes. Una adaptación consciente incluye sus límites. No hace falta defender una etiqueta para reconocer que una técnica concreta os ha ayudado.

Al terminar, evalúa el resultado y el coste de coordinarlo. ¿Se aclaró la decisión? ¿Apareció información nueva? ¿Qué parte fue útil y cuál solo añadió trabajo? Esa revisión te permite construir criterio propio y escuchar la siguiente recomendación con mejores preguntas.

Aprendizajes

  • El problema precede a la herramienta. Define la decisión que necesitas facilitar.
  • Las condiciones importan. No simules usuarios, tiempo o capacidad de decidir.
  • Adaptar exige comprender. Explica qué conservas y qué aprendizaje pierdes.
  • Una etiqueta no coordina. Aclara resultado, participantes y revisión.
  • Evalúa la utilidad real. Completar el proceso no demuestra que ayudó.

Preguntas detonantes

  1. ¿Qué decisión esperamos tomar al terminar?
  2. ¿Qué condición del método no tenemos todavía?
  3. ¿Por qué esta herramienta y no una alternativa más sencilla?
  4. ¿Qué estamos eliminando al adaptarla?
  5. ¿Cómo sabremos si nos ayudó?

Para seguir aprendiendo

PARA ENTENDER LA BASE

Aprender de un libro sin creerlo todo

Distingue las propuestas de un autor de pruebas y condiciones de aplicación.

Leer bitácora →︎
PARA SEGUIR AVANZANDO

Hay problemas que no se resuelven con un plan más detallado

Elige una forma de intervenir según el tipo de incertidumbre del problema.

Leer bitácora →︎
PARA AMPLIAR LA MIRADA

Un sprint sirve para responder una pregunta

Contrasta ese criterio con un método concreto de prototipado y prueba con usuarios.

Leer bitácora →︎

Cómo se ha elaborado esta bitácora

Esta bitácora parte de los apuntes y reflexiones reales que Iván guardó en su Notion personal durante sus cuatro años en LEINN. Ese archivo se ha organizado en una base de 521 notas de conocimiento. Cada entrada toma un concepto de esa base y lo amplía con referencias, explicaciones e infografías para convertirlo en un recurso de aprendizaje.

Fuentes

  1. Notion personal · Mentorías de Luis y Javi de Miguel

    Feedback y siguientes pasos de diciembre de 2022 leídos. No se atribuye una resolución del desacuerdo. Original conservado en el archivo personal; no disponible públicamente.

  2. Notion personal · LP SPRINT para traccionar proyectos

    Contexto, objetivo y reflexión sobre preparación del equipo leídos. No se afirma haber verificado toda su aplicación. Original conservado en el archivo personal; no disponible públicamente.

  3. Autores del Manifiesto Ágil · Manifiesto en español ↗︎

    Texto original consultado; se respeta su contexto de desarrollo de software.

Datos de la entrada
Incorporada el
20 de septiembre de 2026
Última revisión
20 de septiembre de 2026 · Versión 1
Primera lectura recomendada
2.º · primera mitad · Changemaker
Cuándo volver
Cuando dos mentores o métodos ofrecen respuestas incompatibles.
Idioma
Español
Apoyo de IA
OpenAI Codex · texto y edición; ImageGen · infografías
Modelo
Familia GPT-6; variante principal no expuesta por el cliente
Estado
Publicada en everleinner.com