Mi querido amigo y amiga de la calidad, hoy te traigo un nuevo blog con información importante para ti que trabajas como QA, tester o en un equipo de desarrollo.
Seguramente has enfrentado este problema que muchos vivimos en nuestro trabajo diario, y es que te invitan a una reunión y sales sin saber exactamente para qué sirvió. Muchos de nosotros no nos damos cuenta de que podemos aprovechar estas reuniones para evitar:
- bugs en producción
- malentendidos con desarrollo
- retrabajo innecesario
- decisiones mal tomadas
Recientemente estoy trabajando para un cliente que tiene una práctica interesante de reunir a su equipo semanalmente para compartir conocimiento y entrenar al equipo en ciertas habilidades, tanto blandas como técnicas, y se han dado muchas conversaciones respecto a la utilidad de las reuniones y cómo llevarlas. Ya hace un tiempo leí un libro que me ayudó mucho, y este artículo está inspirado en ideas de “El arte de reunirse” de Priya Parker, y voy a intentar explicarlo para todos los que hacemos vida en el mundo de QA.
1. Las reuniones en QA no son opcionales (son parte de la calidad)
Muchos QAs piensan que su trabajo empieza cuando el código está listo o hay una interfaz para probar, pero hoy quiero reafirmarte que la calidad se construye en conversaciones, en las reuniones de:
- refinamientos
- planning
- dailies
- retros
Si esas reuniones fallan, la calidad también. Y te explico las razones: ya sea que no entiendes el negocio, o no identificas riesgos, o tal vez no haces las preguntas correctas, te puedo asegurar que una reunión bien hecha puede evitar más bugs que 100 casos de prueba.
2. El problema no es la reunión, sino no tener un propósito
La mayoría de las reuniones en equipos de desarrollo tienen este problema: se hacen por cumplir ceremonias o porque simplemente “siempre hay daily”, “toca refinamientos” o porque “hay que alinearnos”, pero nadie define:
¿Qué decisión vamos a tomar aquí?
Entonces las reuniones terminan volviéndose una conversación que genera más ruido que valor. Por ello es requisito indispensable saber qué realmente vamos a conseguir con cada reunión.
3. Una reunión en QA es un espacio para decidir
Desde hoy quiero que recuerdes:
Una reunión no es para hablar. Es para decidir.
Para todos los que hacemos calidad, decidir significa:
- qué se prueba primero
- qué riesgo aceptamos
- qué escenarios son críticos
- qué no se va a probar
Si sales de una reunión sin decisiones, no fue una reunión útil.
4. El error más común: querer que la reunión sirva para todo
Este es el clásico en equipos ágiles: una sola reunión donde se intenta hacer seguimiento, discutir bugs, planificar, alinear negocio y resolver bloqueos.
En mi país hay un dicho que dice: “el que mucho abarca, poco aprieta”, y te digo por experiencia que cuando este escenario ocurre, el resultado es:
- nadie profundiza
- nadie decide
- todos pierden tiempo
Ejemplo típico en QA:
- una daily que se convierte en debate técnico
- un refinement que se vuelve retrospectiva
- una demo que termina siendo una discusión de bugs
Por ello te comparto una regla clave: una reunión = un propósito.
5. Cómo diseñar una reunión efectiva como QA
Vamos a poner en pasos cómo preparar una reunión efectiva tomando en cuenta las enseñanzas del libro.
Paso 1: Define un propósito concreto
No sirve:
- “hablar del sprint”
- “ver cómo vamos”
Sirve:
- “identificar riesgos de calidad antes del desarrollo”
- “decidir qué historias entran al sprint considerando testing”
Paso 2: Haz el propósito cuestionable
Esto es una idea clave que comparte el libro:
Un buen propósito genera decisiones difíciles.
Ejemplo:
- “mejorar calidad” → no cambia nada y es muy ambiguo
- “reducir bugs en producción este mes priorizando riesgo sobre cobertura” → cambia muchas planificaciones dentro del equipo
Paso 3: Diseña la reunión desde el resultado
Pregúntate:
¿Qué debería haber cambiado cuando termine esta reunión?
Ejemplos:
- lista de riesgos priorizados
- decisiones de alcance
- acuerdos entre QA y dev
Eso define:
- agenda
- dinámica
- duración
Paso 4: Elimina lo que no aporta
Todo lo que no ayuda al propósito se elimina.
Incluye:
- temas irrelevantes
- personas que no aportan
- discusiones que se pueden mover a otro espacio
6. Por qué esto cambia tu impacto como QA
Como te decía al principio, las reuniones son parte de nuestro trabajo. Así que un QA que utiliza bien las reuniones detecta problemas antes, influye en decisiones, aporta valor temprano y, sobre todo, deja de ser la persona que “prueba”.
Y esto conecta directamente con un enfoque mayor de Shift Left Testing, porque la calidad empieza en la conversación, no en la ejecución de las pruebas.
7. Recurso práctico: Template para reuniones de QA
Puedes usar esto desde mañana:
Plantilla: Reunión efectiva para QA
1. Propósito (1 sola frase):
¿Qué decisión queremos tomar?
2. Resultado esperado:
¿Qué cambia después de la reunión?
3. Qué NO se va a tratar:
Para evitar ruido.
4. Participantes clave:
Solo los necesarios.
5. Agenda enfocada en decisiones:
- Contexto
- Discusión
- Decisión
6. Criterio de éxito:
¿Cómo sabemos que valió la pena?
Puedes integrarlo en:
- refinements
- plannings
- sesiones de riesgo
- retros
8. Cierre: una invitación
Este artículo está basado en ideas del libro “El arte de reunirse” de Priya Parker.
Te recomiendo leerlo, pero más importante aún: empieza a cuestionar tus reuniones desde hoy.
Antes de entrar a la próxima, pregúntate:
¿Para qué existe esta reunión?
Y si no hay respuesta clara… quizás no debería existir.
Déjame saber en los comentarios si este artículo te ha servido y nos vemos la próxima semana con otro tema relacionado con las reuniones.
Si te ha gustado este artículo, recomiéndame con otras personas que estén empezando en el mundo de la calidad o que creas que esta información le puede ser útil.
