blog.testowka.pl

Jak przygotowuję szkolenia?

opublikowany przez 14, Maj, 2011, w kategoriach Agile, Kanban, Scrum, Zarządzanie

Od ponad roku oprócz działalności testerskiej zajmuję się także między innymi szkoleniami z zakresu testowania oprogramowania i zarządzania projektami według zwinnych metodyk zarządzania. Jako że staram się być pragmatyczny we wszystkim co robię to także proces przygotowywania szkoleń staram się jak najbardziej zoptymalizować stosując do tego celu różne narzędzia.

kanbanery.com

Kanban board dla szkolenia "Zapewnianie jakości w projektach Agile"

Szkolenie można potraktować jako projekt dlatego też uważam, iż do zarządzania takim projektem można śmiało zastosować narzędzia stosowane do zarządzania projektami innego rodzaju – także projektami IT. Po wielu próbach i analizach doszedłem do wniosku, iż idealnie w moim przypadku sprawdza się Kanban, a właściwie tablica kanbanowa, która idealnie wizualizuje postępy prac. Moja standardowa tablica składa się z siedmiu kolumn:

Backlog: Tutaj zbieram swoje pomysły na zagadnienia, które chciałbym omówić podczas szkolenia. Zasadniczo (trochę wbrew zasadom kanbana) nie przejmuje się kolejnością zadań – w zależności od natchnienia i humoru wybieram zadania, nad którymi akurat mam ochotę popracować.

Zapewnianie jakośći w Agile - mindmap

Mindmapa do szkolenia "Zapewnianie jakości w Agile"

Analiza: Tutaj pojawiają się zadania nad którymi aktualnie pracuje. Sposób analizy poszczególnych zagadnień zależy w dużej mierze od samych zagadnień, niemniej jednak w moim przypadku najpierw rozpoczynam od zbierania materiałów na dany temat, następnie analizuje zebrane materiały wybierając najważniejsze i najbardziej wartościowe informacje (w końcu czas szkolenia jest ograniczony), po czym jeszcze raz weryfikuje wszystko czy pasuje do ogólnej tematyki szkolenia. Do analizy używam mindmap na których opracowuje materiały – dzięki temu cały czas mam obraz całości szkolenia i unikam zbędnych duplikacji. W efekcie dostaje obraz całego szkolenia, który bardzo łatwo zweryfikować i ogarnąć. Przygotowanie prezentacji na podstawie takiej mindmapy to już w zasadzie formalność. W kolumnie „Analiza” na mojej tablicy kanbanowej przeważnie stosuje limit maksymalnie 2 zadań wykonywanych równolegle – pozwala to na uniknięcie niepotrzebnego rozproszenia, a jednocześnie jeśli jedno zagadnienie zbytnio mnie zmęczy to dzięki temu, iż limit wynosi dwa a nie jeden mogę rozpocząć pracę nad innym zadaniem a do tego wrócić później. Narzuca to pewną dyscyplinę nie zabierając jednocześnie swobody i nie psując całej zabawy jaką jest przygotowywanie szkolenia.

Kolejną kolumną na tablicy jest kolumna Przeanalizowane jest to swego rodzaju backlog dla prezentacji. Tutaj znajdują się zagadnienia dla których opracowałem już mindmapy i które czekają tylko na przetworzenie informacji na prezentację. Tutaj także stosuje limity (przeważnie od 5 do 10) po to by uniknąć przygotowywania wszystkich slajdów nie zostawiać na sam koniec, dzięki temu mam zachowaną pewną płynność i cały czas wzrasta wartość dodana w moim projekcie – mierzona ilością slajdów.

Prezentacja – tutaj znajdują się zagadnienia dla których właśnie opracowuje slajdy. Podobnie jak w przypadku analizy tutaj też stosuje limity – powody takie same jak powyżej.

