poniedziałek, 27 października 2014

Symulacyjne gry szkoleniowe w IT

1.    Gracze rozstawiają figury

Nauczam rozmaitych przedmiotów od dawna. Zacząłem, jeszcze jako nastolatek, ale nigdy nie robiłem tego w tradycyjnej szkole, a więc zawsze moim celem było rzeczywiście nauczyć, a nie wzmóc swój prestiż, okazać władzę, popisać się erudycją czy też zaimponować uczniom, mówiąc, jak to dana dziedzina jest rzekomo strasznie trudna i skomplikowana. Stąd bierze się moje zainteresowanie skutecznością. Napisałem już na ten temat kilka tekstów:
  • „Kupując wiedzę: przewodnik po szkoleniach” (2001)
  • “This Is Simply Not True! Test Teacher’s Confessions” (2004)
  • „Jak sprzedawać nietypowe szkolenia? Podręcznik cynicznego sprzedawcy” 2006
  • „Nareszcie kryzys” 2008
  • „Open Accreditation for Better Certification” (2011).
Dość wygodne jest nauczanie wąskich, praktycznych umiejętności: na przykład języków, zarówno tych naturalnych, jak i języków programowania, obsługi narzędzi, zarówno IT jak i tradycyjnych, systemów operacyjnych, czytania mapy i orientacji w terenie, gotowania, standardu PRINCE2, albo procedury obsługi pralki. Przy stosunkowo niewielkim wysiłku cel zostaje osiągnięty, a korzyść dla uczniów jest oczywista i nieulegająca wątpliwości: automatycznie dobrze oceniają oni nauczyciela, lub trenera, dzięki któremu potrafią zrobić lub nazwać to, co ledwo kilka dni czy nawet kilka godzin wcześniej było nieznane, albo sprawiało trudności.

Sam przebieg takiego szkolenia też zwykle nie przynosi niespodzianek. Zakres tematyczny jest dokładnie określony, potrzeby uczestników – jednoznaczne i dobrze przez nich uświadomione, więc o ile tylko prowadzący jako-tako zna zagadnienie, nie musi spodziewać się ani nieoczekiwanej konieczności modyfikacji zakresu, ani zbyt trudnych pytań, ani zaskakujących zwrotów akcji. Zbędne, a w każdym razie niekonieczne są też wszelkie aktywizujące, motywujące i angażujące sztuki dydaktyczne – konkretna i świadoma potrzeba uczestników jest ich najlepszym stymulatorem. Dzięki temu, takie szkolenie może poprowadzić każdy, kto choć trochę zna temat. Z pomocą gotowych slajdów prezentacji, na które prowadzący może sobie dyskretnie zerkać, jest to jeszcze łatwiejsze.

Trudniejsze, znacznie trudniejsze jest nauczanie umiejętności szerszych, takich jak – między innymi - większość obszarów inżynierii oprogramowania. Wprawdzie niektórzy dostawcy szkoleń IT pod nazwą „inżynieria oprogramowania” umieszczają zwyczajne szkolenia narzędziowe i językowe (na przykład [ocenzurowano] - nie jest to przykład odosobniony), ale wynika to z niezrozumienia, niestety dość powszechnego, czym naprawdę jest inżynieria oprogramowania. W innych branżach takie pomyłki są rzadsze, nikt raczej pod nagłówkiem „architektura”, „budownictwo” czy „inżynieria budowlana” nie umieści szkoleń z zakresu posługiwania się młotkiem, pędzlem, śrubokrętem czy koparką. Pozostawiwszy jednak na boku te kłopoty z nazwami, można stwierdzić, że nauczanie inżynierii oprogramowania, tak samo, jak innych szerokich, otwartych tematów, jest wyzwaniem. To wyzwanie ma wiele wymiarów, skoncentruję się tutaj na dwóch najważniejszych:
  • Zdobycie przez uczestników umiejętności łączenia teorii z praktyką, czyli wyboru i zastosowania odpowiednich modeli rozwiązań do rzeczywistych sytuacji;
  • Uświadomienie sobie przez uczestników swoich rzeczywistych potrzeb oraz zrozumienie, jak do nich stosuje się tematyka szkolenia; to jest koniecznym warunkiem powstania zainteresowania i utrzymania się motywacji podczas trwania szkolenia, zadowolenia uczestników oraz uzyskania przez nich - po szkoleniu - długoterminowych korzyści.
Metody, wystarczające przy realizacji szkoleń wąskich, praktycznych umiejętności, zawodzą wobec nauczania tematów ogólniejszych, złożonych, takich jak – między innymi - zarządzanie (w tym – zarządzanie projektami), inżynieria wymagań, analiza biznesowa, zapewnienie jakości oprogramowania, testowanie.

2.    Analiza finansowa

W sumie, każdemu opłacają się bardziej umiejętności, które powyżej nazwałem szerszymi, czyli na nieco wyższym poziomie abstrakcji. Wiedzę szczegółową daje się zastosować tylko w jednej sytuacji, tylko w określonych okolicznościach, podczas gdy wiedzę ogólniejszą – we wszystkich podobnych sytuacjach. Najcenniejsza jest zgeneralizowana umiejętność uczenia się, pozwalająca radzić sobie lepiej niż inni w każdej nowej sytuacji, co - zwłaszcza w branży IT, gdzie nowości pojawiają się bez przerwy - przekłada się na decydującą przewagę konkurencyjną.

Podsumowując: najbardziej opłaca się wiedza szeroka, czyli… teoretyczna! Jak to? Przecież na co dzień, dla trenera nie ma gorszej opinii, niż ta, że jego wykłady są zbyt „teoretyczne”, a dla konferencji czy szkolenia najwyższą pochwałą jest, że jest „praktyczna”. Skąd ten rozdźwięk?

Popatrzmy na poniższą tabelę:

Potrzeba:             Teoria  A      B      C      Suma kosztów
Koszt szkolenia 1:    0       6.000  8.000  6.000  20.000
Koszt szkolenia 2:    10.000  3.000  4.000  2.000  19.000


