Jak praktycznie wykorzystać wiedzę ze szkolenia - przeładowanie wiedzą

Problem – po szkoleniu nie robię niczego lepiej

Załóżmy, że byliście na naprawdę udanym szkoleniu czy konferencji. Widzieliście kilka nowych technik. Jesteście pewni, że to by się wam przydało w pracy – prowadzący robią to samo, co wy, tylko lepiej (zgodnie z waszymi kryteriami „lepiej”).

Najpewniej po tym szkoleniu wrócicie do pracy i nic się nie zmieni - niczego nie użyjecie ze szkolenia. Po próbach wykorzystania tych technik okaże się, że pracujecie wolniej i szybciej się męczycie. Wrócicie do starych nawyków.

Nie musi tak być. Pokażę wam, jak:

• Niekoniecznie szybko, ale skutecznie możecie budować nowe kompetencje.
• Uczyć się złożonych, skomplikowanych rzeczy (np. „programowanie od zera”).
• Innymi słowy – jak po szkoleniu być „lepszym” według waszych kryteriów „lepszości”.

Z czego wynika problem słabego przyswajania umiejętności ze szkolenia?

Możemy sprowadzić problem niewykorzystywania umiejętności ze szkoleń do czterech głównych komponentów: przeładowanie, brak ugruntowania, brak motywacji i brak powiązania z pracą.

• Przeładowanie - próbuję za dużo zrozumieć i opanować w krótkim czasie. 
• Brak ugruntowania – za szybko rezygnuję i nie osiągam poziomu skuteczności (a umiejętności nieużywane zanikają).
• Brak motywacji - po prostu mi się nie chce czegoś nauczyć; jestem zniechęcony lub coś nie jest ciekawe.
• Brak powiązania z pracą – nie będę robił w pracy rzeczy, które były na szkoleniu. Nie mam okazji ich przećwiczyć, więc wygasną.

W tym artykule skupiam się tylko na pierwszym obszarze (przeładowanie). Pozostałe obszary omówię później.

Co to jest przeładowanie?

Jednym zdaniem: wprowadzacie sporo nowych technik jednocześnie, męczycie się, nic wam nie wychodzi.

Przypomnijcie sobie naukę gotowania.

Gdy próbowaliście nauczyć się gotować, najpewniej zaczęliście od czterodaniowego posiłku, w którym podstawą były delikatne ciasto francuskie i ta dziwna ryba, która jest trująca jak nie jest przyrządzona dobrze (fugu), prawda?

Jasne, że nie. To by się skończyło w niefortunny sposób.

Gdy ja uczyłem się przyrządzać obiad, moja żona zaproponowała mi naukę łososia z patelni. Patelnia, łosoś, kilka ząbków czosnków i 20 minut pracy. Najtrudniejszą czynnością było obracanie łososia i upewnienie się, że: 

• nic się za mocno nie przypaliło
• łosoś nie jest nigdzie surowy

Nie jest to może szczyt mistrzostwa kuchni, ale i tak nie było to proste gdy jednocześnie pilnowałem ziemniaków. I dbałem o to, żeby wszystko było gotowe w tym samym czasie. I że jest odpowiednio przyprawione. 

Gdyby zaproponowała mi rozpoczęcie nauki od przygotowania pasztetu, strasznie bym się pogubił. Kilka różnych typów mięs, przyprawy, warzywa, odpowiednie proporcje, nie można skosztować czy jest dobrze, bo jest tam surowe jajko; do tego forma i piekarnik (który jest tajemniczą formą czarnej magii sam w sobie). 

Mnóstwo rzeczy do zapamiętania i każdy błędny krok może zniszczyć posiłek.

A ja na tym etapie nie potrafiłem jeszcze określić tak podstawowych rzeczy jak “kiedy cebula jest wystarczająco zeszklona”.

Żeby nie było - żadna z czynności potrzebnych do przygotowania pasztetu mnie nie przerastała w izolacji. Problem polegał na tym, że wszystkie trzeba było zastosować jednocześnie. 

Byłbym bardzo przeładowany - wszystko byłoby nowe i nie miałbym informacji zwrotnej czy robię dobrze.

Popatrzmy, co się dzieje, gdy programista Javy pracujący przy użyciu IntelliJ zaczyna wykorzystywać Visual Studio Code do pracy z Javascriptem:

• Nowe środowisko pracy (Visual Studio Code).
• Nowy język programowania z nową składnią (Javascript).
• Inny styl, paradygmat i sposób programowania (bardziej funkcyjny).
• Inne biblioteki i narzędzia, zupełnie inny sposób pisania testów…
• …

