Ein Bug-Report kommt zum dritten Mal mit demselben Kommentar zurück: 'Nicht reproduzierbar.' Fünf Absätze Text, ein exakter Schritt-für-Schritt-Ablauf — und trotzdem versteht das Entwicklerteam nicht, was ich meine. Genau der Moment, an dem ich mich frage, ob visuelle Notizen nicht auch beim Bug-Reporting helfen würden, nicht nur in Meetings.
Im dritten Refinement-Meeting der Woche erkläre ich denselben Edge Case zum wiederholten Mal: eine Kombination aus User-Rolle und Rabattcode, bei der die Validierung aussteigt. Ich benutze Wörter wie 'Interdependenz' und 'State-Management'. In den Kacheln der Videokonferenz sehe ich vor allem leere Blicke, während jemand parallel offensichtlich etwas anderes tippt.
Laut Kalender gehen 62 Prozent meiner Arbeitswoche für Meetings drauf. Bevor ich auf Sketchnotes umgestiegen bin, hatte ich mir eine GTD-App eingerichtet — Projekte, Kontexte, sauber getaggt, ein System zum Vorzeigen. Nach drei Wochen hatte ich sie kein einziges Mal mehr geöffnet. Ende letzten Jahres habe ich stattdessen angefangen, Notizen zu zeichnen, aus Verzweiflung, weil ich meine eigenen Protokolle nicht mehr entziffern konnte. Seit Woche 10 probiere ich das jetzt auch fürs Bug-Reporting aus.
Warum niemand meine Bug-Reports liest
Meine Jira-Tickets sind eigentlich vorbildlich: Schritt 1, Schritt 2, erwartetes Ergebnis, tatsächliches Ergebnis. Die Realität im Sprint sieht anders aus. Text wird gescannt, nicht gelesen. Genau dort, wo die Sprache vage bleibt, entstehen die Missverständnisse.
Vor ein paar Wochen hatte ich so einen Fall. Ein Fehler bei der Synchronisierung von Nutzerdaten, das Ticket lang und technisch sauber, sogar mit dem passenden HTTP-Statuscode für den Client-Fehler, eine klassische 400. Trotzdem kam es dreimal zurück. 'Brauche mehr Kontext.' 'Nicht reproduzierbar.'
Das Problem ist nicht die fehlende Information. Es ist die kognitive Last. Ein Entwickler muss sich durch mehrere Absätze wühlen, um das Modell im Kopf zu bauen, das ich beim Schreiben schon hatte. Irgendwann im Frühjahr wurde mir klar: Wenn ich das Modell einfach zeichne, sparen wir uns den Umweg.
Der Stylus quietscht, die Kachel bleibt still
Bildschirm teilen, leere Fläche öffnen, los. Das Quietschen des Stylus auf dem Glas-Display ist für ein paar Sekunden das einzige Geräusch im Call. Neben dem aufgeschlagenen Heft steht ein Glas Wasser, das ich beim Zeichnen zuverlässig vergesse, bis das Eis darin längst geschmolzen ist. Drei Boxen entstehen: Nutzer, Datenbank, API.
Zeichnen kann ich nicht wirklich. Mein 'Nutzer-Icon' sieht eher aus wie eine deformierte Kartoffel, aber der Pfeil zeigt wenigstens in die richtige Richtung. Wo genau hakt der Flow? Ein dicker roter Blitz markiert die Stelle, an der die Datenübertragung stirbt.
Einer der Entwickler unterbricht mich nicht mit einer Rückfrage, sondern sagt nur: 'Ach so, der State-Wechsel hakt, zeig nochmal die Skizze.' Er hat es in Sekunden verstanden, weil die Struktur sofort erkennbar war. An der Logik dahinter ändert kein Symbol etwas. Aber die Zeichnung bringt wenigstens eine Reihenfolge rein, an der sich alle festhalten können.
Wenn die Sketchnote zu vage wird
Es gibt aber eine Falle. Über die letzten Wochen habe ich gelernt, dass Sketchnotes in Bug-Reports die Kommunikation auch verschlechtern können, nämlich immer dann, wenn sie zu interpretierbar sind. Eine hübsche Zeichnung ohne technischen Kontext verwässert genau die Präzision, die ein Entwickler braucht.
Einmal habe ich einen kompletten Workflow nur mit Symbolen dargestellt. Keine IDs, keine Feldnamen, keine Fehlermeldung. Am Ende wusste das Team grob, worum es geht, war aber ratloser als vorher. Die Skizze konnte 'irgendwie alles und nichts' bedeuten. Visuelle Notizen dürfen die technische Tiefe nicht ersetzen. Sie müssen sie einrahmen.
Heute kombiniere ich beides. Der Flow wird grob vorskizziert, die harten Fakten, etwa die konkrete API-Response, stehen direkt daneben in Textform. Diese Mischung aus visuellem Alphabet und nüchterner Logik funktioniert deutlich besser, als ich bei den ersten Versuchen erwartet hätte. Ähnlich handhabe ich es inzwischen bei meinen visuell aufbereiteten Release Notes, wo dieselbe Kombination gegen das Abschweifen im Team hilft.
Ready-Status ohne Kunstwerk
Am Ende des Meetings steht das Ticket auf 'Ready'. Die Abstimmungszeit hat sich gefühlt halbiert. Eine gestrichelte Linie und eine kleine Uhr erklären 'asynchrones Ladeverhalten' schneller als jede fünfte Wiederholung in Worten.
Wie wichtig dieser visuelle Fokus ist, merke ich vor allem, wenn ich das Heft der letzten Wochen durchblättere: eine ganze Woche Meetings auf ein paar Seiten, auf einen Blick lesbar, während dieselbe Information als Ticket-Liste eine mühsame Suche gewesen wäre. Manchmal übertrage ich die Technik auch aufs Sprint Planning, was die Aufmerksamkeit der Stakeholder merklich erhöht. Es geht nicht darum, dass es gut aussieht. Es geht darum, dass die Information ankommt, ohne dass jemand denselben Absatz dreimal liest.
Tablet einpacken, nächster Call wartet schon. Ein Freund von mir trifft sich freitags am Winterhuder Fährhaus und nimmt dort seinen Podcast über Nachhaltigkeitsthemen auf. Für mich klingt das nach der reinsten Erholung, verglichen mit meinen Kritzeleien über State-Machines. 62 Prozent Meetings sind viel. Wenn man aufhört, nur zu reden, und anfängt, Dinge sichtbar zu machen, fühlt sich zumindest ein Teil davon nach Arbeit an und nicht nach Zeitabsitzen.