Was in der Schule nicht gelehrt wird: wie wir technische Unterstützungsingenieure ausbilden

Hier ist die versprochene „andere Geschichte“.

Herausforderung

Wenn man mich vor vier Jahren gefragt hätte: „Wie kann man Neueinsteiger in der IT-Abteilung / Firma schulen?“ — hätte ich ohne zu zögern geantwortet: „Nach dem Prinzip: „Die Affe sieht — die Affe ahmt nach“, das heißt, man koppelt den Neuling mit einem erfahreneren Kollegen und lässt ihn beobachten, wie die typischen Aufgaben erledigt werden.“ Dieser Ansatz hat bei mir früher funktioniert, er funktioniert auch heute noch, und eine Zeit lang in Veeam, als die Bäume groß waren, die Logos grün und das Produkt klein, konnte man so ebenfalls ausbilden — und das wurde auch gemacht!

Allmählich wurde das Produkt jedoch größer und komplexer, es gab immer mehr neue Ingenieure, und der Ansatz im Stil von RTFM (Read The Freaking Manual) funktionierte immer schlechter — denn so können nur die lernen, die bereits „im Thema“ sind, die die Spezifik des Arbeitens verstehen und in einigen, weniger kritischen Details Hilfe benötigen.

Und wie ist es mit denen, die aus verwandten Bereichen kommen und wachsen und sich entwickeln wollen, aber nicht wissen, wie sie das angehen sollen? Wie geht man beispielsweise mit jemandem um, der eine bedingt seltene Sprache spricht (zum Beispiel eine seltene Sprache für den durchschnittlichen ITler, Italienisch)? Oder wie schult man nach diesem Schema einen vielversprechenden Absolventen einer Hochschule, der keinen großen Berufserfahrung hat?

Lassen Sie uns für einen Moment unsere Erzählung unterbrechen und uns vorstellen: Sie sind Teamleiter in einem Support-Team, waren früher selbst ein guter und erfolgreicher Ingenieur mit viel Erfahrung in Systemadministration und Kommunikation mit verschiedenen Menschen. Ihre Aufgabe ist es, Ihre Erfahrung an einen neuen (man könnte sogar sagen „grünen“) Ingenieur zu vermitteln, einen Hochschulabsolventen, der intelligent und scharfsinnig ist. Es gibt nur einen Haken — dies ist eine Person ohne Erfahrung im Support und sogar im einfachen Helpdesk, und sie wird der erste türkischsprachige Ingenieur in Ihrer Firma sein.

Wie werden Sie diese Aufgabe lösen?

Und wenn Sie diese Frage beantwortet haben (und Sie werden sie beantworten, ich glaube an Sie), lassen Sie uns die Aufgabe komplizieren — was, wenn es zehn solcher Ingenieure geben wird? Was, wenn es zwanzig sind? Was, wenn dies eine ständige Entwicklung der Abteilung ist und zu jedem Zeitpunkt ein Neuling da ist, den man schulen muss, der minimalen Qualitätsstandard (und dieser Standard ist hoch) gezeigt werden muss, und das so, dass die Person nicht so schnell wie möglich fliehen möchte?

(Bitte denken Sie über diese Frage nach, bevor Sie weiter lesen.)

Unsere Geschichte

Genau mit dieser Herausforderung sind wir konfrontiert worden.

Solange die Abteilung noch relativ klein war, funktionierte das Schema "Gib dem Neuling einen Mentor, eine Dokumentenliste und lass ihn arbeiten – schwimm oder sink" gut. Das Schema ist gut, universell und hat sich über Jahre und sogar Jahrhunderte menschlicher Erfahrung bewährt – aber irgendwann haben wir gemerkt, dass wir die Wiederholungen leid sind. Jeder Neuling muss irgendwelche Dinge erklärt bekommen – immer wieder dasselbe, was ihm in seiner Arbeit nützlich sein kann. In dem "traditionellen" Schema kümmert sich der Mentor darum, aber was, wenn bei einem Mentor die Schützlinge nacheinander kommen? Dasselbe immer wieder zu wiederholen macht schnell müde, es kommt zu einem Burnout – und das ist bereits ein Risiko.

