Dokumentations- und Zeitfensterfallen

Neben der Dokumentationsfalle habe ich in meiner Zeit als Software-Entwickler noch eine weitere Falle ausgemacht: die Zeitfensterfalle. Die Idee des Zeitfensters ist einfach: Um die Produktivität zu steigern, soll in Ruhe und störungsfrei gearbeitet werden können. Deshalb wird verabredet, dass Meetings und Telefonate nur am Vormittag abzuhalten sind und auch E-Mails nur in diesem Zeitraum beantwortet werden sollen. Damit haben alle am Nachmittag die Möglichkeit, in Ruhe an den eigenen Aufgaben zu arbeiten, ohne dass das Telefon klingelt, man auf den Posteingang achten muss oder gar jemand persönlich im Büro vorbeischaut.

Mit etwas Pech hat man sogar darauf geachtet, die Zeitfenstervorgabe auch auf das Ticket-System auszudehnen. Die Folgen sind katastrophal, denn im Zweifelsfall ergibt sich in den ersten fünf Minuten nach der Mittagspause eine wichtige Frage, die geklärt werden müsste, um vernünftig weiterarbeiten zu können.

Eine Nachfrage ist aber offiziell erst am nächsten Vormittag möglich, also wird mit der wahrscheinlichsten Vermutung weitergearbeitet. Das hat zur Folge, dass die Arbeit von fünf Stunden für die Tonne sein könnte, weil die Annahme schlichtweg falsch war. Nach ein paar Bekanntschaften mit der Tonne, wird an den Nachmittagen dann mitunter doch lieber erst mal die Festplatte aufgeräumt oder es werden die Bookmarks sortiert.

Erfahrene Entwickler wissen das, können sich aber nicht immer dagegen wehren. Denn um trotzdem erfolgreich eine Kommunikation aufzubauen, muss die andere Seite mitunter entgegen der Arbeitsanweisungen handeln. Sollte das unter der Hand passieren, führt das zusätzlich zum Problem der stillen Post: Man will ja nicht auch noch dokumentieren, dass man sich nicht an die Anordnungen gehalten hat.

Das landet an der Wand

Die Projekte, in denen einer oder in wenigen Fällen auch mehrere dieser Fehler passieren, landen gerne an der Wand. Dem Startup geht das Geld aus und die nächste Finanzierungsrunde scheitert. Oder der Mutterkonzern der Softwarefirma hat irgendwann genug, macht den Laden zu und kauft stattdessen ein Produkt von der Stange. Kleinere Projekte braucht man plötzlich nicht mehr, sie werden eingestellt, weil es aufwendiger ist und mehr Geld kostet, das Tool weiterzuentwickeln, als es nicht zu haben.

Manch ein Projekt wird aber auch mit Gewalt durch die Wand gedrückt und endet tatsächlich mehr oder weniger erfolgreich - wenn auch vielleicht in einem anderen Umfang als ursprünglich geplant. Oder wie es ein freiberuflicher Kollege in einem Kaffeepausengespräch einmal resümierte: "Wir sind in der Wand eingeschlagen, hatten aber genug Schwung, um durchzubrechen. Wesentliche Teile sind zwar dabei an der Wand hängen geblieben und abgerissen worden, aber durch ist durch."

Besser ist: Es gleich richtig machen

Damit die Sache mit der Wand gar nicht erst passiert - egal ob mit oder ohne Durchschlag: schmerzhaft ist die Wand auf jeden Fall -, braucht es gar nicht so viel: nämlich die bereits genannten Kommunikationsfähigkeiten, auch außerhalb des eigenen Expertengebietes und über Rollengrenzen hinweg. Zur Kommunikation gehören dabei zwei Aspekte. Erstens die Frage: Wie wird richtig kommuniziert? Und zweitens das Wissen darum, was an welcher Stelle schiefgehen kann.

Im gesamten Projektteam sollten die Mitarbeiter dazu ermuntert werden, miteinander zu reden. Sie sollten Fragen frühzeitig klären, Probleme ansprechen, aber auch Lösungsmöglichkeiten.