Projektqualität sichtbar machen: von Erfahrung zu gemeinsamen Kriterien

Der Unterschied diesmal ist simpel: Die Kriterien schreiben jetzt die erfahrenen Leute aus den Fachbereichen selbst, nicht mehr eine zentrale Stelle: Engineering, Consulting, Product & Customer Experience, Projektmanagement, Data & AI. Jeder Bereich pflegt seine eigenen Checklisten und Quality Gates in einem internen Tool.

Das macht in der Praxis einen großen Unterschied. Wenn die Checkliste von jemandem kommt, der den Job seit zehn Jahren macht, erkennt das Team schnell, warum die einzelnen Punkte darin stehen. Die Fragen passen zur täglichen Arbeit, benutzen die richtige Sprache und greifen Situationen auf, die man aus echten Projekten kennt, und genau diese Nähe zur Praxis ist für die Akzeptanz entscheidend.

Zwei Begriffe werfe ich selbst ständig durcheinander, deshalb kurz zur Abgrenzung. Eine Checkliste ist bei uns eine Art laufender Gesundheitscheck fürs Projekt: über die gesamte Laufzeit immer wieder neu bewertet. Füllt man sie einmal beim Kickoff aus und dann nie wieder, hat man eine Momentaufnahme, die nach zwei Wochen nichts mehr taugt. Ein Quality Gate ist etwas anderes: ein fester Halt im Ablauf, an dem bestimmte Dinge stimmen müssen, bevor es weitergeht. Das klassische Ja oder Nein vor dem Release, und brauchbar ist so ein Gate nur, wenn es scharf geschnitten ist: Es soll für eine klare Entscheidung sorgen, aber den Ablauf nicht unnötig behindern.

Damit nicht jedes Projekt dieselbe überlange Liste vor die Nase gesetzt bekommt, steht am Anfang ein kurzer Fragebogen. Festpreis oder T&M? Neuentwicklung oder Ablösung eines Altsystems? Regulatorik im Spiel? Wie groß ist das Team? Daraus ergibt sich, welche Checklisten und Gates für dieses Projekt zählen, und nur die bekommt man dann zu sehen. Der Fragebogen nervt am Anfang ein bisschen, ist aber in ein paar Minuten durch und erspart einem später die Frage, welche Kriterien überhaupt gelten. Der Effekt davon ist größer, als man vermuten würde. Eine kurze Liste mit lauter passenden Punkten arbeitet man ab. Eine lange, bei der zwei Drittel egal sind, klappt man irgendwann innerlich zu, und dann ist sie komplett wertlos, auch das eine Drittel, das gezählt hätte. Für die Projektleitung entsteht daraus zum ersten Mal ein belastbares Bild: Statt eines vagen „läuft ganz gut“ steht da dann so etwas wie „das meiste grün, gelb bei Risiko und Schätzung“, und mit dem Satz kann man in ein Meeting gehen.

Fragen dieser Art stehen drin:

• Sind die richtigen Rollen besetzt, und ist klar, wer was entscheidet?
• Kennen wir die größten Risiken bei Umfang, Termin, Budget und Abhängigkeiten, und haben wir für die dicken einen Plan B?
• Haben alle dasselbe Bild davon, was „fertig“ beim Release heißt, Akzeptanzkriterien inklusive?
• Stehen die Schätzungen auf Kapazität, Erfahrung und Komplexität, und ziehen wir sie nach, wenn sich etwas dreht?
• Messen wir Fortschritt an belastbaren Signalen oder eigentlich nur an Betriebsamkeit?
• Sind vor dem Livegang die Freigabekriterien, der Rolloutplan und das Supportmodell wirklich bestätigt?

Das sind keine Häkchen, die man im Vorbeigehen setzt. „Kennen wir unsere größten Risiken?“ beantwortet man nicht mit einem Klick. Da muss man ehrlich hinschauen. Und steht der Punkt zur Schätzung auf Gelb, weiß man sofort, worüber im nächsten Meeting zu reden ist, statt wochenlang das Gefühl zu haben, dass etwas nicht stimmt.