9 stycznia 2015: zmieniłem dane, poprzednie były błędne :-(
Dziękuję http://www.goldenline.pl/jakub-wojt za wskazanie błędu! 

Tabela 1. Koszty szkoleń praktycznych i teoretycznych

Dane w tabeli ilustrują zależność kosztów zdobywania wiedzy , potrzebnej w nowej sytuacji (kolumny A – C w tabeli) od tego, czy ma się w danym obszarze podstawy teoretyczne. Dane są oczywiście uogólnione, mają za zadanie tylko ilustrować ogólną zasadę. Przy takich założeniach, kosztowne i na pierwszy rzut oka nieopłacalne szkolenie teoretyczne, amortyzuje się z nawiązką już po kilku (w naszym przykładzie – trzech) kolejnych sytuacjach, gdzie niezbędna okazała nowa wiedza.

Modny dziś, jednostronny nacisk na korzyści umiejętności praktycznych, na praktyczne doświadczenia, jest poważną przeszkodą dla kreatywności, dla długofalowych inwestycji, dla rozwoju; to recepta na dreptanie w miejscu i podążenie za modą, którą stworzyli inni.

Słyszę głosy protestu? Oczywiście, macie rację! - powyższe wyliczenie jest trafne tylko pod warunkiem, że posiadana wiedza teoretyczna rzeczywiście przekłada się na obniżenie kosztów zdobywania kolejnych umiejętności praktycznych, co przecież nie zawsze się sprawdza.

Podobnie, wyciągnąwszy z zanadrza kolejny mocny argument na rzecz opłacalności umiejętności teoretycznych: że dzięki nim możliwe są nie tylko działania reaktywne, radzenie sobie z nieuniknionymi kłopotami, ale także działania proaktywne – zapobiegania kłopotom, ulepszania sposobu pracy, tworzenia nowych technologii, spotkałbym się ze słusznym zastrzeżeniem, że nie każda wiedza teoretyczna przekłada się na takie pożądane ulepszenia, że równie często,  może nawet częściej staje się jałowym i nieprzydatnym teoretyzowaniem.

Wiedza teoretyczna jest jak laska dynamitu: odpowiednio zastosowana, wysadza skały i usuwa przeszkody, źle użyta nie służy do niczego, albo wręcz może wysadzić domy.

Jak więc zapewnić sobie korzyści, jednocześnie unikając zagrożeń?

3.    Wykłady, warsztaty, seminaria, coaching i doradztwo

Wykład jest najprostszym sposobem nauczania: to w zasadzie mówiona książka, bez ćwiczeń. Doskonale nadaje się do tego, aby wysyłać wiedzę do innych, ale  jego skuteczność dla odbiorców jest już znacznie mniejsza. Wykłady od biedy mają sens wówczas, gdy – jak na studiach – najpierw dostaje się, podczas wykładów, obfity blok wiedzy teoretycznej, a potem – jest okazja, by tę wiedzę próbować zastosować w praktyce. Ponadto, wykłady – ale tylko krótkie! – mogą być wygodnym narzędziem do motywowania, inspirowania, szybką – szybszą niż tekst pisany – odpowiedzią na potrzebę chwili.

Nie bardzo jednak widzę miejsce dla tej formy nauczania w szkoleniach komercyjnych, bo wykład, to dopiero początek nauki, pierwszy krok. Nieskuteczne jest więc, porzucić uczniów i zostawiać ich samym sobie zaraz po pierwszym kroku.

Niedostatkom wykładów – w tym ich usypiającemu działaniu, nawet wobec uczestników rzeczywiście zainteresowanych – usiłuje się przeciwstawiać rozmaite formy przedsięwzięć szkoleniowych takie, gdzie uczestnicy biorą aktywny udział. Rzeczywiście, warsztaty, dyskusje, prace w grupach są zwykle znacznie ciekawsze i bardziej inspirujące od wykładów, ale czy naprawdę lepiej uczą, skuteczniej przekazują wiedzę i umiejętności?

Osobiście mam także sceptyczny stosunek do rozmaitych tak zwanych warsztatów. Są one manną z nieba dla przepracowanych nauczycieli, ale czy naprawdę są równie dobre dla uczestników? Najpierw pokazuje się kilka przeźroczy z teoretycznymi podstawami, potem stawia zagadnienie albo zadaje pytanie, po czym następuje pół godziny pracy w grupach, pięciominutowa prezentacja każdej z grup i voilá! – nauczyciel nie przemęczony wędruje do domu z dobrymi ocenami warsztatu na ankietach. Uczestnicy też czują się dobrze, pogadawszy z pełnymi zrozumienia partnerami niedoli przez kilka godzin. Pozostaje jednak pytanie, czy ktokolwiek czegokolwiek naprawdę nowego się nauczył?

Kurs szkoleniowy nie powinien przypominać spotkania anonimowych alkoholików, gdzie uczestnicy wspólnie roztrząsają swoje poczucie nieadekwatności, wyznają swoje winy i potknięcia, żalą się na bezduszny świat i w końcu wędrują do domu z uczuciem ulgi i pogodzenia ze sobą!” [requirementsjournal.com/PL/Wiedza/kupujac_wiedze.pdf]

Coaching i doradztwo w konkretnych sytuacjach, nie są wprawdzie zaliczane do szkoleń, ale służą temu samemu: kierowaniu rozwojem wiedzy i umiejętności. Jak wykład jest wygodny dla nadawcy, ale niedobry dla odbiorcy, tak doradztwo jest wprawdzie znakomite dla odbiorcy, ale skuteczne jest jedynie pod warunkiem ogromnego zaangażowania czasu i środków, z obu stron. Jednak świat, gdzie każdy będzie miał swojego indywidualnego coacha – doradcę – mentora, chyba nie nadejdzie nigdy, o ile takiego rozrzutnego szaleństwa nie sfinansują nam jacyś Marsjanie.

Żarty na bok – jest droga pośrednia. Symulacyjne gry szkoleniowe łączą w sobie zalety tych trzech form nauczania: wykładu, warsztatu oraz doradztwa. Co więcej, pozwalają sprawnie łączyć teorię z praktyką, uczyć się sposobów elastycznego dobierania metod, poznanych w teorii, do wyzwań, spotykanych w rzeczywistości. Ich prowadzenie wymaga od trenerów najwyższych kwalifikacji, zarówno merytorycznych, jak i metodycznych, oraz dużego doświadczenia, co pośrednio może stać się korzystnym czynnikiem hamującym wielką inflację kwalifikacji, wymaganych do prowadzenia szkoleń, jakiej doświadczamy od kilkunastu lat.

4.    Szkoleniowe gry symulacyjne dzisiaj

Można je zrobić na zamówienie, w różnych formach, od gier planszowych, poprzez rozmaite układanki  i łamigłówki, gry typu znanego „monopolu”, albo projektowanie (np. oferta firm „Pracownia gier”, pracowniagier.pl oraz „MindLab”, mindlab.pl). Dominuje oferta gier menedżerskich: symulacje finansowe, tworzenie strategii, zarządzanie zasobami ludzkimi, sprzedaż (np. trenerzy.pl). Przeszukując zasoby Internetu pod hasłem „szkoleniowe gry symulacyjne” (po angielsku najbliższy znaczeniowo termin to „simulation based training games”), można wręcz ulec wrażeniu, że to podejście dominuje, ale to złudzenie: nadal symulacyjne gry szkoleniowe są raczej rzadkością, a firmy, które je realizują, liczą za swoje usługi znacznie więcej, niż za szkolenia tradycyjne.

5.    Nowość – szkoleniowe gry symulacyjne w nauczaniu IT

Symulacyjne gry szkoleniowe powoli wchodzą także w nauczanie inżynierii oprogramowania, tej prawdziwej, a nie przemycanych pod tą nazwą kursów narzędzi, systemów operacyjnych czy języków programowania. Mają w sobie potencjał, by skutecznie odmienić krajobraz szkoleń IT. Dla zilustrowania, że metoda sprawdza się nawet w odniesieniu do zagadnień uważanych za techniczne, posłużę się przykładem z bliskiej memu sercu dziedziny testowania oprogramowania, a dokładniej – kwestii dotyczących automatyzacji wykonywania testów.

Od wielu lat szerzy się w tym obszarze mnóstwo nieporozumień, pogłębianych mylącymi próbami klasyfikacji typów narzędzi , oraz tym, że promocję nowych narzędzi o wiele skuteczniej prowadzić dziwacznymi nazwami („selen”, „sprawność”, „ogórek” – poznajecie :-) te narzędzia?) i gołosłownymi hasłami („zwinne narzędzia”, „intuicyjne narzędzia”), niż odwołaniem się do uciążliwej systematyki:
Na tych nieporozumieniach wszyscy tracimy wiele czasu i pieniędzy. Ze wstydem przyznam się, że wiele razu sam wpadłem w pułapkę mozolnego i namolnego opowiadania o systematyce narzędzi testowych, usypiając tym uczestników szkoleń. A jak to zrobić grą symulacyjną? Na ilustracji poniżej, stosowny fragment planszy do gry:


