Wat ze niet op school leren: hoe we technische ondersteuningsingenieurs opleiden

Hier is het beloofde “andere verhaal”.

Wat ze niet op school leren: hoe we technische ondersteuningsingenieurs opleiden

Uitdaging

Als je mij vier jaar geleden had gevraagd: “Hoe kun je nieuwkomers op de IT-afdeling/bedrijf opleiden?” - Ik zou zonder aarzeling zeggen: "Gebruik de methode 'aap ziet, aap imiteert', dat wil zeggen: wijs een nieuwkomer toe aan een meer ervaren medewerker en laat hem kijken hoe typische taken worden uitgevoerd." Deze aanpak werkte eerder voor mij, het werkt nu nog steeds, en enige tijd geleden in Veeam, toen de bomen groot waren, de logo's groen waren en het product klein was, was dit ook de manier waarop je kon trainen - en trainen!

Geleidelijk aan werd het product groot en complex, er kwamen steeds meer nieuwe ingenieurs, en de RTFM-stijl (Read The Freaking Manual) aanpak werkte steeds slechter - het feit is dat degenen die al “op de hoogte zijn” op deze manier kunnen leren , die de specifieke kenmerken van het werk begrijpt en enkele, niet zo kritische details nodig heeft.

Maar hoe zit het met degenen die uit verwante vakgebieden komen en willen groeien en ontwikkelen, maar niet weten hoe ze dit moeten aanpakken? Wat te doen bijvoorbeeld met degenen die een relatief zeldzame taal spreken (bijvoorbeeld Italiaans, wat zeldzaam is voor de gemiddelde IT-specialist)? Of hoe kun je in een dergelijk programma een veelbelovende universitair afgestudeerde, die nog niet veel werkervaring heeft, opleiden?

Laten we ons verhaal even stopzetten en ons voorstellen: hier ben je, een teamleider in het ondersteuningsteam, een voormalige goede en succesvolle ingenieur, met uitgebreide ervaring in systeembeheer en communicatie met verschillende mensen. Jouw taak is om je ervaring door te geven aan een nieuwe (je zou zelfs kunnen zeggen “groene”) gevechtsingenieur, een universitair afgestudeerd, slim en snel van begrip. Er is slechts een nuance: dit is een persoon zonder ondersteuningservaring of zelfs een banale helpdesk, en hij zal ook de eerste Turkssprekende ingenieur in uw bedrijf zijn.

Hoe ga je dit probleem oplossen?

En als je deze vraag beantwoordt (en je zult antwoorden, ik geloof in je), laten we de taak dan ingewikkelder maken: wat als er tien van dergelijke ingenieurs zijn? Wat als twintig? Wat als dit een constante ontwikkeling van de afdeling is, en er op elk moment een nieuwkomer zal zijn die moet worden opgeleid, een minimale standaard van werkkwaliteit moet tonen (en deze standaard is hoog) en ervoor moet zorgen dat de persoon niet wil zo snel mogelijk wegrennen?

(Denk alstublieft na over deze vraag voordat u verder leest.)

Wat ze niet op school leren: hoe we technische ondersteuningsingenieurs opleiden

Ons verhaal

Dit is precies de uitdaging/taak waar we voor stonden.

Hoewel de afdeling relatief klein was, werkte het plan “geef een nieuweling een mentor, een lijst met documenten en stop met werken – zwemmen of zinken” goed. Het schema is goed, universeel, bewezen door jaren en zelfs eeuwen van universele menselijke ervaring – maar op een gegeven moment beseften we dat we de herhaling beu waren. Elke nieuwkomer moet een aantal dingen verteld worden - dezelfde dingen die voor hem nuttig kunnen zijn in zijn werk. In het “traditionele” schema doet de mentor dit, maar wat als een mentor afdelingen één voor één heeft? Hetzelfde herhalen wordt snel saai, een burn-out ontstaat - en dit is al een risico.

En hier herinneren we ons een ander, niet minder traditioneel plan: nieuwkomers in groepen verzamelen en lezingen geven - zo is ons trainingsprogramma geboren.

... Soms nemen onze engineers deel aan conferenties – zowel intern als extern, van derden en door onszelf georganiseerd. Vanaf deze gebeurtenis begon de training in ondersteuning, zoals die nu nog steeds plaatsvindt.

Een van onze engineers gaf op VeeamOn in Las Vegas een briljante presentatie over de onderdelen waaruit Veeam Backup & Replication bestaat, en met een paar aanpassingen werd het de lezing ‘Componenten’. Tegen die tijd hadden we al verschillende lezingen gehad over verschillende delen van de functionaliteit, maar het was die lezing die “de toon zette” voor alles wat ervoor en erna kwam. Het was de manier waarop de lezing was gestructureerd, welke materialen er werden gebruikt, enz., die voor ons de standaard werd.

