Spec-Writing und Engineering-Handoff ohne Folgeschäden

Ihre letzte Spec hatte acht Seiten. Engineering öffnete sie einmal am Montag, überflog die Überschriften und öffnete sie nie wieder. Am Donnerstag steckten zwei Stories fest, weil niemand wusste, ob der Export archivierte Datensätze einschließen sollte. Beim nächsten Sprint-Review war 40% der Arbeit überarbeitet worden. Sie wurden für Spec-Chaos verantwortlich gemacht. Engineering wurde beschuldigt, nicht gelesen zu haben. Niemand hat das System geändert.

Das ist der Kreislauf. So durchbrechen Sie ihn.

Warum Ihre letzte Spec nicht gelesen wurde

Ich habe das in den letzten Jahren in drei Teams beobachtet. Jedes hatte einen anderen Stack, eine andere Domain, dasselbe Muster: der PM erstellt eine lange Spec, Engineering produziert einen langen Sprint, und die Lücke zwischen dem Geschriebenen und dem Gebauten wird mit Nacharbeit gefüllt.

Die 40%-Nacharbeits-Zahl stammt nicht aus einer Umfrage. Das ist, was Teams finden, wenn sie tatsächlich zählen. Rufen Sie die Tickets des letzten Sprints ab, markieren Sie jede Story, die den Scope änderte, ein Follow-up-Ticket bekam oder mit einem bekannten Bug geliefert wurde, der auf „das wussten wir nicht" zurückzuführen ist. Das ist Ihre Nacharbeitsrate. Die meisten Teams, die diese Übung ehrlich durchführen, landen zwischen 30 und 50%.

Die Spec hat das nicht allein verursacht. Aber die Spec ist die günstigste Stelle, um es zu beheben. Code ist teuer umzuschreiben. Ein Dokument ist kostenlos umzuschreiben, und eine einseitige Spec wird viel öfter umgeschrieben als eine achtseitige.

Hier ist, womit wir den Roman ersetzen.

Die einseitige Spec

Sieben Abschnitte. Jeder verdient seinen Platz. Wenn ein Abschnitt keine echte Funktion erfüllt, gehört er nicht hinein.

# [Feature-Name]

**Problem**
Was für den Nutzer kaputt ist oder fehlt. Ein Satz. Echter Nutzer, echter Schmerz.
Nicht „Nutzer können X nicht." Eher: „Vertriebsmitarbeiter können ihre Pipeline nicht
exportieren, um sie vor 1:1s mit ihrem Manager zu teilen, also machen sie
Screenshots und fügen sie in Slack ein."

**Hypothese**
Wenn wir [Sache] liefern, wird [Outcome] eintreten, weil [Grund]. Ein Satz.
Das ist die Wette, die wir eingehen.

**Erfolgskennzahl**
Die eine Zahl, die uns sagt, dass wir gewonnen haben. Nicht drei. Eine.
Seien Sie konkret: „30% der Vertriebsmitarbeiter, die ihre Pipeline ansehen,
nutzen Export innerhalb von 14 Tagen nach Veröffentlichung." Fügen Sie einen
Frühindikator hinzu, wenn der Spätindikator zu lange braucht.

**Scope**
Was enthalten ist. Aufzählung, max. 7 Punkte. Jeder Punkt ist etwas, das ein
Nutzer tun oder sehen kann.

**Anti-Scope**
Was NICHT enthalten ist, auch wenn jemand danach fragen wird. Aufzählung.
Konkret sein: „Benutzerdefinierte Export-Vorlagen: nicht in v1. Geplante
Exporte: nicht in v1. CSV-Spalten-Neuanordnung: nicht in v1."
Das ist der Abschnitt, der Ihren Sprint rettet.

**Grenzfälle**
Die fünf Dinge, die schiefgehen, wenn wir jetzt nicht darüber nachdenken:
leere Zustände, Fehler, große Datensätze, Berechtigungen, gleichzeitige
Bearbeitungen. Nennen Sie die tatsächlichen für dieses Feature.

**Offene Fragen**
Die Entscheidungen, auf die wir noch keine Antworten haben, mit Namen.
„Enthält der Export archivierte Deals? @ravi bestätigt mit Sales Ops bis Mi."

Das war es. Eine Seite. Die gesamte Spec.

Das entscheidende Feature ist der Anti-Scope. Die meisten PMs lassen ihn weg, weil er negativ wirkt oder weil sie denken: „Offensichtlich machen wir X nicht." Es ist für Engineering nie offensichtlich. Es ist für Design nie offensichtlich. Es ist für den Stakeholder nie offensichtlich, der Sie freitagabends fragt, warum sein Lieblings-Feature nicht enthalten ist. Anti-Scope ist der Abschnitt, auf den Sie zeigen, wenn jemand die Arbeit mitten im Sprint ausweiten möchte. Ohne ihn argumentieren Sie aus dem Gedächtnis. Mit ihm zeigen Sie auf eine Zeile, die alle vor zwei Wochen unterzeichnet haben.

