{"id":53316,"date":"2019-11-29T00:00:00","date_gmt":"2019-11-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki"},"modified":"2020-02-18T14:01:12","modified_gmt":"2020-02-18T11:01:12","slug":"chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","title":{"rendered":"Was in der Schule nicht gelehrt wird: wie wir technische Unterst\u00fctzungsingenieure ausbilden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hier ist die versprochene \u201eandere Geschichte\u201c.<\/p>\n

\"Was
\n<\/p>\n

Herausforderung
\n<\/h3>\n

\nWenn man mich vor vier Jahren gefragt h\u00e4tte: \u201eWie kann man Neueinsteiger in der IT-Abteilung \/ Firma schulen?\u201c \u2014 h\u00e4tte ich ohne zu z\u00f6gern geantwortet: \u201eNach dem Prinzip: \u201eDie Affe sieht \u2014 die Affe ahmt nach\u201c, das hei\u00dft, man koppelt den Neuling mit einem erfahreneren Kollegen und l\u00e4sst ihn beobachten, wie die typischen Aufgaben erledigt werden.\u201c Dieser Ansatz hat bei mir fr\u00fcher funktioniert, er funktioniert auch heute noch, und eine Zeit lang in Veeam, als die B\u00e4ume gro\u00df waren, die Logos gr\u00fcn und das Produkt klein, konnte man so ebenfalls ausbilden \u2014 und das wurde auch gemacht!<\/p>\n

Allm\u00e4hlich wurde das Produkt jedoch gr\u00f6\u00dfer und komplexer, es gab immer mehr neue Ingenieure, und der Ansatz im Stil von RTFM (Read The Freaking Manual) funktionierte immer schlechter \u2014 denn so k\u00f6nnen nur die lernen, die bereits \u201eim Thema\u201c sind, die die Spezifik des Arbeitens verstehen und in einigen, weniger kritischen Details Hilfe ben\u00f6tigen.<\/p>\n

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\u00fcr den durchschnittlichen ITler, Italienisch)? Oder wie schult man nach diesem Schema einen vielversprechenden Absolventen einer Hochschule, der keinen gro\u00dfen Berufserfahrung hat?<\/p>\n

Lassen Sie uns f\u00fcr einen Moment unsere Erz\u00e4hlung unterbrechen und uns vorstellen: Sie sind Teamleiter in einem Support-Team, waren fr\u00fcher 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\u00f6nnte sogar sagen \u201egr\u00fcnen\u201c) Ingenieur zu vermitteln, einen Hochschulabsolventen, der intelligent und scharfsinnig ist. Es gibt nur einen Haken \u2014 dies ist eine Person ohne Erfahrung im Support und sogar im einfachen Helpdesk, und sie wird der erste t\u00fcrkischsprachige Ingenieur in Ihrer Firma sein.<\/p>\n

<\/a><\/noindex>Wie werden Sie diese Aufgabe l\u00f6sen?<\/p>\n

Und wenn Sie diese Frage beantwortet haben (und Sie werden sie beantworten, ich glaube an Sie), lassen Sie uns die Aufgabe komplizieren \u2014 was, wenn es zehn solcher Ingenieure geben wird? Was, wenn es zwanzig sind? Was, wenn dies eine st\u00e4ndige Entwicklung der Abteilung ist und zu jedem Zeitpunkt ein Neuling da ist, den man schulen muss, der minimalen Qualit\u00e4tsstandard (und dieser Standard ist hoch) gezeigt werden muss, und das so, dass die Person nicht so schnell wie m\u00f6glich fliehen m\u00f6chte?<\/p>\n

(Bitte denken Sie \u00fcber diese Frage nach, bevor Sie weiter lesen.)<\/p>\n

\"Was
\n<\/p>\n

Unsere Geschichte<\/h3>\n

\nGenau mit dieser Herausforderung sind wir konfrontiert worden. <\/p>\n

