Was in ein MVP-Scope-Dokument gehört

Die meisten „Scope-Dokumente" sind eine Aufzählung von Funktionen und eine Zahl. Das ist kein Scope-Dokument. Es ist eine Vermutung mit Formatierung.

Ein echtes ist so konkret, dass zwei verschiedene Entwicklungsteams, die nur das Dokument lesen, erkennbar dasselbe Produkt bauen würden. Hier ist, was das tatsächlich erfordert.

Die kurze Antwort

Acht Abschnitte. Lassen Sie zwei oder drei aus, haben Sie ein Angebot, keinen Plan.

Problemstellung statt Feature-Liste

Das Dokument sollte mit dem zu lösenden Problem und wer es hat beginnen, in einfacher Sprache, bevor auch nur eine Funktion genannt wird. Das klingt offensichtlich und wird ständig übersprungen.

Warum das zählt: Jede folgende Scope-Entscheidung wird daran gemessen. Wenn in Woche sechs eine Funktionsanfrage auftaucht, ist „löst das das genannte Problem" ein schnellerer und ehrlicherer Filter als „klingt das nützlich".

Eine schwache Version: „Eine App, die Flottenbetreiber mit Mechanikern verbindet." Eine funktionierende Version benennt den echten Schmerz - Betreiber verbringen derzeit zwei bis sechs Stunden pro Panne damit, telefonisch einen verfügbaren Mechaniker zu finden, ohne vorherige Kompetenzprüfung.

Nutzerflüsse vor Feature-Listen

Einzelne Funktionen sagen nicht, ob das Produkt funktioniert. Flüsse schon.

Das Dokument sollte die zwei oder drei zentralen Pfade abbilden, die ein Nutzer tatsächlich von Anfang bis Ende durchläuft - nicht jeden Screen, sondern die Abfolge, die das Produkt funktionsfähig macht. Hier entdecken Sie, dass „Bewertungssystem hinzufügen" implizit „Streitfälle bei unfairer Bewertung behandeln" erfordert, was niemand separat einzuplanen bedacht hatte.

Eine tatsächlich priorisierte Feature-Liste

Keine flache Aufzählung - eine Liste, sortiert danach, was das Produkt kaputt macht, wenn es fehlt, gegenüber dem, was schön zu haben wäre. Wir haben bereits darüber geschrieben, eine 46-Funktionen-Liste auf 11 zu reduzieren, genau mit diesem Test: Wenn das fehlt, funktioniert die Kernschleife noch?

Jede Funktion, die diesen Test besteht, kommt in „Muss haben". Alles andere kommt in einen klar gekennzeichneten Abschnitt „Phase zwei" - dokumentiert, grob geschätzt und explizit nicht Teil dessen, was jetzt gebaut wird. Diese eine Praxis verhindert mehr Scope-Streitigkeiten als jede Vertragsklausel.

Technische Architektur mit Begründung

Nicht nur eine Liste von Technologien - die Logik hinter jeder Wahl, denn genau die erlaubt es jemandem zu beurteilen, ob die Entscheidungen sechs Monate später noch sinnvoll sind.

Ein Scope-Dokument sollte den Stack, den Hosting-Ansatz und die zwei oder drei Entscheidungen benennen, die teuer umzukehren wären - die Datenbankwahl für ein transaktionales Produkt, ob Benachrichtigungen über WhatsApp oder nur E-Mail laufen, ob die Architektur später mehrere Plattformen unterstützen muss, auch wenn sie jetzt auf einer startet.

Screens oder ein Prototyp, keine Beschreibung

„Ein sauberes, modernes Dashboard" ist keine Spezifikation. Fünf bis acht Schlüssel-Screens, idealerweise als klickbarer Prototyp, beseitigen die größte Quelle für Überraschungen mitten im Bau: dass Gründer und Team unterschiedliche Bilder derselben Funktion im Kopf haben.

Das muss kein pixelgenaues finales Design sein. Es muss konkret genug sein, dass „das Adminpanel" aufhört, eine Abstraktion zu sein, und zu etwas Realem, Diskutierbarem wird.

Eine modulweise aufgeschlüsselte Schätzung, keine Einzelzahl

Ein einzelner Preis versteckt jede Annahme, die ihn hervorgebracht hat. Eine modulweise Aufschlüsselung - Konten und Berechtigungen, Kern-Transaktionsfluss, Zahlungen, Adminpanel und so weiter - tut zwei Dinge, die eine Einzelzahl nicht kann: Sie zeigt, was teuer ist und warum, und sie erlaubt es, ein bestimmtes Modul zu streichen, wenn das Budget nicht reicht, statt alles neu zu verhandeln.

Konkret benannte Risiken und Abhängigkeiten

Allgemeine Risikosprache („technisches Risiko", „Zeitplanrisiko") ist wertlos. Ein echter Risikoabschnitt benennt das konkrete Ding, das das Projekt verlangsamen könnte - der Genehmigungszeitplan eines Zahlungsanbieters, eine Drittanbieter-API mit unklaren Ratenlimits, eine noch ausstehende Gründerentscheidung - und wer für die Lösung verantwortlich ist.

Dieser Abschnitt ist auch, wo der kritische Pfad identifiziert wird: die zwei oder drei Dinge, die bei Verzögerung das Startdatum verschieben, egal wie gut die Entwicklung sonst läuft.

Was explizit ausgeschlossen ist

Das ist der Abschnitt, den die meisten Scope-Dokumente komplett auslassen, und er ist derjenige, der später die meisten Streitigkeiten verhindert.

Sagen Sie klar, was nicht enthalten ist: Kosten für Drittanbieterdienste, Content-Erstellung, Datenmigration, Support über ein definiertes Fenster hinaus, eine zweite Plattform. Die beste Version dieses Abschnitts ist lang und etwas mühsam zu lesen. Das ist ein Merkmal, kein Fehler - Unklarheit hier ist die Quelle von „ich dachte, das wäre enthalten"-Streitigkeiten.

Wie ein echtes aussieht

Wir veröffentlichen ein anonymisiertes Beispiel-Blueprint, das alle acht Abschnitte für ein reales Projekt ausgefüllt zeigt - keine Vorlage mit Platzhaltertext, sondern ein echtes Scope-Dokument mit echten Entscheidungen und echten Zahlen. Es zu lesen geht schneller als eine Beschreibung davon zu lesen.

Der Test, ob Ihres echt ist

Geben Sie das Dokument einem Ingenieur, der nie mit Ihnen gesprochen hat, und bitten Sie um eine Zeitplanschätzung. Wenn er das ohne Rückfrage schafft, ist es ein Scope-Dokument. Kommt er mit zehn Fragen zurück, haben Sie eine Feature-Liste mit einem Preisschild - und genau diese zehn Fragen tauchen als Änderungsanfragen auf, sobald das Projekt bereits läuft, wenn sie deutlich teurer zu beantworten sind.

Möchten Sie sehen, wie ein vollständiges Scope-Dokument an einem echten Projekt aussieht? Unser Beispiel-Blueprint ist das vollständige Dokument, kein Auszug. Oder erzählen Sie uns von Ihrem Projekt, wir scopen es richtig, bevor wir eine Zahl nennen.