Mida koolis ei õpetata: kuidas koolitame tugitehnikat

Siin on lubatud "teine lugu".

Väljakutse

Kui keegi oleks neli aastat tagasi küsinud minult: "Kuidas saaks algajaid IT-osakonnas/ettevõttes koolitada?" — oleksin ma kohe vastanud: "Meetodi järgi 'ahv näeb — ahv järgib', seega kinnitage algaja kogenud töötajale ning laske tal jälgida, kuidas tüüpilisi ülesandeid täidetakse." See lähenemine töötas varem minu jaoks, see töötab ka praegu, ja mõnda aega tagasi Veeamis, kui puud olid suured, logod rohelised ja toode väike, sai ka nii koolitada — ja koolitati!

Aja jooksul hakkas toode muutuma suureks ja keerukaks, uusi insenere tuli järjest rohkem, ning RTFM (Read The Freaking Manual) lähenemine töötas üha halvemini — asi on selles, et selliselt saavad õppida need, kes juba 'teavad asjast', kes mõistavad töö eripära ja vajavad vaid mõned, mitte nii kriitilised detailid.

Aga kuidas on nende inimestega, kes on tulnud samalaadsetelt aladelt ja soovivad kasvada ja areneda, kuid ei tea, kuidas sellega alustada? Kuidas olla näiteks nende suhtes, kes valdavad tinglikult haruldast keelt (näiteks haruldast keskmise IT spetsialisti jaoks itaalia keelt)? Või kuidas koolitada sellisel viisil perspektiivikat ülikooli lõpetajat, kellel pole piisavalt töökogemust?

Laske meil korraks meie jutustust katkestada ja kujutlege: teie, meeskonna juht tugiteenuses, kes oli kunagi hea ja eduka inseneri, kellel on suur süsteemiadministreerimise ja erinevate inimestega suhtlemise kogemus. Teie ülesanne on edastada oma teadmised uuele (isegi võiks öelda 'rohelisele') inseneri, ülikooli lõpetajale, kes on intelligentne ja arusaav. On ainult üks nüanss — see inimene on ilma toe ja isegi tavalise abiteenuse kogemuseta, ja ta on veel teie ettevõtte esimene türgi keelt kõnelev insener.

Kuidas te selle ülesande lahendate?

Ja kui olete sellele küsimusele vastanud (ja te vastate, ma usun teisse), laske meil ülesannet keeruliseks teha — mis siis, kui selliseid insenere on kümme? Ent kui kakskümmend? Aga kui see on osakonna pidev areng ja igal ajahetkel on uus inimene, keda tuleb koolitada, näidata minimaalset töö kvaliteedi standardit (ja see standard on kõrge) ja teha nii, et inimene ei tahaks võimalikult kiiresti põgeneda?

(Palun mõelge sellele küsimusele, enne kui loete edasi.)

Meie Lugu

Just with such a challenge, we found ourselves.

While the department was conditionally small, the scheme of 'giving a newcomer a mentor, a list of documents, and letting them work - swim or sink' worked well. This scheme is good, universal, and validated by years and even centuries of human experience - but at one point we realized we were tired of repetition. Each newcomer needs to be told certain things - the same things that might be useful in their work. In the 'traditional' scheme, this is handled by the mentor, but what if one mentor has their mentees lined up one after another? Quickly repeating the same things becomes boring, leading to burnout - and that's already a risk.

And here we remember another, no less traditional scheme - gathering newcomers into groups and giving them lectures - thus our training program was born.

… Sometimes our engineers participate in conferences - both internal and external, both third-party and those organized by us. It was at such an event that training in support as we know it now began.

One of our engineers presented at VeeamOn in Las Vegas with an outstanding presentation on what components make up Veeam Backup & Replication, and with a few modifications, it became the lecture 'Components'. By that time, we already had several lectures on different parts of the functionality, but that particular lecture 'set the tone' for all the ones that followed. It was how that lecture was structured, what materials were used, and so on, that became the standard for us.

We began to extensively discuss virtualization, Microsoft technologies, our own products, and introduced basic training for our newcomers with no IT experience, where we cover everything that a support engineer might need - starting with 'hardware' and building levels of abstraction: Disk API, Operating Systems, Applications, Networking, Virtualization.