Natürlich lebt so ein System davon, dass die Bewertungen nachvollziehbar sind. Eine grüne Ampel allein sagt noch gar nichts. Bei wichtigen Punkten arbeiten wir mit Belegen und klaren Kriterien, damit die Bewertung mehr ist als eine Momentaufnahme oder ein persönlicher Eindruck. Das ist wichtig, denn auf diese Bewertungen verlassen sich Menschen. Ein falsches Grün ist schlimmer als keine Bewertung. Auch diese Kriterien werden mit den Erfahrungen aus den Projekten weiter geschärft, sodass sie mit jeder Bewertungsrunde an Aussagekraft gewinnen.

KI verändert ziemlich grundlegend, wie Software entsteht. Damit verändert sich auch, worauf wir bei Qualität eigentlich schauen müssen. Sie unterstützt inzwischen bei vielen Aufgaben in der Softwareentwicklung, etwa beim Schreiben von Code und Tests, bei Reviews oder auch bei Architekturüberlegungen. Was uns beschäftigt, ist die Frage, ob das Ergebnis fachlich stimmt. Denn Tempo hat uns ehrlich gesagt nie gefehlt, und inzwischen kostet es fast nichts mehr. Urteilsvermögen aber schon.

Bei generiertem Code gibt es eine bekannte Schwierigkeit: Er kann auf den ersten Blick sehr überzeugend wirken. Er kompiliert, die Tests sind grün, und die Fachlichkeit liegt trotzdem daneben. Das ist das Unangenehme daran. Wenn eine Maschine baut und die nächste Maschine prüft, haben am Ende womöglich beide denselben blinden Fleck. Irgendwo muss ein Mensch draufschauen und die Fragen stellen, die kein grüner Testlauf beantwortet: Passt das überhaupt zu unserem Fachmodell? Haben wir die richtigen Risiken im Blick? Und manchmal ist die banalste Frage die wichtigste: Ist das wirklich fertig? Die KI kann auf jede dieser Fragen eine Antwort vorschlagen. Verantworten kann sie die Antwort nicht. Ob etwas für diese Fachlichkeit, diesen Kunden und dieses Projekt richtig ist, bleibt eine Entscheidung von Menschen. Und solche Urteile lassen sich nur über viele Projekte hinweg fällen, wenn sie sich an gemeinsamen Kriterien festmachen können. Je mehr die KI vom Bauen übernimmt, desto mehr zählt das Entscheiden, und desto stärker müssen wir Qualität messbar und nachvollziehbar machen, statt sie einfach vorauszusetzen.

Für die Entwicklung selbst verändert das die Rolle, die Qualität im Alltag spielt. Sie ist nicht länger der Stempel, den am Schluss jemand von außen draufdrückt. Die Kriterien stammen ja von erfahrenen Entwicklerinnen und Entwicklern, also sind sie in der Sprache formuliert, in der die Teams ohnehin denken, und weil sie von Tag eins an sichtbar sind, kann man früh nachsteuern, statt zwei Tage vor dem Release die böse Überraschung zu erleben. Das ist übrigens auch der Grund, warum ich lieber von Quality Engineering rede als vom Testen. Testen ist ein Teil davon. Gemeint ist die Grundlage, auf der gute Software aufgebaut ist. Erst recht, wenn ein wachsender Teil davon gar nicht mehr von Hand geschrieben wird.

Nach den ersten Monaten ist mir vor allem eines klar geworden: Sobald Qualität sichtbar wird, verändern sich die Gespräche. Wir kommen schneller zu den Punkten, die wirklich angegangen werden müssen. Fertig werden diese Kriterien wahrscheinlich nie. Dafür verändert sich die Praxis gerade zu schnell. Also müssen wir sie regelmäßig wieder anfassen. Für mich liegt genau darin der eigentliche Wert des Ansatzes: Qualität wird sichtbar und Teams können viel konkreter darüber sprechen, was gut läuft und wo noch etwas fehlt. In diesem Gespräch findet die eigentliche Qualitätsarbeit statt: Menschen, die mit gemeinsamen Kriterien in der Hand entscheiden, was richtig ist. Kein Werkzeug nimmt uns diese Entscheidung ab, und ich möchte auch nicht, dass es das tut. Falls ihr etwas Ähnliches versucht habt, erzählt mir davon. Das interessiert mich ehrlich.

Die in diesem Beitrag geäußerten Ansichten sind meine persönlichen und geben nicht notwendigerweise die Position meines Arbeitgebers wieder.