Ein Kunde bittet um eine Bulk-Edit-Maske im Adminbereich. Die Anfrage ist klar, sie lässt sich leicht schätzen, und wir könnten sie in einer Woche liefern. Bau sie, und der Kunde wird sie benutzen, und ein halbes Jahr später sehen seine Montage genauso aus wie heute. Die Maske war nie das, was falsch war.
Die Frage hinter der Frage
Das XY-Problem hat seinen Namen aus Support-Kanälen, wo man seit Jahrzehnten darüber stolpert. Jemand fragt, wie er die letzten drei Zeichen eines Dateinamens bekommt. Hilfsbereite Leute antworten, denn die Frage ist einfach. Zehn Nachrichten später stellt sich heraus, dass er die Dateiendung wollte. Das ist eine andere Frage mit einer anderen Antwort, und der sorgfältig gebaute Substring wäre bei jedem .jpeg und jedem .tar.gz auf der Platte falsch gewesen.
Y ist das, was wirklich weh tut. X ist das, wovon jemand entschieden hat, dass es hilft. Wenn die Anfrage bei einem Entwickler ankommt, ist meistens nur noch X davon übrig. Die Überlegung, die zu X geführt hat, fand in einem Meeting statt, in dem wir nicht saßen, oft Monate vorher, und sie ist inzwischen zu einer Anforderung mit Namen und Budgetposten erstarrt.
Währenddessen sieht nichts davon nach einem Fehler aus. Jeder Schritt ist eine vernünftige Person, die ihren Job macht. Der Grund reist nur schlecht und die Anfrage reist gut, und nach zwei, drei Stationen bleibt eine sauber formulierte Bitte übrig, die niemand mehr auf einen konkreten Vorfall zurückführen kann.
Vier Formen, in denen es auftritt
Der Feature-Wunsch. Eine bestimmte Maske, ein bestimmter Button, manchmal ein Mockup. Das eigentliche Problem sitzt fast immer weiter vorne: Daten kommen in einem Zustand an, der genau die Korrektur nötig macht, die die Maske beschleunigen soll. Baust du sie, hast du das Aufräumen industrialisiert. Das Chaos ist damit bezahlbar geworden und wird nie behoben.
Der Neubau. “Das System muss ersetzt werden.” Manchmal stimmt das. Meistens ist der Schmerz ein Engpass, eine Query, eine Schnittstelle, die zum Monatsende umkippt, und ein Rewrite reproduziert den Engpass getreu, weil niemand aufgeschrieben hat, worin er bestand. Zwei Jahre später steht ein neues System mit dem alten Problem und einem frischen Satz Bugs drumherum.
Die Integration. “Verbindet A mit B.” Die Daten in A sind falsch, alle im Raum wissen, dass sie falsch sind, und alle haben sich still angewöhnt, sie in B von Hand zu korrigieren. Ein Sync repariert die Daten nicht. Er verschiebt den Fehler an eine teurere Stelle und entfernt den Menschen, der ihn bisher abgefangen hat.
Die KI-förmige Anfrage. “Wir hätten gern einen Assistenten dafür.” Gelegentlich richtig. Oft ist die Lösung ein Cronjob und eine Validierungsregel, für die niemand gern Budget freigibt, weil das nicht nach Zukunft klingt. Der Assistent geht leichter durch die Freigabe, und genau deshalb ist er die Anfrage, die bei uns ankommt.
Warum X so schwer aufzugeben ist
Bis wir von X hören, hat der Kunde echte Arbeit hineingesteckt. Er hat gemerkt, dass etwas nicht stimmt, hat nachgedacht, sich für einen Weg entschieden, ihn den Kolleginnen und Kollegen erklärt und so gut verteidigt, dass er es bis in ein Budget geschafft hat. In den meisten Organisationen ist das eine Leistung.
Wenn wir dann nach dem Warum fragen, kommt das nicht als Neugier an. Es kommt als Angriff auf Arbeit an, die intern längst abgenommen wurde. Dazu kommt: die Person, die uns gegenübersitzt, ist häufig nicht die Person mit dem Problem. Sie trägt den Schmerz von jemand anderem aus zweiter Hand, kann die Lösung deshalb flüssig verteidigen und das Symptom überhaupt nicht beschreiben.
Das ist kein Kundenthema
Nichts daran ist spezifisch für Beratung. Die entscheidende Größe ist der Abstand zwischen der Person mit dem Problem und der Person, die die Arbeit macht, und nicht die Frage, wer zahlt. Bei Kunden ist dieser Abstand nur am größten, und es liegt ein Vertrag darüber.
Verkürz den Abstand, und dasselbe passiert eine Nummer kleiner. Aus einem anderen Team kommt ein Ticket mit dem Wunsch nach einer weiteren Spalte im Export, und der Grund dahinter ist, dass jemand weiter hinten jeden Donnerstag zwei Reports von Hand abgleicht. Ein Issue in einem unserer Open-Source-Repos schlägt eine neue Config-Option vor, und drei Antworten später stellt sich heraus, dass die Person um einen Default herumgebaut hat, den wir einfach ändern könnten. Jemand fragt dich nach einer Regex, obwohl die Datei, die er parst, ein Trennzeichen hat.
Wir machen es uns gegenseitig im eigenen Backlog, und unserem zukünftigen Ich. Du schreibst das Ticket über die Lösung, die dir vorschwebte, statt über das Verhalten, das dich gestört hat, und vier Monate später baut es jemand, der nie erfahren hat, worum es eigentlich ging.
Der Abstand ist kein Defekt. Er ist der Grund, warum eine Organisation an mehr als einer Sache gleichzeitig arbeiten kann. Er bedeutet nur, dass der Grund unterwegs verloren geht, jedes Mal, und dass ihn jemand zurückholen muss.
Und jetzt stimmt dir auch noch das Modell zu
In den letzten zwei Jahren ist das aus einem sehr konkreten Grund schwieriger geworden: Frag ein Sprachmodell nach X, und du bekommst ein besseres X.
Es arbeitet in dem Rahmen, den du ihm gibst. Frag, wie man die Bulk-Edit-Maske baut, und du bekommst eine durchdachte Antwort über die Bulk-Edit-Maske, mit Komponentenschnitt, einem Argument für optimistische Updates und einem Abschnitt über Sonderfälle. Das ist gute Arbeit. Es ist zugleich derselbe Fehler wie beim Dateinamen im Support-Kanal, nur in höherer Qualität und erheblich schneller. Das Modell fragt praktisch nie zurück, was eigentlich passiert, wenn du die Maske gar nicht baust, denn danach hast du nicht gefragt, und deiner Rahmung zuzustimmen ist die Form, die eine hilfreiche Antwort hat.
Das Ergebnis: Kunden kommen inzwischen mit fertig ausformuliertem X. Mit Gliederung. Mit Rollout-Plan. Manchmal mit lauffähigem Prototyp, und das ist die stärkste Variante, weil sich gegen etwas, das existiert, sehr schlecht argumentieren lässt. Aus einer Ahnung ist im Modell ein Dokument geworden, und das Selbstvertrauen, das dabei entstanden ist, belegt nichts.
Wir machen das mit uns selbst genauso, und das ist der Teil, den man zugeben sollte. Du stößt auf ein Symptom, kopierst es rein, fragst nach einer Lösung und bekommst eine. Dann die nächste. Drei Fixes später schaust du auf einen Workaround auf einem Workaround, und jeder einzelne Schritt war gut begründet, weil an keiner Stelle jemand gefragt hat, ob das Design darunter stimmt. Das Modell hat die Frage beantwortet. Es war die falsche Frage, und sie kam von uns.
Nichts davon spricht gegen diese Werkzeuge. Dieser Text ist mit ihnen entstanden, und der Hinweis am Ende dieser Seite sagt das auch. Es spricht dagegen, Zustimmung mit Überprüfung zu verwechseln. Das Einzige, was ein Modell von sich aus fast nie tut, ist, deine Prämisse abzulehnen.
Die vier Fragen
Es gibt hier keinen Trick. Es gibt vier Fragen, und sie helfen vor allem deshalb, weil man sie kaum beantworten kann, ohne versehentlich etwas Wahres zu sagen.
Was passiert, wenn wir das nie bauen? Immer zuerst. Die Frage holt die Kosten des Nichtstuns auf den Tisch, wo man sie gegen die Kosten der Arbeit halten kann. Manchmal kommt eine konkrete geschäftliche Folge mit einer Zahl daran, dann ist das Gespräch vorbei und wir bauen. Oft kommt eine Pause und danach die Beschreibung von etwas mäßig Lästigem, das seit drei Jahren mäßig lästig ist.
Zeig mir das letzte Mal, als das wirklich weh getan hat. Nicht den allgemeinen Fall, den konkreten Vorfall. Welcher Tag, wer war betroffen, was hat die Person stattdessen gemacht. Eine echte Geschichte hat Details, die eine hypothetische nie hat, und irgendwo in der Mitte steckt meistens das eigentliche Problem. Gibt es kein letztes Mal, wird für eine vorgestellte Zukunft gebaut. Das ist völlig legitim und ein ganz anderes Gespräch.
Wer hat danach gefragt, und was hat die Person wörtlich gesagt? Fast jede Anfrage wurde mindestens einmal übersetzt, bevor sie bei uns ankommt. Der ursprüngliche Wortlaut trägt das Problem: jemand hat gesagt, er verbringt jeden Montag damit, denselben Import zu reparieren. Die Übersetzung trägt die Lösung: wir brauchen eine Bulk-Edit-Maske. Zum ersten Satz zurückzukommen ist oft die ganze Arbeit, und es dauert ungefähr eine Minute.
Beschreib mir den Ablauf, ohne ein einziges Tool oder Feature zu nennen. Die unangenehmste der vier und die zuverlässigste. Niemand kann einen Prozess lösungsfrei beschreiben, ohne offenzulegen, wozu er da ist. Sie bricht außerdem den Bann des Prototyps, denn der Prototyp hat einen Namen, und die Regel verbietet Namen.
| Gutes Zeichen | Weitergraben |
|---|---|
| Ein datierter Vorfall mit Namen darin | ”Das passiert ständig” |
| Eine Zahl, die jemand verteidigen kann | ”Es wäre einfach viel besser” |
| Die ursprüngliche Bitte im Wortlaut | ”Alle fragen ständig danach” |
| Ein Ablauf ohne Produktnamen | Ein Ablauf als Abfolge von Masken |
Wenn wir X trotzdem bauen
Manchmal hört ein Kunde alle vier Fragen und will danach immer noch X. Das ist in Ordnung, und es ist seine Entscheidung. Ihm gehört das System, er trägt die Folgen, und er hat Kontext, den wir nicht haben. Wir sind Dienstleister und nicht die letzte Verteidigungslinie gegen die Entscheidungen unserer Kunden.
Was sich ändert: Y steht jetzt geschrieben. Es ist in den Notizen, es ist im Ticket, und wenn es in einem Jahr wieder hochkommt, was meistens passiert, muss es niemand von vorn herausfinden. Dafür lohnen sich die zwanzig Minuten schon allein.
Dinge aufzuschreiben hält dich ehrlich. Es fällt schwerer, auf Papier vage zu bleiben als im Gespräch, und eine Lösung, neben der kein Problem steht, sieht auffällig nackt aus.