Blog

Gut getestet ist halb geschult - Verbesserungspotenziale für IT-Anwenderschulungen

Gut getestet ist halb geschult

Verbesserungspotenziale für IT-Anwenderschulungen

Das klassische Vorgehen

 

Jeder, der schon einmal in (agilen) IT-Projekten Anwenderschulungen vorbereitet und durchgeführt hat, kennt vermutlich die Herausforderung: Der Zeit-/Projektplan gibt den Startschuss zur Schulungsvorbereitung und das realistisch-knapp bemessene Zeitkontingent für folgende Aufgaben beginnt zu schmelzen:

 

  • Einarbeitung (Lesen von Ausschreibung, Dokumentation, Lasten-/Pflichtenheft, Styleguide)
  • Übergabe (Der Projektleiter oder Lead-Entwickler beantwortet wie Templates und Funktionen des z.B. CMS-Systems funktionieren)
  • Agenda ausgestalten und Zeitplan erstellen
  • Übungen erstellen und Test-Content (Text/Bild) vorbereiten
  • Standard-Präsentation durch Projekt-Spezifika ergänzen
  • Handout erarbeiten

 

 

Die größte Hürde

 

Auch wenn man die 300ste Schulung vorbereitet, hat der Trainer eines nicht selbst in der Hand: Den Fertigstellungsgrad des Projekts (zu Beginn der Schulungsvorbereitung). So kommt es vor, dass zum Schulungstermin noch nicht alle Features fertiggestellt wurden. Trotzdem muss der Trainer die Schulung rechtzeitig vor dem GoLive Termin durchführen, damit in Folge die Schulungsteilnehmer ihre Inhalte noch pünktlich einpflegen können.

 

Die Herausforderung: Die Schulungsvorbereitung beginnt zum geplanten Zeitpunkt. Der Trainer muss auf Basis des ihm für die Schulung bereitgestellten Entwicklungsstands schulen und ggf. noch bestehende Lücken durch seine Erfahrung kompensieren.

 

Die Lösung: Der Trainer wird in den Stand der Entwicklung und der Tests involviert. Neben den zahlreichen o.g. Schulungsvorbereitungstasks lernt er so das Projekt detailliert kennen. So trägt der Trainer – aus Projektsicht weitgehend kostenneutral – zur Qualität und Fertigstellung des Systems bei. Das Wichtigste für den Trainer ist dabei, dass er am Schulungstag auf Basis einer gut abgestimmten und ausgearbeiteten Agenda schulen kann – zumindest das Projekt kennt er jetzt fast auswendig und wird so auch projektspezifische Fragen der Schulungsteilnehmer gut beantworten können.

 

 

Von der Not zur Tugend

 

Es soll schon Entwicklungsprojekte gegeben haben, in denen alle verfügbaren Mitarbeiter in Voll-/Überlast waren und der Entwicklungsfortschritt dem Testfortkommen (temporär) vorgezogen wurde. Gleichzeitig war der im späteren Projektverlauf für die Schulungen vorgesehene Trainer ohne aktuellen Schulungsauftrag und konnte so für die Abarbeitung der geplanten Testfälle eingesetzt werden. Aus der „Not“ geboren entstand so eine in vielerlei Hinsicht nutzbringende Situation.

 

 

Alle Seiten profitieren direkt:

 

Aus Sicht des Trainers:

Durch den Einsatz als Tester ergibt sich ein enormer Mehrwert und Zeitgewinn für die nachgelagerte Vorbereitung und Durchführung der Schulung. Der Trainer bearbeitet die Testfälle zielgerichtet aus dem Blickwinkel des Endanwenders/Redakteurs und tut dies intrinsisch motiviert, um möglichst viele Fehler bis zum Zeitpunkt der Schulungsvorbereitung (bzw. spätestens zur Schulungsdurchführung) aus dem Weg zu räumen. Der Trainer profitiert dabei doppelt: Zum einen erhält er einen recht vollständigen Überblick über den gesamten Funktionsumfang des Projekts, zum anderen arbeitet er sich wirtschaftlich im Rahmen des Testbudgets in das Projekt ein, ohne dabei bereits die für Konzeption und Vorbereitung der Schulungen eingeplante Zeit zu verbrauchen.

 

Aus der Sicht des Kunden:

Fehler, werden frühzeitig(er) im realen Anwenderszenario erkannt und können rechtzeitig beseitigt werden. Auch die Projekt- und Schulungsqualität steigt messbar, ohne dass dadurch zusätzliche Kosten fürs Testen oder die Schulungsmaßnahmen entstehen. Und die Qualitätssicherungsmaßnahmen enden nicht vor bzw. mit der Schulung, sondern können ohne Reibungsverluste durch alle Projektphasen hinweg von einem pädagogisch ausgebildeten Trainer begleitet werden. Die daraus entstehenden Erkenntnisse kann der Trainer direkt an die Endanwender des Kunden weitergeben – und das bei gleichzeitig gut funktionierenden Schulungsprojekten.

Dreifacher Nutzen:

 

1. Höhere Qualität des Gesamtprojekts durch praktisch ausgerichtetes Testen

2. Schnellere Fehlerbehebung möglich, da Fehler im Anwenderszenario früher erkannt werden

3. Bessere und Anwenderbezogene Schulungen, da der Trainer tiefgehendes Anwenderwissen mitbringt

 

Verankerung im Projektlebenszyklus

 

Das hört sich ja alles recht logisch und schlüssig an, man könnte auch sagen, das ist eher trivial als die große Effizienz-Offenbarung. Was hindert Euch denn daran, das immer so zu machen? Ja, eigentlich nix. Trotzdem kann ich die Projekte, in denen es – während meiner 10-jährigen Berufstätigkeit als IT-Trainer – so gemacht wurde, an einer Hand abzählen. Und diejenigen, in denen es bewusst so geplant wurde, an einem Finger. 😉

 

Folgende Antworten/Ausreden fallen mir ad hoc ein:

 

  • Die Trainerressourcen sind zu knapp: Alle Trainer sind mit Schulungsvorbereitung, -durchführung und -nachbereitung bereits voll ausgelastet.
  • Die Trainer sind „zu teuer“, um manuell lange Listen von Testfällen abzuarbeiten.
  • Die eher pädagogisch als informatisch ausgebildeten Trainer können Softwaresysteme gar nicht adäquat/effizient/wirksam/erfolgreich/wirtschaftlich testen.

 

Welche Gründe könnte es noch dafür geben? Habt ihr ggf. eigene Ideen und Erfahrungen mit diesem Thema? Schreibt es mir doch unten in den Kommentaren!

 

 

Geht da noch mehr?

 

Wäre es nicht vielleicht sogar sinnvoll den Trainer noch früher als zu den ersten Anwendertests einzubinden und ihn z.B. an der Konzeption der Testfälle zu beteiligen? Noch einen Schritt weiter gedacht: Könnte der Trainer als natürliche Schnittstelle zwischen Anwendungsentwicklung und Endkunde nicht sogar die Gesamt-Verantwortung für die (funktionale) Qualität des Projekts übernehmen? Eine Einbindung des Trainers in das Projekt – auch über die Initialschulungen hinaus  – hätte aus meiner Sicht enormes Potential: Der Trainer testet z.B. die in weiteren Releases veränderten sowie neu hinzugekommenen Funktionen und kann dabei:

 

  • die bestehende Agenda, Übungen und Schulungsunterlagen aktualisieren,
  • neue Themen clustern und daraus Update-Schulungen mit Advanced-Themen konzipieren,
  • Screencast-Tutorials für ergänzendes, asynchrones Lernen nach den Initialschulungen erstellen.

 

Zu guter Letzt versteht sich der Trainer ja nicht nur als Bindeglied zwischen der technischen Softwareentwicklung und dem Endanwender. Er enabled auch den Vertrieb und kann kompetenztechnisch sogar Aufgaben im 3rd-Level-Support übernehmen.

 

Kann man nun behaupten, dass in der Softwareentwicklung Anwendertests und Schulungen im selben Spannungsverhältnis wie die Henne und das Ei stehen? Vielleicht nicht ganz und im selben Maße – aber das ist ja auch eigentlich nicht entscheidend. Mein Ziel ist nun auf jeden Fall mich in allen künftigen Projekten, in denen ich als Trainer eingeplant bin, auch an den Testaktivitäten zu beteiligen! Und an dieser Stelle hör’ ich mal auf zu schreiben und gehe zu unserem Quality Manager, um ihm von meinem Traum zu erzählen…



Keine Kommentare

Hinterlassen Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.