Wat ze niet op school leren: hoe we technische ondersteuning ingenieurs opleiden

Hier is het beloofde 'andere verhaal'.

Wat ze niet op school leren: hoe we technische ondersteuning ingenieurs opleiden

Uitdaging

Als je vier jaar geleden mij had gevraagd: 'Hoe kun je nieuwkomers in de IT-afdeling/bedrijf opleiden?' — dan had ik zonder aarzeling geantwoord: 'Met de methode “de aap ziet, de aap doet”, dat wil zeggen, koppel de nieuwkomer aan een meer ervaren medewerker en laat hem zien hoe gebruikelijke taken worden uitgevoerd.' Deze aanpak werkte eerder voor mij, het werkt nu nog steeds, en enige tijd geleden bij Veeam, toen de bomen groot waren, de logo's groen en het product klein, werd op dezelfde manier geleerd — en zo werd er ook geleerd!

Geleidelijk aan werd het product groter en complexer, er kwamen steeds meer nieuwe ingenieurs bij, en de aanpak in de stijl van RTFM (Read The Freaking Manual) werkte steeds minder goed — het probleem is dat dit alleen kan leren wie al “in het vak” zit, die de specifieke werkwijze begrijpt en behoefte heeft aan enkele, minder kritische details.

En wat moet je doen met degenen die uit aanverwante gebieden komen en willen groeien en zich ontwikkelen, maar niet weten hoe ze dit moeten aanpakken? Wat te doen met iemand die een relatief zeldzame taal beheerst (bijvoorbeeld een taal die ongebruikelijk is voor de gemiddelde IT'er, zoals Italiaans)? Of hoe onderwijs te geven volgens dit schema aan een veelbelovende afgestudeerde die geen uitgebreide werkervaring heeft?

Laten we ons verhaal even onderbreken en ons voorstellen: je bent teamleider van een ondersteuningsgroep, zelf ooit een goede en succesvolle ingenieur met veel ervaring in systeembeheer en communicatie met verschillende mensen. Jouw taak is om jouw ervaring over te dragen aan een nieuwe (je zou kunnen zeggen 'groene') ingenieur, een afgestudeerde, slim en intelligent. Er is maar één probleem — dit is iemand zonder ervaring in ondersteuning en zelfs niet in een eenvoudige helpdesk, en hij zal tevens de eerste Turkstalige ingenieur in jouw bedrijf zijn.

Hoe ga je deze taak aanpakken?

En wanneer je deze vraag hebt beantwoord (en dat ga je doen, ik geloof in je), laten we de taak moeilijker maken — wat als er tien van zulke ingenieurs zijn? En als er twintig zijn? En als het een voortdurende ontwikkeling van de afdeling is, en op elk moment is er een nieuwkomer die moet worden opgeleid, de minimale kwaliteitsnorm moet laten zien (en die norm is hoog) en ervoor zorgen dat de persoon niet zo snel mogelijk wil ontsnappen?

(Denk alsjeblieft over deze vraag na voordat je verder leest.)

Wat ze niet op school leren: hoe we technische ondersteuning ingenieurs opleiden

Ons Verhaal

Met deze uitdaging zijn we geconfronteerd.

Hoewel de afdeling nog relatief klein was, werkte het schema van "geef een nieuweling een mentor, een lijst documenten en laat hem werken - zwem of verzuip" goed. Dit schema is goed, universeel en al jaren, zelfs eeuwen, getest door de menselijke ervaring - maar op een gegeven moment realiseerden we ons dat we moe waren van het herhalen. Aan elke nieuweling moet bepaalde informatie worden overgedragen - hetzelfde dat hij in zijn werk kan gebruiken. In het 'traditionele' schema doet de mentor dit, maar wat als de mentoren allemaal een nieuweling na de andere hebben? Het steeds herhalen van hetzelfde wordt al snel saai, wat leidt tot burn-out - en dat is al een risico.

En dan herinneren we ons een andere, niet minder traditionele aanpak - verzamel de nieuwelingen in groepen en geef ze lezingen - zo is ons opleidingsprogramma ontstaan.

... Soms nemen onze ingenieurs deel aan conferenties - zowel interne als externe, georganiseerd door derden en door onszelf. Juist op zo'n evenement begon de opleiding in de ondersteuning, zoals het nu is.

Een van onze ingenieurs heeft op VeeamOn in Las Vegas een schitterende presentatie gegeven over de verschillende componenten van Veeam Backup & Replication, en met enkele aanpassingen is dit een lezing 'Componenten' geworden. Tegen die tijd hadden we al verschillende lezingen over diverse functionaliteiten, maar die specifieke lezing 'stelde de toon' voor alle lezingen die volgden. Het feit hoe die lezing was opgebouwd, welke materialen werden gebruikt, enzovoorts, is onze standaard geworden.

We zijn veel gaan vertellen over virtualisatie, Microsoft-technologieën, onze eigen producten, en we hebben basis trainingen geïntroduceerd voor onze nieuwelingen zonder ervaring in IT, waarbij we alles uitleggen wat een ondersteuningsingenieur nodig kan hebben - te beginnen met 'hardware' en niveau's van abstractie opbouwend: Disk API, Besturingssystemen, Applicaties, Netwerken, Virtualisatie.

Natuurlijk begrepen en begrijpen we dat het proberen te dekken van de hele breedte van technologieën die we gebruiken met trainingen onmogelijk of althans onredelijk zou zijn. Om alle functies van één product te onderwijzen, zijn nu al enkele maanden nodig, en het product staat niet stil; er komt constant iets nieuws bij. Bovendien kunnen trainingen en lezingen, zoals ze zijn, niet alles bieden wat een toekomstige ingenieur nodig heeft.

En wat dan nog?

Ik houd ervan te zeggen dat we de Pareto-regel toepassen: met onze trainingen geven we ongeveer 20% van wat een succesvolle ingenieur nodig heeft, en 80% blijft op zijn verantwoordelijkheid — het lezen van handleidingen, werken in de labomgeving, het oplossen van test- en echte aanvragen, enzovoort.

20% — trainingen — dat is in feite bijna 100% theoretische basis, maar met alleen theorie kom je niet ver — de klassieke kennis-vaardigheden-vaardigheden structuur werkt. We kunnen kennis bieden, maar vaardigheden ontwikkelen en deze omzetten in vaardigheden is al een heel andere taak.

Precies om deze reden zijn onze oorspronkelijke theoretische lezingen snel aangevuld met andere elementen, en nu ziet het algemene schema er als volgt uit:

  • Lezingen/trainings;
  • Zelfstandig werk;
  • Mentorschap.

Met het eerste punt is alles duidelijk: we nemen een groep beginners, geven ze theorie en gaan geleidelijk over naar het tweede punt, waarbij we aan het einde van de lezing een "huiswerkopdracht" meegeven — een praktische taak die de beginner in de labomgeving moet "uitspelen" en in een bepaalde vorm moet rapporteren (meestal in vrije vorm, maar er zijn uitzonderingen).

We formuleren de opdrachten opzettelijk in vrij algemene termen, om exacte instructies te vermijden zoals "ga daarheen, doe dat, noteer wat je ziet". In plaats daarvan stellen we alleen de taak (bijvoorbeeld: zet een virtuele machine op met deze lijst van componenten) en vragen we om met het verkregen resultaat een soort "onderzoek" te doen, zonder in te gaan op hoe dit moet worden gedaan of hoe het resultaat te verifiëren. Hiermee willen we beginners (vooral degenen die aan het begin van hun IT-reis staan en nog niet weten hoe ingenieurs denken) leren zelf na te denken, handleidingen te lezen en opkomende problemen te analyseren, en, wat heel belangrijk is, om hun eigen grenzen te begrijpen.

We weten allemaal dat het soms lijkt alsof je tegen een muur aanloopt bij het oplossen van een probleem, alsof er een muur opduikt die je niet kunt doorbreken. Het is ook een zeer belangrijke vaardigheid voor een ingenieur die in een team werkt om te begrijpen wanneer het de moeite waard is om door te gaan met het hoofd ertegenaan te slaan en wanneer het tijd is om iemand te vinden die kan helpen.

Bij ons fungeert een mentor als een "helper" voor de beginner.

Een mentor opnieuw waarderen is gewoon onmogelijk. Judge zelf, hij is de eerste "contactpunt" voor de nieuwkomer die aan hem is toegewezen, degene die de meeste vragen kan beantwoorden en kan helpen in de meeste situaties — en die slechte patronen (in de technische aspecten, in de zakelijke ethiek, in de cultuur van het bedrijf) kan corrigeren die zelfs een trainer of teamleider kan over het hoofd zien.

En dit is alles over hem?

Lezingen-trainingen, mentoring, zelfstandig werk — dit zijn de drie belangrijkste bouwstenen die onze opleidingsprogramma's vormen. Maar is dit alles wat er te vertellen valt? Natuurlijk niet!
Zelfs met een goede structuur, vier volledige opleidingsprogramma's (de vijfde is in de maak), stoppen we niet met het verzamelen van onze "trofeeën". Onderwijs is zo levendig als ons product, en daarom verschijnen er constant zowel nieuwe informatie als nieuwe manieren om deze over te brengen.

Een belangrijk keerpunt voor ons was het besef dat we in feite het school-/universitaire onderwijs vrijwel volledig herhalen, en dat het niet altijd werkt. We onderwijzen volwassenen, met ervaring, met hun angsten en voorkeuren. En zo'n "school" systeem schrikt mensen een beetje af (laten we de dingen bij de naam noemen — in 95% van de gevallen komt frustratie door het schoolmodel voort uit angst): we zijn allemaal op de een of andere manier door school en universiteit gegaan, en vaak was dat toch een traumatische ervaring, dus we willen het echt niet herhalen.

Wat ze niet op school leren: hoe we technische ondersteuning ingenieurs opleiden

Hier beginnen we (ja, we beginnen pas, maar "de reis van duizend mijl begint met één stap" en zo verder) onze benaderingen te herzien. We hebben gedacht aan/ontdekt andragogie (onderwijs voor volwassenen — in tegenstelling tot pedagogie, dat in feite over onderwijs aan kinderen gaat) met de focus op ervaring, begrip van doelen, met nuances over het verwerven van informatie en het comfort van de leerlingen, en het belang van de emotionele component (voor kinderen is dit zelfs nog belangrijker), de noodzaak van praktische elementen, enzovoort. We hebben geleerd over de Cyclus van Kolb en nu draaien we onze trainingen, denkend aan hoe we zelfs iemand die absoluut "niet in het onderwerp" zit, naar de training kunnen brengen met al een bepaalde ervaring, die we zullen helpen actualiseren en aanvullen, verdiepen en ordenen, en, wat belangrijk is, niet alleen blote theorie te geven, maar ook praktische kennis die kan worden omgezet in vaardigheden met de hulp van een mentor of zelfstandig.

We invited business coaches who worked extensively with our lecturers on public speaking, discussed emotions, trained assertiveness, provided tools for managing group dynamics, and, of course, helped us answer the questions “what do we want from training?” and “what is our ultimate goal?”. The results are already noticeable — some training sessions that previously received the most feedback along the lines of “boring and unclear” are now being called some of the most interesting and heartfelt — and yet the lecturer has remained the same!

Recently, a couple of very cool and motivated individuals came to us, discussing Knowledge Centered Support and how to build video courses — and we gained many good ideas from them on how to redesign the latest offerings and move away from the “webinar recording style” to beautiful and simple courses that clearly and understandably convey everything we want, without drowning in the diversity of information delivery methods.

Moreover, we are now focusing not only on the technical aspects of training, that is, so-called hard skills, but we are also working on soft skills, not just for lecturers or management, but also for engineers. We are doing this so that a hypothetical Ignat, coming into the company, can practice the skills that will be 100% necessary for his work, manage his emotions, and know that in any situation, even the most difficult and hopeless, he will not be alone: after all, Support is about people, and “we do not abandon our own in trouble.” Before the first incoming phone calls, we play role games with the newcomer to help him get into the process and find his response style; before the first cases, we explain how best to work with them and what to pay attention to, and throughout the entire process, we will monitor and assist.
We are support. And who should we support first of all, if not our own?

And in conclusion, a few words…

I realize that my account sounds laudatory. And I’m not boasting — this is our story, our present, and just a small part of our plans for the future.

Onze opleiding is allesbehalve perfect. We hebben veel tekortkomingen en hebben talloze fouten gemaakt — oh my! We ontvangen veel feedback en meestal is deze niet positief; mensen wijzen ons op problemen, tekortkomingen en gewenste verbeteringen. Aangezien we worldwide trainen, krijgen we heel diverse feedback, en als we ook de culturele verschillen in overweging nemen…

Wat ze niet op school leren: hoe we technische ondersteuning ingenieurs opleiden

We hebben nog veel ruimte om te groeien, en gelukkig hebben we mensen die bereid zijn om te werken, te bekritiseren, te discussiëren en nieuwe ideeën aan te dragen. Dit is een enorme bron van steun.

En ondersteuning gaat over mensen — het zijn juist de mensen die de opleiding vormgeven, opleiding helpt nieuwe medewerkers eerder waarde te bieden en sneller op te groeien tot goede ingenieurs, en goede ingenieurs maken de wereld beter.

… en daarmee laat ik u graag mijn toelichting beëindigen.

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster