Vad de inte lär ut i skolan: hur vi utbildar supportingenjörer

Här är den utlovade "andra berättelsen".

Utmaning

Om man för fyra år sedan hade frågat mig: "Hur kan man utbilda nykomlingar i en IT-avdelning / företag?" — skulle jag, utan att tveka, ha sagt: "Genom metoden 'apa ser — apa gör', dvs. koppla nykomlingen till en mer erfaren medarbetare och låt dem se hur typiska uppgifter utförs." Denna metod fungerade för mig tidigare, den fungerar fortfarande nu, och för en tid sedan på Veeam, när träden var stora, logotyperna gröna och produkten liten, så kunde man också utbilda — och det gjordes!

Produkten blev gradvis större och mer komplex, och antalet nya ingenjörer ökade hela tiden, och metoden RTFM (Read The Freaking Manual) fungerade allt sämre — saken är den att sådana kan lära sig de som redan "är insatta", de som förstår arbetsmetoderna och behöver vissa, mindre kritiska detaljer.

Men hur ska man göra med dem som kommer från besläktade områden och vill växa och utvecklas, men inte vet hur man ska närma sig det? Hur ska man göra med någon som har en relativt sällsynt språkbehärskning (t.ex. ett sällsynt språk för en genomsnittlig IT-person, som italienska)? Eller hur ska man utbilda en lovande nyutexaminerad student, som inte har stor arbetslivserfarenhet?

Låt oss pausa berättelsen ett ögonblick och föreställa oss: ni, teamledare i supportteamet, själva en gång en duktig och framgångsrik ingenjör med stor erfarenhet av systemadministration och kommunikation med olika människor. Er uppgift är att överföra er erfarenhet till en ny (kanske till och med "grön") ingenjör, en nyutexaminerad från universitetet, smart och klipsk. Det finns bara en twist — det är en person utan erfarenhet av support och till och med grundläggande helpdesk, och han kommer att vara den första turkisktalande ingenjören i ert företag.

Hur kommer ni att lösa denna uppgift?

Och när ni har svarat på den frågan (och ni kommer att svara, jag tror på er), låt oss komplicera uppgiften — vad händer om det finns tio sådana ingenjörer? Vad om det är tjugo? Och om det är en ständig utveckling av avdelningen och det kommer att finnas en nykomling att utbilda, att visa den minimi standard för arbetets kvalitet (och den standarden är hög) och se till att personen inte vill fly så fort som möjligt?

(Vänligen tänk på denna fråga innan du läser vidare.)

Vår Historia

Det var just en sådan utmaning som vi ställdes inför.

När avdelningen fortfarande var ganska liten fungerade schemat "ge en nyanställd en mentor, en lista med dokument och låt dem börja arbeta - simma eller sjunka" bra. Det är ett bra, universellt schema, prövat genom århundraden av mänsklig erfarenhet — men vi insåg snart att vi var trötta på upprepningar. Varje nyanställd behöver få veta vissa saker — samma sak som kan vara användbart i arbetet. I det "traditionella" schemat ansvarar mentorn för detta, men vad händer om en mentor har flera mösslingar som kommer en efter en? Att upprepa samma sak blir snabbt tråkigt, vilket leder till utbrändhet — och det är redan en risk.

Och här kommer vi att tänka på ett annat, inte mindre traditionellt schema — att samla nyanställda i grupper och ge dem föreläsningar — så föddes vårt utbildningsprogram.

… Ibland deltar våra ingenjörer i konferenser — både interna och externa, arrangerade av andra och av oss själva. Det var just vid ett sådant evenemang som utbildningen i support började, som den ser ut idag.

En av våra ingenjörer talade på VeeamOn i Las Vegas med en lysande presentation om de olika delarna av Veeam Backup & Replication, och med några mindre justeringar blev den en föreläsning om "Komponenter". Vid den tidpunkten hade vi redan haft flera föreläsningar om olika funktionaliteter, men just den föreläsningen satte tonen för alla de som kom före och efter. Det var sättet som den föreläsningen var strukturerad på, vilka material som användes och så vidare, som blev vår standard.

