Was ist eine Software-Discovery-Phase und warum kommt sie vor dem Code?

Discovery soll die nächste Investitionsentscheidung klarer machen. Halte Problem, vorhandene Belege, Lieferbedingungen und Annahmen fest, die Bauen, Kaufen, Verkleinern oder Stoppen beeinflussen. Das kann vermeidbare Nacharbeit reduzieren, begründet aber keine allgemeine Ersparnis von Wochen oder Monaten.

Wavects Discovery + Roadmap richtet sich an eine Produktrichtung, die klar genug für die Lieferplanung ist. Das veröffentlichte Angebot kostet EUR 3.500 fix, ohne anwendbare Umsatzsteuer, bei einer Dauer von 2 bis 3 Wochen. Bei anschließender Umsetzung durch Wavect wird die Gebühr vollständig von der Baurechnung abgezogen. Architektur, Meilensteine und ein Festpreisangebot für die Umsetzung sind die Kernleistungen. Zugang, Kundenentscheidungen und unterschriebener Umfang bestimmen die Arbeit.

Ist die Nachfrage noch ungeprüft, besprich zuerst die frühe Produktvalidierung. Plane bei Bedarf einen entscheidungsrelevanten Versuch, vereinbare aber Rekrutierung, Interviews, Prototyperstellung, Usability-Sitzungen und technische Testausführung ausdrücklich. Eine Planungsleistung umfasst nicht automatisch jedes empfohlene Experiment.

Mit einem Entscheidungsprotokoll statt einer Wunschliste abschließen

Halte auf einer Seite Käufer, Nutzeraufgabe, aktuellen Behelf, einen vollständigen Zielablauf und die Budgetgrenze fest. Ergänze die riskanteste Annahme, entscheidungsrelevante Evidenz und die Person, die den Umfang freigeben darf. Trenne Nachfrage von technischer Machbarkeit: Eine funktionierende API beweist weder Zahlungsbereitschaft noch wiederholte Nutzung.

Teile den Backlog in Muss, Später und Streichen. Muss umfasst den kleinsten vollständigen Ablauf samt nötiger Kontrollen für sicheren Betrieb. Später enthält nützliche Ergänzungen, die die aktuelle Annahme nicht prüfen. Streichen enthält durch Evidenz widerlegte oder budgetwidrige Ideen samt Begründung. Das entfernt eine Funktion aus diesem Umfang; bei neuer Evidenz darf sie neu bewertet werden.

Halte vor einem Prototypentest fest, welche Entscheidung ansteht und was du bei jedem möglichen Ergebnis tust. Geht es vor allem um eine Integration, kläre zuerst, ob du Zugriff auf eine Testumgebung und repräsentative Daten bekommst und wer die Nutzung freigibt. Fehlt der Nachweis bei der Freigabe, dokumentiere die Abhängigkeit, die verantwortliche Person und den nächsten Prüftermin. Das Servicehandbuch von GOV.UK sieht gezielte Prototypen für riskante Annahmen in der Alpha-Phase vor. Das hilft, das Experiment separat abzugrenzen. GOV.UK-Leitfaden zur Alpha-Phase.

Durchgespieltes Beispiel: Portal für Wartungsanfragen

Dies ist ein vorgeschlagener, separat abgegrenzter Forschungsversuch, keine automatische Leistung des fixen Planungsangebots. Ein klickbarer Prototyp prüft Verständnis und Ablauf; produktive Autorisierung und Weiterleitung brauchen Implementierungstests.

Illustrativ, kein Wavect-Kundenergebnis. Hypothese: Gebäudeverantwortliche können eine vollständige Wartungsanfrage einreichen, ohne dass ein Koordinator sie neu erfasst. Test: Fünf repräsentative Verantwortliche erhalten einen klickbaren Prototyp und realistische Beispielanfragen; beobachtet werden Einreichung und Triage ohne Hilfestellung. Vorab vereinbarte Beispielschwelle: Vier von fünf füllen die Pflichtfelder selbstständig aus, und keine Anfrage landet beim falschen Gebäude. Die kleine Stichprobe prüft Bedienbarkeit, weder Marktnachfrage noch eine statistisch belastbare Erfolgsquote.

Muss: Gebäude auswählen, Problem beschreiben, Eingang bestätigen und mit Zugriffskontrollen an den zuständigen Koordinator leiten. Später: native Apps und automatische Lieferantenempfehlungen. Für diesen Umfang streichen: ein öffentlicher Lieferantenmarktplatz, der den Anfrageprozess nicht prüft. Wird die Schwelle verfehlt, überarbeiten und erneut testen; ist das zugrunde liegende Problem nicht wertvoll, stoppen. Bei Erfolg einen begrenzten Betriebspiloten planen, statt Product-Market-Fit zu behaupten.

Abnahme und Änderungen ausdrücklich regeln

Erfasse für jedes Muss Ausgangszustand, Aktion, erwartetes Ergebnis und einen Fehlerfall. Ergänze Integrationsannahmen, Datenverantwortung, Abhängigkeiten, Nicht-Ziele und Abnahmeverantwortliche. Eine neue Funktion ersetzt vereinbarten Umfang oder benötigt eine ausdrückliche Kosten- und Terminentscheidung. Die Übergabe enthält Erkenntnisse und offene Fragen, damit ein anderes Team damit weiterarbeiten kann.

Die Discovery-Hinweise von GOV.UK helfen, das Problem vor der Umsetzung zu verstehen. Die Anleitung für moderierte Usability-Tests beschreibt die Beobachtung repräsentativer Aufgaben. Die obigen Grenzwerte sind eigene illustrative Planungsannahmen, keine Vorgaben dieser Quellen. Quellen geprüft am 11. November 2026.