Anforderungsmanagement ist kein Spezialistenproblem

Warum zwei Personen nicht reichen

Anforderungen sind das einzige Dokument im gesamten Entwicklungsprozess, auf das sich alle verlassen. Entwickler bauen, was darin steht. Tester prüfen, ob es stimmt. Projektleiter berichten auf Basis davon. Und trotzdem pflegen sie in den meisten Unternehmen nur zwei oder drei Personen aktiv.

Das klingt nach Effizienz. Es ist das Gegenteil.

Wenn zwei Requirements Engineers das Wissen über alle laufenden Anforderungen tragen, entsteht ein Flaschenhals. Jede Rückfrage geht über sie. Jede Klärung blockiert sie. Und wenn eine von beiden das Unternehmen verlässt, ist die Hälfte des Anforderungswissens weg. Nicht in einem System, sondern in einem Kopf, der jetzt woanders ist.

Anforderungen betreffen mehr Rollen als gedacht

Wer schreibt Anforderungen? Auf den ersten Blick: der Requirements Engineer, der Business Analyst, vielleicht der Product Owner.

Wer arbeitet täglich damit? Eine andere Liste.

Der Kundenbetreuer, der weiß was der Fachbereich wirklich braucht. Der Entwickler, der eine Anforderung interpretieren muss, bevor er anfängt zu bauen. Der Tester, der prüft ob die Umsetzung dem entspricht was ursprünglich beschlossen wurde. Der IT-Architekt, der technische Rahmenbedingungen einbringt. Der Projektleiter, der dem Vorstand nächsten Dienstag erklären muss, warum das Feature noch nicht fertig ist.

Alle diese Rollen treffen täglich Entscheidungen auf Basis von Anforderungen. Und die meisten von ihnen haben keinen strukturierten Zugang dazu.

Das Ergebnis: Jeder arbeitet mit seiner eigenen Version der Wahrheit. E-Mails aus dem Vormonat. Notizen aus Meetings, die niemand sonst kennt. Annahmen, die nie schriftlich standen. Und irgendwo dazwischen entsteht das Feature, das am Ende nicht das ist, was der Fachbereich gemeint hat.

Das eigentliche Problem: Zugang, nicht Kapazität

Anforderungsmanagement skaliert nicht, weil zu wenige Leute es machen. Es skaliert nicht, weil zu wenige Leute wirklich damit arbeiten können.

Ein Anforderungssystem, das nur für Requirements Engineers zugänglich ist, löst das Problem nicht. Es verlagert es. Das Wissen steckt jetzt in einem Tool statt in E-Mails. Aber es steckt immer noch bei zwei Personen.

Was wirklich hilft: eine Arbeitsweise, bei der jede Rolle das sieht, was sie braucht. Der Entwickler sieht die Anforderung mit den richtigen Akzeptanzkriterien, bevor er anfängt. Der Tester sieht was ursprünglich vereinbart war, bevor er prüft. Der Projektleiter sieht den Status ohne manuell aggregieren zu müssen.

Das bedeutet nicht, dass alle alles bearbeiten. Es bedeutet, dass niemand auf eine Person warten muss, um die Information zu bekommen, die er für seine Arbeit braucht.

‍

Was das für die Einführung bedeutet

Wer ein Anforderungssystem einführt und nur die Requirements Engineers onboarded, hat den schwersten Teil noch vor sich. Die Akzeptanz entsteht nicht durch das Tool. Sie entsteht dadurch, dass die Menschen, die täglich damit arbeiten sollen, von Anfang an eingebunden sind.

Ein Pilot mit einem Team - vier bis acht Wochen, ein Projekt, klare Erfolgskriterien - zeigt schneller als jede Präsentation, ob das System im Alltag funktioniert. Nicht als Beweis für den Vorstand. Als echte Grundlage für die Entscheidung, wie breit ausgerollt wird.

Was jetzt

Anforderungsmanagement ist keine Frage von zwei Lizenzen oder zwanzig. Es ist eine Frage davon, ob die richtigen Menschen zur richtigen Zeit Zugang zu den richtigen Informationen haben.

Wenn das heute nicht funktioniert - nicht wegen fehlender Tools, sondern wegen fehlender Struktur - ist das der Ausgangspunkt für ein Gespräch.