Antwort.

Eine standardisierte Präsentation der Lösung für den Kunden (Demo) ist ein wichtiger Teil der Kommunikation zwischen dem IT-Team und den Stakeholdern. Der Business Analyst ist verantwortlich für die Vorbereitung der Struktur, das Sammeln und Beschreiben der Anwendungsfälle sowie die Kontrolle der Vollständigkeit und Logik der Präsentation der Ergebnisse.

Der Business Analyst:

• Bestimmt die Schlüssel-Szenarien (Flows) basierend auf den Anforderungen und den Pain Points des Kunden.
• Erstellt Storyboards oder Checklisten für das Produkt/Prototyp mit dem Fokus darauf, was der Nutzer erwartet.
• Organisiert Feedback, dokumentiert Anmerkungen und Änderungsanfragen.

Die Demonstration sollte kurz, strukturiert sein und nicht alles zeigen, sondern gezielt auf die relevanten Punkte eingehen.

Schlüsselmerkmale:

• Die Szenarien für die Demo sollten die Benutzeraufgaben widerspiegeln und keine technischen Umsetzungen zeigen.
• Die Demo ist keine Prüfung für Entwickler, sondern ein Kommunikationsmittel mit dem Geschäft.
• Dokumentieren Sie immer das Feedback und die korrekten Protokolle.

Fangfragen.

Kann man in der Demo nur zeigen, was „funktioniert“, und teilweise umgesetzte Aspekte ignorieren?

Nein, der Kunde verliert das Vertrauen, wenn er nachträglich von Mängeln erfährt. Man sollte den Fortschritt ehrlich zeigen und Bereiche ansprechen, die Aufmerksamkeit erfordern.

Ist es zwingend notwendig, dass der Business Analyst die Demo persönlich durchführt?

Nein, aber der Analyst sollte derjenige sein, der die Szenarien strukturiert und dafür verantwortlich ist, dass die gezeigten Funktionen aus geschäftlicher Sicht geeignet sind.

Muss man in der Demo alle technischen Details der Entwicklung besprechen?

Nein, das Ziel ist es, den Geschäftswert zu demonstrieren, nicht architektonische Lösungen; technische Details können separat mit den technischen Stakeholdern besprochen werden.

Typische Fehler und Anti-Patterns

• Fehlende strukturierte Szenarien für die Präsentation.
• Präsentation von Funktionen, die nicht mit den realen Aufgaben der Benutzer verbunden sind.
• Versäumnis, Anmerkungen zu sammeln; mündliche Dokumentation des Feedbacks nur von einem Vertreter des Kunden.

Beispiel aus dem Leben

Negativer Fall:

• Bei der Demo für den Kunden zeigte das Team nur die Standardbildschirme und sprach nicht darüber, welche Dialoge gelöst wurden und welche nicht. Der Kunde ging davon aus, dass alles bereit ist, und stellte nach der Implementierung viele Bugs und Schwierigkeiten fest. Vorteile: Schnelle Durchführung der Demonstration. Nachteile: Unklare Bugs, Vertrauensverlust, die Implementierung weicht von den Erwartungen ab.

Positiver Fall:

• Vor der ersten Veröffentlichung erstellte der Business Analyst einen Szenarienplan für die Präsentation (User Flows), der im Voraus mit dem Kunden abgestimmt wurde. Während der Demo wurden alle Fragen und Anmerkungen dokumentiert, auf deren Grundlage Änderungen vor der Veröffentlichung vorgenommen wurden. Vorteile: Hohe Transparenz, die Erwartungen stimmten mit dem tatsächlichen Ergebnis überein. Nachteile: Zeitaufwand für die Vorbereitung eines klaren Szenarios und die Dokumentation des Feedbacks.