Sie haben sich grundsätzlich geeinigt, dass eine maßgeschneiderte Softwarelösung für Ihr Unternehmen sinnvoll ist. Das erste Gespräch mit einer Entwicklungsfirma verlief vielversprechend. Dann fallen die Worte: „Wir starten mit einer Discovery-Phase."
Für viele Unternehmer beginnt hier die Verwirrung. Was bedeutet das überhaupt? Wie lange dauert das? Warum kann man nicht einfach direkt anfangen?
Dieser Artikel erklärt, wie die Discovery-Phase aus Ihrer Perspektive aussieht — was tatsächlich passiert, was Sie beitragen müssen und was Sie am Ende in den Händen halten sollten.
Was die Discovery-Phase eigentlich ist
Die Discovery-Phase — manchmal auch Anforderungserhebung, Analyse oder Scoping genannt — ist der strukturierte Prozess, um genau herauszufinden, was gebaut werden muss, bevor irgendjemand eine Zeile Code schreibt.
Es handelt sich um eine Arbeitsphase, keine administrative. Echte Gespräche finden statt. Echte Entscheidungen werden getroffen. Das Ergebnis ist nicht nur ein Dokument — es ist ein gemeinsames Verständnis zwischen Ihrem Team und dem Entwicklungsteam darüber, was das System leisten soll, warum es das tun soll und wie es funktionieren soll.
Gut durchgeführt, eliminiert die Discovery das teuerste Softwareproblem überhaupt: das falsche Ding zu bauen. Die Kosten für eine Kurskorrektur während der Entwicklung werden in Wochen und Budget gemessen. Die Kosten für eine Kurskorrektur während der Discovery werden in Stunden gemessen.
Was während der Discovery passiert
Die Discovery dauert für die meisten Unternehmens-Softwareprojekte typischerweise zwei bis sechs Wochen, bei komplexen oder umfangreichen Systemen kann es länger sein. So sieht diese Zeit in der Praxis aus.
Strukturierte Interviews und Workshops
Der Discovery-Prozess ist gesprächsintensiv. Sie treffen sich mit dem Entwicklungsteam — in der Regel ein Business Analyst, ein Solution Architect und manchmal ein UX-Designer — und arbeiten eine strukturierte Reihe von Fragen durch.
Diese Gespräche decken viel ab: wie Ihre aktuellen Prozesse aussehen, wo die Schmerzpunkte liegen, wer das System wie nutzt, was die Ausnahmen und Sonderfälle sind, wie Erfolg aussieht und welche Einschränkungen bestehen (Budget, Zeitplan, regulatorische Anforderungen, bestehende Systeme).
Wundern Sie sich nicht, wenn die Fragen breiter sind als erwartet. Ein guter Analyst hinterfragt nicht nur die oberflächliche Anfrage, sondern erkundet das zugrundeliegende Geschäftsproblem. Die Lösung, die Sie in Ihrem Brief beschrieben haben, kann genau richtig sein — oder es gibt einen besseren Ansatz, der erst sichtbar wird, wenn das gesamte Bild klar ist.
Erfassung des Ist-Zustands
Bevor ein neues System entworfen wird, muss das Team verstehen, was es ersetzen soll — formell oder informell. Das bedeutet, zu dokumentieren, wie Ihre Prozesse tatsächlich funktionieren, nicht wie sie auf dem Papier funktionieren sollen.
Hier erleben Unternehmer häufig eine Überraschung: Die Lücke zwischen dokumentierten Prozessen und gelebter Praxis ist fast immer größer als erwartet. Menschen haben Workarounds entwickelt, informelle Werkzeuge (meistens Tabellen) genutzt und implizites Wissen angesammelt, das nirgendwo aufgeschrieben wurde. Die Discovery bringt all das ans Licht.
Definition des Soll-Zustands
Sobald der Ist-Zustand verstanden ist, verschiebt sich das Gespräch in die Zukunft. Was soll das neue System leisten? Wie soll die Erfahrung für die Nutzer aussehen? Was sind Must-haves, was sind Nice-to-haves und was liegt explizit außerhalb des Umfangs?
Hier werden Anforderungen formuliert — nicht als starre Spezifikation, die jeden Detail einfriert, sondern als strukturierte Beschreibung dessen, was das System erreichen soll. Gute Anforderungen enthalten die Geschäftslogik hinter jeder Funktion, nicht nur die Funktion selbst. Dieser Kontext ermöglicht es Entwicklern, gute Entscheidungen zu treffen, wenn während der Entwicklung Randfälle auftauchen.
Technische Bewertung
Parallel zu den geschäftlichen Gesprächen bewertet das technische Team die Architektur: womit das System integriert werden muss, welche Leistungs- oder Sicherheitsanforderungen gelten, wie die Deployment-Umgebung aussieht und welche technischen Risiken bestehen.
Dies ist für Sie als Kunde größtenteils unsichtbar, fließt aber direkt in die Genauigkeit des Kostenvoranschlags ein, den Sie am Ende erhalten.
Was Sie zur Discovery mitbringen müssen
Discovery ist ein kollaborativer Prozess. Das Entwicklungsteam bringt Struktur und Methodik; Sie bringen das Wissen über Ihr Unternehmen. Keine Seite kann es ohne die andere schaffen.
Verfügbarkeit der richtigen Personen. Die häufigste Ursache für eine langsame oder oberflächliche Discovery ist das Fehlen der richtigen Menschen. Die Person, die den Vertrag unterschreibt, ist nicht immer die Person, die weiß, wie der Prozess in der Praxis funktioniert. Beziehen Sie die Menschen ein, die die Arbeit tatsächlich machen, zusammen mit denjenigen, die Entscheidungen treffen.
Offenheit gegenüber den unordentlichen Teilen. Jedes Unternehmen hat Prozesse, die peinlich manuell sind, Systeme, die niemand ganz versteht, oder Abläufe, die vom Wissen einer einzelnen Person abhängen. Discovery funktioniert am besten, wenn diese Dinge aufgedeckt und nicht versteckt werden. Es gibt keine Bewertung — nur nützliche Informationen.
Klarheit über Einschränkungen. Budget und Zeitplan sind keine Themen, die vermieden werden sollten. Wenn es eine harte Deadline oder eine feste Budgetobergrenze gibt, sagen Sie es frühzeitig. Das prägt, was das Team realistischerweise vorschlagen kann. Ein guter Entwicklungspartner wird innerhalb Ihrer Einschränkungen planen, nicht so tun, als gäbe es sie nicht.
Geduld mit dem Prozess. Unternehmer empfinden Discovery manchmal als frustrierend, weil es sich wie eine Verzögerung anfühlt. Der Instinkt ist, sofort zu bauen. Aber die in der Discovery verbrachte Zeit zahlt sich fast immer während der Entwicklung aus — oft mehrfach. Ein Projekt, das die Discovery überspringt und sofort mit der Entwicklung beginnt, wird fast sicher mehr Zeit und Geld für spätere Korrekturen aufwenden.
Was Sie am Ende haben sollten
Eine abgeschlossene Discovery-Phase sollte Ihnen mehrere konkrete Ergebnisse liefern, nicht nur ein Gefühl des gemeinsamen Verständnisses.
Eine funktionale Spezifikation. Dieses Dokument beschreibt, was das System tun wird — die Funktionen, die Arbeitsabläufe, die Geschäftslogik, die Benutzerrollen und die Integrationen. Es ist kein technischer Bauplan (der kommt später), aber es ist spezifisch genug, dass Sie es überprüfen, korrigieren und mit Vertrauen abnehmen können.
Wireframes oder User Flows. Bei den meisten kundenorientierten oder komplexen internen Systemen entstehen in der Discovery grobe visuelle Skizzen, wie die Benutzeroberfläche funktionieren wird. Das ist kein Design — es ist Struktur. Abstrakte Anforderungen werden konkret, und Lücken werden sichtbar, die schriftliche Beschreibungen übersehen.
Ein abgegrenzter und kalkulierter Kostenvoranschlag. Sobald der Umfang definiert ist, kann das Entwicklungsteam einen genauen Kostenvoranschlag erstellen. Diese Zahl ist deutlich anders als der grobe Budgetrahmen, der zu Beginn genannt wurde — sie basiert auf tatsächlichen Anforderungen und ist die Grundlage für einen Projektvertrag.
Eine priorisierte Feature-Liste. Eine gute Discovery liefert auch Klarheit darüber, was am wichtigsten ist. Wenn Budget oder Zeitplan eine Reduzierung des Umfangs erfordern, sollten Sie genau wissen, welche Funktionen für das Produkt unverzichtbar sind und welche auf eine spätere Phase warten können.
Häufige Bedenken — und ehrliche Antworten
„Wir wissen bereits, was wir wollen. Warum Wochen mit Analyse verbringen?"
Manchmal wissen Unternehmen wirklich genau, was sie brauchen, und die Discovery ist entsprechend kürzer. Aber auch dann muss das technische Team die Anforderungen tief genug verstehen, um genau schätzen und korrekt bauen zu können. Die Frage ist nicht, ob Discovery stattfindet — sondern wie viel davon benötigt wird.
„Wir haben das schon ohne Discovery-Phase gemacht."
Manche Projekte überspringen eine formale Discovery und sind trotzdem erfolgreich — meist wenn der Umfang sehr eng ist, das Team sehr erfahren mit ähnlichen Systemen ist oder die Anforderungen wirklich einfach sind. Aber die meisten Budgetüberschreitungen und Scope-Streitigkeiten in Softwareprojekten lassen sich direkt auf Anforderungen zurückführen, die am Anfang nicht richtig definiert wurden.
„Kann die Discovery Teil des Hauptvertrags sein?"
Ja, und in vielen Fällen sollte es so sein. Manche Entwicklungsfirmen bieten Discovery als eigenständiges Engagement mit einem separaten Vertrag an. Das erlaubt beiden Seiten, die Zusammenarbeit zu bewerten, bevor man sich auf die vollständige Entwicklung festlegt — was oft die klügere Struktur ist, besonders wenn Sie zum ersten Mal mit einem neuen Partner arbeiten.
Ein Hinweis zu Firmen, die es überspringen
Wenn eine Entwicklungsfirma anbietet, sofort mit dem Bauen zu beginnen, ohne einen nennenswerten Anforderungsprozess, sollten Sie aufhorchen. Das ist nicht zwangsläufig ein rotes Tuch — manche Teams arbeiten iterativ und manche Projekte sind tatsächlich einfach genug, um schnell zu starten. Aber es sollte eine Frage aufwerfen: Woher werden sie wissen, was sie bauen sollen?
Wenn die Antwort lautet „das klären wir unterwegs", überträgt dieser Ansatz das Risiko auf Sie. Iterative Entwicklung funktioniert, erfordert aber ein abgestimmtes Backlog, regelmäßige Reviews und strukturierte Entscheidungen über Umfang und Priorität. Informalität ist nicht dasselbe wie Agilität.
Die besten Entwicklungspartner betrachten Discovery nicht als Gemeinkosten, sondern als Grundlage eines vertrauenswürdigen Projekts. Wenn Sie wissen, was Sie bauen und warum, bevor die Entwicklung beginnt, ist alles, was folgt, vorhersehbarer — Zeitplan, Kosten und Ergebnis.
Jedes Softwareprojekt beginnt mit einem Gespräch. Was die Discovery-Phase tut, ist sicherzustellen, dass dieses Gespräch tief genug geht, um wirklich zu bedeuten — bevor die Uhr für den teuren Teil beginnt zu ticken.