Rysunek 1. Fragment planszy do 3-dniowej symulacyjnej gry szkoleniowej „Testowanie oprogramowania”

Gra toczy się na specjalnej planszy, uczestnicy (zespoły) rzucają kolejno kostką i przesuwają swoje piony na wyznaczone liczbą oczek kostki pola. Jest wiele pól decyzyjnych – tam zespoły muszą podjąć decyzję, którą odnogę wybrać. Do wielu pól przywiązane są rozmaite wydarzenia, korzystne dla zespołu lub niekorzystne, czasem wymagające dodatkowej pracy, albo obliczeń, albo dalszych decyzji.

Kiedy uczestnik, lub zespół, rzucając kostką, dojdzie do pola „76”, musi podjąć decyzję „D14”: automatyzacja wykonywania testów, lub rezygnacja z niej. W tym miejscu może też pojawić się, zależnie od przewidzianej czasochłonności partii tego testowego brydża, praca w grupach, prezentacja stanowisk oraz mini-wykład dotyczący (1) innych opcji automatyzacji; (2) argumentów za i przeciw automatyzacji.

Wybrawszy rezygnację, zespół będzie prowadził swój pionek dalej trasą 77, 78…, na której oczywiście czeka wiele niespodzianek, natomiast wybrawszy automatyzację, zespół rusza polami 90, 91, 92… Kto ma pecha, i stanie pionkiem na polu 91, przeczyta: „analiza i porównywanie dostępnych na rynku narzędzi zajęła trzy osoby przez dwa tygodnie, tracisz kolejkę i cofasz się z powrotem na pole 76” :-). Ale pech!