Hier erinnern wir uns an ein anderes, nicht weniger traditionelles Schema – die Neulinge in Gruppen zu sammeln und ihnen Vorträge zu halten – so entstand unser Schulungsprogramm.

… Manchmal nehmen unsere Ingenieure an Konferenzen teil – sowohl internen als auch externen, von Dritten und von uns selbst organisierten. Genau von einer solchen Veranstaltung begann die Schulung im Support, wie sie jetzt ist.

Einer unserer Ingenieure hielt auf der VeeamOn in Las Vegas einen glänzenden Vortrag darüber, aus welchen Bestandteilen Veeam Backup & Replication besteht. Mit einigen Anpassungen wurde daraus der Vortrag "Komponenten". Zu diesem Zeitpunkt hatten wir bereits mehrere Vorträge über verschiedene Teile der Funktionalität, aber genau dieser Vortrag "gab den Ton an" für alle, die davor und danach kamen. Die Art und Weise, wie dieser Vortrag aufgebaut war, welche Materialien verwendet wurden und so weiter, wurde zu unserem Standard.

Wir begannen viel über Virtualisierung, Microsoft-Technologien und unsere eigenen Produkte zu erzählen, führten grundlegende Schulungen für unsere neuen Mitarbeiter ohne IT-Erfahrung ein, in denen wir alles vermitteln, was ein Supportingenieur benötigen könnte – beginnend mit "Hardware" und steigernd in die Abstraktionsebenen: Disk API, Betriebssysteme, Anwendungen, Netzwerk, Virtualisierung.

Natürlich wussten und wissen wir, dass es unmöglich oder zumindest unvernünftig sein wird, mit Schulungen das gesamte Spektrum der Technologien, die wir verwenden, abzudecken. Um alle Funktionen eines Produkts zu vermitteln, benötigt man bereits jetzt mehrere Monate, und das Produkt selbst steht nicht still, ständig kommt etwas Neues hinzu. Darüber hinaus können nur Vorträge, wie sie sind, nicht alles bieten, was ein zukünftiger Ingenieur benötigt.

Was gibt es also darüber hinaus?

Ich sage gerne, dass bei uns das Pareto-Prinzip gilt: Mit unseren Schulungen vermitteln wir etwa 20 % dessen, was ein erfolgreicher Ingenieur benötigt, und 80 % bleiben in seiner Verantwortung – das Lesen von Handbüchern, die Arbeit im Labor, das Lösen von Test- und Produktionsanfragen usw.

20 % – Schulungen – sind tatsächlich fast 100 % theoretischer Basis, aber nur mit Theorie erreicht man nicht alles – das klassische Schema Wissen-Fähigkeiten-Kompetenzen funktioniert. Wir können Wissen vermitteln, aber Fähigkeiten zu entwickeln und daraus Kompetenzen zu machen, ist eine ganz andere Herausforderung.

Genau deshalb kann man sehr schnell sehen, wie unsere anfänglichen theoretischen Vorlesungen durch andere Aspekte ergänzt wurden, und nun sieht das Gesamtschema so aus:

• Vorlesungen/Schulungen;
• Selbständige Arbeit;
• Mentoring.

Mit dem ersten Punkt ist alles klar: Wir nehmen eine Gruppe von Anfängern, erklären ihnen die Theorie und gehen dann sanft zum zweiten Punkt über, indem wir am Ende der Vorlesung eine „Hausaufgabe“ stellen – eine praktische Aufgabe, die der Anfänger im Labor „spielen“ und in irgendeiner Form (meist in freier Form, aber es gibt auch Ausnahmen) einen Bericht präsentieren soll.