Ich habe Features ohne Anti-Scope geliefert und musste den Export-Flow zweimal neu bauen, weil die erste Version ungefilterte Daten annahm und die zweite nachträglich für gespeicherte Filter angepasst wurde. Zwei Engineers, drei Wochen. Alles durch einen 4-Punkte-Anti-Scope vermeidbar, der 90 Sekunden zum Schreiben brauchte.

Das Pre-Spec-Engineering-Review (15 Minuten)

Die Spec geht nicht direkt von Ihrem Laptop in Jira. Sie durchläuft zuerst ein 15-minütiges Engineering-Review, und Sie bringen einen Entwurf mit, kein fertiges Dokument.

Die Vorbereitung:

• Wer: Tech Lead, ein erfahrener Engineer, Sie. Das war es. Noch kein Designer. Kein PM-Kollege. Kein Manager.
• Wann: Bevor Sie die Spec irgendjemandem gezeigt haben. Bevor Design begonnen hat. Bevor Stakeholder sich geäußert haben.
• Was Sie mitbringen: Die einseitige Spec, als ENTWURF markiert. Problem- und Hypothese-Abschnitte sind fest. Alles andere ist Diskussionsgrundlage.
• Was Sie bekommen: Eine Liste von Grenzfällen, die Sie übersehen haben, eine grobe Einschätzung des Aufwands und ein frühes „Das ist der falsche Ansatz", wenn es der falsche Ansatz ist.

Die Agenda, auf einem Notizzettel festgehalten:

0-2 Min:  Problem + Hypothese (Sie reden)
2-8 Min:  Engineering prüft Scope und Grenzfälle kritisch
8-12 Min: Engineering skizziert zwei oder drei Implementierungsansätze
12-14 Min: Offene Fragen, wer jede übernimmt
14-15 Min: „Sind wir grundsätzlich einig?" - Ja/Nein/Vielleicht

Wenn die Antwort „Nein" oder „Vielleicht" ist, schreiben Sie keine weitere Spec. Sie gehen und beheben die Problemrahmung oder den Ansatz. Die meisten Spec-Probleme sind Rahmungsprobleme im Kostüm.

Warum das funktioniert: Engineering, das eine halbfertige Spec prüft, gibt Ihnen sein bestes Denken, bevor es in der Defensive ist. Sobald eine Spec „fertig" ist, wird das Review zur Kritik an Ihrer Arbeit. Wenn sie ein Entwurf ist, arbeiten Sie gemeinsam. Derselbe Engineer, der in Jira einen 12-Kommentar-Verriss geschrieben hätte, sagt stattdessen: „Was wäre, wenn wir dem bestehenden Export-Endpunkt einfach ein Flag hinzufügen?" und spart Ihnen eine Woche.

Das Kickoff-Dokument

Sobald die einseitige Spec das Pre-Spec-Review bestanden hat und Design sich geäußert hat, schreiben Sie das Kickoff-Dokument. Das wird im Team-Channel angepinnt. Es ist ein Vertrag.

Vier Abschnitte, jeder kurz:

RACI-Tabelle mit einem Namen pro Rolle

Ein Komitee ist nicht verantwortlich. Ein Name schon.

Wenn Sie die Accountable-Zeile nicht mit einem einzigen Namen füllen können, ist das Projekt noch nicht bereit zu starten.

Meilensteine mit Daten

Drei oder vier Meilensteine. Echte Daten. Nicht „Ende des Sprints".

• 14. März: Design fertig, Dev startet
• 21. März: Backend-Endpunkt hinter Feature-Flag, interner Test auf Staging
• 28. März: Beta mit 10 Kunden
• 4. April: Demo Day (nicht verhandelbar)
• 11. April: GA

Demo-Day: nicht verhandelbar

Legen Sie ein Datum fest. Sagen Sie es dem Team. Sagen Sie es den Stakeholdern. Sagen Sie sich selbst, dass Sie an diesem Tag demo, was existiert, auch wenn es unfertig aussieht.

Demo-Termine, die sich verschieben, sind keine Demo-Termine. Sie sind Wünsche. Liefern Sie, was Sie haben. Wenn das eine halbe Funktion ist, präsentieren Sie eine halbe Funktion und erklären Sie, was noch fehlt. So wird Vertrauen aufgebaut. Das Team, das alle zwei Wochen demo, auch wenn es unpoliert ist, wird am Ende immer schneller als das Team, das erst demo, wenn es perfekt ist.

