.st0{fill:#FFFFFF;}

Po prostu burza mózgów 

 17 września, 2018

Tomasz Dzierżek

Niewiele osób wie, że burza mózgów jest techniką, która jest całkiem ściśle zdefiniowana. Większości kojarzy się ona po prostu z niczym nieskrępowanym zgłaszaniem tematów. Zapominają oni jednak o etapie selekcji. Cała technika też dość „agile’owa”, dlatego zajmiemy się nią dziś nieco bliżej.

 

Z wielu technik i narzędzi korzystamy rutynowo, bez zastanowienia się. Im lepiej coś jest nam znane (albo wydaje nam się, że jest znane), tym bardziej polegamy na pamięci mięśniowej, przyzwyczajeniach i odruchach. Nie da się ukryć, że znacząco ułatwia nam to codzienne życie, ale i prowadzi do pułapek. Wystarczy przypomnieć sobie błędy poznawcze.

 

Burza mózgów, czyli generowanie pomysłów

Burza mózgów składa się z dwóch etapów, gdzie pierwszym jest oczywiście dobrze wszystkim znany etap generowania pomysłów.

Najważniejsze w tym etapie jest zaufanie i brak krytycyzmu. „Nie ma głupich pomysłów” to zasada, która powinna przyświecać każdej burzy mózgów. Wszyscy musza się czuć bezpiecznie i mieć możliwość nieskrępowanego zgłaszania idei.

Bardzo popularne agile’owe usprawnienie tej techniki, to zastąpienie dyskusji zapisywaniem pomysłów na samoprzylepnych karteczkach. Unikamy sugerowania się (patrz: anchoring), uwalniamy się od ocen innych, no i możemy zgłosić tyle pomysłów, ile nam się żywnie podoba.

Z drugiej jednak strony tracimy możliwość inspirowania się pomysłami innych. Dlatego też w niektórych przypadkach zalecane jest umieszczanie przygotowanych karteczek na wspólnej tablicy. Inni mogą je wtedy przeczytać, ale niekoniecznie znowu muszą je komentować.

Każdy etap burzy mózgów, a pierwszy w szczególności, powinien mieć z góry zdefiniowany czas trwania, czyli timebox. Oczywiście, wszystko może trwać krócej, jeśli widzimy, że dyskusja zamiera lub że nie pojawiają się nowe karteczki.

Wtedy powinniśmy ruszyć dalej.

 

Burza mózgów, czyli selekcja

Burza mózgów to nie jest po prostu zgłaszanie wszystkiego, co nam przyjdzie do głowy i traktowanie tego, jako świetnych pomysłów trafiających od razu do wdrożenia. Musi nastąpić chwila refleksji i selekcji. Musimy wybrać te najbardziej istotne problemy lub najbardziej atrakcyjne pomysły.

Sposobów na wypracowanie tego konsensusu jest mnóstwo. Podejrzewam, że jest ich nawet więcej niż technik usprawniających samo generowanie idei.

W klasycznym wariancie wspieramy się ekspertami, którzy oceniają zgłoszone pomysły i wybierają spośród nich te, które są najbardziej atrakcyjne. Podejście te ma oczywiste wady: pomysły są „oceniane” przez „ekspertów”, a więc grupa traci odpowiedzialność za efekt swojej pracy.

O wiele lepsze techniki to różnego rodzaju głosowania (tajne bądź jawne), gdzie ci sami ludzie, którzy zgłaszali pomysły oddają głosy na ich zdaniem najważniejsze punkty. Ponieważ całe ćwiczenie wykonuje wtedy ta sama grupa, to jest ona w pełni odpowiedzialna z efekt końcowy i bardziej się z nim identyfikuje.

W ramach głosowania zbliżone pomysły można grupować tak, aby uniknąć rozmieniania się na drobne. Jedna idea wyrażona na kilkanaście sposobów nadal pozostaje jednym pomysłem.

 

Uwaga na dominację

Największym zagrożeniem, są silne jednostki, które potrafią zdominować całe spotkanie. Szczególnie widać to wśród grup, w których pomysły są zgłaszane w toku dyskusji. Problem ten wcale nie znika, jeżeli zdecydujemy się na karteczki!

Wystarczy, że jedna osoba zgłosi kilkadziesiąt karteczek, podczas gdy reszta grupy – po jednej lub dwóch. Spowoduje to, że przez cały czas rozmawiać będziemy o tym, co trapi daną osobę o silnym charakterze i „zapomnimy” o całej grupie.

W podobny sposób możemy stracić opinię osób, które są wstydliwe bądź boją się być oceniane. Jeżeli nie zapewnimy odpowiedniego środowiska, nie będą one zgłaszały kontrowersyjnych propozycji, pomimo tego, że ustaliliśmy, że nie oceniamy.

Oczywiście osobą, która powinna zapanować nad grupą w kontekście spotkań typu Sprint Retrospective jest Scrum Master. To on, jako facylitator, powinien zapewnić nie tylko płynność procesu, ale i przede wszystkim jego efekt końcowy. W tym także równomierny udział wszystkich w spotkaniu.

 

Agile’owa burza mózgów

Dlaczego ta technika zdobyła popularność wśród entuzjastów zwinnego podejścia? Bo jest… „zwinna”. Bo nie zakłada z góry, jakie jest rozwiązanie problemu, tylko pozwala na wygenerowanie dużej liczy pomysłów (backlog) i następnie szereguje je w te bardziej i mniej pożądane (Product Backlog Refinement, Sprint Planning).

Można też powiedzieć, że jest to pewien sposób na realizację zapisanego w 12 Zasadach Zwinnego Tworzenia Oprogramowania postulatu mówiącego o tym, że „prostota, rozumiana jako sztuka maksymalizacji niezrobionej pracy, jest kluczowa”. Najpierw rozpoznajemy możliwości (generowanie pomysłów), a następnie odrzucamy jak najwięcej z nich (selekcja).

Bo udana burza mózgów jest nie wtedy, kiedy zgłosimy dziesiątki propozycji, ale kiedy dziesiątki odrzucimy. Celem jest wybranie najlepszej możliwej opcji.

Więcej o tym będziecie mogli posłuchać już za kilka dni na naszym kanale na YouTube.

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

  1. Fajnie , krótko i zwinnie opisany temat. Dodałbym może pare słów o sposobach wybory optymalnego rozwiązania. Ważnym aspektem na pewno też jest umiejętne dobranie osób. Często w obecności szefa wielu pracowników się zamyka, co może stanowić duży kłopot.

  2. Ciekawy artykuł! Myślę, że bardzo ciekawym narzędziem pomagającym zmitygować wspomnianą dominację jest użycie Liberating Structures zamiast klasycznej burzy mózgów 🙂

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}