Solange die Abteilung noch relativ klein war, funktionierte das Schema \"Gib dem Neuling einen Mentor, eine Dokumentenliste und lass ihn arbeiten \u2013 schwimm oder sink\" gut. Das Schema ist gut, universell und hat sich \u00fcber Jahre und sogar Jahrhunderte menschlicher Erfahrung bew\u00e4hrt \u2013 aber irgendwann haben wir gemerkt, dass wir die Wiederholungen leid sind. Jeder Neuling muss irgendwelche Dinge erkl\u00e4rt bekommen \u2013 immer wieder dasselbe, was ihm in seiner Arbeit n\u00fctzlich sein kann. In dem \"traditionellen\" Schema k\u00fcmmert sich der Mentor darum, aber was, wenn bei einem Mentor die Sch\u00fctzlinge nacheinander kommen? Dasselbe immer wieder zu wiederholen macht schnell m\u00fcde, es kommt zu einem Burnout \u2013 und das ist bereits ein Risiko.<\/p>\n

Hier erinnern wir uns an ein anderes, nicht weniger traditionelles Schema \u2013 die Neulinge in Gruppen zu sammeln und ihnen Vortr\u00e4ge zu halten \u2013 so entstand unser Schulungsprogramm.<\/p>\n

\u2026 Manchmal nehmen unsere Ingenieure an Konferenzen teil \u2013 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.<\/p>\n

Einer unserer Ingenieure hielt auf der VeeamOn in Las Vegas einen gl\u00e4nzenden Vortrag dar\u00fcber, aus welchen Bestandteilen Veeam Backup & Replication besteht. Mit einigen Anpassungen wurde daraus der Vortrag \"Komponenten\". Zu diesem Zeitpunkt hatten wir bereits mehrere Vortr\u00e4ge \u00fcber verschiedene Teile der Funktionalit\u00e4t, aber genau dieser Vortrag \"gab den Ton an\" f\u00fcr 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.<\/p>\n

Wir begannen viel \u00fcber Virtualisierung, Microsoft-Technologien und unsere eigenen Produkte zu erz\u00e4hlen, f\u00fchrten grundlegende Schulungen f\u00fcr unsere neuen Mitarbeiter ohne IT-Erfahrung ein, in denen wir alles vermitteln, was ein Supportingenieur ben\u00f6tigen k\u00f6nnte \u2013 beginnend mit \"Hardware\" und steigernd in die Abstraktionsebenen: Disk API, Betriebssysteme, Anwendungen, Netzwerk, Virtualisierung.<\/p>\n

Nat\u00fcrlich wussten und wissen wir, dass es unm\u00f6glich oder zumindest unvern\u00fcnftig sein wird, mit Schulungen das gesamte Spektrum der Technologien, die wir verwenden, abzudecken. Um alle Funktionen eines Produkts zu vermitteln, ben\u00f6tigt man bereits jetzt mehrere Monate, und das Produkt selbst steht nicht still, st\u00e4ndig kommt etwas Neues hinzu. Dar\u00fcber hinaus k\u00f6nnen nur Vortr\u00e4ge, wie sie sind, nicht alles bieten, was ein zuk\u00fcnftiger Ingenieur ben\u00f6tigt.<\/p>\n

Was gibt es also dar\u00fcber hinaus?<\/h3>\n

\nIch sage gerne, dass bei uns das Pareto-Prinzip gilt: Mit unseren Schulungen vermitteln wir etwa 20 % dessen, was ein erfolgreicher Ingenieur ben\u00f6tigt, und 80 % bleiben in seiner Verantwortung \u2013 das Lesen von Handb\u00fcchern, die Arbeit im Labor, das L\u00f6sen von Test- und Produktionsanfragen usw.<\/p>\n

20 % \u2013 Schulungen \u2013 sind tats\u00e4chlich fast 100 % theoretischer Basis, aber nur mit Theorie erreicht man nicht alles \u2013 das klassische Schema Wissen-F\u00e4higkeiten-Kompetenzen funktioniert. Wir k\u00f6nnen Wissen vermitteln, aber F\u00e4higkeiten zu entwickeln und daraus Kompetenzen zu machen, ist eine ganz andere Herausforderung.<\/p>\n

Genau deshalb kann man sehr schnell sehen, wie unsere anf\u00e4nglichen theoretischen Vorlesungen durch andere Aspekte erg\u00e4nzt wurden, und nun sieht das Gesamtschema so aus:<\/p>\n