Abbruchkriterien

Das ist der Abschnitt, den niemand schreiben möchte und den alle brauchen.

„Wir hören auf, das zu bauen, wenn: Beta-Kunden den Export nicht innerhalb von 7 Tagen nach Aktivierung nutzen, ODER die Backend-Latenz 800 ms bei p95 mit unserem Testdatensatz überschreitet, ODER mehr als zwei Kunden während der Beta Datengenauigkeitsprobleme melden."

Drei Bedingungen. Konkret. Messbar. Im Voraus vereinbart.

Ohne Abbruchkriterien lebt jedes Feature ewig. Mit ihnen hat das Team Rückendeckung, um es abzubrechen. Ich habe in den letzten 18 Monaten zwei Features mit diesem Abschnitt abgebrochen, und beide Male haben mir die Engineers gedankt. Niemand möchte drei weitere Wochen mit etwas verbringen, das nicht funktioniert. Sie brauchen nur die Erlaubnis, schriftlich, im Voraus festgelegt.

Loom statt Meeting (meistens)

Das Übergabe-Meeting, in dem Sie Engineering 30 Minuten durch die Spec führen? Überspringen Sie es. Nehmen Sie stattdessen ein 4-minütiges Loom auf.

Was ins Loom gehört:

1. Die einseitige Spec auf dem Bildschirm, Sie erklären sie.
2. Zwei Demo-Flows: der Happy Path und ein Grenzfall.
3. Die drei Dinge, die Sie am ehesten als Fragen erwarten.
4. Ein abschließender Satz: „Stellen Sie Fragen im Thread, ich antworte bis Tagesende."

Was das bringt: Engineering schaut mit 1,5-facher Geschwindigkeit, wenn es bereit ist, nicht wenn Ihr Kalender es erlaubt. Fragen gehen in einen Thread, was bedeutet, dass jeder die Antwort einmal sieht statt dass Sie dasselbe in drei Slack-Direktnachrichten erklären. Neue Engineers, die zwei Wochen später zum Projekt stoßen, schauen dasselbe Loom statt jemanden beiseite zu ziehen.

Wann Loom nicht funktioniert: wenn das Projekt wirklich mehrdeutig ist und das Team laut diskutieren muss. Wenn das Vertrauen gering ist und asynchrones Arbeiten sich anfühlt, als würde sich der PM verstecken. Wenn es echte strategische Abwägungen gibt, die einen gemeinsamen Raum brauchen. Für diese Fälle machen Sie das Meeting. Für alles andere: Loom.

Die „Es ist fertig"-Definition

Abnahmekriterien, die als „Nutzer kann sich anmelden" geschrieben werden, sind keine Abnahmekriterien. Es ist ein Wunsch.

Verwenden Sie Given / When / Then. Konkrete Beispiele, echte Daten, echte Zustände.

Schlecht:

Nutzer kann Pipeline exportieren.

Gut:

Given ich ein Vertriebsmitarbeiter mit Ansichtszugriff auf meine Pipeline bin, And ich einen Filter angewendet habe, der nur Deals zeigt, die mir gehören und den Stage „Verhandlung" haben, When ich auf Export klicke und CSV auswähle, Then wird eine Datei namens pipeline-2026-04-28.csv heruntergeladen, die genau die nach dem Filter sichtbaren Deals enthält, mit den Spalten: Name, Stage, Betrag, Abschlussdatum, Inhaber.

Grenzfall (leeres Ergebnis): Gibt der Filter null Deals zurück, wird ein Toast angezeigt: „Keine Deals zu exportieren", und es wird keine Datei heruntergeladen.

Grenzfall (großer Datensatz): Gibt der Filter über 10.000 Deals zurück, wird der Export in die Warteschlange gestellt und die Datei per E-Mail gesendet, wenn sie fertig ist. Toast anzeigen: „Export in der Warteschlange. Wir senden Ihnen die Datei per E-Mail."

Das sind zwei weitere Minuten des Schreibens. Es spart drei Tage Diskussionen. Der QA-Engineer liest das und schreibt einen Test. Der Backend-Engineer liest das und kennt den Endpunkt-Vertrag. Der Customer-Success-Lead liest das und weiß, was er Beta-Kunden sagen soll. Ein Artefakt, vier Aufgaben.

Überspringen Sie die Grenzfälle nicht. In den Grenzfällen steckt die Nacharbeit.

Post-Ship-Retro-Vorlage

Zwanzig Minuten. Fünf Fragen. Im Team-Slack-Channel innerhalb einer Woche nach GA gepostet.

**[Feature-Name] - Post-Ship-Retro**

