Czego nie uczą w szkole: jak przygotowujemy inżynierów wsparcia technicznego

Oto obiecana „inna historia”.

Wyzwanie

Gdyby cztery lata temu zapytano mnie: „Jak można szkolić nowicjuszy w dziale IT/firmie?” — nie zastanawiając się, odpowiedziałbym: „Metodą „małpka widzi — małpka naśladuje”, czyli przywiąż nowicjusza do bardziej doświadczonego pracownika i niech obserwuje, jak wykonuje typowe zadania”. To podejście działało dla mnie wcześniej, działa i teraz, a przy jakimś czasie temu w Veeam, gdy drzewa były duże, logotypy zielone, a produkt mały, też można było szkolić — i rzeczywiście szkolono!

Z czasem produkt stawał się coraz większy i bardziej skomplikowany, a liczba nowych inżynierów rosła w zastraszającym tempie, i podejście w stylu RTFM (Read The Freaking Manual) działało coraz gorzej — rzecz w tym, że tak mogą uczyć się ci, którzy już są „w temacie”, rozumieją specyfikę pracy i potrzebują jedynie kilku, mniej istotnych szczegółów.

A co z tymi, którzy przybyli z pokrewnych dziedzin i chcą się rozwijać, ale nie wiedzą, od czego zacząć? Co z tymi, którzy znają rzadki język (na przykład rzadki dla przeciętnego informatyka włoski)? Jak wyszkolić według takiego schematu obiecującego absolwenta uczelni wyższej, który nie ma jeszcze dużego doświadczenia zawodowego?

Przerwijmy na chwilę naszą opowieść i wyobraźmy sobie: oto ty, lider zespołu wsparcia, sam w przeszłości dobry i odnoszący sukcesy inżynier z dużym doświadczeniem w administrowaniu systemami oraz w komunikacji z różnymi ludźmi. Twoim zadaniem jest przekazanie swojego doświadczenia nowemu (można nawet powiedzieć „zielonemu”) inżynierowi, absolwentowi uczelni wyższej, inteligentnemu i bystremu. Jest tylko jeden szczegół — to osoba bez doświadczenia w wsparciu i nawet w podstawowym helpdesku, a ponadto będzie pierwszym inżynierem mówiącym po turecku w twojej firmie.

Jak zamierzasz rozwiązać to zadanie?

A kiedy odpowiesz na to pytanie (a ty odpowiesz, wierzę w ciebie), to utrudnijmy zadanie — co jeśli takich inżynierów będzie dziesięciu? A jeśli dwudziestu? A jeśli to ciągły rozwój działu i w każdej chwili będzie nowicjusz, którego trzeba przeszkolić, pokazać minimalny standard jakości pracy (a ten standard jest wysoki) i zrobić tak, aby ta osoba nie zapragnęła uciec jak najszybciej?

(Proszę, zastanów się nad tym pytaniem, zanim przejdziesz dalej.)

Nasza historia

To właśnie z takim wyzwaniem się zmierzyliśmy.

Póki dział był w miarę mały, dobrze działał schemat „dać nowemu mentora, listę dokumentów i puścić do pracy — płyń lub ton”. To dobry, uniwersalny schemat, sprawdzony latami, a nawet wiekami ludzkiego doświadczenia — ale w pewnym momencie zrozumieliśmy, że zmęczyliśmy się powtarzaniem. Każdemu nowemu trzeba opowiedzieć pewne rzeczy — to samo, co może mu się przydać w pracy. W „tradycyjnym” schemacie zajmuje się tym mentor, ale co jeśli jakiś mentor ma podopiecznych, którzy przychodzą jeden po drugim? Powtarzanie tego samego szybko się nudzi, pojawia się wypalenie — a to już ryzyko.

I wtedy przypominamy sobie o innej, nie mniej tradycyjnej schemacie — zbieramy nowych w grupy i wygłaszamy wykłady — tak powstał nasz program szkoleniowy.

Czasami nasi inżynierowie biorą udział w konferencjach — zarówno wewnętrznych, jak i zewnętrznych, organizowanych przez innych jak i przez nas samych. To właśnie z jednego z naszych wydarzeń rozpoczęła się edukacja w wsparciu, tak jak wygląda teraz.

Jeden z naszych inżynierów wystąpił na VeeamOn w Las Vegas z doskonałą prezentacją na temat tego, z jakich elementów składa się Veeam Backup & Replication, a po drobnych poprawkach stała się wykładem „Komponenty”. W tym czasie mieliśmy już kilka wykładów na różne części funkcjonalności, ale to właśnie ten wykład „nadał ton” wszystkim, które były przed i po. To, jak ten wykład był zbudowany, jakie materiały były użyte i tak dalej, stało się dla nas standardem.

Zaczęliśmy dużo opowiadać o wirtualizacji, technologiach Microsoft, naszych własnych produktach, wprowadziliśmy podstawowe szkolenia dla naszych nowych pracowników bez doświadczenia w IT, na których omawiamy wszystko, co może być potrzebne inżynierowi wsparcia — zaczynając od „sprzętu” i zwiększając poziomy abstrakcji: Disk API, Systemy Operacyjne, Aplikacje, Sieci, Wirtualizacja.

Oczywiście rozumieliśmy i nadal rozumiemy, że z próbą objęcia szkoleniami całego spektrum technologii, które wykorzystujemy, będzie niemożliwe lub przynajmniej nierozsądne. Żeby nauczyć wszystkich funkcji jednego produktu, już teraz potrzeba kilku miesięcy, a produkt nie stoi w miejscu, cały czas pojawia się coś nowego. Ponadto tylko wykłady szkoleniowe, jakimi są obecnie, nie mogą dać wszystkiego, co potrzebne przyszłemu inżynierowi.

A co jeszcze oprócz tego?

Lubię mówić, że mamy zasady Pareto: na naszych szkoleniach dajemy około 20% tego, co jest potrzebne dla udanego inżyniera, a 80% pozostaje na jego sumieniu – czytanie instrukcji, praca w laboratorium, rozwiązywanie zgłoszeń testowych i produkcyjnych itp.

20% – szkolenia – to tak naprawdę prawie 100% podstaw teoretycznych, ale tylko teoria nie wystarczy – działa klasyczny schemat Wiedza-Umiejętności-Kwalifikacje. Możemy przekazać Wiedzę, ale rozwijanie Umiejętności i przekształcanie ich w Kwalifikacje to już zupełnie inne zadanie.

Z tego powodu nasze początkowe teoretyczne wykłady szybko wzbogacają się o inne elementy, a teraz ogólny schemat wygląda następująco:

• Wykłady/szkolenia;
• Praca samodzielna;
• Mentoring.

Pierwszy punkt jest jasny: bierzemy grupę nowicjuszy, czytamy im teorię i płynnie przechodzimy do drugiego punktu, dając na zakończenie wykładu „pracę domową” – jakąś praktyczną zadanie, które nowicjusz musi „odegrać” w laboratorium i przedstawić raport w jakiejś formie (zwykle forma swobodna, ale bywają wyjątki).

Zadania formułujemy celowo w dość ogólny sposób, unikając precyzyjnych instrukcji „idź tam, zrób to, zapisz, co widzisz”. Zamiast tego stawiamy tylko zadanie (na przykład: uruchom maszynę wirtualną z tym listą komponentów) i prosimy o przeprowadzenie jakiegoś „badania” na uzyskanym wyniku, nie wdając się w to, jak to zrobić, ani jak sprawdzić wynik. Chcemy w ten sposób nauczyć nowicjuszy (szczególnie tych, którzy są na początku swojej drogi w świecie IT i nie wiedzą, jak myśli inżynierska), samodzielnego myślenia, umiejętności czytania dokumentacji i analizy pojawiających się problemów, a co bardzo ważne, zrozumienia swoich ograniczeń.

Wszyscy wiemy, że czasami rozwiązanie zadania prowadzi do ściany, jakby z przodu wyrastała ściana, której w żaden sposób nie można przełamać. I zrozumienie, w jakich przypadkach warto dalej w nią uderzać, a kiedy warto znaleźć kogoś, kto może pomóc – to także bardzo ważna umiejętność dla inżyniera pracującego w zespole.

Jako taki „pomocnik” dla nowicjusza występuje mentor.

Niezwykle trudno jest przecenić mentora. Zastanówcie się sami, on jest pierwszym "punktem kontaktu" dla przydzielonego mu nowicjusza, tym, który może odpowiedzieć na większość pytań i pomóc w większości sytuacji — i poprawić te złe wzorce (w aspekcie technicznym, w etyce biznesowej, w kulturze firmy), które mogą przeoczyć nawet trener, a nawet lider zespołu.

I to wszystko o nim?

Wykłady-szkolenia, mentoring, samodzielna praca — oto trzy podstawowe cegiełki, które składają się na nasz program nauczania. Ale czy to wszystko, co można powiedzieć? Oczywiście, że nie!
Nawet mając niezłą strukturę, cztery pełne programy nauczania (piąty w drodze), nie zatrzymujemy się na zbieraniu naszych „plonów”. Nauczanie jest tak żywe, jak nasz produkt, dlatego wciąż pojawiają się zarówno nowe informacje, jak i nowe sposoby, aby je przekazać.

Na przykład, ważnym krokiem dla nas było zrozumienie, że w rzeczywistości powielamy szkolne/uniwersyteckie nauczanie w większym stopniu, niż czujemy, i nie zawsze to działa. Uczymy dorosłych ludzi, z doświadczeniem, z własnymi obawami i preferencjami. Taki "szkolny" system nieco ich przeraża (nazywajmy rzeczy po imieniu — w 95% przypadków wszelkie frustracje związane z modelem szkolnym wynikają z lęku): wszyscy jakoś przeszliśmy przez szkołę i uniwersytet, a najczęściej było to traumatyczne doświadczenie, dlatego nie chcemy go powtarzać.

Stąd zaczynamy (tak, dopiero zaczynamy, ale "podróż w tysiąc mil..." i tak dalej) przekształcać nasze podejścia. Przypomnieliśmy sobie/poznaliśmy andragogikę (nauczanie dorosłych — w przeciwieństwie do pedagogiki, która w zasadzie dotyczy nauczania dzieci) z jej orientacją na doświadczenie, zrozumienie celów, z niuansami dotyczącymi przyswajania informacji i komfortu uczniów, ważnością aspektu emocjonalnego (dla dzieci jest to nawet ważniejsze), potrzebą praktycznej części i tak dalej. Dowiedzieliśmy się o cyklu Kolba i teraz kręcimy nasze szkolenia, myśląc, jak nawet osobę zupełnie "nie w temacie" wprowadzić na szkolenie już z jakimś doświadczeniem, które pomożemy uaktualnić, uzupełnić, pogłębić i poprawić, a co ważne, dać nie tylko surową teorię, ale także praktyczną wiedzę, którą można przekształcić w umiejętności za pomocą mentora lub samodzielnie.

Zaprośmy trenerów biznesowych, którzy przeprowadzili z naszymi wykładowcami intensywne warsztaty dotyczące wystąpień publicznych, opowiadali o emocjach, ćwiczyli asertywność, dostarczyli narzędzia do zarządzania dynamiką grupy i, oczywiście, pomogli nam odpowiedzieć na pytania „czego chcemy od szkolenia?” oraz „jaki jest nasz ostateczny cel?”. Wyniki już są — niektóre szkolenia, które wcześniej zbierały najwięcej opinii w stylu „nudno i nic nie zrozumiałem”, teraz nazywane są niemal najbardziej interesującymi i angażującymi — a wykładowca pozostał ten sam!

A jeszcze niedawno dołączyła do nas para naprawdę fajnych i zmotywowanych osób, które opowiadały o Knowledge Centered Support i o tym, jak tworzyć kursy wideo — i z ich doświadczeń czerpniemy wiele dobrych pomysłów na przekształcenie ostatnich i odejście od stylu „nagranie webinaru” na rzecz pięknych i prostych kursów, które jasno i zrozumiale przedstawiają wszystko, co chcemy, i nie pozwalają utknąć w różnorodności metod przekazywania informacji.

Co więcej, teraz zajmujemy się nie tylko technicznymi aspektami szkolenia, czyli tzw. hard skills, ale także pracujemy z soft skills, nie tylko dla wykładowców czy menedżerów, ale też dla inżynierów. Robimy to po to, aby warunkowy Ignat, wchodząc do firmy, mógł ćwiczyć te umiejętności, które będą mu w 100% niezbędne w pracy, potrafił zarządzać swoimi emocjami i wiedział, że w każdej, nawet najbardziej skomplikowanej i beznadziejnej sytuacji, nie będzie sam: ponieważ wsparcie to ludzie, a „niczym swoich w trudnych chwilach nie zostawiamy”. Przed pierwszymi przychodzącymi telefonami zagramy z nowym pracownikiem w gry aktorskie, pomagając mu w zaangażowaniu się w proces i znalezieniu własnego stylu odpowiedzi, przed pierwszymi sprawami opowiemy, jak najlepiej z nimi pracować i na co zwracać uwagę, a w całym procesie będziemy towarzyszyć i pomagać.
Jesteśmy wsparciem. A kogo powinniśmy wspierać w pierwszej kolejności, jeśli nie swoich?

I na koniec kilka słów...

Zdaje sobie sprawę, że moja opowieść brzmi pochlebnie. I jednocześnie nie przechwalę się — to nasza historia, nasza teraźniejszość i tylko niewielka część planów na przyszłość.

Nasze szkolenie nie jest idealne. Mamy wiele niedociągnięć i popełniliśmy sporo błędów – mój Boże! Otrzymujemy wiele opinii, a najczęściej nie są one pochwalne. Piszą do nas o problemach, niedociągnięciach i oczekiwaniach na poprawki – a ponieważ szkolimy globalnie, pojawia się bardzo zróżnicowana liczba opinii, a jeśli uwzględnimy także różnice kulturowe…

Mamy wiele możliwości rozwoju, a dzięki Bogu mamy też tych, którzy są gotowi pracować, krytykować, dyskutować i proponować nowości. To ogromny zasób i wielka pomoc.

Wsparcie to rzecz o ludziach – to właśnie ludzie sprawiają, że szkolenie ma sens. Szkolenie pomaga nowym pracownikom szybciej zacząć przynosić korzyści i szybciej rozwijać się w dobrych inżynierów, a dobrzy inżynierowie czynią świat lepszym.

… i na tym pozwólcie mi zakończyć zezwolone przemówienie.

Źródło: habr.com