Zwischen Fachbereich, Entwicklung und Test entsteht die eigentliche Projektarbeit

In IT-Projekten haben Fachbereich, Entwicklung und Test oft alle recht – und trotzdem entsteht genau da das Problem.

Die meisten Konflikte in IT-Projekten sind keine Streitigkeiten. Der Fachbereich beschreibt eine Anforderung so, wie sie fachlich Sinn ergibt. Die Entwicklung setzt um, was technisch machbar und eindeutig ist. Das Testteam prüft, ob sich das Ergebnis überhaupt zuverlässig testen lässt. Jede Seite handelt konsequent nach ihrer eigenen Logik – und trotzdem passt am Ende nicht alles zusammen.

Das eigentliche Problem liegt selten in einem der drei Bereiche. Es liegt dazwischen.

Dieselbe Anforderung, drei verschiedene Realitäten

Eine Anforderung wie „Der Kunde soll den Projektstatus jederzeit einsehen können“ ist fachlich klar. Für die Entwicklung stellt sich sofort die Frage: Heißt „jederzeit“ in Echtzeit – oder reicht ein täglicher Abgleich? Für das Testteam stellt sich eine andere Frage: Wie lässt sich „jederzeit“ überhaupt zuverlässig testen, wenn nicht klar ist, unter welchen Bedingungen sich der Status ändert?

Fachlich ist an der Anforderung nichts falsch. Sie ist nur noch nicht konkret genug, um technisch eindeutig umgesetzt und anschließend sauber geprüft zu werden. Genau an dieser Stelle entstehen die meisten Reibungsverluste in Projekten – nicht, weil jemand schlecht arbeitet, sondern weil eine fachliche Idee erst noch in etwas Entwickelbares und Testbares übersetzt werden muss.

Jede Seite braucht etwas anderes

Die Entwicklung braucht vor allem Klarheit: eindeutige Prioritäten, getroffene Entscheidungen, eine Anforderung, die nicht drei verschiedene Interpretationen zulässt. Ohne das entsteht Software, die zwar funktioniert, aber nicht das tut, was sich der Fachbereich eigentlich vorgestellt hat.

Das Testteam braucht etwas anderes: eine stabile Grundlage, eine Anforderung, die sich in überprüfbare Kriterien übersetzen lässt, und genug Zeit, um das auch tatsächlich zu tun. Wird eine Anforderung erst kurz vor dem Test präzisiert, bleibt für echtes Testen oft nur noch die Zeit für das Nötigste.

Der Fachbereich wiederum braucht die Sicherheit, dass eine fachliche Idee nicht auf dem Weg durch Entwicklung und Test verloren geht oder in etwas anderes verwandelt wird, als ursprünglich gemeint war.

Alle drei Bedürfnisse sind berechtigt.

Das Problem entsteht, wenn niemand zwischen diesen Perspektiven übersetzt.

Übersetzen statt Schuld zuweisen

Wenn ein Projekt an dieser Schnittstelle ins Stocken gerät, ist die naheliegendste Reaktion, nach einer verantwortlichen Seite zu suchen: War die Anforderung schlecht beschrieben? Hat die Entwicklung zu viel hineininterpretiert? Hätte das Testteam früher nachfragen müssen?

Diese Fragen führen selten weiter, weil an der Schnittstelle meist jede Seite für sich genommen richtig gehandelt hat. Hilfreicher ist eine andere Frage: Was muss passieren, damit eine fachliche Idee, eine technische Umsetzung und ein Testkriterium wieder dasselbe meinen?

Das ist eine Übersetzungsaufgabe, keine Schiedsrichter-Aufgabe. Es geht nicht darum, wer recht hat, sondern darum, die drei Perspektiven so zusammenzubringen, dass am Ende alle über dieselbe Sache sprechen.

Was das im Projektalltag bedeutet

Konkret heißt das für uns: Anforderungen nicht nur fachlich abnehmen, sondern gemeinsam mit Entwicklung und Test auf Eindeutigkeit und Testbarkeit prüfen, bevor sie in die Umsetzung gehen. Offene Interpretationsspielräume früh sichtbar machen, statt sie unausgesprochen mitlaufen zu lassen. Und wenn sich Fachbereich, Entwicklung und Test uneinig sind, das nicht als Konflikt behandeln, sondern als Signal, dass eine Anforderung noch übersetzt werden muss.

Das bedeutet auch, alle drei Perspektiven an einen Tisch zu holen, statt nur zwischen ihnen hin- und herzutragen. Vieles klärt sich in einem einzigen gemeinsamen Gespräch schneller als über mehrere Runden getrennter Abstimmungen.

Fazit

Die eigentliche Projektarbeit passiert oft nicht dort, wo einzelne Aufgaben erledigt werden. Sie passiert dort, wo fachliche Anforderungen, technische Umsetzung und Testbarkeit zusammenkommen müssen.

Gute Projektsteuerung sorgt genau dort für Übersetzung – nicht, um zu entscheiden, wer recht hat, sondern damit Fachbereich, Entwicklung und Test am Ende wieder dasselbe meinen.

Werden in Ihren Projekten Anforderungen zwischen Fachbereich, Entwicklung und Test immer wieder unterschiedlich verstanden? In einem unverbindlichen Austausch schauen wir gemeinsam darauf, wo die Übersetzung fehlt.

Kontaktieren Sie uns unter: office@gruener-it.at

Das ist der vierte Teil unserer PM-Serie über die Dinge, die im Projektalltag wirklich den Unterschied machen. Im nächsten Teil geht es darum, warum Testmanagement nicht erst am Projektende beginnen sollte.