Lo que deja una lluvia de ideas
Por qué una lluvia de ideas pierde ideas durante y después de la sesión, y cómo Storyarn mantiene las decisiones del equipo unidas a los personajes, flujos y escenas que cambian.
Una lluvia de ideas puede salir bien y aun así no dejar nada.
La hora se pasa volando. Cuarenta notas llenan el tablero, dos finales sobreviven a la discusión y todo el mundo sale de acuerdo en que el farero quiere perdón, no poder. Tres semanas después, su ficha de personaje sigue describiéndolo como ambicioso, quien está reescribiendo el tercer acto no sabe qué final ganó y nadie recuerda quién iba a cambiar el flujo. Las ideas eran buenas. Lo que se perdió fue la decisión.
La lluvia de ideas es más antigua que casi todas las herramientas que usamos para practicarla, y la investigación sobre ella es especialmente clara sobre dónde falla: cuando un grupo habla demasiado pronto y cuando nadie lleva el resultado hasta el trabajo.
El doble de ideas
En 1953, Alex Osborn publicó Applied Imagination, el libro que convirtió la lluvia de ideas en un método: buscar cantidad, aplazar la crítica, dar la bienvenida a las ideas extravagantes, combinar y mejorar. En la edición de 1957 fue más allá y afirmó que una persona media podía pensar el doble de ideas en grupo que sola.
Los experimentos apuntaron en la dirección contraria. En 1958, Taylor, Berry y Block compararon grupos reales con grupos «nominales», formados por personas que trabajaban solas y cuyas ideas se sumaban después. Los grupos nominales produjeron casi el doble de ideas distintas. En 1987, Michael Diehl y Wolfgang Stroebe atribuyeron la mayor parte de esa pérdida al bloqueo de producción: en una sesión hablada solo habla una persona a la vez, y las ideas se desvanecen mientras los demás esperan su turno. Un metaanálisis de 1991 de veinte estudios, firmado por Brian Mullen, Craig Johnson y Eduardo Salas, concluyó que los grupos de lluvia de ideas son significativamente menos productivos que los grupos nominales «tanto en cantidad como en calidad».
Los grupos, además, convergen. Nicholas Kohn y Steven Smith comprobaron que las ideas de los participantes se ajustaban a las que ya habían propuesto otros, y que los grupos exploraban menos tipos de ideas. Y casi nadie lo nota: Paul Paulus y sus colegas describieron una ilusión de productividad del grupo, en la que sus miembros creen que el grupo les ayudó más de lo que lo hizo.
Nada de esto significa que los equipos deban dejar de reunirse. Significa que el orden importa. Los métodos que parten de esa idea existen desde hace más de cincuenta años. El brainwriting 6-3-5 de Bernd Rohrbach, de 1969, hace que todo el mundo escriba antes de que nadie hable. La técnica de grupo nominal que describieron André Delbecq y Andrew Van de Ven en 1971 pide a los participantes que primero trabajen en silencio y por separado, y solo después compartan, discutan y elijan. Las ideas de los demás no son el problema; pueden despertar ideas nuevas una vez que cada persona ha podido escribir las suyas.
Elegir es el paso débil
Generar ideas se lleva casi toda la atención, pero elegir entre ellas es más difícil de lo que parece. En un estudio de 2006, Eric Rietzschel, Bernard Nijstad y Wolfgang Stroebe observaron que, cuando los participantes escogían sus mejores ideas, su selección «no era significativamente mejor que el azar».
Además, una buena elección tiene que salir de la sala. No encontramos ningún estudio que mida con qué frecuencia se pierden las decisiones de un taller, y no vamos a inventarnos una cifra. Los indicios indirectos, eso sí, van en la misma dirección. Un estudio de 92 reuniones de equipo grabadas asoció la planificación de acciones con la productividad del equipo, y el investigador de reuniones Steven Rogelberg señala que poner un nombre a una tarea delante de todos aumenta la probabilidad de que se haga. Los propios fabricantes de pizarras digitales lo dicen. Un artículo de Miro describe ideas que «acumulan polvo» cuando termina la sesión y propone enviarlas a Jira. Una guía de Figma pide que alguien pueda volver a abrir el archivo semanas después «y ver dónde terminasteis», y que se asignen responsables.
Los equipos de software se toparon con el mismo problema de otra forma. En 2011, Michael Nygard propuso los registros de decisiones de arquitectura: registros breves con un estado (propuesta, aceptada y, más adelante, obsoleta o sustituida) que se guardan junto al código porque «los documentos grandes nunca se mantienen al día». La decisión vive donde ocurre el trabajo.
Una decisión narrativa llega lejos
En un juego narrativo, la distancia entre la sala de reuniones y el trabajo es mayor. «Tobin quiere perdón, no poder» no es una tarea. Cambia una ficha de personaje, las condiciones de una conversación ramificada, el final que depende de ellas, quizá una escena y, más tarde, las frases que van a traducción y a grabación.
Baldur’s Gate 3 muestra ese alcance a gran escala y hace muy poco. Durante el acceso anticipado, Larian llegó a la conclusión de que la historia de uno de sus compañeros no funcionaba. En el Panel From Hell de 2023, el guionista jefe Adam Smith explicó que Wyll «tenía una historia increíblemente atractiva, pero no la estábamos contando tan bien como podíamos», y que «prácticamente cada línea de diálogo se ha reescrito». En enero de 2026, el guionista sénior Kevin VanOrd añadió que el equipo «empezó de cero en un momento en que la mayoría de las historias de los demás compañeros ya estaban bastante asentadas». Se recortó una situación en el Colegio de la Guerra Roja en la que Wyll iba a tener mucho peso y, cuando llegó el momento de escribir el material nuevo, una enfermedad inesperada apartó a VanOrd del estudio durante bastante tiempo. El contenido de Wyll, dice, quedó «más escaso de lo que me habría gustado». La decisión fue acertada. Aun así, tuvo que llegar a cada línea de un personaje con voz completa y a cada escena que dependía de él.
Una pizarra de uso general no sabe de qué ficha de personaje ni de qué flujo habla una nota. No es un defecto; es lo que la hace buena para todo. Pero significa que el vínculo entre el acuerdo y el contenido vive en la memoria de alguien, o en un ticket que describe el cambio en lugar de señalar el contenido.
Cómo lo hemos planteado en Storyarn
El brainstorming de Storyarn vive dentro del proyecto, junto a las Fichas, los Flujos y las Escenas de los que habla. Es deliberadamente acotado. Miro, FigJam y otras pizarras siguen siendo mejores herramientas para talleres abiertos, diagramas y todo lo que queda fuera de la historia, y no pretendemos sustituirlas. Queríamos un lugar donde la exploración de un equipo narrativo termine en el contenido que cambia.
Una sesión es un lienzo de notas dividido en rondas, cada una con su propia pregunta. Una ronda puede ser privada: cada persona escribe sola y solo ve marcadores grises en lugar de las notas de los demás, hasta que el facilitador revela la ronda, o lo hace el temporizador si la ronda está configurada para revelarse al terminar el tiempo. Es el orden del grupo nominal, escribir primero a solas y compartir después, integrado en el lienzo en lugar de depender de la disciplina de cada uno. Las notas relacionadas se reúnen en grupos con una síntesis escrita, que es donde empieza a tomar forma una dirección.
Después, una decisión recoge lo que el equipo acordó hacer, con una forma pensada para sobrevivir a la sesión: un verbo (crear, cambiar, probar, mantener o descartar), hasta cinco Fichas, Flujos o Escenas afectados, una conclusión, un motivo y una siguiente acción opcionales, y la versión exacta de las notas de las que sale. El responsable la acepta de forma explícita. No hay votaciones, y nadie más puede aceptarla en su nombre. Como un registro de decisiones, se puede revisar, retirar o sustituir sin perder su historial.
Lo más importante llega después de aceptarla. La decisión aparece donde está el trabajo: como un contador en la cabecera del editor afectado, en una lista de «Decisiones sobre Mara» dentro de ese editor, como un aviso junto al contenido cuando alguien va a aplicarla, como una notificación para quien tiene que actuar, en un dashboard que puede agrupar las decisiones por contenido afectado y en la paleta de comandos cuando buscas al personaje. Después, un editor marca cada Ficha, Flujo o Escena afectado como aplicado, aplicado en parte o sin cambios necesarios; normalmente, quien hizo el cambio.
El puente también funciona en sentido contrario. Desde cualquier Ficha, Flujo o Escena puedes empezar una exploración con ese contenido como contexto, o retomar las sesiones que ya están vinculadas a él. Las guías de Brainstorming explican cada pieza en detalle.
De las notas a la historia
El valor de una lluvia de ideas se comprueba tres semanas después, cuando el equipo necesita recordar qué eligió y qué debe cambiar. Escribir primero en privado abre espacio a perspectivas distintas; compartir y sintetizar ayuda a elegir. La decisión perdura cuando alguien la acepta y la lleva al contenido.
Storyarn conserva el recorrido desde las notas hasta el acuerdo y, cuando el equipo señala el contenido afectado, hasta las Fichas, los Flujos y las Escenas donde habrá que actuar. Las personas siguen haciendo y revisando esos cambios. Cuando quien reescribe el tercer acto encuentra el acuerdo sobre el farero y el trabajo pendiente, la sesión ha dejado una decisión que el equipo puede entender y llevar a cabo.