To nie jest jedna kompetencja: zamiast Javy mam Javascript. Tak naprawdę to pełen zestaw kompetencji. A każda z tych kompetencji składa się z kolejnych, mniejszych (ideę złożonych kompetencji opisywałem w artykule o Klątwie Wiedzy .

Jak sobie z tym radzimy? Jak z przykładem nauki gotowania - zaczynamy od najprostszych rzeczy, osiągamy małe sukcesy i krok po kroku dodajemy złożoność i trudność; opiszę to dokładniej przy artykule z Ugruntowania w tym cyklu.

Przeładowanie a szkolenia

Sytuacja jest dużo bardziej skomplikowana, gdy mówimy o szkoleniach w obszarze w których już mamy jakiś poziom kompetencji. Jako przykład, weźmy radzącego sobie dobrze programistę. Delikwent idzie na szkolenie ze wzorców projektowych, gdzie poznaje kilka nowych konceptów:

• Dlaczego kompozycja jest przydatniejsza niż dziedziczenie.
• Kilkanaście wzorców projektowych.
• Jak strukturyzować swój kod.

Delikwent wraca do swojego projektu i postanawia, że wykorzysta te techniki. Co się dzieje:

1. Nasz delikwent ma pewien poziom kompetencji – osiąga sukcesy starymi technikami. To jest status quo - 100% wydajności.
2. Gdy wprowadzamy nowe techniki, wpierw musimy świadomie kontrolować proces i zwalczać stare nawyki – robić inaczej niż robiliśmy to wcześniej:

Powyższy rysunek to jest krzywa Virginii Satir dotycząca reagowania na zmiany, tzw. „Satir Change Model”, później zaadaptowana przez Gerarda Weinberga do zarządzania projektami i wprowadzania zmian.

(Ważna rzecz - w powyższym wykresie jest wbudowane założenie, że nowy sposób jest faktycznie bardziej wydajny niż stary sposób. To nie zawsze jest prawda przy szkoleniach; jeśli nie jest, naturalnie wydajność nowego sposobu będzie poniżej wydajności starego sposobu.)

Tak czy inaczej, gdy na początku uczymy się używać nowych technik - nawet docelowo “lepszych” - nasza wydajność najpierw spada do momentu, aż zaczniemy integrować nowy sposób z pracą. 

Powiedzmy optymistycznie, że w okresie chaosu wydajność naszego programisty wynosi 70% wydajności starego sposobu.

I teraz – niech nasz programista spróbuje wprowadzić wszystkie pięć nowych technik jednocześnie. Co się dzieje? Ano, każda nowa technika ma 70% wydajności i to się na siebie nakłada.

Nasz programista widział, że „na szkoleniu działało”. Ale gdy sam próbował wprowadzić te pięć technik jednocześnie do swojego projektu, jego wydajność spadła ze 100% bazowej do nędznego 16.8% (70% do potęgi piątej).

Czyli programista pracuje pięć razy wolniej i ciężej by osiągnąć ten sam efekt. Niezbyt zachęcające.

Nic dziwnego, że zaraz nasz programista powie „a tam, u mnie nie działa, to na pewno kwestia tego, że nasz projekt jest inny” i zrezygnuje. Różnica pomiędzy oczekiwaniami a rzeczywistością była za duża – programista oczekiwał postępu a pojawiło się dramatyczne pogorszenie wydajności.

A gdzie naprawdę leżał problem? W próbie wprowadzania wszystkich zmian od razu – a nie stopniowo, jak w wypadku nauki jazdy samochodem, jazdy konnej czy gotowania.

Jak rozwiązać problem przeładowania?

Przede wszystkim – musicie zrozumieć, że to normalne. Najpierw będzie gorzej, potem będzie lepiej – macie swoje oczekiwania, ale umiejętności nie są jeszcze zintegrowane. Trzeba ten bolesny okres po prostu przetrwać (o tym więcej przy ugruntowaniu).

Po drugie, w ramach możliwości zmieńcie sposób wprowadzania nowych technik z równoległego (wszystko naraz) na szeregowy (wpierw jedną, potem drugą…):

Jako analogię ze świata rzeczywistego weźcie żonglera. Żongler wpierw bierze jedną piłeczkę, podrzuca, potem drugą, trzecią – i tak do krańca swoich umiejętności.

Zamiast walczyć z pięcioma kompetencjami na poziomie chaosu, wpierw zintegrujcie pierwszą (najbardziej przydatną). Gdy pierwsza zostanie zintegrowana, weźcie kolejną (następną najbardziej przydatną). I tak do momentu, aż przestaniecie widzieć wartość w dodawaniu nowych kompetencji.

Czyli jeżeli idziecie na szkolenie, wybierzcie jedną rzecz z tego szkolenia którą faktycznie chcecie i możecie użyć. Nieważne, ile fajnych czy przydatnych rzeczy tam było – wpierw opanujcie pierwszą, potem dopiero weźcie się za drugą**.**

Może wyglądać to na metodę wolniejszą, ale w praktyce jest szybsze, bardziej motywujące i skuteczniejsze.

Dobrze, ale po czym poznacie, że kompetencja została zintegrowana? To dobry moment, by przejść do drugiej części – ugruntowania.