We begonnen veel te praten over virtualisatie, Microsoft-technologieën, onze eigen producten, introduceerden een basistraining voor onze beginners zonder IT-ervaring, waarin we alles vertelden wat een ondersteuningsingenieur nodig zou kunnen hebben - te beginnen met hardware en toenemende abstractieniveaus: Disk API, Bediening Systemen, applicaties, netwerken, virtualisatie.

Natuurlijk begrepen en begrijpen we dat het onmogelijk of op zijn minst onredelijk zou zijn om het hele scala aan technologieën die we gebruiken met training te dekken. Het duurt al enkele maanden om alle eigenschappen van één product aan te leren, maar het product staat niet stil en er verschijnt voortdurend iets nieuws. Bovendien kunnen alleen trainingscolleges, zoals ze zijn, niet alles bieden wat een toekomstige ingenieur nodig heeft.

Wat nog meer?

Ik zeg graag dat de Pareto-regel voor ons werkt: met onze trainingen voorzien we in ongeveer 20% van wat een succesvolle ingenieur nodig heeft, en 80% blijft op zijn geweten: handleidingen lezen, in het laboratorium werken, test- en gevechtsverzoeken oplossen, enz. .

20% - trainingen - in feite is dit bijna 100% van de theoretische basis, maar met theorie alleen kun je niet alles bereiken - het klassieke schema van Kennis-Vaardigheden-Vaardigheden werkt. We kunnen kennis geven, maar het ontwikkelen van vaardigheden en het omzetten ervan in vaardigheden is een heel andere taak.

Daarom konden onze eerste theoretische lezingen heel snel worden aangevuld met andere dingen, en nu ziet het algemene schema er als volgt uit:

  • Lezingen/trainingen;
  • Onafhankelijk werk;
  • Begeleiding.

Alles is duidelijk met het eerste punt: we nemen een groep beginners, lezen hen de theorie voor en gaan soepel verder met het tweede punt, waarbij we aan het einde van de lezing 'huiswerk' geven - een soort praktisch probleem dat de beginner moet 'spelen'. out” in het laboratorium en geef een rapport in een of andere vorm (meestal is het formulier gratis, maar er zijn uitzonderingen).

We formuleren de taken opzettelijk in een vrij algemene vorm, waarbij we precieze instructies vermijden ‘ga daarheen, doe dat, schrijf op wat je ziet’. In plaats daarvan stellen we gewoon een taak voor (bijvoorbeeld: implementeer een virtuele machine met deze lijst met componenten) en vragen ons om wat “onderzoek” te doen met het verkregen resultaat, zonder in te gaan op hoe we dat moeten doen of hoe we het resultaat kunnen controleren. Hiermee willen we beginners (vooral degenen die aan het begin staan ​​van hun reis uit de wereld van IT en hoe de technische broederschap denkt) onafhankelijk denken leren, de vaardigheid van het lezen van documentatie en het analyseren van opkomende problemen, en, heel belangrijk, het begrijpen van hun problemen. grenzen.

We weten allemaal dat het oplossen van een probleem soms tot een doodlopende weg leidt, alsof er een muur voor ons staat die niet kan worden doorbroken. En begrijpen wanneer het de moeite waard is om er je hoofd in te blijven steken, en wanneer het tijd is om iemand te vinden die kan helpen, is ook een zeer belangrijke vaardigheid voor een ingenieur die in teamverband werkt.

In ons geval is deze ‘helper’ voor een nieuweling een mentor.

Het is simpelweg onmogelijk om een ​​mentor te overschatten. Oordeel zelf, hij is het eerste ‘contactpunt’ voor de nieuweling die hem is toegewezen, degene die de meeste vragen kan beantwoorden en in de meeste situaties kan helpen – en die slechte patronen kan corrigeren (in het technische gedeelte, in de bedrijfsethiek, in de Bedrijfscultuur), die zowel de coach als zelfs de teamleider kunnen missen.

En het draait allemaal om hem?

Lezingen-trainingen, mentoring, zelfstandig werken - dit zijn de drie belangrijkste bouwstenen waaruit ons trainingsprogramma bestaat. Maar is dat alles wat er te vertellen valt? Natuurlijk niet!
Zelfs met een goed plan, vier complete trainingsprogramma's (de vijfde is onderweg), stoppen we niet met het verzamelen van onze “plunderbroden”. Onderwijs is net zo levend als ons product, en daarom verschijnen er voortdurend nieuwe informatie en nieuwe manieren om deze over te brengen.

Een belangrijke mijlpaal voor ons was bijvoorbeeld het inzicht dat we de school-/universiteitsopleiding eigenlijk iets meer dan volledig herhalen, en dat dit niet altijd werkt. Wij geven les aan volwassenen met ervaring, met hun eigen angsten en voorkeuren. En dit “school”-systeem maakt de mensen een beetje bang (laten we het maar bij alles noemen – in 95% van de gevallen komt elke frustratie als gevolg van het schoolmodel voort uit angst): we hebben allemaal op de een of andere manier school en universiteit doorlopen, en meestal was het allemaal. Het was nog steeds een traumatische ervaring, dus ik wil het helemaal niet herhalen.