Pole „93” wymusza podjęcie kolejnej decyzji, „D15”: czy będziemy tworzyć skrypty (programy) automatycznych testów metodą zarejestruj-odtwórz (dalszy kierunek 100, 101…), czy też sposobami bardziej zaawansowanymi (kierunek 94, 95…)? Na planszy droga w kierunku 100, 101… jest kusząco znacznie krótsza, niż kierunek alternatywny, ale najeżona pułapkami. Możecie się domyśleć, że zaraz za granicą tego kawałka planszy, może już na polu 102 albo 103, kryje się straszna bomba: „uruchomienie nagranych skryptów tylko siłami testerów akceptacyjnych okazało się zbyt trudne i czasochłonne: rezygnujesz z automatyzacji, wracasz na pole 75 i tracisz dwie kolejki na zmianę harmonogramu testów oraz szukanie winnych i kozła ofiarnego”.

Czytelnikom, nieobeznanym z tajnikami i dość szczególną terminologią automatycznych testów, powiem, że tę metodę można stosować do mnóstwa innych zagadnień: zmieniwszy tło planszy :-), można decyzję „D14” przedstawić na przykład jako wybór między opisem wymagań w języku naturalnym, a ich opisem w postaci diagramów wybranego modelu UML; wówczas decyzja „D15” może być miejscem trudnego wyboru między ręcznym rysowaniem takich modeli, a konstruowaniem ich przy pomocy narzędzia, i tak dalej.

Niezależnie od tematyki, kształtu i treści każdej gry, daje ona uczestnikom następujące korzyści:
  • Uczymy się podejmować decyzje w różnych sytuacjach i obszarach projektu;
  • Poznajemy w praktyce sposoby myślenia dla budowania najlepszej strategii;
  • Motywuje nas rywalizacyjna między zespołami, i walka z losem;
  • Spotykamy się z ryzykiem, prawdopodobieństwem i nieprzewidzianymi zmianami sytuacji, jak w życiu;
  • Dostajemy informację od trenera wtedy, gdy jest nam potrzebna, co wybitnie ułatwia zapamiętywanie;
  • Uczestnicy są bardzo zaangażowani, dobrze się bawią i nie męczą intensywną pracą.
  • Uczestnicy w naturalny, a nie wymuszony sposób, pracują i podejmują decyzje zespołowo, wymieniając się doświadczeniami z własnej praktyki zawodowej.
6.    Zapraszam do gry!

Opisy szkoleń, realizowanych metodą gry symulacyjnej, zaczniemy prezentować już wkrótce na victo.eu/uczenie.html, ale już dziś możemy dla Was stworzyć i zorganizować taką grę związaną z każdym z tematów naszych szkoleń, lub z innym tematem, zadanym przez Was: bogdan.bereza@victo.eu.

Dla CTS, prowadzę grę pt. "Wyprawa statkiem „Fram” – symulacja biznesowa Agile".

Ponadto, 20 listopada (czwartek) podczas kolejnego spotkania WarszawQA, o godzinie 18:00 w Warszawie, będę miał przyjemność zaprezentować kawałek takiej gry na temat testowania.

W dniach 26-27 listopada poprwadzę w tej formule warsztaty testowania w metodykach agile, dla IDG: computerworld.pl/warsztaty.

Brak komentarzy:

Prześlij komentarz