faq-database.de

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Pre-Words ======

Jemand hat Ihnen gesagt, dass Sie vielleicht nicht die ursprüngliche Ausgabe erzählen, also lesen Sie dies bitte sorgfältig.

===== Wikipedia =====

 (([[https://en.wikipedia.org/wiki/XY_problem|Wikipedia Über das X und Y Problem]]))
<WRAP center round info 100%>
Das XY-Problem ist ein Kommunikationsproblem, das in Helpdesk- und ähnlichen Situationen auftritt, in denen die Person, die um Hilfe bittet, das eigentliche Problem X verschleiert, weil sie, anstatt direkt nach dem Problem X zu fragen, nach der Lösung eines sekundären Problems Y fragt, von dem sie glaubt, dass es ihr ermöglicht, das Problem X zu lösen. Die Lösung des Problems Y löst jedoch oft nicht das Problem X oder ist ein schlechter Weg, es zu lösen, und die Verschleierung des eigentlichen Problems und die Einführung des potenziell seltsamen sekundären Problems kann dazu führen, dass die Person, die zu helfen versucht, unnötige Kommunikationsschwierigkeiten hat und/oder schlechte Lösungen anbietet.

Das XY-Problem tritt häufig in der technischen Unterstützung oder im Kundendienst auf, wenn der Endbenutzer versucht hat, das Problem selbst zu lösen, und die wahre Natur des Problems missversteht, weil er glaubt, dass sein eigentliches Problem X bereits gelöst wurde, abgesehen von einem kleinen Detail Y in seiner Lösung. Die Unfähigkeit des Support-Personals, das eigentliche Problem zu lösen oder die Art der Anfrage zu verstehen, kann beim Endbenutzer Frustration hervorrufen. Die Situation kann deutlich werden, wenn der Endbenutzer nach einem scheinbar unbedeutenden Detail fragt, das in keinem Zusammenhang mit einem nützlichen Endziel steht. Die Lösung für das Support-Personal besteht darin, bohrende Fragen zu stellen, warum die Informationen benötigt werden, um das Grundproblem zu identifizieren und den Endbenutzer von einem unproduktiven Weg der Anfrage wegzulenken.
</WRAP>

----

==== Stack Exchange ====
 (([[https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem|StackExchange über das X- und Y-Problem]]))

<WRAP center round info 100%>

Was ist das? \\
Beim XY-Problem geht es eher um Ihren Lösungsversuch als um Ihr eigentliches Problem. \\
 \\
Das heißt, Sie versuchen, Problem X zu lösen, und denken, dass Lösung Y funktionieren würde, aber anstatt nach X zu fragen, wenn Sie auf Probleme stoßen, fragen Sie nach Y. \\
 \\
====== Das Problem ====== \\

Dies kann zu Frustration bei denjenigen führen, die versuchen, Ihnen bei der Lösung des Problems zu helfen, denn wenn Sie danach fragen, hat die Lösung, bei der Sie Hilfe benötigen, möglicherweise keine offensichtliche Verbindung zu dem Problem, das Sie zu lösen versuchen.

Wie man es vermeidet
Um zu vermeiden, dass Sie in diese Falle tappen, sollten Sie bei jedem Lösungsversuch immer auch Informationen über ein breiteres Bild mitliefern. Wenn jemand um weitere Informationen oder insbesondere um eine spezifischere Frage bittet, geben Sie Details an. Wenn es andere Lösungen gibt, von denen Sie glauben, dass sie vorgeschlagen werden, und die Sie bereits ausgeschlossen haben, dann versuchen Sie nicht, sie zu vermeiden, sondern geben Sie an, warum Sie sie ausgeschlossen haben, da dies mehr Informationen über Ihre Anforderungen liefert und anderen hilft, bessere Antworten zu geben.

== Ein Beispiel ==


Eine aktuelle IRC-Konversation zur Veranschaulichung: \\

<WRAP center round help 90%>

F: Gibt es eine Funktion, die eine Zeichenkette zwischen zwei Begrenzungszeichen zurückgibt? \\
B: Ich verstehe nicht, was Sie meinen, aber ich bezweifle, dass es bereits eine Funktion gibt \\
C: Splitten und Schneiden \\
D: Partitionieren auch \\
F: Ich habe versucht zu partitionieren \\
F: Ich habe versucht, Build-Ins zu verwenden, um die Zahl zwischen etwas wie diesem in einer Zeichenfolge "Attribut1: 50.223, Attribut2: 442.1" zu erhalten \\
D: Warum nicht einfach die Zeichenkette parsen? \\
F: Ich dachte, es gäbe vielleicht ein paar eingebaute Parsing-Funktionen \\
D: pairs = [x.strip() for x in s.split(",")]; attribs = {k: v for x in pairs for k, v in [x.split(": ")]} \\
D: Es gibt ein paar Bibliotheken, aber einfache Formate sind einfach genug -- wenn man sich nicht um die Fehlerbehandlung kümmert \\
D: Die Änderung des Quelltextes in ein bekanntes Format, z. B. json oder yaml, ist vorzuziehen, wenn möglich. \\
F: Dieser Code stammt eigentlich aus HTML \\
Q: Aber ich weiß nicht, wie ich Javascript mit HTMLParser oder wie auch immer es heißt, analysieren kann \\
D: Ist es lediglich in HTML eingebettet oder eine verstümmelte Version von HTML? \\
F: Es ist in HTML eingebettet \\
D: Wenn es JavaScript ist (und das ist es, abgesehen von den fehlenden äußeren Klammern), kann JSON es wahrscheinlich parsen \\
F: Danke \\
D: Ich habe es nicht ausdrücklich gesagt: JSON parst nur Datenstrukturen, nicht JS-Code \\
F: Das ist alles, was ich brauche, ist eine Datenstruktur. \\
</WRAP>

Das Problem ist //eigentlich// um das Parsen von JavaScript-Datenstrukturen und nicht darum, "eine Zeichenkette zwischen zwei Begrenzungszeichen" zu finden, und doch braucht man ziemlich viel Zeit und Intuition, um das eigentliche Problem zu erkennen.

Dies ist in einem vollständig interaktiven Chat (egal in welchem Modus) leichter zu bewerkstelligen, aber auf einer SE-Website, wo man einen Beitrag ein wenig aufpoliert, ihn veröffentlicht und dann 5-30 Minuten oder länger Zeit hat, bevor man ein Feedback erhält, ist es wirklich hilfreich, von Anfang an die richtige Richtung einzuschlagen.
</WRAP>

----

==== XYProblem.info ====
 (([[https://xyproblem.info/|xyproblem.info über das X- und Y-Problem]]))


Beim XY-Problem geht es um den Lösungsversuch und nicht um das eigentliche Problem. Dies führt zu einer enormen Verschwendung von Zeit und Energie, sowohl auf Seiten der Hilfesuchenden als auch auf Seiten derjenigen, die Hilfe anbieten.
\\
<WRAP center round info 90%> \\
Der Benutzer möchte X tun. \\
Der Benutzer weiß nicht, wie er X machen soll, glaubt aber, dass er sich zu einer Lösung durchfummeln kann, wenn er nur Y machen kann. \\
Der Benutzer weiß auch nicht, wie er Y machen soll. \\
Der Benutzer bittet um Hilfe bei Y. \\
Andere versuchen, dem Benutzer bei Y zu helfen, sind aber verwirrt, weil Y ein seltsames Problem zu sein scheint, das sie lösen wollen. \\
Nach viel Interaktion und verschwendeter Zeit wird schließlich klar, dass der Nutzer wirklich Hilfe bei X sucht und dass Y nicht einmal eine geeignete Lösung für X war. \\
Das Problem tritt auf, wenn Menschen sich auf das versteifen, was sie für die Lösung halten, und nicht in der Lage sind, einen Schritt zurückzutreten und das Problem vollständig zu erklären. \\
</WRAP> \\

== Was kann man dagegen tun? ==

<WRAP center round important 90%>
Geben Sie bei jedem Lösungsversuch auch Informationen über ein breiteres Bild an. \\
Wenn jemand um weitere Informationen bittet, geben Sie Details an. \\
Wenn es andere Lösungen gibt, die Sie bereits ausgeschlossen haben, teilen Sie mit, warum Sie sie ausgeschlossen haben. So erhalten Sie mehr Informationen über Ihre Anforderungen. \\
Denken Sie daran, dass Sie nicht um Hilfe bitten würden, wenn Ihre diagnostischen Theorien zutreffend wären, oder? \\

</WRAP>


---

# Beispiele
Beispiel 1
n00b will eigentlich nicht die letzten 3 Zeichen eines Dateinamens, sondern die Dateierweiterungen. Warum also nach den letzten 3 Zeichen fragen? \\
\\
<WRAP center round help 90%> \\
<n00b> Wie kann ich die letzten drei Zeichen eines Dateinamens ausgeben?  \\
<feline> Wenn sie in einer Variablen stehen: echo ${foo: -3}  \\
<feline> Warum 3 Zeichen? Was wollen Sie WIRKLICH?  \\
<feline> Willst du die Erweiterung?  \\
<n00b> Ja.  \\
<feline> Es gibt keine Garantie, dass jeder Dateiname eine Erweiterung mit drei Buchstaben hat, \\
<feline> Das blinde Greifen nach drei Zeichen löst das Problem also nicht. \\
<feline> echo ${foo##*.} \\
</WRAP>

== Beispiel 2 ==

Hätte Angela zu Beginn einfach erklärt, dass sie verhindern will, dass andere ihr Betriebssystem entdecken, wäre die Diskussion viel kürzer und produktiver gewesen.

<WRAP center round help 90%> \\
Angela: 'nmap -O -A 127.0.0.1' gibt einige Zeilen zurück, die mit 'OS:' beginnen. Wie kann man das ändern? \\
Obama: Schauen Sie in den Quellcode von nmap, finden Sie heraus, wie es den Linux-Teil herausfindet, und schreiben Sie dann Ihren TCP/IP-Stack so um, dass er nicht auf eine Weise funktioniert, die nmap erkennen kann. \\
Angela: Ja, aber ich weiß überhaupt nichts über die Linux-System-Api. \\
Obama: Nun, der Fingerabdruck von nmap basiert auf der Art und Weise, wie der TCP/IP-Stack funktioniert, es gibt keine andere Möglichkeit, als die entsprechenden Teile des Stacks neu zu schreiben. \\
Angela: Ich muss diese Nachrichten wirklich vermeiden. Kann iptables diese Arbeit erledigen? \\
Obama: Nun, verwenden Sie keine OS-Erkennung oder Versionsüberprüfung \\
Angela: Ich möchte verhindern, dass andere den Typ meines Betriebssystems kennen. \\
</WRAP>

----

====== Schlussfolgerungen ======

Das X- und Y-Problem kann so gelöst werden, dass man vollständig sagt, was man tun will und was man versucht hat.