Do weryfikacji to kolumna, w której znajdują się w pełni opracowane zadania wraz z utworzonymi slajdami czekające na ostateczną weryfikację. Nie stosuje tutaj limitów, gdyż najbardziej efektywne okazało się weryfikowanie wszystkiego na samym końcu, gdy mam już pełny obraz całości szkolenia.

Weryfikacja, jak sama nazwa wskazuje w tej kolumnie pojawiają się zagadnienia, które są aktualnie weryfikowane. Narzuciłem sobie limit weryfikowanych zadań równy jeden, gdyż weryfikacja wymaga dużego skupienia i zwracania uwagi na wszystkie szczegóły. Weryfikacja polega na sprawdzeniu poprawności merytorycznej, wyłapaniu błędów i literówek, oraz ogólnym przejrzeniu materiałów. Często też podczas weryfikacji a także analizy zdarza mi się pytać o opinię koleżanki i kolegów po fachu.

Done – tę kolumnę lubię najbardziej, zwiększająca się tutaj ilość zagadnień daje mi największą satysfakcję i jest najlepszą miarą postępów w pracy nad przygotowywaniem szkolenia. Dzięki przejściu przez wszystkie poprzednie etapy/kolumny każde zagadnienie spełnia swoistą „definition of done”, która wygląda mniej więcej tak: Każde zagadnienie zostało zaplanowane i przeanalizowane, następnie zostały utworzone slajdy oraz nastąpiła ostateczna weryfikacja merytoryczna oraz weryfikacja pod kątem bezbłędności materiałów.

Dzięki powyższemu procesowi mam pewność, iż prezentowane przeze mnie materiały są w pełni wartościowe i nie zawierają błędów. Niemniej jednak na tym  nie kończy się cykl życia moich szkoleń. Pozostaje jeszcze ich prezentacja oraz ciągły rozwój i udoskonalanie.

Gdy rozpoczynałem swoją przygodę ze szkoleniami miałem okazję porozmawiać na ten temat z jednym z weteranów prowadzenia szkoleń w naszym kraju, zwrócił on moją uwagę na pułapkę monotonii. Pomimo tego, iż samo prowadzenie i przygotowywanie szkoleń jest bardzo ciekawe to z czasem znużenie podczas prezentowania po raz n-ty tych samych materiałów dotyka każdego, nawet najlepszego trenera. Mając na uwadze rady starszego kolegi (któremu z tego miejsca dziękuję) staram się takiej monotonii unikać, dlatego też moje szkolenia żyją własnym życiem i cały czas się rozwijają.

Nawiązując do zwinnych metodyk zarządzania projektami których jestem pasjonatem i które często są tematem moich szkoleń staram się prowadzić szkolenia mając na uwadze jedną z kluczowych zasad Agile – informację zwrotną. Gdy sam uczestniczyłem w różnego rodzaju szkoleniach zauważyłem pewne podobieństwo większości szkoleń do projektów informatycznych prowadzonych według klasycznych metodyk zarządzania opartych o waterfal. Przeważnie prowadzący szkolenie dostawał informacje zwrotną dopiero na sam koniec szkolenia, gdy uczestnicy wypełniali ankiety i oceniali szkolenie – podobnie jak w projektach informatycznych w modelu kaskadowym testy dające informacje zwrotną na temat tego czy aplikacja działa przeprowadzane są na końcu. Taka informacja owszem jest bardzo wartościowa, ale niestety prowadzący dostaje ją po fakcie i może co najwyżej udoskonalić następne szkolenia, niestety niezadowolenie czy też niedosyt uczestników obecnego szkolenia pozostaje.

Zastanawiając się nad tym jak efektywniej prowadzić szkolenia doszedłem do wniosku, iż podobnie jak w projektach informatycznych najważniejsze jest zdanie i wymagania klienta. Klientem dla moich szkoleń są ich uczestnicy, wiec szukałem sposobu, który podobnie jak Agile pozwala klientowi na sterowanie pracami na projektem informatycznym, pozwoli moim klientom sterować szkoleniem. Obecnie stosuje dwa artefakty zaczerpnięte z -Agile/Scrum – spotkania typu stand-up oraz retrospekcje.