1. Was war in der Spec unklar?
   (Ein Punkt pro Person, keine Diskussion, nur auflisten.)

2. Was haben wir beim Scoping verpasst, was ist aufgetaucht, das wir nicht geplant haben?
   (Aufwand, Risiko, Abhängigkeit, alles.)

3. Welche Nacharbeit ist entstanden, und warum?
   (Konkret sein. „Filter-Persistenz zweimal neu gebaut, weil wir uns nicht früh genug
   über URL vs. Local Storage einigen konnten.")

4. Welcher Grenzfall hat uns erwischt?
   (Der, der von Anfang an in der Spec hätte sein sollen.)

5. Was kommt in die nächste Spec?
   (Eine konkrete Änderung an der Vorlage oder dem Prozess.)

- Antworten im Thread bis Freitag. Ich fasse zusammen und veröffentliche die
  nächsten Spec-Änderungen montags.

Der Punkt ist nicht die Schuldzuweisung. Der Punkt ist die Weiterentwicklung der Vorlage. Die nächste Spec bekommt eine Verbesserung. Dann die übernächste eine weitere. Nach sechs Monaten ist der Spec-Prozess Ihres Teams wesentlich besser als zu Beginn, und niemand musste dafür an einem 90-minütigen Retro teilnehmen.

Ich führe eine laufende Datei namens spec-improvements.md mit einem Punkt pro Retro. Nach einem Jahr umfasst sie zwei Bildschirmseiten. Es ist das wertvollste Dokument, das ich besitze.

Häufige Anti-Muster, auf die Sie achten sollten

Einige Muster tauchen immer wieder auf. Benennen Sie sie laut, sobald Sie sie sehen. Sie verschwinden, wenn sie benannt werden.

• Der „Design hat es über die Mauer geworfen"-Handoff. Design ist fertig, wirft einen Figma-Link in die Spec, verschwindet. Engineering stößt auf eine Interaktion, die die Mockups nicht abdecken, fragt Design, bekommt „nutzt Ihr Urteil". Drei Tage später wird es falsch geliefert. Lösung: Design nimmt am Kickoff teil. Ihre RACI-Zeile ist „Consulted" mit einem angehängten Namen. Sie sind für Interaktionsfragen im ersten Sprint erreichbar.

• Die Spec, die während des Sprints wächst. Ein Stakeholder schreibt Ihnen dienstags. „Können wir auch X zu diesem Release hinzufügen?" Sie sagen ja, weil Nein politisch anmutet. Bis Freitag ist das Team im Rückstand. Lösung: Anti-Scope. Zeigen Sie darauf. „X ist in v2. Ich habe es erfasst." Erledigt.

• Der fehlende Anti-Scope. Engineering baut das Feature und fragt dann: „Was ist mit archivierten Datensätzen?" Sie sagen: „Gute Frage, fügen wir das hinzu." Das ist Anti-Scope, der als Trojanisches Pferd wieder hereinkommt. Lösung: Anti-Scope steht von Anfang an in der Spec. Alles, was nicht auf der In-Scope-Liste steht, ist standardmäßig ausgeschlossen.

• Die Demo-Day-Überraschung. Demo Day ist da. Der PM hat den Build seit Montag nicht gesehen. Die Hälfte der Flows funktioniert nicht wie in der Spec beschrieben. Stakeholder gehen verwirrt. Lösung: PM macht 24 Stunden vor dem Demo Day einen privaten Walkthrough mit dem Engineering-Lead. Abweichungen werden entdeckt, wenn sie noch behebbar sind.

Abschluss

Eine Spec ist ein Vertrag, kein Essay.

Die einseitige Spec ist kurz, weil kurze Specs gelesen werden. Das Pre-Spec-Engineering-Review dauert 15 Minuten, weil alles Längere zu einem Meeting wird, das niemand will. Das Kickoff-Dokument hat einen Namen pro Rolle, weil Komitees nicht verantwortlich sein können. Loom ersetzt den Walkthrough, weil asynchrones Schreiben skaliert und Meetingkalender es nicht tun. Given/When/Then existiert, weil „Nutzer kann sich anmelden" tausend kaputte Logins geliefert hat.

Anti-Scope und Abbruchkriterien sind die zwei Abschnitte, die die meisten PMs überspringen und am meisten bereuen. Überspringen Sie sie nicht. Es ist die günstigste Versicherung, die Sie je abschließen werden.

Kürzer, schärfer, abgezeichnet. Das ist das ganze Spiel.

Mehr erfahren

• Product-Manager-Stellenbeschreibung
• Sprint-Planung, die nicht zieht
• Roadmap-Kommunikation für funktionsübergreifende Teams
• Mit Design arbeiten: PM und Designer-Handoff