Discovery-Phase.

In der Discovery geht es um Verstehen, nicht um Beschreiben von Funktionen. Typische Bestandteile sind Gespräche mit den Menschen, die den Ablauf täglich ausführen, eine Aufnahme des heutigen Prozesses samt Umwegen und Zettelwirtschaft, eine Sichtung der bestehenden Daten und Systeme sowie das Sammeln der Randbedingungen: Schnittstellen, Datenschutz nach revidiertem DSG, Aufbewahrungspflichten, Verfügbarkeit interner Ansprechpersonen. Wichtig ist die Trennung zwischen dem, was Menschen sagen, und dem, was sie tun. Beobachtung am Arbeitsplatz liefert regelmässig andere Erkenntnisse als das Meeting darüber.

Am Ende stehen keine Folien, sondern Arbeitsgrundlagen: eine Skizze des Soll-Ablaufs, eine nach Nutzen und Risiko priorisierte Liste der Anwendungsfälle, eine Liste offener technischer Fragen mit Vorschlag, wie sie geprüft werden, sowie eine grobe Kostenspanne mit den Annahmen dahinter. Dazu gehört eine Vorprüfung der Kauf-oder-Bauen-Frage: Existiert am Markt ein Werkzeug, das achtzig Prozent des Bedarfs deckt, muss der Rest die Eigenentwicklung rechtfertigen. Diese Prüfung gehört an den Anfang, weil sie später niemand mehr ergebnisoffen stellt.

Ein Beispiel: Ein Handelsbetrieb möchte ein Kundenportal, weil das Telefon zu viel Zeit frisst. In der Discovery zeigt sich, dass ein grosser Teil der Anrufe eine einzige Frage betrifft — den Lieferstatus — und dass diese Information bereits im Warenwirtschaftssystem liegt. Statt eines Portals wird zunächst eine automatische Statusmeldung per Mail umgesetzt, gefolgt von einer schlanken Statusseite. Das Portal bleibt als spätere Option bestehen. Die Discovery hat hier nicht das Projekt verkleinert, sondern das eigentliche Problem freigelegt.

Zur Ehrlichkeit gehört auch das Mass. Eine Discovery, die Monate dauert und in einem Pflichtenheft mündet, das niemand mehr liest, ist selbst zum Problem geworden. Für ein KMU-Vorhaben reichen meist ein bis drei Wochen konzentrierte Arbeit. Sie ersetzt ausserdem das Testen nicht: Discovery reduziert Unsicherheit über das Problem, nicht über die Lösung. Deshalb endet sie idealerweise mit einem klar geschnittenen nächsten Schritt — einem Prototyp, einem Proof of Concept oder der begründeten Empfehlung, ein Standardprodukt zu kaufen.