Er war neuen Erkenntnissen zu seinen aktuellen SW-Fehlern auf der Spur. Endlich hatte er eine wichtige Ursache ausgemacht und war bei einer groben Schätzung zu dem Ergebnis gekommen, dass er noch 3 Wochen brauchen würde, alles glatt und sauber zu ziehen. Im besten Fall eine Woche. Die Änderung würde eine Umstrukturierung größerer Programmteile umfassen. Er hatte schon gut eine Woche für die Analyse benötigt und 2 Fixes machen können, die das Problem entschärften.
„Drei Wochen? Wie teuer ist denn das Problem?“, fragte ich ihn.
„Häh?“
„Na ja, das Problem habt ihr ja schon länger. Was passiert aktuell? Was kann im schlimmsten Falle passieren? Wer ist davon wie betroffen?“
Ich wollte ihn motivieren, die Programmierer-Perspektive zu verlassen und sich das Thema von außen anzuschauen.
Wir kamen darauf, dass zur Zeit zur Vermeidung des Problems jeden Tag das System einmal einen Reset machen musste. Wenn jemand einen Fehler in der Konfiguration seiner Export-Task machte, konnte das System Amok laufen. Gelegentlich schlugen ein Export oder ein Import fehl. Das System ist ein Firmen-internes Tool, hat also keinen direkten Impact auf die Kundenanwendungen. Die internen Anwender sind genervt, müssen bei einem Abbruch den Export nochmal starten. Bricht ein Import ab, kann es zu Inkonsistenzen kommen, die man im schlechtesten Fall nicht entdeckt. Das hat dann indirekt Auswirkungen auf die Kundenapplikationen, kann aber durch einen erneuten Import behoben werden.
„Und wie groß ist die Wahrscheinlichkeit, dass ein fehlerhafter Import unentdeckt bleibt?“
„Sehr klein. Eigentlich weiß es jeder, dass man das Ergebnis überprüfen muss.“
„Und der Neustart des Systems?“
„Der ist schon lange automatisiert. Darum braucht sich niemand zu kümmern.“
„Und wie oft treten Fehler auf?“
„Weiß ich nicht.“
„Also kostet es vor allem die Zeit und Nerven der internen Nutzer, die auf das Ergebnis warten, um eine bestimmte Aufgabe weiter zu führen. Um die Kosten des Problems kalkulieren zu können, musst du also herausfinden, wieviel Zeit jede Woche verloren geht, um einen abgebrochenen Task nochmal zu starten.“
Ich erklärte ihm das Prinzip, das ich auf der Architektur-Schulung von Gernot Starke und Peter Hruschka gelernt hatte. (Blog von Gernot und Peter)
Versuche die Kosten, die das Problem verursacht, zu beziffern. Nur wenn die Kosten deutlich höher sind als das Lösen des Problems, lohnt es sich, das Problem zu lösen.
In diesem Fall war das Problem noch nicht komplett gelöst. Mit dem täglichen Neustart, den angewendeten Fixes sollte es nur noch selten auftreten. Eindeutig ein Fall für „Nicht weiter glatt ziehen“.
Es war das erste Mal, dass ich bewusst versucht habe, dieses Prinzip anzuwenden. Interessant war das Gefühl, den Perspektiven-Wechsel zu machen. Dabei konnte man auch schauen, ob es auf anderen Ebenen Lösungen für das Problem gab. Insbesondere fiel es meinem Kollegen diesmal leichter, auch seinen Chef abzuholen und eine differenziertere Entscheidungsgrundlage zu bieten.
Was sind die Kernpunkte:
- „Lösungsorientiert“ ist ein schönes Schlagwort, das insbesondere von Managern missbraucht wird, um vermeintlich Kosten zu senken. Oft ist eine Lösung zwar eine Lösung, technisch gesehen sogar manchmal eine gute Lösung, aber vielleicht für das falsche Problem. Das Problem muss erst aus allen Ebenen heraus verstanden werden, bevor man entscheiden kann, in welche Richtung man später Anstrengungen unternimmt.
- Oft steckt der Betrachter des Problems zu tief im technischen Detail. Es ist wichtig, die Perspektive zu wechseln und sich alle Auswirkungen nochmal auf der Ebene der Auswirkungen im Prozess anzuschauen. Oft gibt es Zusammenhänge in den Gesamtprozessen des Unternehmens und vielleicht ist die Ursache des Problems in einem ganz anderen Bereich anzusiedeln und nicht da, wo es sich manifestiert.
- Für Änderungen auf Architektur-Ebene müssen die Kosten des Problems deutlich kleiner sein als die Kosten zur Behebung des Problems.