Drei Monate nach dem Kickoff sitzt dein Team im Review, und drei Leute erinnern sich an drei verschiedene Lesarten derselben Anforderung. Niemand lügt. Jeder hat recht — gemessen an dem Stand, den er zuletzt gesehen hat.
Du kennst die Stille danach. Drei Sekunden, in denen niemand etwas sagt, weil jeder gerade merkt, dass er von etwas anderem ausgegangen ist. Dann redet jemand weiter, und der Termin läuft über den Riss hinweg.
Der eine hat das Workshop-Protokoll im Kopf, handschriftlich, mit einem Pfeil an den Rand gekritzelt. Die zweite hat die Excel-Tabelle offen, Spalte F, gefiltert auf „offen“. Der dritte liest ein Jira-Ticket, das im Mai angelegt und im Juni umformuliert wurde, weil der Kunde am Telefon etwas anderes gesagt hatte. Drei Quellen, drei Wahrheiten. Die einzige Instanz, die sie zusammenführen könnte, ist das Gedächtnis der Anwesenden.
So scheitern Anforderungen. Nicht laut, nicht in einem Eskalationstermin; sie scheitern leise, an genau der Stelle, an der niemand mehr sagen kann, welcher Satz gerade gilt.
Anforderungen sterben nicht am Anfang
Am Anfang ist die Lage übersichtlich. Ein Kunde beschreibt, was er braucht, jemand schreibt es auf, alle nicken. Kritisch wird es bei der ersten Weitergabe. Aus dem Protokoll wird eine Zeile in einer Liste. Aus der Liste wird ein Ticket. Aus dem Ticket wird ein Absatz in einer Mail an das Team, das gerade Kapazität hat. Jede dieser Weitergaben ist eine Kopie — und jede Kopie ist eine Abzweigung, die niemand bemerkt.
Kopien sind harmlos, solange sie tot sind. Gefährlich werden sie, wenn sie weiterleben: wenn jemand die Tabelle anpasst, weil der Kunde im Jour fixe eine Zahl korrigiert hat, das Ticket aber unverändert stehen bleibt. Ab diesem Moment gibt es zwei Anforderungen, die dieselbe Nummer tragen und Verschiedenes verlangen. Auffallen wird das frühestens im Test. Wahrscheinlich erst beim Kunden.
Rechne kurz mit. Fünf Projekte, je vierzig Anforderungen, drei Ablagen: Tabelle, Ticketsystem, Postfach. Das sind sechshundert Orte, an denen ein Satz stehen kann, und keine einzige Stelle, die sagt, welcher davon gilt. Kein Team ist schlampig, weil es diese Lage nicht im Griff hat. Es ist nur menschlich.
Der Preis dafür taucht in keiner Rechnung auf. Niemand schreibt „zweimal gebaut“ in eine Nachkalkulation. Er versteckt sich in Nachfragen, in einem Sprint, der neu geplant wird, in einem Kundentermin, der mit einer Klärung beginnt statt mit einer Demo. Genau deshalb bleibt die Lage so lange bestehen: Was keine Zahl hat, wird nicht abgestellt.
Wer diesen Preis zahlt, steht ebenfalls nirgends. Es ist die Entwicklerin, die zum dritten Mal nachfragt, was gemeint war, und langsam den Verdacht bekommt, sie stelle sich an. Es ist der Projektleiter, der vor dem Kunden ein Ergebnis erklärt, das er selbst zum ersten Mal in dieser Form sieht. Beide sind gut in ihrem Beruf; sie arbeiten nur gegen eine Ablage, die sie allein lässt.
Der zweite Sterbeort ist die Übersetzung ins Produkt. Ein Kunde sagt „Wir brauchen Sammelrechnungen“. Was dein Produkt daraus machen muss — Sammellauf, Storno, Export — steht nirgendwo neben dem Kundensatz, sondern im Kopf der Person, die den Auftrag verstanden hat. Wechselt diese Person das Projekt, bleibt die Anforderung stehen und die Begründung geht. Drei Monate später fragt jemand im Review: „Warum bauen wir das eigentlich?“ Und niemand kann antworten, ohne im Postfach zu suchen.
Ein Lebenszyklus ist kein Prozess-Theater
Die übliche Antwort auf dieses Problem heißt Prozess, und die übliche Reaktion auf Prozess heißt Ausweichen. Wer schon einmal ein Freigabeformular ausgefüllt hat, das niemand liest, weiß warum. Ein Lebenszyklus, der nur Zustände zählt, ist Theater. Er erzeugt Arbeit und keine Klarheit.
Ein Lebenszyklus, der etwas taugt, tut genau eine Sache: Er erzwingt ein Gespräch zu dem Zeitpunkt, an dem es noch billig ist. Entwurf, in Prüfung, genehmigt, in Bearbeitung, geliefert — die Namen sind austauschbar. Was zählt, sind die Schranken dazwischen. Eine Schranke ist kein Stempel; sie ist eine Frage, die beantwortet sein muss, bevor der nächste Schritt möglich ist.
Die Fragen sind unspektakulär, und genau deshalb wirken sie. Wer hat das verlangt? Steht da genug, dass ein anderer es lesen kann, ohne nachzufragen? Widerspricht es etwas, das wir schon zugesagt haben? Wer diese drei Fragen im Entwurf beantwortet, verliert zehn Minuten. Wer sie erst in der Umsetzung beantwortet, verliert einen Sprint.
Ein Beispiel aus der Praxis. „Der Import soll auch große Dateien vertragen.“ Der Satz sieht aus wie eine Anforderung, ist aber ein Wunsch mit einem Loch in der Mitte. Er bleibt an der Schranke hängen, und dann fragt jemand nach: Wie groß ist groß? Woran erkennen wir, dass er sie verträgt? Zwei Rückfragen beim Kunden, fünf Minuten am Telefon, und aus dem Satz wird „bis 5.000 Zeilen, ohne Zeitüberschreitung, mit Fehlerprotokoll je Zeile“. Dieselbe Rückfrage in der Umsetzung kostet nicht fünf Minuten, sondern zwei Tage, weil dann schon jemand geraten hat.
Der Unterschied zwischen Schranke und Bürokratie ist leicht zu prüfen: Eine Schranke, die dir nicht sagen kann, warum sie zu ist, ist Bürokratie. Eine Schranke, die dir sagt, welcher Satz fehlt, ist ein Kollege.
Nachvollziehbarkeit schlägt Erinnerung
Das Review am Anfang dieses Textes lässt sich nicht durch bessere Erinnerung reparieren. Es lässt sich nur reparieren, indem es etwas gibt, das besser erinnert als die Anwesenden. Nicht eine weitere Ablage neben den drei vorhandenen, sondern eine Stelle, auf die sich die anderen beziehen: ein Ledger, in dem eine Anforderung einmal steht, von der Kundenaussage bis zur Umsetzung.
Eine Anforderung, die an zwei Orten lebt, ist zwei Anforderungen.
Nachvollziehbarkeit klingt nach Dokumentationspflicht, meint aber etwas viel Praktischeres: die Kette vom Kundensatz bis zur Funktion, die ihn erfüllt, jederzeit in beide Richtungen lesbar. Nach vorn beantwortet sie „Was passiert mit meinem Wunsch?“. Nach hinten beantwortet sie „Für wen bauen wir das, und was passiert, wenn wir es nicht bauen?“. Beide Fragen kommen in jedem Projekt. Nur selten zu einem Zeitpunkt, an dem sie noch bequem sind.
„Ein Ort“ heißt dabei nicht, dass alles umzieht. Die Entwicklung arbeitet weiter in Jira, die Dokumentation bleibt in Confluence, und der Kunde schickt weiter Tabellen — das wird sich nicht ändern, und es muss sich auch nicht ändern. Was sich ändert, ist der Bezugspunkt: Die Anforderung steht einmal, und sie behält den Schlüssel des Tickets, das aus ihr entstanden ist, statt in ihm aufzugehen. Der Unterschied zwischen einer Kopie und einem Verweis ist der ganze Unterschied zwischen diesem Text und deinem letzten Review.
Damit die Kette hält, braucht sie zwei Enden. Der Kundensatz ist die eine Anforderung: was dieser Kunde in diesem Projekt verlangt, in seinen Worten. Die Fähigkeit deines Produkts ist die andere: was du einmal baust und beliebig oft auslieferst. Zwischen beiden liegt eine ausdrückliche Verknüpfung — und der ganze Nutzen liegt darin, dass sie ausdrücklich ist. Solange sie nur im Kopf existiert, ist sie beim nächsten Personalwechsel weg.
Diese Lücken gibt es auf zwei Ebenen, und beide sind unangenehm. Die erste fragt: Was hat ein Kunde verlangt, das keine Produktanforderung trägt? Die zweite fragt: Was steht als Produktanforderung fest und ist noch immer nicht umgesetzt? Die erste Lücke kostet Vertrauen, die zweite kostet Termine. Keine von beiden fällt jemandem im Vorbeigehen auf.
| Anforderung | Status | Deckung |
|---|---|---|
| Sammelrechnung je Quartal | TEILWEISE | |
| Mahnstufen eskalieren | LÜCKE | |
| DATEV-Export | ERFÜLLT | |
| Kundenportal-Login | UNBEWERTET |
Woran du morgen früh erkennst, ob du betroffen bist
Kein Reifegradmodell, keine Punktzahl. Fünf Sätze, die entweder auf dich zutreffen oder nicht.
- Deine neueste Anforderungsliste ist ein Mailanhang, und der Dateiname endet auf „_final_v2“.
- Auf die Frage „Wer wollte das?“ folgt eine Suche im Postfach und nicht ein Klick.
- Zwei Projekte bauen dieselbe Funktion, und aufgefallen ist es beim Testen, nicht beim Planen.
- Vor jedem Kundentermin baut jemand eine Statusübersicht von Hand zusammen — dieselbe wie vor vier Wochen, nur mit anderen Zahlen.
- Du kannst nicht in unter einer Minute sagen, welche Zusagen aus dem letzten Angebot heute durch nichts abgedeckt sind.
Ein Haken ist Alltag. Drei sind ein Muster. Fünf sind kein Teamproblem, sondern ein Ablageproblem: Deine Anforderungen haben keinen Ort, sie haben Fundorte.
Wo du anfängst
Nicht mit einem Werkzeug. Fang mit einer Anforderung an, die gerade weh tut, und schreib zwei Sätze auf: was der Kunde verlangt hat, und was dein Produkt dafür können muss. Wenn dir der zweite Satz schwerfällt, hast du die Ursache gefunden — und das ist eine gute Nachricht, denn dieser Satz lässt sich schreiben. Die Erinnerung von drei Leuten lässt sich nicht reparieren.
Der erste Satz, der endlich an einer Stelle steht, an der ihn alle finden, fühlt sich unspektakulär an. Den Unterschied merkst du erst im nächsten Review: Die Frage „Wie war das noch mal gemeint?“ kommt nicht. Niemand feiert das. Es ist trotzdem der Moment, in dem dein Projekt aufgehört hat, sich auf Erinnerung zu verlassen.
Der nächste Schritt ist die Verknüpfung zwischen beiden Sätzen, und dafür lohnt sich Von der Kundenstimme zur Produktanforderung — dort steht, wie derselbe Bedarf aus drei Projekten zu einer Produktanforderung wird, ohne dass die Kundensätze ihre Herkunft verlieren. Wenn du lieber sehen möchtest, wie sich das im Arbeitsalltag anfühlt, statt es als Methode zu lesen: Ein Tag als Product Owner geht einen ganz normalen Dienstag durch, Stunde für Stunde, vom Posteingang bis zur Statusfrage am Nachmittag, die sich selbst beantwortet.