Wenn Sie ein technisches Projekt einem fachfremden Publikum erklären, beginnen Sie mit der Auswirkung, die es verstehen muss. Zeigen Sie danach genug vom Ablauf, damit Belege und Abwägungen nachvollziehbar werden. Fachwörter durch kurze Wörter zu ersetzen hilft nur, wenn dadurch der Gedankengang klarer wird.
Ihre Kolleginnen und Kollegen kennen Kunden, Betriebsabläufe oder Budgets möglicherweise besser als Sie. Ihnen fehlt vielleicht der spezielle Hintergrund eines Architekturdiagramms. Bauen Sie diesen Zusammenhang auf, ohne die Unsicherheit zu entfernen, die für die Bewertung wichtig ist. Aus der vorbereiteten Erklärung kann Presenti einen ersten Folienentwurf aus Text erstellen; die technische Bedeutung muss dabei erhalten bleiben.
Mit der Frage des Publikums beginnen
Notieren Sie Rollen und gewünschte Handlung. Eine Supportleitung muss Kunden ein geändertes Verhalten erklären können. Ein Produktmanager entscheidet über den Umfang eines Pilotversuchs. Eine Finanzkollegin bewertet den Ressourceneinsatz. Dafür werden andere Details gebraucht als bei einer Codeprüfung.
Im Beispiel möchte ein Entwicklungsteam die Freigabe für einen begrenzten Test einer neuen Berichterstellung. Im Raum sitzen Produktverantwortliche sowie Personen aus Betrieb und Support. Sie müssen verstehen, was Nutzende sehen, was schiefgehen kann und welche Belege vor einer breiteren Einführung erforderlich sind.
Das MIT EECS Communication Lab empfiehlt für Folien, Vorwissen zu berücksichtigen, unbekannte Abbildungen einzuführen und jeder Folie eine klare Aussage zu geben. Überlegen Sie daher zuerst, welcher Teil des Ablaufs nötig ist, bevor Sie die gesamte Architektur zeigen.
Vorher und nachher: Berichte über eine Warteschlange erklären
Das folgende System und die Übungsdaten sind erfunden und dienen der Überarbeitung einer Erklärung. Es handelt sich weder um Kundenergebnisse noch um einen durchgeführten Produkttest.
Der erste Titel lautet: „Asynchrone Orchestrierung mit dauerhaften Warteschlangen und idempotenten Workern“. Im Diagramm stehen API-Gateway, Warteschlange, Hintergrundprozesse, Datenbank, Wiederholungspfeile und Überwachungskomponenten. Fachleute erkennen das Muster; andere müssen erst verstehen, was sich beim Anfordern eines Berichts ändert.
Ein verständlicherer Titel ist: „Nutzende können die Berichtsseite verlassen, während der Bericht erstellt wird.“ Darunter steht die vorgeschlagene Folge:
- Eine Person fordert einen Bericht an.
- Die Anwendung bestätigt die Anfrage und speichert einen ausstehenden Auftrag.
- Ein Hintergrundprozess erstellt den Bericht.
- Die Anwendung zeigt das fertige Ergebnis oder einen eindeutigen Fehlerstatus.
Ergänzen Sie direkt am Ablauf: Anfrage angenommen bedeutet nicht Bericht fertig. Eine schnelle Bestätigung kann das Warten anders erlebbar machen, beweist aber nicht, dass die Berechnung schneller abgeschlossen wird.
Microsofts Beschreibung des Warteschlangenmusters zur Lastverteilung erläutert die Trennung eingehender Aufträge von ihrer Verarbeitung. Sie weist auch darauf hin, dass die Warteschlange wächst, wenn dauerhaft mehr Arbeit ankommt, als verarbeitet werden kann. Für die Präsentation wird daraus die Frage: „Was sehen Nutzende, wenn der Rückstau wächst?“
Die entscheidungsrelevanten Fachbegriffe behalten
Manche Begriffe brauchen eine Erklärung, andere können im technischen Anhang bleiben. Definieren Sie einen notwendigen Begriff einmal im Zusammenhang und verwenden Sie ihn danach einheitlich.
| Begriff | Verständliche Erklärung | Damit beantwortbare Frage |
|---|---|---|
| Warteschlange | Ein Ort, an dem ausstehende Berichtsaufträge auf Verarbeitung warten. | Was passiert bei vielen gleichzeitigen Anfragen? |
| Worker | Der Hintergrundprozess, der den Bericht erstellt. | Was arbeitet weiter, nachdem die Person die Seite verlassen hat? |
| Wiederholungsversuch | Ein erneuter Versuch nach einem Fehler oder einer Unterbrechung. | Wie wird ein fehlgeschlagener Auftrag wieder aufgenommen, und wann greift jemand ein? |
| Idempotente Verarbeitung | Denselben Auftrag erneut bearbeiten, ohne unbeabsichtigt ein doppeltes Ergebnis auszulösen. | Was verhindert doppelte Datensätze oder Aktionen bei einer Wiederholung? |
Die Tabelle beweist nicht, dass das System diese Fälle bereits korrekt behandelt. Sie zeigt, was das Entwicklungsteam erklären oder prüfen muss. Tatsächliches Fehlerverhalten, Implementierungsentscheidungen und Testbelege gehören in die Begleitunterlagen.
Als Einstieg kann eine Warteschlange mit einer Reihe wartender Bearbeitungstickets verglichen werden. Nennen Sie die Grenze des Vergleichs: Mehrere Worker und Wiederholungen können die Reihenfolge beeinflussen. Ein einfaches Bild „zuerst hinein, zuerst hinaus“ könnte daher eine Eigenschaft versprechen, die der Entwurf nicht bietet.
Belege verständlich machen, ohne sie zu verstärken
Nutzen Sie diese Zahlen als Schreibübung: Von 100 Berichtsaufträgen werden 90 innerhalb von 60 Sekunden fertig, zehn dauern länger. Angenommen, der vorgeschlagene Zielwert beträgt 95 % innerhalb von 60 Sekunden. Das sind Beispielwerte, keine für diesen Artikel erhobenen Messungen.
| Angabe | Zulässige Schlussfolgerung |
|---|---|
| 90 von 100 Aufträgen sind innerhalb von 60 Sekunden fertig. | Der Anteil innerhalb dieser Zeit beträgt 90 %. |
| Beispielziel: 95 % innerhalb von 60 Sekunden. | Die Stichprobe liegt unter dem Ziel. Eine schnelle Eingangsbestätigung schließt diese Lücke nicht. |
| Es fehlt ein Vergleich mit dem aktuellen System. | Eine Leistungsverbesserung ist damit nicht belegt. |
| Die zehn langsameren Fälle sind nicht aufgeschlüsselt. | Ihre Verzögerungsursache bleibt eine Frage, kein Befund. |
„Die neue Architektur macht Berichte schnell“ ist zu pauschal. Besser: „Die Übungsstichprobe verfehlt das vorgeschlagene Ziel für die Fertigstellungszeit.“ Zeigen Sie Bezugsgröße und Schwelle an der Grafik und erläutern Sie, welche zusätzlichen Belege die Entscheidung verändern würden.
Bei einem echten Vorschlag müssen Start und Ende der Zeitmessung, Arbeitslast, Anzahl der Anfragen und Einbeziehung von Fehlern klar sein. Trennen Sie Beobachtungen, Prognosen und Ziele. Vergleichen Sie bisheriges und vorgeschlagenes System unter vergleichbaren Bedingungen oder erklären Sie die Unterschiede. Der englische Leitfaden zum Data Storytelling vertieft den Weg von Belegen zur Handlung.
Eine Erklärung in sechs Folien
Ersetzen Sie die Beispieldaten vor beruflicher Verwendung durch geprüfte Projektbelege. Die folgende Folge erhält die technische Frage, ohne mit einer vollständigen Systemübersicht einzusteigen.
1. Die heutige Nutzungserfahrung erklären
Titel: „Bei der Berichterstellung warten Nutzende auf der Seite.“
Gesprochene Erklärung: „Im aktuellen Ablauf bleibt die Person hier, bis der Bericht erstellt ist. Wir prüfen einen Ablauf, der die Anfrage bestätigt und das Ergebnis später bereitstellt.“ Zeigen Sie die derzeitigen Schritte, ohne eine nicht gemessene Fehlerquote hinzuzufügen.
2. Die geplante Änderung zeigen
Titel: „Der vorgeschlagene Ablauf trennt Anforderung und Erhalt des Berichts.“
Gesprochene Erklärung: „Die Anwendung erfasst die Anfrage, ein Hintergrundprozess erstellt den Bericht, und die Person sieht dessen Status. Annahme und Fertigstellung sind getrennte Ereignisse.“ Verwenden Sie die vier Schritte statt der kompletten Bereitstellungsarchitektur.
3. Den Wissensstand erklären
Titel der Übung: „90 % sind innerhalb von 60 Sekunden fertig – unter dem vorgeschlagenen Ziel von 95 %.“
Gesprochene Erklärung: „Die Beispielstichprobe enthält 100 Anfragen. Zehn überschreiten die Schwelle. Für eine Verbesserungsaussage brauchen wir repräsentative Messungen und einen Ausgangswert des aktuellen Systems.“ In einer echten Besprechung stehen hier tatsächliche Belege mit ihren Grenzen.
4. Neue Verantwortung sichtbar machen
Titel: „Der neue Ablauf braucht klare Status- und Wiederherstellungsregeln.“
Gesprochene Erklärung: „Nutzende müssen erkennen, ob ein Bericht wartet, fertig oder fehlgeschlagen ist. Der Support muss einen langsamen Auftrag von einem Fall mit Eingriffsbedarf unterscheiden können. Wiederholungen dürfen keine unbeabsichtigten doppelten Ergebnisse erzeugen.“ Verweisen Sie auf die konkreten Entwurfs- und Testfragen im Anhang.
5. Einen begrenzten nächsten Schritt vorschlagen
Titel: „Ein begrenzter Pilotversuch kann Warteerfahrung und Wiederherstellung prüfen.“
Gesprochene Erklärung: „Teilnehmende, Startbedingungen, Messungen, Abbruchkriterien und Verantwortung werden vor Beginn vereinbart. Wir messen Fertigstellung und Fehler zusätzlich zur Eingangsbestätigung.“ Lassen Sie Werte offen, bis die zuständigen Personen sie festlegen.
6. Eine tatsächlich begründbare Entscheidung erbitten
Titel: „Über Pilotversuch und Verantwortung für die Auswertung entscheiden.“
Gesprochene Erklärung: „Wir beantragen den abgegrenzten Test und die Prüfung vereinbarter Belege vor einer breiteren Einführung.“ Verhindert offene Entwurfsarbeit schon diesen Schritt, beantragen Sie zuerst die kleinere nötige Klärung.
Einen Anhang für die nächste Frage bereithalten
Die vereinfachte Erklärung führt zu Details, statt sie verschwinden zu lassen. Verwenden Sie stabile Anhangsbezeichnungen: Architektur und Abhängigkeiten, Messdefinitionen, Testbedingungen, Fehler- und Wiederholungsverhalten, geprüfte Alternativen sowie Verantwortung für Einführung oder Rücknahme. Verweisen Sie von der Hauptfolie auf die passende Seite.
Auf „Sind Berichte jetzt sofort fertig?“ antworten Sie in zwei Teilen: Die Bestätigung ändert sich; die Fertigstellung hängt weiterhin von Verarbeitung und Last ab. Bei „Was passiert im Rückstau?“ zeigen Sie Status- und Wiederherstellungsplan oder benennen die noch offene Entwurfsarbeit.
Erproben Sie die Erklärung mit einer Person aus dem vorgesehenen Publikum. Lassen Sie sie beschreiben, was sich für Nutzende ändert und worüber entschieden werden soll. Bleibt nur „ein schnelleres System“ hängen, muss die Trennung von Annahme und Fertigstellung deutlicher werden.
Vor dem Folienentwurf ein Briefing vorbereiten
Die Vorlage für die technische Erklärung mit sechs Folien enthält Beispielwerte und die entscheidenden Unterscheidungen. Sammeln Sie Publikum, Auswirkung, kurzen Ablauf, notwendige Definitionen, geprüfte Belege, Unsicherheit und gewünschte Entscheidung.
Presenti kann aus diesem Text einen Plan und Folienentwurf vorschlagen. Beteiligen Sie beim Kürzen weiterhin die technisch verantwortliche Person: Ein flüssigerer Satz kann eine wichtige Voraussetzung verlieren.
Erkläre [Projekt] für [Publikum und Rollen]. Diese Personen müssen [Aufgabe] verstehen oder entscheiden. Verwende nur den gelieferten Ablauf und die Belege. Ordne sechs Folien nach Auswirkung, Ablauf, Belegen, Abwägung, nächstem Schritt und Entscheidung. Definiere unbekannte entscheidungsrelevante Begriffe. Erhalte Einheiten, Bezugsgrößen, Unsicherheit und Grenzen. Markiere fehlende Belege, statt sie zu erfinden. Verweise für Implementierungsdetails auf den Anhang.
Hilfreich wird das Gespräch, wenn die Fragen konkreter werden: Welche Voraussetzung ist offen, welcher Nachteil akzeptabel und welcher Beleg als Nächstes nötig? Damit können Entwicklungsteam und Fachkollegen gemeinsam weiterarbeiten.
