Software-Discovery vor der Entwicklung: Das Problem klären, bevor Funktionen gebaut werden
Von Kevin Kröger, Geschäftsführer, Software und Plattformbetrieb
Eine Discovery klärt Nutzer, Arbeitsweg, Kosten des heutigen Problems, harte Randbedingungen, Daten, Schnittstellen und riskante Annahmen, bevor ein Entwicklungspaket festgelegt wird. Ihr Ergebnis ist nicht automatisch ein neues System. Es ist eine belastbare Entscheidung, ob gebaut, integriert, vereinfacht oder bewusst nichts verändert werden sollte.
Warum beginnt Discovery nicht mit einer Funktionsliste?
Eine Funktionsliste übernimmt häufig bereits die vermutete Lösung. Wenn der eigentliche Engpass eine doppelte Datenerfassung, unklare Verantwortung oder eine vertragliche Grenze ist, digitalisiert neue Software womöglich nur den Umweg. Der GOV.UK Service Manual empfiehlt, vor einer Bauentscheidung das Problem, die Nutzer, den Kontext und bestehende Einschränkungen zu verstehen. Deshalb beobachten wir reale Fälle und formulieren zuerst, welches Ergebnis für wen besser werden soll.
Welche Personen und Abläufe müssen betrachtet werden?
Erfasst nicht nur den späteren Hauptnutzer. Vertrieb, Sachbearbeitung, Leitung, Support, Datenschutz und externe Partner sehen andere Teile des Vorgangs. Zeichnet den Weg vom Auslöser bis zum abgeschlossenen Ergebnis, einschließlich Telefon, Papier, Excel und Ausnahmen. Markiert Wartezeit, Nacharbeit, Medienbruch und Entscheidungen. So wird sichtbar, ob ein Portal, eine Schnittstelle, eine Automatisierung oder eine organisatorische Änderung den größten Nutzen bringt.
Wie werden Randbedingungen und Bestandssysteme geprüft?
Dokumentiert Verträge, Fristen, gesetzliche Vorgaben, Identitäten, Datenqualität, Exportmöglichkeiten, Schnittstellen und Betriebswissen. Trennt harte Grenzen von Gewohnheiten, die verändert werden können. Baut für die riskantesten Integrationen einen kleinen technischen Nachweis. Eine zugesagte API ist erst dann eine belastbare Grundlage, wenn Authentifizierung, Datenumfang, Begrenzungen, Fehlerverhalten und Testzugang tatsächlich geprüft wurden.
Was gehört in ein belastbares Discovery-Ergebnis?
Das Ergebnis enthält Problemdefinition, Nutzergruppen, heutigen Ablauf, messbaren Ausgangswert, priorisierte Risiken, Daten- und Systemkarte sowie mehrere Lösungsoptionen. Für die bevorzugte Option werden ein kleiner erster Umfang, Abnahmekriterien, Betriebsanforderungen und offene Entscheidungen beschrieben. Annahmen bleiben sichtbar. Ein klickbarer Prototyp kann den Nutzerweg prüfen, ein technischer Spike die schwierige Integration. Beides ist noch kein Produktionssystem.
Wann ist Stoppen die richtige Entscheidung?
Wenn der Nutzen gering, die harte Abhängigkeit ungelöst oder eine bestehende Lösung ausreichend ist, spart ein Stopp Geld und Folgekosten. Discovery ist erfolgreich, wenn sie eine gute Entscheidung ermöglicht, nicht nur wenn daraus ein Auftrag entsteht. Auch eine einfachere Prozessänderung, bessere Information oder gezielte Schnittstelle kann das Problem lösen. Wird weitergebaut, entsteht aus den geprüften Risiken eine Reihenfolge für Alpha, MVP und späteren Betrieb.
Quellen und Grundlage
Zentrale Aussagen dieses Beitrags wurden anhand der folgenden Primärquellen geprüft.
Häufige Fragen
- Wie lange dauert eine Discovery?
- Das hängt von Risiko und Umfang ab. Sie sollte so kurz wie möglich sein, aber genügend reale Nutzer, Randbedingungen und technische Unsicherheiten abdecken.
- Entsteht dabei bereits Quellcode?
- Nur gezielte Prototypen oder technische Nachweise. Produktionscode ist nicht das Hauptziel, weil die Lösungsentscheidung noch geprüft wird.
- Wer sollte teilnehmen?
- Menschen aus dem realen Prozess, fachliche Entscheider, Technik und die Rollen, die Betrieb, Sicherheit oder Datenschutz später verantworten.