Elena LucconeMenschen und Unternehmen

Wo drückt der Schuh? Oder: Nehmen Sie sich Zeit für die wichtigen Dinge?

Wer krank ist, kommt selten auf die Idee, in die Apotheke zu gehen, sich das erstbeste Medikament aus dem Regal zu nehmen oder alle Beipackzettel hintereinander zu lesen, ohne vorher zu überlegen, welche Schmerzen man hat und welche Medikamentengruppen für die Krankheit überhaupt geeignet sind. Niemand käme auf die Idee, im ersten Regal zu suchen, weil es besser beleuchtet ist oder seinen Arzt anzurufen mit der Frage: „Mir ist irgendwie nicht gut. Ich weiß zwar nicht genau was ich habe, aber welche Tabletten soll ich einnehmen?“

Doch im Berufsleben wird interessanterweise genau das manchmal getan. Hier einige Beispiele:

  • „Unsere Anwendung hat Performance-Probleme. Wir haben daher vor, das Datenbank Feature X einzusetzen.“ (Der Hersteller preist es an, daher muss es wohl für alles gut sein.)
  • „Wir machen so viele Überstunden im Moment, weil wir Performance-Probleme haben. Wir haben uns nun zwei Wochen lang den ganzen Application Code angesehen, aber noch nichts gefunden.“
  • „Wir haben Performance-Probleme. Vor zwei Wochen war die Verarbeitung zwei Stunden lang langsam. Was sollen wir tun?“

Solche oder ähnliche Aussagen höre ich häufig in meinem Alltag. Dabei stelle ich immer wieder die gleichen „lästigen“ Fragen: Wissen Sie, wo die Probleme auftreten? Beschreiben Sie mir bitte, wann Sie was genau beobachten. Sind die Probleme reproduzierbar?

Mit coolen Schlagwörtern, „irgendwas“ machen und in Hektik verfallen, kann man sich jetzt beim Kunden beliebt machen. Denn man handelt ja sofort und hinterlässt den Eindruck, bei so einem schwierigen, fast unlösbaren Problem zu helfen. Aber dennoch verliert man kostbare Zeit.

Was bringt es, wenn ein neues Datenbank-Feature wegen Performance-Problemen eingesetzt wird? Vielleicht hat das Vorteile, aber ein neuer Index würde vielleicht auch helfen, ohne zusätzliche Kosten zu verursachen und das Anlegen geht deutlich schneller. Und nebenbei: Löst die Datenbank überhaupt die Probleme aus?

Was bringt es, wochenlang die Applikations-Sourcen durchzusehen, wenn man eine langsame Datenbankabfrage aufgrund fehlender Datenbankstatistiken hat? Außer Überstunden wahrscheinlich wenig. Ein gutes Beispiel hierfür liegt Jahre zurück, ist mir aber in Erinnerung geblieben, weil es sich immer wieder in einer ähnlichen Form wiederholt. Damals fragte ich den Kunden vorsichtig, ob das Problem in der Datenbank liegen könnte. Die rasche Antwort war: „Das können wir gar nicht analysieren, dafür haben wir keine Zeit.“ Letztendlich verriet ein kurzer Blick auf die Datenbank, dass ein Statistiklauf gestartet werden musste. So war das Problem in weniger als 30 Minuten erledigt. Es war zwei Wochen lang an der falschen Stelle gesucht worden.

Ich hatte damals Glück. Es hätte genauso gut ein Netzwerkproblem oder etwas anderes sein können. Die Erkenntnis daraus ist daher nicht „der Volltreffer“, sondern der Versuch, zuerst die betroffene Komponente zu bestimmen. Wie auch immer die Probleme lauten und wie stark auch immer der Ruf nach Hilfe ist, fangen Sie an der richtigen Stelle an und nehmen Sie sich Zeit für die wichtigen Dinge.

Die richtige „Stelle“ ist eine Problembeschreibung und eine strukturierte Problemanalyse, bei der zunächst einmal die Problemquelle lokalisiert wird. Die Daten müssen gesammelt und ausgewertet werden, denn das Fach Glaskugellesen gibt es an den meisten Unis noch nicht ;-). Das mag auf den ersten Blick lästig erscheinen, aber ein strukturiertes und zielgerichtetes Vorgehen und Ruhe bewahren, führen in der Praxis am schnellsten zur Lösung. Und das ist vielleicht nicht nur in der IT so.