Discovery-Phase

Der Begriff stammt aus der agilen Produktentwicklung und hat sich als Gegenentwurf zu einem alten Muster etabliert: dem Projekt, das mit einem Angebot beginnt. Wer auf Basis eines Erstgesprächs einen Festpreis für ein komplexes System nennt, schätzt nicht das Projekt, sondern seine Vertriebschance. Die Discovery-Phase zieht genau hier eine Grenze ein. Sie trennt die Frage „Was ist eigentlich das Problem?" von der Frage „Was kostet die Lösung?", und sie beantwortet die erste, bevor jemand die zweite beantworten darf.

Was in einer Discovery-Phase passiert

Eine Discovery ist keine Meeting-Serie, sondern strukturierte Untersuchungsarbeit. Im Zentrum stehen vier Fragen: Welches Problem soll gelöst werden, und für wen? Wie läuft der betroffene Prozess heute wirklich, nicht wie er im Organigramm steht? Welche technischen und organisatorischen Rahmenbedingungen begrenzen den Lösungsraum? Und lohnt sich die Lösung überhaupt, gemessen an dem, was das Problem heute kostet?

Dahinter steckt eine Einsicht, die im britischen GOV.UK Service Manual, einem der meistzitierten Standards für diese Projektphase, explizit formuliert ist: Am Anfang steht oft eine vorgefertigte Lösung („wir brauchen ein neues Portal"), und die erste Aufgabe der Discovery ist, diese Lösung wieder in ein Problem zurückzuübersetzen. Aus „Wir brauchen eine interaktive Karte unserer Standorte" wird „Wie finden Kunden schneller den richtigen Ansprechpartner?". Die Qualität dieser Umformulierung entscheidet über die Qualität aller späteren Lösungsideen.

Typische Aktivitäten

• Stakeholder- und Nutzerinterviews: Gespräche mit den Menschen, die mit dem System arbeiten werden, und denen, die es bezahlen. Beide Gruppen wollen selten dasselbe.
• Prozessanalyse: Den Ist-Prozess dort anschauen, wo er stattfindet, inklusive der Excel-Dateien, Zurufe und Workarounds, die in keiner Dokumentation stehen und oft der eigentliche Kern des Problems sind.
• Technische Bestandsaufnahme: Welche Systeme sind betroffen, welche Schnittstellen existieren wirklich, wo liegen die Daten, welche Altsysteme setzen harte Grenzen? Die Frage „Hat das ERP eine API oder nur einen CSV-Export per Nachtjob?" gehört in die Discovery und nicht in den dritten Sprint.
• Anforderungs-Priorisierung: Trennen, was in ein erstes produktives MVP gehört und was in spätere Ausbaustufen. Ohne diese Trennung gibt es keinen planbaren Scope.
• Risiko- und Constraint-Analyse: Rechtliche Vorgaben, Verträge, Legacy-Technologie, organisatorische Abhängigkeiten. Das Service Manual unterscheidet harte Constraints, die man akzeptieren muss, von weichen, die man verändern kann.

Die Ergebnisse: woran man eine echte Discovery erkennt

Am Ende einer belastbaren Discovery liegen drei Artefakte auf dem Tisch. Erstens ein priorisiertes Backlog, das MVP-Umfang und Ausbaustufen trennt. Zweitens eine Architekturskizze mit den kritischen Integrationspunkten, denn Integrationen in Bestandssysteme sind der klassische versteckte Kostentreiber. Drittens eine Schätzung, die pro Baustein begründet ist, statt als Gesamtsumme vom Himmel zu fallen. Fehlt eines dieser drei Ergebnisse, war es keine Discovery, sondern ein verlängertes Verkaufsgespräch.

Ein viertes, oft übersehenes Ergebnis ist genauso legitim: die Erkenntnis, nicht zu bauen. Das GOV.UK Service Manual hält ausdrücklich fest, dass ein Stopp nach der Discovery kein Scheitern ist, sondern gespartes Geld, etwa weil eine Standardsoftware das Problem bereits löst oder der Nutzen die Kosten nicht trägt. Eine Discovery, die strukturell nie zu diesem Ergebnis kommen kann, weil der Dienstleister am anschließenden Bauauftrag verdient, hat einen eingebauten Interessenkonflikt, den Auftraggeber kennen sollten.

Dauer, Kosten und Team

Für die Dauer gibt es keinen Normwert, aber einen belastbaren Erfahrungskorridor: Das GOV.UK Service Manual nennt vier bis acht Wochen als typisch, abhängig davon, wie gut das Problemfeld schon verstanden ist. Für ein mittelgroßes Individualsoftware-Projekt im Mittelstand sind zwei bis sechs Wochen ein üblicher Rahmen, oft als eigenständig beauftragtes und bezahltes Arbeitspaket mit definierten Ergebnissen.

Dass die Discovery Geld kostet, ist dabei kein Nachteil, sondern ihr Sinn. Sie verlagert einen kleinen, kontrollierten Teil des Budgets an die Stelle, an der Erkenntnisse am billigsten sind. Ein Anforderungsfehler, der in der Discovery auffällt, kostet ein Gespräch und eine korrigierte Backlog-Zeile. Derselbe Fehler, entdeckt nach dem Go-live, kostet Umbau, Migration und Vertrauen. Die seit Jahrzehnten in der Softwaretechnik diskutierte Kostenkurve der Fehlerbehebung, populär geworden durch Barry Boehms Arbeiten zur Software-Ökonomie, sagt im Kern genau das: Je später ein Anforderungs- oder Designfehler gefunden wird, desto teurer wird seine Korrektur, häufig um ein Vielfaches.

Zum Team einer Discovery gehören typischerweise ein Produkt- oder Projektverantwortlicher, jemand mit Architektur-Kompetenz und, je nach Projekt, UX-Research. Auf Auftraggeberseite braucht es Zugang zu den Menschen, die den Prozess täglich ausführen. Eine Discovery, die nur mit der Geschäftsführung spricht, untersucht das Wunschbild des Prozesses, nicht den Prozess.

Discovery-Phase und klassisches Lastenheft

Die Discovery ersetzt das Lastenheft nicht, sie geht ihm voraus und macht es besser. Der Unterschied liegt in der Richtung: Ein Lastenheft schreibt auf, was der Auftraggeber glaubt zu brauchen. Eine Discovery prüft diesen Glauben, bevor er Vertragsbestandteil wird. In der Praxis ist das Ergebnis einer Discovery oft die inhaltliche Grundlage für Lastenheft und Pflichtenheft, dann aber mit validierten statt vermuteten Anforderungen.

Abgrenzung: Discovery, Design Sprint, Product Discovery

Drei verwandte Begriffe werden gern vermischt. Der Design Sprint nach Jake Knapp (entwickelt bei Google Ventures) ist ein stark verdichtetes Format von fünf Tagen, in dem eine konkrete Produktidee prototypisch getestet wird. Er kann Teil einer Discovery sein, ersetzt sie aber nicht, weil er die technische Bestandsaufnahme und die Wirtschaftlichkeitsfrage ausklammert. Product Discovery bezeichnet in Produktorganisationen einen kontinuierlichen Prozess, in dem laufend geprüft wird, welche Features es wert sind, gebaut zu werden; die Discovery-Phase eines Projekts ist gewissermaßen die einmalige, kompakte Ausgabe davon. Und die Konzeptphase klassischer Vorgehensmodelle wie des V-Modells verfolgt ein ähnliches Ziel, arbeitet aber dokumentgetrieben statt forschungsgetrieben: Sie schreibt Anforderungen fest, während eine Discovery sie zuerst infrage stellt.

Realbeispiel: die Discovery im GOV.UK Service Standard

Das prominenteste dokumentierte Beispiel für institutionalisierte Discovery-Phasen ist der britische Government Service Standard. Seit 2013 durchläuft jeder digitale Dienst der britischen Verwaltung verpflichtend die Phasen Discovery, Alpha, Beta und Live, und das Service Manual des Government Digital Service beschreibt öffentlich, was in der Discovery zu leisten ist: Problem definieren statt Lösung übernehmen, Nutzerkontext verstehen, harte und weiche Constraints identifizieren, Erfolgsmessung festlegen und am Ende bewusst entscheiden, ob es weitergeht. Bemerkenswert ist die Klarheit, mit der dort das Nicht-Weitermachen als Erfolgsfall behandelt wird. Für privatwirtschaftliche Softwareprojekte ist dieses Modell deshalb interessant, weil es zeigt, dass Discovery kein agiles Ritual ist, sondern ein Kontrollpunkt für Investitionsentscheidungen.

Häufige Fehler in der Praxis

Der häufigste Fehler ist die Schein-Discovery: Workshops, deren Ergebnis von Anfang an feststeht, weil das Angebot längst geschrieben ist. Erkennbar daran, dass am Ende keine begründete Schätzung pro Baustein steht, sondern dieselbe Summe wie vorher, jetzt mit Folien. Der zweite Fehler ist die endlose Discovery, die aus Angst vor Festlegung nie in eine Entscheidung mündet; gegen ihn hilft ein hartes Zeitfenster und ein vorab definiertes Ergebnisformat. Der dritte ist die Discovery ohne Techniker: Wenn niemand die Bestandssysteme untersucht, wandern die teuersten Risiken, nämlich Integrationen und Datenqualität, ungeprüft ins Projekt. Und der vierte ist die übersprungene Discovery bei vermeintlich klaren Projekten. Gerade Migrationen und Ablösungen von Altsystemen gelten als „klar", bis die erste undokumentierte Sonderlogik auftaucht, von der drei Sachbearbeiter wussten und kein Dokument.

Ausblick

KI-Werkzeuge verändern derzeit die Mechanik der Discovery, nicht ihren Zweck. Interview-Transkription, die Analyse von Prozessdokumenten und das schnelle Prototyping von Oberflächen beschleunigen die Untersuchungsarbeit spürbar, und Code-Analyse-Tools machen die technische Bestandsaufnahme von Altsystemen gründlicher, als es manuelle Sichtung je war. Was bleibt, ist der Kern, den keine Automatisierung ersetzt: die Entscheidung, welches Problem ein Unternehmen wirklich lösen will und ob es dafür Software bauen sollte. Eine Discovery-Phase ist am Ende genau das, eine kleine, bezahlte Portion Ehrlichkeit am Anfang eines teuren Vorhabens.

FAQ zur Discovery-Phase

Was ist die Discovery-Phase in der Softwareentwicklung?

Die Discovery-Phase ist der erste Projektabschnitt, in dem Problem, Nutzer, Prozesse und technische Rahmenbedingungen untersucht werden, bevor entwickelt wird. Ergebnis sind ein priorisiertes Backlog, eine Architekturskizze und eine pro Baustein begründete Schätzung, oder die bewusste Entscheidung, nicht zu bauen.

Wie lange dauert eine Discovery-Phase?

Das GOV.UK Service Manual nennt vier bis acht Wochen als typisch. Für Mittelstandsprojekte sind je nach Komplexität zwei bis sechs Wochen üblich, oft als eigenständig beauftragtes Arbeitspaket. Entscheidend ist weniger die Dauer als ein hartes Zeitfenster mit vorab definierten Ergebnissen.

Warum sollte eine Discovery-Phase extra bezahlt werden?

Weil sie ergebnisoffen sein muss. Eine kostenlose Discovery finanziert sich über den anschließenden Bauauftrag und hat damit einen eingebauten Anreiz, immer „bauen" zu empfehlen. Ein bezahltes Arbeitspaket mit definierten Ergebnissen kann auch zum Schluss kommen, dass Standardsoftware reicht oder sich das Projekt nicht lohnt.

Was ist der Unterschied zwischen Discovery-Phase und Lastenheft?

Das Lastenheft dokumentiert Anforderungen aus Sicht des Auftraggebers; die Discovery prüft vorher, ob diese Anforderungen das richtige Problem lösen. Idealerweise liefert die Discovery die validierte Grundlage, aus der Lastenheft und Pflichtenheft entstehen, statt dass Annahmen ungeprüft Vertragsbestandteil werden.

Woran erkennt man eine gute Discovery-Phase?

An den Ergebnissen: priorisiertes Backlog mit MVP-Schnitt, Architekturskizze mit den kritischen Integrationspunkten und eine Schätzung, die pro Baustein begründet ist. Und an der Haltung: Ein seriöser Anbieter behandelt „nicht bauen" als mögliches, legitimes Ergebnis, nicht als Betriebsunfall.