Was läuft in den IT-Abteilungen der großen Unternehmen? Ganz klar ist, dass zu viel Arbeit auf zu wenige Köpfe verteilt wurde. Stress und Hektik wohin das Auge schaut. Ein Meeting jagt das nächste. Die Arbeit stapelt, nein, sie queuet sich – zum Denken bleibt keine Zeit; machen, machen, machen ist angesagt und schließlich geht es erschöpft nach Hause. Der Fachkräftemangel, die internen Anforderungen, die gesetzlichen Anforderungen, die immer neuen IT-Lösungen und die ganzen neuen Medien treiben den ITler durch den Wald auf der Jagd nach der Kokosnuss, die er niemals finden wird. Ist es wirklich so? Ist es wirklich so schlimm? Und falls ja, warum ist das so?

Eine analytische Beobachtung

Da haben wir den IT-Mitarbeitenden, nicht einen, sondern viele, aneinandergereiht und thematisch aufgeteilt. Was Henry Ford am Fließband begonnen hat, wird nach jahrzehntelanger Optimierung fortgeführt. Er wäre stolz auf die IT. Es gibt Leute für das Frontend, das Backend, den Webshop, das Netzwerk, die Applikation, die Middleware, die DMZ, fürs Dispatchen, fürs Queuen, fürs zentrale Verwalten, für die Objekte, die Technik, die Datenbank, das Projekt, den Support, den Betrieb, das Personal, den Kunden, den Lieferanten, die Produkte, die Bestellungen und so weiter und so weiter. So arbeiten sie da, in ihrem Raum, versorgt mit ihrer „Aufgabe“, ihren Zielen und manchmal auch mit Kontakt zu anderen Menschen.

Da ist er und ist glücklich. Er befindet sich in seiner „Happy Bubble“, seinem Wohlfühlbereich, einem über die Arbeitsplatzbeschreibung oder einige Zurufe definiertem Raum, der disziplinarisch relevant, kalkulierbar und absolut sicher ist. Neben dem Mitarbeitenden befindet sich darin die direkt zuordenbare Arbeit. Soll er JavaScript programmieren und es gibt eine Aufgabe „Programmiere JavaScript“ und diese wird ihm über das Ticketsystem zugewiesen, schnappt er diese mit Freude, da er weiß, wenn er es nicht täte, könnte er dafür bestraft werden. Vielleicht macht es ihm auch Spaß, dieses Ticket zu bearbeiten. Man weiß es nicht.

Sein eigentlicher Aktionsradius ist aber noch viel größer, ist er doch eingehüllt von einer zweiten Blase, die jegliche Art von Arbeitspaketen beinhaltet, deren Zuordenbarkeit zum Mitarbeitenden erst aus dem Kontext der Aufgabe oder einem Gespräch darüber hervorgeht. Das Betreten dieses Raumes wird möglichst vermieden; lauern dort doch ggf. unvorhersehbare Herausforderungen, die der Lebensplanung in die Quere kommen könnten. Im schlimmsten Fall könnte sich bei genauem Hinterfragen einer Aufgabenstellung, der Analyse einer Fehlermeldung oder einer Anforderung, ergeben, dass er selbst verantwortlich wäre und Hand anlegen müsste.

Der gesamte, große Rest des arbeitstäglichen Lebensraumes ist nicht näher spezifiziert, enthält jedoch alle Arbeiten, die im Rahmen der bekannten oder unbekannten Fertigkeiten des Mitarbeiters liegen und somit – zumindest theoretisch – von ihm erledigt werden könnten.

Basierend auf diesem Baustein des fröhlichen Schaffens werden große Abteilungen aufgebaut, hierarchisch strukturiert und umfassend dokumentiert.

Da können die Blasen ganz unterschiedlich groß und der Kommunikationswille zu Kollegen in den anderen Räumen ganz unterschiedlich gerichtet und stark sein. Einige schweben in der Raummitte, um möglichst gar keinen Kontakt aufzunehmen.

Aber zurück zur anfänglichen Frage: Woher kommen Stress und Überlastung?

Wird nun versucht, dieses bunte Potpourri mit Arbeitspaketen zu versorgen, benötigen wir erstmal jemanden, der die Arbeitspakete erstellt. Eine anstehende Aufgabe (ich nenne sie „Anforderung“) wird analysiert, spezifiziert und unterteilt. Gehen wir davon aus, dass die Anforderung system- und technologieübergreifend ist, benötigen wir jemanden, der system- und technologieübergreifend denkt.