Of course, we understood and understand that trying to cover the entire range of technologies we use in training would be impossible or, at least, unreasonable. To train on all the features of one product already takes several months, and the product doesn't stand still, with new things constantly appearing. Moreover, just lectures, as they are, cannot provide everything needed for a future engineer.

So what else is there?

Mulle meeldib öelda, et meil kehtib Pareto printsiip: oma koolitustega anname ligikaudu 20% sellest, mis on eduka inseneri jaoks vajalik, ja 80% jääb tema enda vastutusele — manuaalide lugemine, laboratoorses töös osalemine, testülesannete ja reaalse tööde lahendamine jne.

20% — koolitused — on tegelikult peaaegu 100% teoreetilisest baasis, kuid ainult teooriast ei piisa — kehtib klassikaline skeem Teadmised-Oskused-Osavused. Me saame anda Teadmis, kuid Osavuste omandamine ja nende muutmine Oskusteks — see on juba täiesti erinev ülesanne.

Just seetõttu on meie algsed teoreetilised loengud kiiresti täienenud teiste aspektidega, ja nüüd näeb üldine skeem välja selline:

• Loengud/koolitused;
• Iseseisev töö;
• Mentorlus.

Esimese punktiga on kõik selge: võtame uue gruppi, räägime neile teooriat ja liigume sujuvalt teise punkti juurde, andes loengu lõpus "koduülesande" — mingi praktilise ülesande, mille uus tulija peab "praktiseerima" laboris ja esitama aruande mingis vormis (tavaliselt on vorm vabalt valitud, kuid erandeid esineb).

Me formuleerime ülesandeid teadlikult üsna üldiselt, vältides täpset juhendamist “mine sinna, tee seda, kirjuta, mida nägid”. Selle asemel seame lihtsalt ülesande (näiteks: käivita virtuaalne masin selle komponentide nimekirjaga) ja palume teha saadud tulemuse osas mingi "uurimustöö", süvenemata ei sellesse, kuidas seda teha, ega ka sellesse, kuidas tulemust kontrollida. Sellega tahame õpetada uusi tulijaid (eriti neid, kes on alguses IT maailmast kaugel ja ei mõista, kuidas inseneride mõtlemine käib) iseseisva mõtlemise oskust, dokumentatsiooni lugemise oskust ja probleemide analüüsimise oskust, ja mis on väga oluline, oma piiride mõistmist.

Me kõik teame, et mõnikord viib ülesande lahendamine olukorrani, kus tundub, et ees kasvab sein, mille taha ei saa tungida. Ja mõista, millal on mõistlik jätkata peaga seina tagumist ja millal on aeg leida kedagi, kes saab aidata — see on samuti väga oluline oskus insenerile, kes töötab meeskonnas.

Meie jaoks on selline “abimees” uuele tulijale mentor.

Mentori ülehindamine on lihtsalt võimatu. Kohtuge ise, ta on esimene "kontaktpunkt" talle määratud uue töötaja jaoks, see, kes suudab vastata enamikule küsimustele ja aidata enamikus olukordades — ning parandada halbu mustreid (tehnilises osas, ärieetikas, ettevõtte kultuuris), mida võib treener, isegi tiimijuht, paremini märgata.

Ja see ongi kõik temast?

Loengud, mentorlus, iseseisev töö — need on kolm põhielementi, mis moodustavad meie õppeprogrammi. Aga kas see on kõik, mida saab rääkida? Muidugi mitte!
Isegi kui meil on hea skeem, neli täisõppeprogrammi (viies on teel), ei peatu me "trükkide kogumise" juures. Haridus on nii elav kui meie toode, ja seetõttu ilmub pidevalt nii uut teavet kui ka uusi viise, kuidas seda edastada.

Näiteks oli meie jaoks oluline verstapost mõista, et me tõepoolest kopeerime kooli/ülikooli õppimist rohkem kui täielikult, ja see ei tööta alati. Õpetame täiskasvanud inimesi, kellel on oma kogemused, hirmud ja eelistused. Ja see "kooli" süsteem hirmutab inimesi veidi (nimetame asju õigete nimedega — 95% juhtudest tuleb igasugune frustratsioon koolimudeli tõttu hirmust): me kõik oleme mingil viisil käinud läbi koolist ja ülikoolist ning enamasti oli see siiski traumaatiline kogemus, seetõttu ei soovi me seda üldse korrata.

Siit me alustame (jah, alles alustame, aga "tuhande liikumise tee..." ja nii edasi) oma lähenemiste ümberkorraldamist. Me meenutasime/saime teada andragogikast (täiskasvanute õppimise teadus — vastupidiselt pedagogikale, mis tegelikult tegeleb laste õpetamisega) selle kogemusele orienteerituse, eesmärkide mõistmise, teabe omandamise ja õppijate mugavuse olulisusest, emotsionaalse komponenti tähtsusest (lastele on see isegi olulisem), praktilise osa vajalikusest jne. Me saime teada Kolbi tsüklist ja nüüd viime meie koolitusi läbi, mõeldes, kuidas isegi inimesi, kes on täiesti "mängust väljas", viia koolitusele koos mingi kogemusega, mida me aitame ajakohastada ja täiendada, süvendada ja kohendada, ning mis kõige tähtsam, anda mitte ainult palja teooria, vaid ka praktilisi teadmisi, mille abil meie mentori või iseseisva õppimise kaudu oskusteks muuta.

Me kutsusime ärikoolitajaid, kes tegid meie lektoritega suure töö avalike esinemiste osas, rääkisid tunnetest, treenisid enesekehtestamist, andsid tööriistu grupidünaamika juhtimiseks ja muidugi aitasid meil vastata küsimustele "mida me tahame koolituselt?" ja "mis on meie lõppeesmärk?" Tulemused on juba käes — mõned koolitused, mis kogusid kõige enam tagasisidet stiilis "igav ja midagi ei ole selge", nimetatakse nüüd peaaegu kõige huvitavamateks ja südamega sooritatuks — samas on lektor jäänud samaks!

Samuti tuli meile hiljuti paar väga lahedat ja motiveeritud noort, kes rääkisid Knowledge Centered Supportist ja sellest, kuidas luua videokursuseid — ning me saime neilt palju häid ideid, kuidas viimaseid ümber töötada ja liikuda “veebiseminari stiilist” kaunites ja lihtsatest kursustest, mis selgelt ja arusaadavalt edastavad kõike, mida me tahame, ning ei lase eksida teabe edastamise erinevustes.

Veelgi enam, nüüd tegeleme mitte ainult koolituse tehnilise koostisosaga, st nn hard skills, vaid viime läbi ka soft skills'ide arendamist, mitte ainult lektorite või juhtimise jaoks, vaid ka inseneride jaoks. Me teeme seda selleks, et hüpoteetiline Ignat, tulles ettevõttesse, saaks harjutada neid oskusi, mis on talle 100% vajalikud töös, oskaks oma emotsioone juhtida ja teaks, et olenemata olukorra keerukusest ei jää ta üksi: sest Tugi — see on inimeste jaoks ja "me ei jäta oma inimesi hädas". Enne esimesi sissetulevaid telefonikõnesid mängime algajaga rollimänge, aidates tal protsessi harjuda ja leida oma vastamise stiil, enne esimesi juhtumeid räägime, kuidas nendega paremini töötada ja millele tähelepanu pöörata, ja kogu protsessi käigus jälgime ja aitame.
Meie oleme tugi. Ja keda me toetame kõigepealt, kui mitte oma inimesi?

Ja lõpetuseks paar sõna…

Mõistan, et minu jutt kõlab kiitvalt. Ja samas ma ei uhkusta — see on meie lugu, meie olevik ja vaid väike osa tulevikuplaanidest.

Meie koolitus ei ole kunagi ideaalne. Meil on palju puudusi ja oleme teinud rohkeid vigu — issand, kui palju! Saame palju tagasisidet, ja enamik sellest ei ole kiitev; meile kirjutatakse probleemidest, puudustest ja soovitud täiustustest — kuna koolitame üle kogu maailma, siis on tagasiside väga mitmekesine, ja kui arvestada kultuurilisi nüansse…

Meil on veel arenguruumi ja tänu Jumalale, et meil on inimesi, kes on valmis töötama, kritiseerima, arutama ja uut tooma. See on suur ressurss ja suur toetus.

Aga tugi — see on inimeste asi; just inimesed muudavad koolituse tõhusaks, koolitus aitab uutest töötajatest kiiremini kasulikud jõud luua ja headest inseneridest saavad paremad insenerid kiiremini, ja head insenerid muudavad maailma paremaks.

... ja lubage mul sellel lõpetada lubatud kõne.

Allikas: habr.com