Die Aufgaben formulieren wir absichtlich in ziemlich allgemeiner Form und vermeiden genaue Anweisungen wie „geh dorthin, mach das, schreib auf, was du siehst“. Stattdessen stellen wir einfach eine Aufgabe (z. B.: Richte eine virtuelle Maschine mit dieser Liste von Komponenten ein) und bitten darum, mit dem erhaltenen Ergebnis eine Art „Untersuchung“ durchzuführen, ohne uns darum zu kümmern, wie man das macht oder wie man das Ergebnis überprüft. Damit wollen wir unsere Anfänger (insbesondere die, die zu Beginn ihres Weges weit von der IT-Welt und der Denkweise der Ingenieure entfernt sind) zur selbständigen Denkweise, zum Lesen von Dokumentationen und zur Analyse aufkommender Probleme anregen, und was sehr wichtig ist, ihr Verständnis für ihre Grenzen fördern.

Wir alle wissen, dass die Lösung eines Problems manchmal in eine Sackgasse führt, als ob eine Wand vor uns wächst, die man nicht durchbrechen kann. Zu verstehen, in welchen Fällen man weiterhin dagegen ankämpfen sollte und wann es Zeit ist, jemanden zu suchen, der helfen kann, ist ebenfalls eine sehr wichtige Fähigkeit für Ingenieure, die im Team arbeiten.

Uns dient dabei als ‚Helfer‘ für die Anfänger ein Mentor.

Es ist einfach unmöglich, einen Mentor neu zu bewerten. Urteilen Sie selbst, er ist der erste "Kontaktpunkt" für den Neuling, der ihm zugeordnet ist, derjenige, der die meisten Fragen beantworten und in den meisten Situationen helfen kann – und die schlechten Muster (im technischen Bereich, in der Geschäftsethik, in der Unternehmens­kultur), die ein Trainer oder sogar ein Teamleiter übersehen könnte, korrigieren kann.

Und das ist alles über ihn?

Vorlesungen, Trainings, Mentoring, selbstständige Arbeit – das sind die drei Grundpfeiler, die unser Ausbildungsprogramm bilden. Aber ist das wirklich alles, was man darüber sagen kann? Natürlich nicht!
Selbst mit einem soliden Plan, vier vollständigen Ausbildungsprogrammen (ein fünftes steht in den Startlöchern), hören wir nicht auf, unsere "Trödel zu plündern". Ausbildung ist so lebendig, wie unser Produkt lebendig ist, und deshalb gibt es ständig neue Informationen sowie neue Wege, diese zu vermitteln.

Ein Beispiel: Ein wichtiger Meilenstein für uns war das Verständnis, dass wir tatsächlich die schulische/universitäre Ausbildung mehr oder weniger vollständig wiederholen und dass sie nicht immer funktioniert. Wir bilden erwachsene Menschen aus, die Erfahrung, eigene Ängste und Präferenzen haben. Und ein solches "schulisches" System macht den Menschen ein wenig Angst (nennen wir die Dinge beim Namen – in 95 % der Fälle kommt jede Frustration durch das schulische Modell aus Angst): Wir sind alle mehr oder weniger durch Schule und Universität gegangen, und oft war es dennoch eine traumatische Erfahrung, weshalb wir ihn nicht wiederholen möchten.

Von da aus beginnen wir (ja, wir beginnen nur, aber „der Weg von tausend Meilen beginnt...“ und so weiter), unsere Ansätze zu überdenken. Wir erinnerten uns an/lernten über Andragogik (Ausbildung von Erwachsenen im Gegensatz zur Pädagogik, die im Wesentlichen die Ausbildung von Kindern betrifft) mit ihrer Ausrichtung auf Erfahrung, Zielverständnis, den Nuancen des Informationserwerbs und dem Komfort der Lernenden sowie der Bedeutung der emotionalen Komponente (die für Kinder noch wichtiger ist), der Notwendigkeit praktischer Komponenten usw. Wir erfuhren von dem Kolb-Zyklus und nun gestalten wir unsere Trainings so, dass wir auch Menschen, die absolut "nicht im Thema" sind, bereits mit irgendeiner Erfahrung zum Training bringen, die wir helfen, zu aktualisieren und zu ergänzen, zu vertiefen und zu ordnen, und was wichtig ist, nicht nur nackte Theorie zu vermitteln, sondern auch praktische Kenntnisse, die mit Hilfe eines Mentors oder selbstständig in Fähigkeiten umgewandelt werden können.

Wir haben Business-Coaches eingeladen, die mit unseren Dozenten intensiv an öffentlichen Reden gearbeitet haben, über Emotionen gesprochen, die Durchsetzungsfähigkeit trainiert, Werkzeuge zur Steuerung der Gruppendynamik bereitgestellt haben und uns natürlich geholfen haben, die Fragen "Was wollen wir vom Unterricht?" und "Was ist unser Endziel?" zu beantworten. Die Ergebnisse sind bereits vorhanden – einige Trainings, die bisher am meisten Feedback in der Art "langweilig und nichts ist klar" gesammelt haben, werden nun als fast die interessantesten und herzlichsten bezeichnet – und der Dozent war der gleiche geblieben!

Vor kurzem haben uns auch ein paar sehr coole und motivierte Leute besucht, die über Knowledge Centered Support und darüber, wie man Videokurse erstellt, berichteten – und wir haben von ihnen viele gute Ideen gesammelt, wie wir die letzten umgestalten und von dem "Webinar-Aufnahme-Stil" zu schönen und einfachen Kursen übergehen können, die klar und verständlich alles vermitteln, was wir wollen, und nicht dazu führen, dass man in der Vielfalt der Methoden zur Informationsbereitstellung ertrinkt.

Darüber hinaus beschäftigen wir uns jetzt nicht nur mit den technischen Aspekten des Unterrichts, also den sogenannten Hard Skills, sondern arbeiten auch an Soft Skills, und zwar nicht nur für Dozenten oder das Management, sondern auch für Ingenieure. Wir tun dies, damit ein gewisser Ignat, wenn er ins Unternehmen kommt, die Fähigkeiten trainieren kann, die er für seine Arbeit zu 100 % benötigt, in der Lage ist, seine Emotionen zu steuern, und weiß, dass er in jeder, auch der kompliziertesten und hoffnungslosesten Situation nicht allein sein wird: denn Support geht um Menschen, und "wir lassen unsere Leute in der Not nicht im Stich". Vor den ersten eingehenden Anrufen spielen wir mit dem Neuling Rollenspiele, um ihm den Einstieg zu erleichtern und seinen Stil beim Antworten zu finden, vor den ersten Fällen erklären wir, wie man am besten damit umgeht und worauf man achten sollte, und während des gesamten Prozesses werden wir beobachten und helfen.
Wir sind der Support. Und wen sollten wir in erster Linie unterstützen, wenn nicht unsere eigenen?

Und zum Schluss ein paar Worte...

Ich bin mir bewusst, dass meine Erzählung wohlwollend klingt. Gleichzeitig prahle ich nicht – das ist unsere Geschichte, unser Jetzt und nur ein kleiner Teil unserer Pläne für die Zukunft.

Unsere Ausbildung ist bei weitem nicht perfekt. Wir haben viele Mängel und haben einige Fehler gemacht – oh je! Wir erhalten viele Rückmeldungen, und meist sind diese nicht lobend; man schreibt uns über Probleme, Mängel und gewünschte Verbesserungen – und da wir weltweit ausbilden, bekommen wir sehr vielfältige Rückmeldungen, besonders wenn man auch kulturelle Besonderheiten berücksichtigt ...

Wir haben noch viel Spielraum zur Verbesserung, und Gott sei Dank haben wir diejenigen, die bereit sind, zu arbeiten, zu kritisieren, zu diskutieren und neue Vorschläge zu machen. Das ist eine große Ressource und eine große Unterstützung.

Und Unterstützung bedeutet Menschen – es sind die Menschen, die die Ausbildung gestalten, und die Ausbildung hilft neuen Mitarbeitern, schneller nützlich zu sein und schneller zu guten Ingenieuren zu wachsen, und gute Ingenieure machen die Welt besser.

... und damit erlaube ich mir, die erlaubten Worte zu beenden.

Quelle: habr.com