Vi började berätta mycket om virtualisering, Microsoft-teknologier, våra egna produkter, och införde grundutbildningar för våra nyanställda utan IT-erfarenhet, där vi går igenom allt som kan behövas av en supportingenjör — vi började med "hårdvara" och ökade nivåerna av abstraktion: Disk-API, Operativsystem, Applikationer, Nätverk, Virtualisering.

Självklart förstod och förstår vi att det är omöjligt, eller åtminstone oklokt, att försöka täcka hela spektrumet av teknologier vi använder genom utbildningar. Att lära sig alla funktioner hos en produkt kräver redan flera månader, och produkten står inte stilla, nya saker dyker ständigt upp. Dessutom kan endast föreläsningar och utbildningar, som de är, inte ge allt som en framtida ingenjör behöver.

Vad mer?

Jag gillar att säga att vi följer Paretoprincipen: genom våra utbildningar ger vi ungefär 20% av det som en framgångsrik ingenjör behöver, och 80% ansvarar de själva för - genom att läsa manualer, arbeta i laboratoriet, lösa test- och verkliga ärenden etc.

20% - utbildningar - utgör egentligen nästan 100% av den teoretiska grunden, men med enbart teori når man inte allt - den klassiska modellen Kunskap-Färdigheter-Kompetens fungerar. Vi kan ge Kunskap, men att utveckla Färdigheter och förvandla dem till Kompetens är en helt annan uppgift.

Just därför har våra initiala teoretiska föreläsningar snabbt kompletterats med andra inslag, och nu ser den övergripande modellen ut så här:

• Föreläsningar/utbildningar;
• Självständigt arbete;
• Mentorskap.

För den första punkten är det klart: vi tar en grupp nykomlingar, föreläser teori för dem och går smidigt vidare till den andra punkten, där vi ger dem “hemuppgift” - en praktisk uppgift som den nya personen ska “öva” på i laboratoriet och lämna en rapport i någon form (vanligtvis i fri form, men det finns undantag).

Vi formulerar uppgifterna ganska allmänt avsiktligt, och undviker exakta instruktioner som “gå dit, gör det, skriv ner vad du ser”. Istället ställer vi bara uppgiften (till exempel: konfigurera en virtuell maskin med den här listan av komponenter) och ber dem göra en slags “undersökning” av det erhållna resultatet, utan att gå in på hur man gör det eller hur man kontrollerar resultatet. Detta syftar till att lära nykomlingarna (särskilt de som är långt borta i början av sin väg från IT-världen och hur ingenjörsgemenskapen tänker) att tänka självständigt, utveckla färdigheten att läsa dokumentation och analysera uppkomna problem, och, vilket är mycket viktigt, att förstå sina begränsningar.

Vi vet alla att ibland kan lösningen på ett problem kännas omöjlig, som om en vägg reser sig framför en som man inte kan ta sig igenom. Att förstå när man bör fortsätta slå huvudet mot väggen och när det är dags att hitta någon som kan hjälpa är också en mycket viktig färdighet för en ingenjör som arbetar i team.

Vår "hjälpare" för nybörjaren är en mentor.

Det går helt enkelt inte att överskatta en mentors betydelse. Tänk själv, han är den första "kontaktpunkten" för den nybörjare som knutits till honom, den som kan svara på de flesta frågor och hjälpa i de flesta situationer - och rätta till de dåliga mönster (i den tekniska delen, i affärsetik, i företagskulturen) som en tränare, och till och med en teamledare, kan missa.

Är det allt om honom?

Föreläsningar, mentorskap, självständigt arbete - det är de tre grundläggande byggstenarna i vårt utbildningsprogram. Men är det verkligen allt vi kan berätta? Självklart inte!
Även med en bra struktur och fyra fullständiga utbildningsprogram (det femte är på väg) slutar vi aldrig att samla våra "pluddersäkringar". Utbildning är lika levande som vår produkt, och därför dyker både ny information och nya sätt att förmedla den ständigt upp.

Till exempel blev en viktig insikt för oss att vi faktiskt upprepar skol- och universitetsutbildning mer eller mindre helt, och det fungerar inte alltid. Vi undervisar vuxna människor, med erfarenhet, med sina rädslor och preferenser. Och ett sådant "skolsystem" skrämmer människor lite (låt oss kalla saker vid deras rätta namn - i 95% av fallen kommer all frustration från den skolmodellen från rädsla): vi har alla på något sätt gått igenom skolan och universitetet, och oftast var det trots allt en traumatisk upplevelse, så att uppleva det igen känns verkligen inte lockande.