Wat ze niet op school leren: hoe we technische ondersteuningsingenieurs opleiden

Vanaf hier beginnen we (ja, we zijn nog maar net begonnen, maar “de reis is duizend mijl...” enzovoort) om onze aanpak te herwerken. We herinnerden ons/leerden over andragogie (lesgeven aan volwassenen - in tegenstelling tot pedagogie, die in essentie gaat over het lesgeven aan kinderen) met zijn focus op ervaring, begrip van doelen, met nuances over de assimilatie van informatie en het comfort van studenten, het belang van de emotionele component (voor kinderen is dit zelfs nog belangrijker), de behoefte aan een praktische component, enzovoort. Wij hebben erover geleerd fles cyclus en nu wisselen we onze trainingen af, waarbij we bedenken hoe we zelfs iemand die volledig ‘buiten het onderwerp’ is, met enige ervaring, naar de training kunnen halen, die we zullen helpen bijwerken en aanvullen, verdiepen en kammen, en, wat belangrijk is , geef niet alleen kale theorie, maar ook praktische kennis die met behulp van een mentor of zelfstandig kan worden omgezet in vaardigheden.

We nodigden bedrijfstrainers uit die met onze docenten werkten aan spreken in het openbaar, spraken over emoties, trainden assertiviteit, gaven ons tools voor het beheren van groepsdynamiek en hielpen ons natuurlijk bij het beantwoorden van de vragen ‘wat willen we van de training?’ en “wat is ons einddoel?” De resultaten zijn er al - sommige trainingen die de meeste feedback verzamelden in de stijl van "saai en niets is duidelijk" worden nu misschien wel de meest interessante en oprechte genoemd - maar de docent blijft dezelfde!

En onlangs kwamen er een paar hele coole en gemotiveerde jongens naar ons toe, die spraken over Knowledge Centered Support en hoe je videocursussen kunt bouwen - en we hebben veel goede ideeën van hen geleerd over hoe je dat laatste opnieuw kunt maken en af ​​kunt stappen van 'opname'. een webinar-stijl” in prachtige en eenvoudige cursussen die ons op een eenvoudige en duidelijke manier alles vertellen wat we willen, en ons niet laten verdrinken in de verscheidenheid aan methoden om informatie te presenteren.

Bovendien hebben we nu niet alleen de technische component van de opleiding ter hand genomen, dat wil zeggen de zogenaamde harde vaardigheden, maar werken we ook met zachte vaardigheden, niet alleen voor docenten of management, maar ook voor ingenieurs. We doen dit zodat de voorwaardelijke Ignat, wanneer hij naar het bedrijf komt, de vaardigheden kan oefenen die hij 100% nodig zal hebben in zijn werk, zijn emoties kan beheersen en dat weet in elke, zelfs de meest moeilijke en hopeloze situatie. , dat zal hij niet doen: Ondersteuning gaat tenslotte over mensen, en “we laten de onze niet in de steek als we in de problemen komen.” Vóór de eerste inkomende telefoontjes spelen we rollenspellen met de nieuwkomer, helpen we hen bij het proces betrokken te raken en hun eigen antwoordstijl te vinden; vóór de eerste gevallen zullen we hen vertellen hoe ze het beste met hen kunnen werken en wat ze moeten doen. zoeken, en wij monitoren en helpen gedurende het gehele proces.
Wij zijn steun. En wie moeten we in de eerste plaats steunen, als het niet de onze is?

En tot slot nog een paar woorden...

Ik ben me ervan bewust dat mijn verhaal lovend klinkt. En tegelijkertijd schep ik niet op: dit is onze geschiedenis, ons heden en slechts een klein deel van onze plannen voor de toekomst.

Onze trainingen zijn nooit perfect. We hebben veel tekortkomingen en we hebben veel fouten gemaakt - lieve moeder! We krijgen veel feedback, en meestal is het niet lovend, ze schrijven ons over problemen, tekortkomingen, gewenste verbeteringen - en omdat we wereldwijd lesgeven, krijgen we veel gevarieerde feedback, en als we ook rekening houden met culturele kenmerken ...

Wat ze niet op school leren: hoe we technische ondersteuningsingenieurs opleiden

We hebben ruimte om te groeien, en godzijdank hebben we mensen die bereid zijn te werken, kritiek te leveren, te discussiëren en nieuwe dingen aan te bieden. Dit is een geweldige hulpbron en geweldige ondersteuning.

En Support gaat over mensen: het zijn mensen die trainingen geven, training helpt nieuwe medewerkers eerder nuttig te worden en sneller uit te groeien tot goede ingenieurs, en goede ingenieurs maken de wereld een betere plek.

...en laat mij hiermee mijn toegestane toespraken afmaken.

Bron: www.habr.com

Voeg een reactie