Problemlösung in IT-Berufen

In IT-Berufen gehört es zur täglichen Arbeit Probleme zu lösen. Softwareentwicklung als permanente Prototypentwicklung komplexer Systeme provoziert Fehler, bei denen Lösungen gefunden werden müssen. In der Systemadministration sieht das nicht anders aus, auch hier müssen wir tagtäglich Probleme lösen, weil Server überlastet sind oder andere Fehler auftreten.

Ein Zitat von Ellen Ullmann bringt perfekt auf den Punkt, dass Fehler ein normaler Bestandteil des Programmierer-Berufes sind:

“To be a programmer is to develop a carefully managed relationship with error. There’s no getting around it. You either make your accommodations with failure, or the work will become intolerable.”

Was ist ein Problem?

Ist jeder Fehler ein Problem? Haben wir bei jedem Bugfix einen Fall von “Problemlösung”? Um die Fragen beantworten zu können, müssen wir im ersten Schritt klären, was genau ein Problem ist.

Ausgangszustand, Endzustand, Barriere

Ein Problem ist durch drei Bausteine gekennzeichnet. Es gibt einen Ausgangszustand, der in einen gewünschten Endzustand überführt werden soll. Die direkte Überführung verhindert jedoch eine Barriere, die zwischen beiden Zuständen steht.

Ist also “1 + 1 = X” ein Problem? Ich denke nicht. Ausgangszustand ist die linke Seite der Formel, der gewünschte Endzustand ist die Lösung und eine Barriere ist nicht zu erkennen.

Ist “250 * 750 = X” ein Problem? Wahrscheinlich nicht. Die meisten Menschen sollten auch hier die Lösung (den gewünschten Endzustand) ermitteln können, vielleicht unter Einsatz von Papier und Stift.

Ist “((568 * 794)^2 * 493) / 783,23 = X” ein Problem? Ja, für die meisten Menschen ist das ein Problem. Die Barriere zwischen Ausgangs- und Endzustand ist einfach zu groß.

Die letzten beiden Punkte habe ich bewusst mit “die meisten Menschen” beantwortet, da ein Problem ist immer abhängig vom Betrachter zu sehen ist. Eine Barriere kann für einen Menschen vorhanden sein, ein anderer hingegen hat die Lösung im Kopf und nimmt erst gar keine Barriere wahr.

Drei Arten von Barrieren

Man unterscheidet zwischen drei Arten von Barrieren. Um ein Problem lösen zu können, sollte man sich immer bewusst sein, vor welcher der drei Barrieren man sich gerade befindet, da sich die Wege der Problemlösung unterscheiden können.

1. Mittel zur Transformation sind unbekannt

• Ein Dienst, den ich bisher nicht kenne, ist ausgefallen.
• Ich kenne den Befehlssatz nicht.
• Die Mittel, um das Problem zu lösen, sind mir nicht bekannt.

2. Mittel zur Transformation sind zu komplex

• Ein neu eingerichteter Datenbankserver eines neuen Services ist überlastet.
• Die Mittel zur Lösung sind mir zwar bekannt, ich sehe im ersten Schritt aber nicht, welches Mittel ich einsetzen muss.
• Es kann ein Problem der Servereinstellungen sein, ein Hardwareproblem des neuen Servers oder ein Problem im Quellcode des neuen Services.

3. Endzustand ist unbekannt

• Wir haben ein zentrales Stück Infrastruktur, das bisher nicht skalierbar ist, mit einem überlasteten Server.
• Um dieses Problem lösen zu können, muss erst einmal bestimmt werden, wie die entsprechende Infrastruktur skalierbar gemacht werden kann.
• Es muss also im ersten Schritt der gewünschte Endzustand bestimmt werden.

Was ist Problemlösung

Unter der Problemlösung versteht man die Überwindung der oben genannten Barrieren.

Bei Bugfixes bewegen wir uns in der Regel im Bereich der Problemlösung. In vielen Fehlerfällen haben wir die zweite Barriere – die Mittel zur Transformation oder der Quellcode sind zu komplex, dass diese Hürde überwunden werden muss, bevor wir den Fehler korrigieren können.

In anderen Fällen kann aber auch die dritte Barriere auftreten. Durch einen Bugreport muss erst einmal geklärt werden, wie der gewünschte Soll-Zustand aussieht.

Um ein Problem zu lösen eignet sich folgendes Basisvorgehen:

1. Problem definieren
2. Zielanalyse – wie ist der gewünschte Soll-Zustand?
3. Situationsanalyse – welche Mittel stehen mir zur Verfügung, welche Barriere besteht?
4. Plan erstellen
5. Plan ausführen
6. Evaluieren

Arten von Problemlösung

Auch mit dem oben beschriebenen Basisvorgehen lässt sich nicht gleich jedes Problem lösen. Oft blockiert eine “funktionale Gebundenheit” das Überwinden der Barriere. Wir treffen unbewusst bestimmte Annahmen, die das Finden der eigentlichen Lösung unterbinden. Verschiedene Praktiken helfen dabei, Barrieren oder funktionale Gebundenheit zu überwinden.

trial & error

Der einfachste Lösungsansatz ist “trial & error”. Man probiert einen Weg und springt zurück zum Anfang, wenn kein Erfolg in Aussicht ist. In der Regel kommt man mit der Methode nicht allzu weit oder sollte viel Zeit einplanen.

Unterschiedsreduktion

Bei der Unterschiedsreduktion versucht man in jedem Lösungsschritt den Unterschied zwischen Ausgangs- und Endzustand so weit wie möglich zu verkleinern. Die Methode hilft oft beim Lösen von Logikrätseln und kommt bei IT-Problemen eher selten vor.

Ausschließen des Gemeinsamen

Das Ausschließen des Gemeinsamen hilft beim Überwinden von funktionaler Gebundenheit und neuer Ideenfindung. Hat man mehrere Lösungswege erfolglos ausprobiert, überlegt man ganz bewusst, was das Gemeinsame an allen bisherigen Lösungsansätzen ist – und schließt dieses Gemeinsame aus, um einen komplett neuen Lösungsweg zu finden.

Mittel-Ziel-Analyse

Die Mittel-Ziel-Analyse hilft oft bei komplexeren IT-Problemen. Das eigentliche Problem wird hierbei in Teilprobleme zerlegt, die nacheinander erreicht oder gelöst werden. Gerne möchte ich zu unserem Beispiel mit dem unbekannten, ausgefallenen Server zurückzukommen. Das erste Teilproblem könnte also sein, herauszufinden, welche Dienste auf dem Server laufen. Wenn das erreicht ist, kann man sich die Befehlssätze der ausgefallenen Dienste aneignen und so weiter – iterativ arbeiten wir uns zum eigentlichen Problem vor.

Ideen von Bewertung trennen

Auch diese Methode hilft, wenn man sich an einem Problem festbeißt. Man erstellt eine Liste von Ideen für die Lösung, ohne diese Ideen direkt zu bewerten. Man notiert alle Ideen, seien sie auch noch so schlecht oder unrealistisch. Erst wenn es keine weiteren Ideen mehr gibt, schaut man sich die Liste an und bewertet oder entscheidet, welche Ideen man als Nächstes ausprobiert.

Fazit

ITler lösen jeden Tag kleine oder größere Probleme und oft tun wir das nach einem der oben beschriebenen Muster. Hängt man an einem Problem länger fest, ist es immer gut sich bewusst zu machen, um welche Barriere es geht und eine der oben beschriebenen Praktiken anzuwenden.

Quellen
Problemlösen – Wikipedia, Praktisches Problemlösen – Universität Heidelberg