Das ist kein Supermann und auch kein Teufelskerl, es ist schlicht jemand, der bereit ist, sein gesamtes Potential zu nutzen, um seine Aufgaben zu bewältigen. Dieser Mitarbeiter – ich nenne ihn „Anforderungsmanager“ – erzeugt die einzelnen Arbeitspakete in fachlich fassbarer und technologisch abgegrenzter Größe, testbar und überschneidungsfrei. Mit oder ohne gewissenhaft durchgeführter Qualitätssicherung (wer sollte diese eigentlich durchführen?) gelangen diese Pakete nun in die Verteilung. Der Verteiler („Chef:in“, „Projektleiter:in“, „Vortänzer:in“) sieht nun zu, dass die Arbeitspakete genau so auf die Mitarbeitenden verteilt werden, dass sie im Wohlfühlbereich eines jeden zu liegen kommen.

Nun beginnt das Arbeiten, die Phasen oder Sprints, in denen die Finger und manchmal auch die Köpfe qualmen, eine als eigentliche Wertschöpfung angesehene Zeitspanne, in der so etwas wie eine arbeitssame Ruhe aufkommen möchte. Es werden Schnittstellen spezifiziert und entwickelt, es werden Softwarepakete installiert und „zum Rennen“ gebracht, Masken designt, verworfen und neugebaut. Kurzum, jeder arbeitet an seiner Aufgabe was das Zeug hält.

Noch vor Ablauf dieser Arbeitsphasen kehrt der Verteiler („Chef:in“, „Projektleiter:in“, „Vortänzer:in“) seine Perspektive auf die Dinge um: aus den Ergebnissen der Arbeitspakete synthetisierend ist er versucht, ein Bild von der Gesamterfüllung der gestellten Anforderung zu erschaffen. Das Resultat ist ernüchternd, sein Urteil niederschmetternd: Es passt Nichts zusammen. Und nun? Nun ist der Stress da!

Wo liegt der Fehler, wer zum Geier trägt die Verantwortung und warum muss das denn immer wieder passieren? Was ist nun zu tun? Melden und gegebenenfalls das gesamte Unterfangen aufs Spiel setzen oder selbst Hand anlegen? Selbst ist der Mann! Es ist noch ein wenig Zeit, also ran an die Themen: No-Fit-Big-Gap-Analyse, Anforderungspriorisierung, Ressourcenaufbau. Unwichtiges wird gestrichen oder verschoben, Wichtiges muss funktionieren oder den Anschein der Testbarkeit wahren. Der Verteiler („Chef:in“, „Projektleiter:in“, „Vortänzer:in“) läuft zur Hochform auf, das monatelange Management-By-Excel gerät in Vergessenheit, acht Ärmel werden gleichzeitig hochgekrempelt und wie ein Krake legt er sich über die organisatorische Landschaft.

Irgendwo hier müssen die Sachen nicht funktioniert haben, die Leute nicht miteinander geredet; irgendwo hier ist die Transparenz der Aufgabenstellung verloren gegangen, in irgendeiner Ecke muss die Vorstellung der Lösung liegengeblieben und ignoriert worden sein. In mühsamer Kleinarbeit wird nun jeder Ergebnistyp (-> Produkt) auf Fehler und Kompatibilität untersucht. Alle Mitarbeiter werden kontaktiert, ein Meeting jagt das nächste und die Aufarbeitung sowie die Neuerstellung, Reparatur und Verbesserung werden vorangetrieben. Der Verteiler kann das!

Schließlich – und niemand weiß so genau wie – wurde es vollbracht: das nächste Tor (Stufe, Phase, Quality-Gate) wird durchschritten. Nicht ohne Stolz stehen die Projektbeteiligten zusammen und sind sich einig, dass sie jetzt, nach der harten Phase, der Ruhe bedürfen. Die eigentliche Arbeit ist getan, nun kommen nur noch ein paar Tests, die nicht ganz so relevanten Kommentare der Fachseiten und etwas Bugfixing. Das können ja auch die Rookies tun, die erfahrenen (und teuren) Leute können erstmal raus, die geleisteten Überstunden haben in der Tat zu viel gekostet. Ordnung und friedliche Koexistenz werden wieder hergestellt, die Arme des Kraken eingefahren und die Bühne öffnet sich für den Tester („Testmanager:in“, „Qualitätssicherer:in“, „Auftraggeber:in“).

Der Tester liest viel und gerne, er hat manches Mal über Methoden des Testens gelesen und diese auch angewendet. Er liest auch die Konzeptionen zu den Anforderungen und am allerliebsten Test- und Berechtigungskonzepte, sofern diese vorhanden sind. Er geht präzise vor und verfährt genau nach der Beschreibung, nimmt sich die „Anleitung“ und arbeitet sie gewissenhaft durch. Er leitet andere Mitarbeitende an, die ihn unterstützen, damit jede zu testende Funktionalität abgedeckt wird. Mit großer Geschwindigkeit werden fünfzehn Prozent Testabdeckung erreicht, Anmeldung und Datenerfassung eines jeden Testfalls funktionieren einwandfrei. Alles geht prima los, doch dann kommt der Aufschrei:

So sollte das doch alles nicht funktionieren und so aussehen schon gar nicht!

to be continued …

No responses yet

Schreibe einen Kommentar

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