Retrospekcja podczas szkolenia.

Mniej więcej co 3 godziny robię spotkanie stand-up na którym każdy z uczestników odpowiada na trzy pytania:
– Co ciekawego dowiedziałem się od ostatniego spotkania?
– Co było nudne i nużące, czego powinniśmy unikać na przyszłość?
– Czy było coś czego nie zrozumiałem/zrozumiałam i chciałbym/chciałabym aby zostało wyjaśnione dokładniej?
Dzięki odpowiedziom na powyższe pytania od razu dostaję informację zwrotną na temat tego co należy poprawić i co omówić dokładniej. Ponadto odpowiedzi na pierwsze pytanie nie są bezpośrednio dla mnie, lecz raczej podobnie jak spotkania stand-up w projektach informatycznych mają za zadanie wspierać wymianę informacji pomiędzy uczestnikami szkolenia – jest to pewnego rodzaju podsumowanie wiedzy, którą uczestnicy szkolenia zdobywają w jego trakcie.

Na zakończenie każdego dnia szkolenia przeprowadzamy retrospekcję podczas której na osi czasu, każdy uczestnik szkolenia zaznacza wydarzenia, które według niego miały wpływ na całkowity obraz szkolenia. Wbrew pozorom w ciągu jednego dnia może wydarzyć się bardzo dużo – na przykład na jednym z ostatnich szkoleń właśnie dzięki retrospekcjom uzyskałem bardzo trafną informacje na temat tego z jaką częstotliwością powinniśmy robić przerwy kawowe, czy też sugestię, że po każdej większej partii materiału powinienem zrobić jeszcze małe podsumowanie i utrwalenie wiedzy, a także jakich informacji było podczas szkolenia za mało. Ostatniego dnia szkolenia retrospekcje przeprowadzam przeważnie około 2 godziny przed planowanym czasem zakończenia szkolenia, dzięki temu mam jeszcze czas na wprowadzenie ostatnich poprawek i zadowolenie moich klientów.

Powyższa metoda jest cały czas w fazie rozwoju, jak na razie wszystko się sprawdza i uczestnicy są zadowoleni (ostatnia średnia ocena po szkoleniu była powyżej 4,7). Jeśli macie jakieś propozycje jak jeszcze mógłbym udoskonalić swoją pracę piszcie, będę wdzięczny za jakąkolwiek informację zwrotną!


3 Comments for this entry

  • Krystian

    Używam podobnych metod. Dodatkowo używam Evernote do zapisywania pomysłów, które wpadają mi do głowy w nieoczekiwanym momentach lub płyną z feedbacku, który dostaję face 2 face.
    Przegląd materiałów i slajdów robię po przynajmniej 24h, żeby nie przypominać sobie tego co chciałem napisać, ale naprawdę przeczytać te materiały 🙂
    Bardzo fajny pomysł z wykorzystaniem stand-upów.
    Każda grupa ma inne oczekiwania i dobrze jest też zebrać oczekiwania na początku szkolenia i pod koniec sprawdzić czy wszystko jest odhaczone (być może u Ciebie jest to część retrospekcji).
    Bardzo podoba mi się taki sposób podejścia do szkoleń i myślę, że Twoje szkolenia są wysokiej jakości.
    Wiele osób może dużo skorzystać z Twojego opisu i mogą skorzystać także ich klienci. 😉

  • Adam Hepner

    Bardzo mi przypadła do gustu Twoja metoda pracy, z całą pewnością poddam ją pod rozwagę, kiedy będę przygotowywał własne szkolenia. Mam natomiast pytanie z trochę innej beczki, w sumie zarówno do Ciebie, jak i do Krystiana: jakie macie podejście do propagacji waszych szkoleń? W jaki sposób do tego podchodzicie, gdzie umieszczacie informacje o nadchodzących szkoleniach?

  • Krsytian

    Własna strona. Goldenline.pl, forum SJSI, strony partnerów.

Skomentuj