Beantworte nicht die erste Frage

 (lalitm.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei Performance-Debugging-Tools sollte man auf seltsame Anfragen nicht sofort antworten, sondern zuerst nach dem Hintergrund fragen, denn so werden sowohl das eigentliche Problem des Nutzers als auch Lücken im Tool sichtbar
  • Das geht über die bloße Reaktion auf ein XY-Problem hinaus: Man nimmt die Verwirrung, aus der die falsche Frage entstanden ist, selbst als Ausgangspunkt, um das Verständnis auf Seiten des Nutzers und des Produkts zu vertiefen
  • In Perfetto ist es zwar möglich, Traces für die Berechnung aller Metriken zu verwenden, aber ineffizient; ein dediziertes System zur Metrikerfassung kann geeigneter sein
  • Wenn sichtbare Antwort und tatsächlicher Bedarf auseinanderfallen, wie bei der Anfrage nach einer Trace-Aufteilung, kann eine bestehende Funktion wie periodic trace snapshots der bessere Weg sein
  • Produktänderungen sollten besser erst entschieden werden, wenn sich wiederkehrende Bedürfnisse ausreichend klar gezeigt haben; vorschnell hinzugefügte Funktionen können zu großer technischer Schuld führen

Warum man nicht sofort auf die erste Frage antwortet

  • Wenn Nutzer bei Performance-Debugging-Tools wie Perfetto eine merkwürdig wirkende Frage stellen wie „Wie teile ich einen Perfetto-Trace in mehrere Dateien auf?“, sollte man nicht sofort eine Methode nennen, sondern zuerst fragen: „Warum musst du überhaupt einen so großen Trace erfassen?“
  • Dieser Ansatz geht einen Schritt weiter als das bloße Lösen eines XY-Problems
    • Man übersetzt die Frage des Nutzers nicht einfach in die „eigentliche Absicht“, beantwortet sie und beendet das Gespräch, sondern nimmt die Verwirrung selbst, aus der die falsche Frage entstanden ist, als Ausgangspunkt des Dialogs
    • Der Nutzer gewinnt ein besseres mentales Modell des Tools, und die Entwicklerseite erkennt klarer, an welchen Stellen das Produkt Verwirrung stiftet
    • Am Ende des Gesprächs kann man sogar zu dem Schluss kommen, dass das Produkt selbst geändert werden sollte
  • Diese Herangehensweise ist besonders direkt auf Menschen anwendbar, die Tools für Engineers bauen
    • Auf Consumer-Produkte oder B2B-Services lässt sie sich womöglich weniger direkt übertragen, aber der grundlegende Ansatz kann dennoch nützlich sein

Wie man Anfragen diagnostiziert

  • Nicht jede Frage erfordert ein tiefes Gespräch
    • Einfache und wiederkehrende Fragen, die sich mit einem Verweis auf die Dokumentation beantworten lassen, sind hier nicht gemeint
    • Interessant wird es, wenn schon bei der ersten Anfrage Kontext fehlt und die Frage selbst anders wirkt als üblich
  • Bei seltsamen Fragen sucht man nach dem Punkt, an dem etwas nicht zusammenpasst
    • Prüfen, ob man diese Frage schon einmal gesehen hat; wenn nicht, sollte man sie als ungewöhnliche Anfrage behandeln und bewusst langsamer vorgehen
    • Im Vergleich zu anderen Fragen prüfen, ob sie plausibel ist, und wenn nicht, nach einer allgemeineren Frage suchen, die darunterliegt
    • Prüfen, ob die Anfrage zur Struktur des Tools passt oder ob der Nutzer unbewusst gegen die Architektur anarbeitet
  • Hat man die Unstimmigkeit gefunden, stellt man Fragen, die den fehlenden Kontext sichtbar machen
    • Die unmittelbare Antwort wäre zwar X, aber wegen Grund Y wirkt die Anfrage ziemlich seltsam, daher sollte der Nutzer das größere Problem schildern
    • Wie schnell es dann weitergeht, hängt davon ab, wie gut der Nutzer seine Gedanken vermitteln kann
  • Das Gespräch führt meist zu einer von drei Schlussfolgerungen
    • Der Nutzer verfehlt die Philosophie des Tools
    • Der richtige Weg existiert bereits im Produkt, ist aber schwer zu finden
    • Das Produkt selbst muss geändert werden

Wenn die Philosophie des Tools verfehlt wird

  • Nutzer greifen oft zu einem Tool, ohne genau zu wissen, was sie wollen oder welches Problem sie eigentlich lösen möchten
    • Das ist nicht als Kritik am Nutzer gemeint
    • Teams arbeiten unter begrenzter Zeit und mit begrenzten Ressourcen an Problemen und suchen nach neuen Debugging-Tools, wenn sie nicht weiterkommen
    • Selbst wenn ein Tool einen großen Teil der gewünschten Funktionalität bietet, führen Unterschiede zwischen dem Modell des Nutzers und der tatsächlichen Arbeitsweise des Tools oft zu Feature-Anfragen
  • Ein häufiges Beispiel bei Perfetto ist die Vorstellung, ein Trace sei die universelle Lösung für jede Metrikberechnung
    • Ein Perfetto-Trace zeichnet sehr detailliert auf, was ein Gerät in einem bestimmten Zeitraum getan hat
    • Weil sich Metriken aus einem Trace berechnen lassen, versuchen Nutzer auch Werte wie Framerate oder den Speicherverbrauch einer App vollständig aus Traces zu berechnen
    • Prinzipiell lässt sich jede Metrik aus einem Trace berechnen
  • Aber alle Metriken per Trace zu berechnen, ist ineffizient
    • Das Erfassen und Verarbeiten von Traces ist teuer
    • Selbst wenn man nur eine einzelne Zahl braucht, sammelt man Daten des gesamten Systems
    • Ein dediziertes System zur Metrikerfassung kann dieselbe Aufgabe deutlich effizienter erledigen
  • Tools haben eine Designphilosophie, und Nutzer übersehen sie leicht, weil sie sich auf ihr unmittelbares Problem konzentrieren
    • Es ist wichtig, nicht nur die Nutzung von Perfetto zu erklären, sondern auch zu vermitteln, wie man grundsätzlich an Performance Engineering herangeht
    • Man muss erklären, wie man Themen wie Startzeit, Frame Drops, Speicher und Energieverbrauch denkt und behandelt
    • Nutzer sollten verstehen, welche Tools man sowohl im Normalfall als auch bei Problemen wann einsetzt

Wenn der richtige Weg verborgen ist

  • Manchmal versteht der Nutzer das Problem selbst, weiß aber nicht, wie sich bestehende Tools kombinieren lassen
    • Das Tool ist bewusst leistungsfähig gestaltet, und man kann nicht davon ausgehen, dass andere Teams den gesamten Funktionsumfang vollständig verstehen
    • Wenn man herausarbeitet, was tatsächlich gebraucht wird, stellt sich oft heraus, dass eine Funktion, die für einen anderen Zweck gebaut wurde, den Bedarf bereits erfüllt
  • Die Anfrage nach Trace-Aufteilung ist ein typisches Beispiel
    • Nutzer sagen, sie wollten einen interessanten Abschnitt aus einem langen Trace herausschneiden
    • Der Grund ist, Performance und Visualisierung leichter handhabbar zu machen
    • In diesem Fall kann es aber geeigneter sein, von vornherein gar keinen langen Trace zu erfassen
  • Perfetto bietet bereits periodic trace snapshots
    • Damit zeichnet man statt einer einzigen langen Aufzeichnung wiederholt kurze Aufzeichnungen auf
    • So entfällt überhaupt die Notwendigkeit, einen langen Trace nachträglich aufzuteilen
  • Die Antwort auf die gestellte Frage und die Antwort auf den tatsächlichen Bedarf können unterschiedlich sein
    • Reaktionen wie „Genau das habe ich gebraucht“ sind ein Signal dafür, dass man nicht die gedachte Anfrage, sondern den wirklichen Bedarf gefunden hat

Wenn das Produkt geändert werden muss

  • Manche Antworten legen einen neuen Bedarf offen, der zu größeren Produktänderungen führen kann
    • Solche Fälle sind knifflig
    • Selbst wenn eine Anfrage neu ist, kann der Anfragende womöglich nicht klar ausdrücken, was wirklich gebraucht wird
  • In grundlegender Software sind die Kosten falscher Entscheidungen hoch
    • Deshalb ist es oft besser, etwas erst dann zu bauen, wenn das Fehlen tatsächlich schmerzt
    • Wenn mehrere Teams denselben Bedarf äußern, zeigt sich meist eher der Kern, der es wirklich wert ist, umgesetzt zu werden
    • Diesen Kern aus nur einer einzigen Anfrage herauszufiltern, ist sehr schwierig; deshalb ist Abwarten oft wirkungsvoll
  • Die ad-hoc-UI-Anpassung in Perfetto ist ein Beispiel für eine falsche Entscheidung
    • Leute wollten die UI passend zu ihrem Workflow hacken und beklagten sich immer wieder darüber, dass das schwierig sei
    • In dem Moment, in dem man das zuließ, entstand massive technische Schuld
    • Jede neue Funktion musste mit allen bestehenden Funktionen zusammenspielen, und die gesamte Struktur wurde schnell nicht mehr skalierbar
    • Es dauerte etwa ein Jahr, mit einer sauberen Plugin-API einen Weg aus diesem Problem zu finden
  • Der tatsächliche Bedarf lautete: „Wie kann man die UI für Teams oder Anwendungsfälle personalisieren, ohne dass sich das auf alle Nutzer auswirkt?“
    • Dieser Bedarf wurde anfangs nicht klar formuliert
    • Die Verantwortung, ihn im Fluss der Anfragen früh zu erkennen, lag auf Seiten des Produkts
  • Die Funktion zum „Merge“ von Perfetto-Traces ist ein Beispiel dafür, dass es auch gut laufen kann
    • Viele Leute haben immer wieder danach gefragt, aber sie wurde nicht sofort gebaut
    • Stattdessen gab man Hinweise zu Workarounds und beobachtete die Lage weiter
    • Man wusste, dass eine saubere Umsetzung viel Arbeit ist und sich leicht falsch entwickeln kann
    • Erst nach ausreichendem Verständnis des Problemraums wurde die Funktion im vergangenen Jahr auf wartbare Weise implementiert

Zentrale Lehre

  • Die erste Frage ist oft nicht die eigentliche Frage
    • Bevor man antwortet, sollte man fragen, warum diese Frage überhaupt gestellt wird
    • In manchen Fällen lernt der Nutzer dadurch, wie das Tool sinnvoll eingesetzt werden sollte
    • In manchen Fällen zeigt sich, dass der richtige Weg im Produkt bereits existiert, aber verborgen ist
    • In manchen Fällen kommt man zu dem Schluss, dass es noch nichts gibt, das den Bau wirklich lohnt
    • In manchen Fällen ist man bereit, das nächste große Feature beim ersten Mal richtig statt zweimal zu bauen
  • Das ist eine einfache, aber leicht zu übergehende Technik
    • Der Druck, schnell zu reagieren, ist immer da
    • Schnelle Antworten fühlen sich jedes Mal produktiv an
    • Trotzdem gewinnt fast immer jede Seite mehr als zuvor, wenn man einen Schritt zurücktritt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Der Verfasser sagt zwar, dieser Text gehe weit über das XY-Problem hinaus, aber für mich wirkt er eher wie ein Artikel, der erklärt, wie man mit dem XY-Problem umgeht, und das mit interessanten Einsichten und im Detail.

    • Ich denke nicht, dass das hier wirklich ein Text über das XY-Problem ist. Es ist viel breiter anwendbar als das XY-Problem und auch nicht so riskant wie die Annahme der antwortenden Person: „Das ist ein XY-Problem.“
      Wenn man eine Frage als XY-Problem framed, greift man leicht wieder zu den kontraproduktiven Heuristiken, die Leute benutzen, wenn sie Fragen beantworten, die wie ein XY-Problem aussehen.
      Ich habe unzählige Male um Rat gefragt und musste dann immer wieder erklären, dass Leute um mich herum einfach unterstellt haben, ich hätte ein XY-Problem, bis ich endlich bei jemandem angekommen bin, der tatsächlich gelesen hat, was ich geschrieben hatte. Ich habe das Gefühl, dass die Reaktion auf das XY-Problem in der Programmierkultur falsch kalibriert ist, und dieser Text liest sich wie eine Erwiderung auf diese Überkorrektur.
      Selbst wenn man das Gefühl hat, dass die fragende Person viel weniger weiß als man selbst, ist es wichtig, langsamer zu machen und nicht bloß Pattern Matching zu betreiben. Die Wahrscheinlichkeit, dass es überhaupt ein XY-Problem ist, ist nicht überwältigend hoch, und selbst wenn es eines ist, kann es besser sein, so zu tun, als wäre es keins.

  • Das war ein guter Text. Mir kam dabei derselbe Gedanke von der anderen Seite derselben Medaille: Man muss aufpassen, eine gestellte Frage nicht in eine einfachere Frage umzuschreiben und dann diese zu beantworten.
    Zum Beispiel auf die Frage „Wie groß ist die Entfernung zwischen Amsterdam und San Francisco?“ mit „Mit dem Flugzeug dauert es 12 Stunden“ zu antworten.
    Die Frage bezog sich auf die Entfernung, aber die zu kennen ist schwieriger, während einem die Flugzeit eher einfällt, also beantwortet die antwortende Person stattdessen die einfachere Frage.
    Das sieht man ziemlich oft, und besonders häufig scheint es vorzukommen, wenn es eine Machtungleichheit zwischen fragender und antwortender Person gibt.

  • Aus verschiedenen Gründen haben wir während einer Systemmodernisierung dem Ingress-Router eine 404-Seite hinzugefügt, und das hat Probleme verursacht. Ein Entwickler wollte das alte 404-Verhalten zurück, weil die frühere Seite eine Navigationsleiste und Menüs hatte.
    Beim Nachfragen kam heraus, dass in einigen Kundensetups beim Login immer ein 404 erschien und die Kunden über die alte 404-Seite tatsächlich dorthin navigierten, wo sie hinmussten.
    Für genau solche Momente wurde lolcry erfunden 🤣😭

    • > GET /hyrums-law HTTP/1.1
> Host: ingress.customer.doctor_eval.work
>
< HTTP/1.1 404 Not Found
< Content-Type: text/plain
<
< Wenn die Zahl der API-Nutzer groß genug wird,
< spielt es keine Rolle mehr, was im Vertrag versprochen wurde:
< Auf jedes im System beobachtbare Verhalten
< wird sich irgendjemand verlassen.
<

  • @lalitm, dieses Problem ist älter als das Internet und hat bereits einen Namen: Anforderungsanalyse.
    Ed Yourdon und andere unterschieden zwischen dem Prozess als dem Ergebnis, das ein Benutzer erreichen will, und der Prozedur als der Art und Weise, wie dieses Ergebnis erzielt wird. Einen Kunden darüber zu informieren, dass seine Bestellung versandt wurde, ist zum Beispiel der Prozess; diese Information per E-Mail zu verschicken, ist die Prozedur.
    Nutzer eines Systems neigen dazu, Lösungen so zu betrachten, als wären sie Funktionen des Systems. Programmierer sind da keine Ausnahme, daher gibt es so viele Varianten von „Y in X lösen“. Die Aufgabe des Analysten ist es, aus einer konkreten Implementierungsform die Anforderungen herauszuziehen, und als Ingenieur implementiert man anschließend die Lösung dahinter.
    Vor Kurzem war ich an einer Diskussion beteiligt, ob man das Logging schneller machen sollte, weil syslog(3) manchmal hinterherhinkt und dadurch Ereignisse aus den Logs verschwinden. Aber das eigentliche Problem war kein schnelleres Logging. Benutzer wollen nicht schnelleres Logging, sie wollen ihr Problem lösen. Der Prozess ist, die nötigen Informationen bereitzustellen; alles in Logs zu schreiben, ist nur eine von mehreren möglichen Methoden dafür.
    Yourdon gehörte zu den Leuten, die CASE-Tools befürworteten. Vielleicht wäre das erfolgreich gewesen, wenn das Management Qualität und Produktivität hätte messen können, aber das ist eine Beschwerde für einen anderen Tag.

  • Man sagt zwar, „die Verwirrung, aus der die falsche Frage entsteht, ist selbst eine Chance“, aber wenn man nicht gerade der Top-Experte in einem Gebiet ist, ist es ziemlich schwer, von Anfang an zu beurteilen, welche Frage falsch ist.

    • Stimmt. Außerdem gibt es Fälle, in denen es niemandem hilft, Zeit darauf zu verwenden herauszufinden, welche Besonderheiten einer Organisation zu so einer „falschen“ Frage geführt haben.

  • In Wahrheit sollte man die Frage beantworten.
    Wenn man nicht gerade als Türsteher kostbare mentale Ressourcen bewachen muss, sollte man es wie im Improvisationstheater mit „Ja, und …“ halten. Natürlich kann man hinzufügen, dass es vielleicht auch andere Wege gibt, zum gewünschten Ergebnis zu kommen.
    Wenn man eine festgefahrene Situation auflösen will, ist es besser, nicht nur eine Strategie zu verwenden, sondern alle Strategien, die einem zur Verfügung stehen.

    • Diese Formulierung gefällt mir sehr. Es gibt unzählige Wege, auf denen eine Botschaft missverständlich werden kann, und man braucht mehrere Ansätze, um jemandem zu helfen, zur Wurzel des Problems vorzudringen. Und natürlich ist es nicht immer die andere Person, die etwas missverstanden hat.