Brainstorming Guiado

0

El brainstorming es una de las técnicas más utilizadas cuando se desea generar ideas. Básicamente consiste en juntarse en una sala, establecer unas reglas y dejar que la gente proporcione ideas. Pero ¿Qué reglas deben ser?

Este artículo versará no sólo sobre el brainstorming clásico, sino también sobre una variante muy útil cuando se desea encontrar una solución a un problema.

Brainstorming básico

La necesidad de un brainstorming es clara: necesitamos ideas. Hay que generar ideas. Para ello necesitamos juntar a todo aquel capaz de generar una idea y pedirle que las exprese sin tapujos. Sólo imponemos una norma: Prohibido criticar. Cuando alguien exprese una idea, nadie puede criticarla. El objetivo no es detectar la mejor idea, sino obtener ideas.

En este tipo de brainstorming debería haber dos roles clave, que pueden recaer en la misma persona:

  • Moderador: El moderador sólo tiene dos misiones. La primera es ir animando a la gente a decir ideas. La segunda es cortar cualquier crítica de raíz. Si alguna persona tiene más poder o influencia sobre los presentes en la sala, debería ejercer de moderador.
  • Secretario: La misión es ir apuntando todas las ideas que surjan. Su misión es que no se le escape ninguna. A ser posible lo que apunta debería ser público: como una pizarra o una pantalla de ordenador que todos ven. El secretario tiene mucha influencia en esta reunión.

Al final del Brainstorming obtendremos un montón de ideas. ¿Ese era el objetivo, no?

Brainstorming guiado

Este es un poco más complejo, y consiste en encontrar un acuerdo o una solución a un problema que no tiene una solución clara. Hablamos de situaciones en las que la intuición juega un papel importante y en donde es imposible demostrar que una solución es mejor a otra. Pero necesitamos encontrar una solución consensuada por todo el equipo.

Un ejemplo sería el diseño de una pantalla. Como dice mi anterior jefe (y mentor) “Hasta el camarero del bar es un experto en usabilidad”. Todo el mundo tiene una opinión. Y a veces en los equipos se montan discusiones que no terminan nunca sobre si esa lista tendría que ser un desplegable, un montón de iconos o abrirse en un pop-up. Además hablamos de problemas con soluciones multi-dimensionales. Es decir, hay que decidir una serie de aspectos, y se tienen que decidir en conjunto. Siguiendo el ejemplo, ¿Donde pongo el botón de aceptar? ¿Qué colores utilizo? ¿Cómo muestro cuando haya un error en los datos introducidos? Son varias dimensiones para las que hay que dar respuesta. El riesgo principal en estos casos es el análisis-parálisis. Es decir analizar, analizar y analizar, pero nunca actuar. El Brainstorming guiado nos evitará este análisis-parálisis.

El Brainstorming guiado es un poco más complejo que el básico y tiene varias fases, que deben seguirse a rajatabla.

Debe existir un rol de moderador, que igual que en el clásico debería ser la persona con más poder o influencia. Aunque podría ser otro.

Fase 1: Explicación del problema

El moderador explica el problema que se tiene entre manos. No proporciona soluciones, ni da su opinión. Simplemente expone el problema y da la guía de los objetivos que se desean cumplir.

Es importante la parte de no dar ninguna solución. No queremos en esta fase que haya una solución por encima de las demás. No queremos coartar a nadie. Lo ideal es que el equipo no tenga ni idea de la opinión del moderador. Hablamos del rol de moderador imparcial.

Fase 2: Brainstorming

Se pone un tiempo (10-20 minutos suele ser sano) y se abre un brainstorming. Se prohíbe criticar. El moderador tiene que ser muy estricto en eso. Y él es el primero que debe morderse la lengua. También debe controlar el tema. Es posible que la gente comience a dar ideas a temas que no son lo que se había venido a hablar. El moderador debe cortar esas ideas y mantener el alcance acotado.

Las ideas se van apuntando en una pizarra.

El moderador debe callarse sus propias ideas, por si alguien del equipo las dice primero. Si al acabarse el tiempo tiene ideas que no han surgido, las expone. Si han salido, no descubre sus cartas para demostrar su opinión, y se queda al margen. Recordemos que es un moderador imparcial.

Fase 3: Alegatos

Uno a uno todos los participantes exponen su solución y la justifican. Cada uno tiene que justificar por qué está escogiendo esa solución. El resto no puede criticar. Puede aplaudir (esto es nuevo, porque en la fase anterior no se podía), pero no puede hablar mal o poner malas caras. Cada participante coge el rotulador, la tiza o lo que sea que se use para explicar su solución completa. Básicamente es un ¿Cómo lo harías tú?. Todos los participantes están obligados a contar su solución al problema.