Här börjar vi (ja, vi börjar bara, men "vägen till tusen mil..." osv.) att omarbeta våra tillvägagångssätt. Vi kom ihåg/lärde oss om andragogik (utbildning av vuxna — i motsats till pedagogik, som i grunden handlar om att utbilda barn) med dess fokus på erfarenhet, förståelse av mål, nuanser kring informationsupptagande och lärandets komfort, emotionella aspekters betydelse (vilket är ännu viktigare för barn), behovet av praktiska inslag osv. Vi lärde oss om Kolbs cykel och nu vrider vi våra träningar, tänker på hur vi kan få en person som helt "inte är i ämnet" att delta i träningen med någon form av erfarenhet, som vi kan hjälpa till att aktualisera och komplettera, fördjupa och finslipa, och, viktigt nog, ge inte bara ren teori utan också praktiska kunskaper som kan omvandlas till färdigheter med hjälp av en mentor eller på egen hand.

Vi har bjudit in affärstränare som har arbetat intensivt med våra föreläsare kring offentliga tal, pratat om känslor, tränat assertivitet, gett verktyg för att hantera gruppdynamik och, självklart, hjälpt oss att svara på frågorna "vad vill vi uppnå med utbildningen?" och "vad är vårt slutmål?". Resultaten är redan synliga — vissa träningar som tidigare fått mest feedback i stil med "tråkigt och inget är klart" kallas nu knappt de mest intressanta och inspirerande — och föreläsaren har förblivit densamma!

Och nyligen kom ett par riktigt coola och motiverade personer till oss, som berättar om Knowledge Centered Support och hur man bygger videokurser — och vi har samlat mycket bra idéer från dem om hur vi kan omarbeta dem och lämna "webinarieinspelning-stil" till vackra och enkla kurser som tydligt och klart förklarar allt vi vill, och förhindrar oss från att sjunka ner i en överflöd av metoder för informationspresentation.

Dessutom fokuserar vi nu inte bara på de tekniska aspekterna av utbildningen, det vill säga de så kallade hårda färdigheterna, utan arbetar även med mjuka färdigheter, inte bara för föreläsare eller ledning, utan även för ingenjörer. Vi gör detta för att en viss Ignat, när han kommer till företaget, ska kunna öva på de färdigheter som han kommer att behöva i sitt arbete, kunna hantera sina känslor, och veta att han i vilken, även den svåraste och mest hopplösa situation, inte kommer att vara ensam: för Support handlar om människor, och "vi överger inte våra i nöd". Inför de första inkommande telefonsamtalen kommer vi att spela rollspel med nykomlingen för att hjälpa honom att komma in i processen och hitta sin stil i svar, innan de första fallen kommer vi att berätta hur man bäst arbetar med dem och vad man ska titta på, och under hela processen kommer vi att följa upp och hjälpa.
Vi är support. Och vem ska vi först och främst stödja om inte våra egna?

Och avslutningsvis några ord…

Jag är medveten om att min berättelse låter lovordande. Och samtidigt skryter jag inte — detta är vår historia, vårt nu och bara en liten del av planerna för framtiden.

Vår utbildning är inte perfekt. Vi har många brister och vi har gjort misstag — herregud! Vi får mycket feedback, och oftast är den inte lovordande, folk skriver till oss om problem, brister, önskade förbättringar — och eftersom vi utbildar globalt får vi väldigt mycket varierande feedback, särskilt om vi tar hänsyn till kulturella skillnader…

Vi har utrymme för tillväxt, och tack och lov har vi dem som är villiga att arbeta, kritisera, diskutera och föreslå nytt. Detta är en stor resurs och ett stort stöd.

Och Support handlar om människor — det är just människor som gör utbildningen, utbildningen hjälper nya anställda att snabbt börja bidra och växa till bra ingenjörer snabbare, och bra ingenjörer gör världen bättre.

… och med det låt mig avsluta mina tillåtna tal.

Källa: habr.com