Software-Discovery-Deliverables: Was Sie für eine glaubwürdige Budget- und Zeitplan-Schätzung brauchen
Discovery-Deliverables für eine glaubwürdige Softwareschätzung — für Founder mit MVP, Startups und RFPs mit unklaren Anforderungen. Ziele, Prioritäten und Artefakte nach Discovery.
Software-Discovery-Deliverables: Was Sie für eine glaubwürdige Budget- und Zeitplan-Schätzung brauchen
Vom Smartym Pro Team | Juli 2026
Serie: Discovery & Dokumentation (3 Teile):
- Anforderungspaket vor Entwicklung — was bereit sein muss
- Discovery-Prozess und D1–D11 (dieser Artikel) — wie man dorthin kommt
- KI-gestützte Dokumentationsentwürfe — wie man Entwürfe beschleunigt
Einleitung
Teil 1 beschreibt das Dokumentenpaket — Discovery-Ergebnis vor Schätzung und Entwicklung. Hier geht es um den Discovery-Prozess selbst: Workshops, Rollen Kunde vs. Partner, den komprimierten D1–D11-Check und Szenarien MVP, Ausschreibung sowie Ballpark vs. Fixed Phase.
Die meisten Projekte starten mit: „Was kostet es, und wann ist es fertig?“ Käufer wollen diese Zahl oft vor Discovery. Anbieter polstern oder unterbieten. Discovery macht aus einer Idee das Paket aus Teil 1; erst danach ergeben Schätzung und Vertrag Sinn.
Wo Discovery im Projekt-Lifecycle sitzt
Idee / Brief / Rohinput
↓
Discovery (Workshops, Gap-Analyse, Feasibility)
↓
Artefaktpaket D1–D9 (+ D11 bei Bedarf)
↓
Schätzung und Budgetplan (D10)
↓
Sign-off Scope Phase eins → Vertrag
↓
Entwicklung (Sprint 0, Delivery)
Discovery ist die verpflichtende Stufe zwischen Absicht und Code, wenn die Unsicherheit über Ballpark-Niveau liegt. Das Ergebnis ist das Paket in Teil 1; unten der komprimierte D1–D11-Index.
| Phase | Was existiert | Was Sie besprechen können |
|---|---|---|
| Vor Discovery | One-Pager, Deck, Notizen | Nur Spanne (Ballpark) |
| Nach Discovery | D1–D9, abgestimmte Annahmen | Schätzung Phase eins, Festpreis für die Phase |
| Nach Sign-off | Unterzeichneter Scope + Vertrag | Kickoff Entwicklung |
Discovery ist nicht „Spec upfront“ — es ist der Weg zum Anforderungspaket
Ein häufiges Scheitermuster auf beiden Seiten:
- Der Kunde will Budget und Zeitplan, während Anforderungen noch in einem kurzen Brief oder im Kopf leben.
- Der Anbieter will alles in Anforderungen geschrieben haben, bevor er eine Zahl nennt.
Beide überspringen Discovery selbst — die gemeinsame Arbeit, die das Anforderungspaket erzeugt. Das Discovery-Ergebnis kann umfangreich sein (modulares SRS, Rollenmatrix, Flows, NFR-Tabellen) — aber das ist der Ausgang der Phase, keine Voraussetzung, „mit Engineers zu sprechen“.
Discovery friert nicht jeden Edge Case vor dem Release ein. Es erzeugt entscheidungsreife Klarheit: genug, um Phase eins zu schätzen, ein Team zu besetzen und die Entwicklung auf abgestimmtem Scope zu starten — ohne vorzutäuschen, Unbekanntes existiere nicht.
Für Produktunternehmen verlangsamt erschöpfende Frühdokumentation oft das Lernen. Prioritäten und Hypothesen zählen mehr als jeder Edge Case vor dem ersten Release. Das Ziel ist keine Perfektion. Das Ziel ist eine Software-Scope-Definition, die alle ausführen und überarbeiten können.
Business-Ziele und Priorisierung schlagen erschöpfende Dokumentation
Behandeln Sie Discovery-Dokumente als Entscheidungswerkzeuge, nicht als Compliance-Papierkram.
Genug für Discovery:
- Problemstellung und Erfolgsmetriken
- Zielnutzer und Top-Workflows (typisch 5–15 Kernflows)
- Must-have-NFRs (Security, Performance, Availability) auf Prioritätsniveau
- Explizite Out-of-scope-Liste
- Phasierung: MVP vs. spätere Releases (MoSCoW o. ä.)
Gegen eine Phase schätzen, nicht gegen ein Fantasie-Backlog. „Alles in v1“ ist, wie Festpreisprojekte scheitern. MoSCoW hilft: Must für MVP, Should/Could für v2+. Ihr Partner sollte Must für Phase eins bepreisen, mit Optionen für das Danach.
Festpreis für ein gesamtes mehrjähriges Produkt ohne Discovery ist ein verstecktes Risiko. Festpreis für eine unterzeichnete Phase, Time & Materials mit Cap oder Hybridmodelle sind oft ehrlicher. Siehe Engagement-Modelle: Vor- und Nachteile, wenn Sie von Schätzung zum Vertrag gehen.
Was Sie vorbereiten vs. was ein Dev-Partner liefert
Sie müssen keine fertige technische Spezifikation übergeben. Sie müssen Business-Kontext und Prioritäten besitzen. Der Partner strukturiert Workshops, entwirft Artefakte, prüft Feasibility und baut die Schätzung.
| Bereich | Kunde | Entwicklungspartner (Discovery) |
|---|---|---|
| Business-Ziele und Erfolgsmetriken | Accountable / Responsible | Consulted |
| Prioritäten (MVP vs. später) | Approves | Facilitates, challenges |
| Stakeholders und Fachexperten | Provides access | Runs workshops |
| Bestehende Materialien (Pitch Deck, Notizen, Legacy-Docs) | Provides | Structures, Gap-Analyse |
| Compliance / rechtliche Interpretation | Accountable | Informed (Engineering-Impact) |
| User Journeys und Stories (Entwurf) | Consulted | Responsible |
| NFR-Matrix (Entwurf) | Consulted | Responsible |
| Integrationsinventar | Consulted | Responsible |
| Architektur-Optionen und Trade-offs | Informed | Responsible |
| Risiken und Annahmen | Joint | Facilitates |
| Budget- und Zeitplan-Schätzung | Reviews | Responsible (Spannen + Annahmen) |
| Sign-off Scope Phase eins | Approves | Consulted |
Praktische Regel: Sie bringen Kontext und Entscheidungen; der Partner macht daraus ein schätzungsreifes Paket.
Checkliste Discovery-Deliverables (Output vor Entwicklungsstart)
Am Ende von Discovery sollten Sie ein abgestimmtes Paket haben — siehe Teil 1 (SRS, Rollen, Flows, Ordner, Schätzungsanfrage). Unten der komprimierte D1–D11-Index:
| # | Deliverable | Zweck |
|---|---|---|
| D1 | Scope Brief (in / out / Phasen) | Begrenzt die Schätzung |
| D2 | Vision oder PRD lite | Ziele, Personas, Probleme |
| D3 | Priorisiertes Backlog (MVP vs. später) | Phasenbasierte Preisbildung |
| D4 | User Stories + Acceptance Criteria (Top-Flows) | Vertragsbasis Phase eins |
| D5 | NFR-Matrix (must / should / could) | Jenseits funktionaler Features |
| D6 | Integrationskatalog | API- und Datenfluss-Komplexität |
| D7 | Architektur-Richtung (Optionen, kein mehrjähriges HLD) | Feasibility |
| D8 | Risiko- und Annahmenregister | Transparente Schätzung |
| D9 | Roadmap und Phasierung | MVP → v1 → v2 |
| D10 | Detaillierte Schätzung und Budgetplan | Kommerzielle Entscheidung nach Abstimmung D1–D9 |
| D11 | Wireframes oder PoC (optional) | UI-lastige oder hochunsichere Fälle |
Minimum, um der Zahl zu vertrauen: D1, D3, D4 (Top-Flows), D5 (Prioritäten), D8 — dann D10. Ohne D1–D9 bleibt jede Einzelzahl eine Schätzung im Dunkeln.
Unser Entwicklungsansatz beschreibt Discovery als Stufe eins: Kommunikation, Research und gemeinsamer Entwicklungsplan mit detaillierter Schätzung, Roadmap und Budget-Alignment.
Was „gut genug für die Schätzung“ aussieht
Nicht jedes Gespräch verdient dieselbe Tiefe.
| Stufe | Wann | Was Sie bekommen |
|---|---|---|
| Ballpark | One-Pager + kurzer Call | Breite Spanne; Annahmen gelistet |
| Discovery-Output | Ca. 1–3 Wochen Workshops | Paket D1–D9 (+ D11); dann D10 |
| Fixed Phase | Nach Sign-off auf Stories und Annahmen | Preis für MVP oder Phase eins |
| Volles Festpreis-Produkt | Selten ohne PoC | Nur bei niedriger Unsicherheit |
Schätzungspaket (Checkliste):
- Scope in und out
- Fünf bis fünfzehn Kern-Workflows
- NFR-Prioritäten
- Integrationsliste (read / write / batch, soweit bekannt)
- Explizit besessene Annahmen und Risiken
Ohne das behandeln Sie jede Einzelzahl als Guess. Fordern Sie Spannen und was die Schätzung ändern würde.
MVP und Startup: Was Founder mitbringen
Early-Stage-Founder schreiben oft ein Founder-Anforderungsdokument in Notion oder Google Docs und mailen es an mehrere Anbieter. Angebote, die um den Faktor 3× bis 10× differieren, spiegeln meist unterschiedlichen impliziten Scope wider — nicht Unehrlichkeit.
Sie brauchen keine 80-seitige Spezifikation, um Discovery zu starten. Am Ausgang von Discovery kann das Paket detailliert sein — das ist normal und trennt Schätzung vom Raten.
Typischer Input reicht:
- Pitch Deck oder One-Pager
- Bullet-Liste Features und Wettbewerber („wie X, aber einfacher“)
- Zielnutzer und Value-Hypothese
- Drei bis sieben Kern-User-Flows
- Budget- und Zeitkorridor
- Definition von MVP-Erfolg
Das ist Input für Discovery. Discovery strukturiert ihn, schließt Lücken und erzeugt das Anforderungspaket und den MVP-Scope, den Sie für Phase eins bepreisen können. Erst dann — MVP-Entwicklung und Delivery.
Nach MVP-Launch ist laufendes Product Management (Backlog Grooming, Metriken, Pivots) eine eigene Disziplin. Discovery bringt Sie zu einer glaubwürdigen Schätzung Phase eins; es ersetzt keine tägliche Product Ownership.
RFPs und Ausschreibungen bei noch unscharfen Anforderungen
Procurement setzt manchmal Deadline und Budget fest, während funktionale Anforderungen undefiniert bleiben. Anbieter bieten dann auf Vermutungen. Der niedrigste Preis gewinnt, bis Change Requests erscheinen.
Bessere Praxis:
- Einen Klärungs- oder Discovery-Schritt im Prozess vorsehen
- Ein gemeinsames Antwortformat verlangen: Annahmen, Phasenschätzung, Time-and-Materials-Option
- Unbekanntes als [ASSUMPTION] markieren, damit Antworten vergleichbar sind
Ein bindender Festpreis auf fünf generische Absätze ist ein vorhersehbarer Konflikt. Phasenangebote nach Discovery schützen beide Seiten.
Discovery bei Smartym Pro
Wir behandeln Discovery als erste Stufe der Delivery, nicht als Verkaufszubehör. Workshops alignen Ziele und Constraints; Research deckt Stack, Integrationen und Patterns ab; gemeinsam definieren wir Phasierung und erzeugen detaillierte Schätzung und Budgetplan. Bei Bedarf ergänzen wir Wireframes, UI-Design oder einen Proof of Concept vor der Entwicklung.
Discovery-Output speist denselben SDLC, den wir in der Delivery nutzen: klarer Scope, reviewbare Quality Gates und transparentes Reporting nach Kickoff. Siehe Code-Qualität und SDLC-Kontrollen für die Fortsetzung in den Build.
Für Custom Products jenseits MVP teilen Web Application Development und verwandte Practices dieselbe Discovery-Disziplin.
Serie: Teil 1 — Anforderungspaket · Teil 3 — KI und Prompts
FAQ
Ist das vor oder während der Entwicklung?
Discovery und Artefaktpaket kommen vor Sprint Zero. Entwicklung startet nach Sign-off Phase eins und Vertrag.
Können wir ohne Discovery einen Festpreis bekommen?
Nur bei sehr niedriger Unsicherheit und eng begrenzter Phase. Sonst erwarten Sie eine Spanne oder zuerst ein bezahltes Discovery-Engagement.
Reicht mein Founder-Dokument?
Es ist ein starker Start, wenn Nutzer, Kernflows und Constraints abgedeckt sind. Erwarten Sie Lücken; Discovery füllt sie.
Wie lange dauert Discovery?
Oft ein bis drei Wochen für fokussiertes MVP oder Modul; länger bei Enterprise oder Brownfield-Programmen.
Brauchen wir Wireframes für eine Schätzung?
Nicht immer. UI-lastige Produkte profitieren von Low-Fi-Flows oder Referenzen vor festem UI-Scope.
Was ist mit Brownfield und Legacy?
Integrationsinventar, Migrations-Scope und Technical-Risk-Review zum Deliverable-Set hinzufügen.
Fazit
Eine glaubwürdige Budget- und Zeitplan-Schätzung erfordert abgeschlossene Discovery: ein abgestimmtes Anforderungspaket (D1–D9), ehrliche Annahmen — und erst dann D10 und Vertrag. Das kommt immer vor Entwicklungsstart, außer das Projekt ist ein trivialer Ballpark.
Ob Sie Founder mit MVP-Scope sind, ein Product-Team eine Release plant oder Procurement Angebote vergleicht: bestehen Sie auf Discovery-Phase-Deliverables, bevor Sie eine Einzelzahl als final behandeln.
Wenn Sie einen Discovery-Workshop, ein schätzungsreifes Backlog oder Hilfe brauchen, frühe Notizen in einen Phasenplan zu überführen — schreiben Sie uns. Wir helfen Teams von der Idee zur Delivery mit Scope- und Engineering-Disziplin, die dazu passt, wie Software wirklich gebaut wird.
Disclaimer: Dieser Artikel ist allgemeine Orientierung zur Delivery-Praxis, keine Rechts- oder Beschaffungsberatung.