Mientras las expone el moderador trabaja en la posible división del problema. Intenta ver en qué puntos la gente ya está de acuerdo y en donde están los desacuerdos. De esta forma la decisión se descompone en una serie de preguntas con un listado de posibles respuestas cada una.

El último en mostrar su alegato es el moderador. Y sólo lo hará si su solución no puede extrapolarse con las soluciones de los demás. Sólo si aporta alguna visión nueva.

Fase 4: División del problema

Tras todas las soluciones explicadas, el moderador hace su división del problema, y plantea las preguntas y opciones. Los asistentes deben estar de acuerdo. Si alguno cree que las preguntas no son las adecuadas, o que falta alguna opción, debe indicarlo. El moderador les preguntará para asegurarlo.

Al acabar esta fase en la pizarra estará una serie de preguntas y las posibles respuestas.

Fase 5: Votaciones

Todos los presentes votan en cada pregunta y se mira qué opción es la más votada. Esto lleva a describir una solución.

Fase 6: Confirmación y compromiso

Se expone la solución y se pide confirmación a todos los asistentes. Aquí es muy fácil que todos estén de acuerdo en la solución pactada. Puede que no sea la que uno habría escogido, pero reconocerá que hay mayoría y la aceptará.

El moderador redacta la solución y la comunica a todos (un email, una wiki,…)

Ejemplo

Vamos a ver un ejemplo. Un equipo de 6 personas arranca y se va a gestionar por Scrum. No acaban de ponerse de acuerdo con los roles dentro del equipo, la duración del sprint, las dinámicas a implantar y las definiciones de “Ready” y “Done”. Todos estos aspectos se discuten continuamente y no se encuentra un quorum. El director del departamento lo detecta y decide montar un brainstorming guiado para evitar el análisis-parálisis. Así mete a todos en una sala y les dice que antes de comenzar deben quedar claros los roles, las dinámicas que se montarán y la duración del sprint. Las definiciones de “Ready” y “Done” quedan fuera del alcance, ya se tratarán más adelante.

Así explica a los asistentes que vayan diciendo ideas de como hacerlo, y que está prohibido opinar sobre lo que digan los otros. Comienza a anotar en la pizarra todas las ideas:

  • Carlos Scrum master
  • Scrum master rotativo
  • Sprint de 2 semanas
  • Sprint de 4 semanas
  • Duración de sprint variable
  • Posibilidad de que el sprint pueda ser de doble duración si el equipo lo acuerda
  • Usar el sprint planning
  • Hacer una review cada sprint
  • Hacer una review, pero cuando el equipo lo considere
  • Subir a producción al final de cada sprint.
  • Sólo subir a producción cuando el equipo lo considere.
  • Hacer releases cada N sprints
  • Etc.

Aparecen muchas ideas, y se van apuntando a la pizarra. Llega un momento que a nadie se le ocurre nada más. Y el moderador añade una mas: Hacer demos a negocio cada 2 sprints.

Con todo en la pizarra el moderador va pidiendo uno a uno que expliquen como lo harían. El primero entra y expone como montaría el rol de scrum master, la duración de los sprints y las dinámicas que ve en el equipo. El moderador hace una foto de la pizarra y le da el rotulador al siguiente. El siguiente dice que haría lo mismo, pero borra un par de cosas y las cambia. Así van saliendo todos y van aportando su visión.

Una vez han pasado todos, el moderador expone que hay quorum en los siguientes aspectos:

  • Se harán stand-up meetings
  • Se hará un sprint planning
  • Se hará review en cada sprint

También ve que hay 4 preguntas y cada una con las siguientes opciones:

  • Scrum Master
    • Carlos (tiene certificación)
    • Rotativo, cada dos sprints cambia (todos aprenden)
  •  Sprint
    • Cada 2 semanas (predecible, facilidad para reservar salas)
    • Variable, al inicio del sprint el equipo lo pacta. (adaptación al tamaño de las historias de usuario)
  • Frecuencia de Releases
    • Cuando el product owner considere, avisará en el sprint planning (alineación con negocio)
    • Cada 3 sprints (fuerza al equipo a tener versiones completas)
  • Demo a usuarios
    • Las hará el product owner
    • Las hará todo el equipo

Pregunta al equipo si creen que se ha dejado algo y todos confirman que no. Así comienza la votación a mano alzada sobre cada pregunta. Sale una combinación. El moderador la explica y el equipo está de acuerdo.

El moderador redacta un email y lo manda a todos los interesados.

Conclusiones y palabras finales

Este método permite llegar a un quorum en temas en los que se ve difícil solución. Y no es muy costoso. Cuando lo he utilizado hemos llegado al quorum en menos de una hora, para temas que rondaban meses por la oficina. Por lo tanto considero que es una buenísima herramienta para gestores.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios