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

Oto obiecana „inna historia”.

Opis projektu

Gdybyś cztery lata temu zapytał mnie: „Jak szkolić nowicjuszy w dziale/firmie IT?” - Ja bez wahania powiedziałbym: „Stosując metodę „małpa widzi, małpa naśladuje”, czyli przydziel nowicjusza do bardziej doświadczonego pracownika i pozwól mu obserwować, jak wykonywane są typowe zadania”. To podejście sprawdziło się w moim przypadku wcześniej, sprawdza się nadal, a jakiś czas temu w firmie Veeam, kiedy drzewa były duże, logo zielone, a produkt mały, w ten sposób można było trenować – i to trenować!

Stopniowo produkt stawał się duży i skomplikowany, pojawiało się coraz więcej nowych inżynierów, a podejście w stylu RTFM (Read The Freaking Manual) sprawdzało się coraz gorzej - faktem jest, że ci, którzy już „wtajemniczeni” mogą się w ten sposób uczyć , który rozumie specyfikę pracy i potrzebuje kilku, mniej krytycznych szczegółów.

Ale co z tymi, którzy pochodzą z pokrewnych dziedzin i chcą się rozwijać, ale nie wiedzą, jak do tego podejść? Co zrobić np. z tymi, którzy mówią stosunkowo rzadkim językiem (np. włoskim, co dla przeciętnego informatyka jest rzadkością)? Albo jak w ramach takiego programu wyszkolić obiecującego absolwenta uczelni, który nie ma dużego doświadczenia zawodowego?

Zatrzymajmy się na chwilę na naszej historii i wyobraźmy sobie: oto jesteś liderem zespołu w zespole wsparcia, który był wcześniej dobrym i odnoszącym sukcesy inżynierem, z dużym doświadczeniem w administrowaniu systemami i komunikowaniu się z różnymi ludźmi. Twoim zadaniem jest przekazanie swojego doświadczenia nowemu (można nawet powiedzieć „zielonemu”) inżynierowi myśliwskiemu, absolwentowi uniwersytetu, inteligentnemu i bystremu. Jest tylko niuans - jest to osoba bez doświadczenia w zakresie wsparcia lub nawet banalnego działu pomocy technicznej, a także będzie pierwszym tureckojęzycznym inżynierem w Twojej firmie.

Jak rozwiążesz ten problem?

A kiedy już odpowiesz na to pytanie (a odpowiesz, wierzę w Ciebie), skomplikujmy zadanie – a co jeśli takich inżynierów będzie dziesięciu? A co jeśli dwadzieścia? A co jeśli jest to ciągły rozwój działu i w każdej chwili pojawi się nowicjusz, którego trzeba przeszkolić, wykazać się minimalnym standardem jakości pracy (a ten standard jest wysoki) i upewnić się, że dana osoba nie chce uciekać tak szybko, jak to możliwe?

(Przemyśl to pytanie, zanim zaczniesz czytać dalej.)

Nasza Historia

To jest dokładnie wyzwanie/zadanie, przed którym stanęliśmy.

Choć wydział był stosunkowo niewielki, schemat „daj nowicjuszowi mentora, listę dokumentów i rzuć pracę – pływaj lub toń” sprawdził się dobrze. Schemat jest dobry, uniwersalny, sprawdzony przez lata, a nawet stulecia powszechnego ludzkiego doświadczenia – jednak w pewnym momencie zdaliśmy sobie sprawę, że znudziło nam się powtarzanie. Każdemu nowicjuszowi trzeba powiedzieć pewne rzeczy - te same, które mogą mu się przydać w jego pracy. W „tradycyjnym” schemacie robi to mentor, a co jeśli jakiś mentor ma podopiecznych jeden po drugim? Powtarzanie tego samego szybko staje się nudne, pojawia się wypalenie zawodowe – a to już jest ryzyko.

I tutaj pamiętamy inny, nie mniej tradycyjny schemat - łączenie nowicjuszy w grupy i wygłaszanie dla nich wykładów - tak narodził się nasz program szkoleniowy.

...Czasami nasi inżynierowie biorą udział w konferencjach - zarówno wewnętrznych, jak i zewnętrznych, zewnętrznych i organizowanych przez nas. Od tego wydarzenia rozpoczęło się szkolenie wsparcia, tak jak to ma miejsce obecnie.

Jeden z naszych inżynierów wygłosił błyskotliwą prezentację na konferencji VeeamOn w Las Vegas na temat elementów, z których składa się rozwiązanie Veeam Backup & Replication, i po kilku poprawkach stał się on wykładem „Komponenty”. Do tego czasu odbyliśmy już kilka wykładów na temat różnych części funkcjonalności, ale to właśnie ten wykład „nadał ton” wszystkiemu, co nastąpiło wcześniej i później. To właśnie sposób skonstruowania wykładu, użyte materiały itp. stał się dla nas standardem.

Zaczęliśmy dużo rozmawiać o wirtualizacji, technologiach Microsoft, własnych produktach, wprowadziliśmy podstawowe szkolenia dla naszych początkujących bez doświadczenia IT, na których opowiadamy wszystko, czego może potrzebować inżynier wsparcia - zaczynając od sprzętu i rosnących poziomów abstrakcji: Disk API, Operation Systemy, aplikacje, sieci, wirtualizacja.

Oczywiście rozumieliśmy i rozumiemy, że próba objęcia szkoleniami całego zakresu technologii, z których korzystamy, byłaby niemożliwa, a co najmniej nieuzasadniona. Nauczenie wszystkich funkcji jednego produktu zajmuje już kilka miesięcy, jednak produkt nie stoi w miejscu i cały czas pojawia się coś nowego. Poza tym same wykłady szkoleniowe, jakie są, nie są w stanie zapewnić wszystkiego, czego potrzebuje przyszły inżynier.

Co jeszcze?

Lubię powtarzać, że u nas sprawdza się zasada Pareto: dzięki naszym szkoleniom zapewniamy około 20% tego, czego potrzebuje odnoszący sukcesy inżynier, a 80% pozostaje na jego sumieniu – czytanie instrukcji, praca w laboratorium, rozwiązywanie zadań testowych i bojowych itp. .

20% - szkolenia - tak naprawdę to prawie 100% podstawy teoretycznej, ale samą teorią nie da się wszystkiego osiągnąć - sprawdza się klasyczny schemat Wiedza-Umiejętności-Umiejętności. Możemy dawać Wiedzę, ale rozwijanie Umiejętności i przekształcanie ich w Umiejętności to zupełnie inne zadanie.

Dlatego nasze początkowe wykłady teoretyczne można było bardzo szybko uzupełnić o inne rzeczy i obecnie ogólny schemat wygląda tak:

• Wykłady/szkolenia;
• Niezależna praca;
• Mentoring.

Wszystko jest jasne w pierwszym punkcie: bierzemy grupę początkujących, czytamy im teorię i płynnie przechodzimy do drugiego punktu, zadając „pracę domową” na koniec wykładu - jakieś praktyczne zadanie, które początkujący musi „rozgryźć” out” w laboratorium i dostarczyć raport w jakiejś formie (zwykle formularz jest dowolny, ale są wyjątki).

Celowo formułujemy zadania w dość ogólnej formie, unikając precyzyjnych instrukcji „idź tam, zrób to, zapisz, co widzisz”. Zamiast tego stawiamy po prostu zadanie (na przykład: wdrożenie maszyny wirtualnej z tą listą komponentów) i prosimy nas o wykonanie „badań” na temat uzyskanego wyniku, bez wchodzenia w to, jak to zrobić i jak sprawdzić wynik. Chcemy w ten sposób nauczyć początkujących (szczególnie tych, którzy są na początku swojej podróży ze świata IT i sposobu myślenia wspólnoty inżynierskiej) samodzielnego myślenia, umiejętności czytania dokumentacji i analizowania pojawiających się problemów oraz, co bardzo ważne, zrozumienia swoich problemów limity.

Wszyscy wiemy, że czasami rozwiązanie problemu prowadzi do ślepego zaułka, jak gdyby przed nami stał mur, którego nie da się przebić. A zrozumienie, kiedy warto dalej się głowić, a kiedy znaleźć kogoś, kto może pomóc, to także bardzo ważna umiejętność dla inżyniera pracującego w zespole.

W naszym przypadku tym „pomocnikiem” nowicjusza jest mentor.

Mentora po prostu nie da się przecenić. Sami oceńcie, jest on pierwszym „punktem kontaktowym” dla przypisanego mu nowicjusza, tym, który potrafi odpowiedzieć na większość pytań i pomóc w większości sytuacji – i skorygować złe wzorce (w części technicznej, w etyce biznesu, w Kultura firmy), której może zabraknąć zarówno trenerowi, jak i nawet liderowi zespołu.

I to wszystko o nim?

Wykłady-szkolenia, mentoring, samodzielna praca - to trzy główne elementy, z których składa się nasz program szkoleniowy. Ale czy to wszystko, co można powiedzieć? Oczywiście nie!
Nawet mając dobry plan, cztery kompletne programy szkoleniowe (piąty jest w drodze), nie przestajemy zbierać naszych „lęgów grabieży”. Edukacja jest tak żywa jak nasz produkt, dlatego stale pojawiają się nowe informacje i nowe sposoby jej przekazywania.

Na przykład ważnym kamieniem milowym dla nas było zrozumienie, że tak naprawdę powtarzamy szkolenie szkolne/uniwersyteckie nieco więcej niż w całości i nie zawsze to działa. Uczymy dorosłych z doświadczeniem, z własnymi obawami i upodobaniami. I ten system „szkolny” trochę ludzi przeraża (nazwijmy rzeczy po imieniu – w 95% przypadków wszelka frustracja związana z modelem szkoły wynika ze strachu): wszyscy w ten czy inny sposób przeszliśmy przez szkołę i uniwersytet, i najczęściej to było wszystko. To było wciąż traumatyczne przeżycie, więc nie chcę tego w ogóle powtarzać.

Od tego momentu zaczynamy (tak, dopiero zaczynamy, ale „podróż liczy tysiąc mil…” itd.), aby przerobić nasze podejście. Przypomnieliśmy/uczyliśmy się o andragogice (nauczaniu dorosłych – w przeciwieństwie do pedagogiki, która w istocie polega na nauczaniu dzieci) z jej naciskiem na doświadczenie, zrozumienie celów, z niuansami dotyczącymi przyswajania informacji i komfortu uczniów, znaczeniem składnika emocjonalnego (w przypadku dzieci jest to jeszcze ważniejsze), potrzeby elementu praktycznego i tak dalej. Dowiedzieliśmy się o cykl kolbowy i teraz rotujemy nasze szkolenia, zastanawiając się, jak w ogóle wprowadzić na szkolenie osobę zupełnie „z tematu” z pewnym doświadczeniem, które pomożemy zaktualizować i uzupełnić, pogłębić i przeczesać, a co ważne , przekazują nie tylko suchą teorię, ale także wiedzę praktyczną, którą można przełożyć na umiejętności przy pomocy mentora lub samodzielnie.

Zaprosiliśmy trenerów biznesu, którzy pracowali z naszymi wykładowcami nad wystąpieniami publicznymi, rozmawiali o emocjach, trenowali asertywność, dali nam narzędzia do zarządzania dynamiką grupy i oczywiście pomogli nam odpowiedzieć na pytania „czego chcemy od szkoleń?” i „jaki jest nasz cel końcowy?” Efekty już są – niektóre szkolenia, które zebrały najwięcej opinii w stylu „nudne i nic nie jest jasne”, teraz nazywane są bodaj najciekawszymi i szczerymi – ale prowadzący pozostaje ten sam!

Niedawno przyszło do nas kilku bardzo fajnych i zmotywowanych facetów, aby porozmawiać o wsparciu skoncentrowanym na wiedzy i o tym, jak tworzyć kursy wideo - i nauczyliśmy się od nich wielu dobrych pomysłów, jak przerobić to drugie i odejść od „nagrywania w stylu webinaru” na piękne i proste kursy, które w prosty i jasny sposób powiedzą nam wszystko, czego chcemy, a nie pozwolą nam utonąć w różnorodności sposobów przekazywania informacji.

Co więcej, teraz zajęliśmy się nie tylko techniczną częścią szkoleń, czyli tzw. umiejętnościami twardymi, ale pracujemy także z umiejętnościami miękkimi, nie tylko dla wykładowców czy kadry zarządzającej, ale także dla inżynierów. Robimy to tak, aby warunkowy Ignat przychodząc do firmy mógł wyćwiczyć umiejętności, które będą mu w 100% potrzebne w swojej pracy, potrafił panować nad swoimi emocjami i wiedział, że w każdej, nawet najtrudniejszej i beznadziejnej sytuacji , nie zrobi tego: w końcu Support to ludzie i „nie zostawiamy swoich w tarapatach”. Przed pierwszymi przychodzącymi telefonami przeprowadzimy z nowicjuszem zabawę polegającą na odgrywaniu ról, pomagając mu zaangażować się w proces i odnaleźć własny styl odpowiadania, a przed pierwszymi przypadkami podpowiemy, jak najlepiej z nim pracować i na co zwrócić uwagę szukaj, a my będziemy monitorować i pomagać przez cały proces.
Jesteśmy wsparciem. A kogo powinniśmy wspierać w pierwszej kolejności, jeśli nie swoich?

I na zakończenie kilka słów...

Mam świadomość, że moja historia brzmi pochwalnie. A jednocześnie nie przechwalam się – to nasza historia, nasza teraźniejszość i tylko niewielka część naszych planów na przyszłość.

Nasze treningi nigdy nie są idealne. Mamy wiele braków i popełniliśmy wiele błędów – droga mamo! Otrzymujemy wiele informacji zwrotnych i najczęściej nie są one pochwalne, piszą do nas o problemach, niedociągnięciach, pożądanych ulepszeniach – a ponieważ uczymy na całym świecie, otrzymujemy wiele różnorodnych informacji zwrotnych, a jeśli uwzględnimy także cechy kulturowe ...

Mamy przestrzeń do rozwoju i dzięki Bogu mamy takich, którzy są gotowi pracować, krytykować, dyskutować i oferować nowe rzeczy. To świetne źródło informacji i świetne wsparcie.

A wsparcie to ludzie - to ludzie przeprowadzają szkolenia, szkolenia pomagają nowym pracownikom wcześniej zacząć być przydatnymi i szybciej stać się dobrymi inżynierami, a dobrzy inżynierowie czynią świat lepszym miejscem.

...i na tym pozwólcie mi zakończyć dozwolone przemówienia.

Źródło: www.habr.com