„Wir brauchen ein System, das Buchungen abwickelt" ist keine Anforderung — es ist ein Wunsch, und keine Entwicklerin kann einen Wunsch schätzen. Die Lücke zwischen dem, was eine Kundin meint, und dem, was ein Entwickler tatsächlich bauen kann, ist genau die Stelle, an der die meisten Angebote scheitern, bevor auch nur eine Zeile Code geschrieben wurde — denn ein vages Briefing bekommt eine vage Schätzung, und eine vage Schätzung ist der Keim jedes Umfangsstreits, der darauf folgt.
Der Unterschied zwischen einer Funktion und einer Anforderung
„Kunden sollen online buchen können" beschreibt eine Funktion. Es sagt nicht, was passiert, wenn zwei Kunden zur selben Sekunde denselben Termin buchen wollen, ob eine Buchung eine Freigabe braucht oder sofort bestätigt wird, was bei fehlgeschlagener Zahlung nach reserviertem Termin passiert, oder ob eine Stornierung eine Stunde vor dem Termin anders behandelt wird als eine Woche vorher. Jeder dieser Punkte ist eine echte Entscheidung mit echten Entwicklungskosten, und keiner davon ist in der Ein-Satz-Funktionsbeschreibung sichtbar — sie tauchen erst auf, wenn jemand zu bauen beginnt und raten muss, oder innehält und fragt.
Akzeptanzkriterien machen aus einem Wunsch etwas Baubares
Eine Anforderung wird schätzbar, sobald sie konkret festlegt, wie „fertig" aussieht: bei dieser Eingabe genau diese Ausgabe; bei diesem Grenzfall genau dieses Verhalten. „Ein Kunde kann einen Termin buchen" wird baubar, sobald es eher lautet wie „ein Kunde wählt einen verfügbaren Termin, erhält innerhalb von 60 Sekunden eine Bestätigung, und der Termin wird für andere Kunden in dem Moment gesperrt, in dem er ausgewählt wird — nicht erst nach abgeschlossener Zahlung". Dieses Maß an Genauigkeit wirkt bei einer kleinen Funktion übertrieben und erscheint essenziell, sobald eine unklare Funktion zum ersten Mal einen zweiwöchigen Streit darüber auslöst, was eigentlich versprochen wurde.
Die Unklarheiten, die zuverlässig Überschreitungen verursachen
Eine Handvoll Lücken zeigt sich in fast jedem unzureichend spezifizierten Projekt: Was passiert bei einem Fehler (sieht der Nutzer nichts, eine generische oder eine konkrete Meldung), was passiert an den Rändern normaler Nutzung (null Ergebnisse, die maximal erlaubte Eingabe, eine doppelte Übermittlung), wer darf was sehen oder bearbeiten, und was soll das System tun, wenn zwei Personen gleichzeitig an demselben Datensatz handeln wollen. Nichts davon ist exotisch — es sind gewöhnliche Situationen, die im Betrieb ständig vorkommen —, aber genau das sind die Situationen, die ein Ein-Absatz-Briefing nie erwähnt, weil sie erst offensichtlich werden, wenn jemand die Sache tatsächlich baut.
Warum das beide Seiten schützt, nicht nur die Entwicklerin
Eine detaillierte Anforderung ist keine Bürokratie um ihrer selbst willen — sie ist das Dokument, auf das beide Seiten später zurückgreifen können, wenn eine Meinungsverschiedenheit auftaucht. Ohne sie sind „das haben wir nicht so verlangt" und „genau das habt ihr verlangt" beide wahre Aussagen über denselben vagen Satz, und das zu klären kostet mehr Zeit und Vertrauen, als die Anforderung von Anfang an sauber aufzuschreiben gekostet hätte.
Das von Beginn an richtig zu machen ist Teil derselben Entscheidung kaufen, bauen oder konfigurieren — denn selbst der richtige Ansatz liefert nur dann ein tatsächlich funktionierendes System, wenn das zu Bauende klar genug spezifiziert wurde, um gebaut werden zu können.
Unser Software-Team verwandelt die einfache Beschreibung einer Kundin in Anforderungen auf Akzeptanzkriterien-Niveau, bevor irgendetwas geschätzt wird, damit das Angebot widerspiegelt, was tatsächlich gebaut wird — keine Vermutung darüber.
