Liebe Leser!
Sperriger Titel, aber folgender Gedanke beschlich mich beim morgendlichen Zähneputzen:
These:
Investitionsbereitschaft in Software Qualität ist reziprok proportional zum zeitlichen Abstand des Eintritts eines - kausal auf ein Qualitätsproblem folgendes - negativen Ereignisses, dessen Eintrittswahrscheinlichkeit und dessen Auswirkung.
Argumentation anhand von Beispielen (die angeführten Zahlen sind meine persönlichen Annahmen):
Softwareversagen im Bereich Avionik:
Zeitlicher Abstand -> wenige Minuten
Negatives Ereignis -> Absturz
Eintrittswahrscheinlichkeit -> nahezu 100%
Auswirkung -> Multiple Todesfälle nahezu 100%
Softwareversagen im Bereich Automotive:
Zeitlicher Abstand -> wenige Sekunden
Negatives Ereignis -> Unfall
Eintrittswahrscheinlichkeit -> ca. 50%
Auswirkung -> Tod zu 40%, Verletzung zu 60%
Softwareversagen im Bereich betrieblicher Informationssysteme:
Zeitlicher Abstand -> Stunden, Tage, Monate, Jahre
Negatives Ereignis -> Fehler, verletzte Datenintegrität und Konsistenz, Datenverlust, Finanzieller Verlust, überproportional steigende Wartungskosten
Eintrittswahrscheinlichkeit -> ca. 99%
Auswirkung -> Imageschaden, finanzieller Schaden, Kundenunzufriedenheit, Haftungen (bis hin zur Haftstrafe)
Trotz hoher Eintrittswahrscheinlichkeit eines negativen Ereignisses ist der zeitliche Abstand in vielen Fällen derart groß, dass eine Investitionsbereitschaft stark gebremst wird, noch dazu, wo die Auswirkungen nicht als lebensbedrohlich gewertet werden und Folgen wie mögliche Haftungen oft nicht transparent sind.
Ergo:
Um die Investitionsbereitschaft zu steigern, müssen die möglichen Auswirkungen transparenter dargestellt werden, um Entscheidungsträger nach dem Kosten-Nutzen Prinzip geeignet aufzuklären. Eine Darstellung des Ablaufs im Zeitraffer ist anzuraten, um dem Gefühl der „Sicherheit aufgrund eines ausreichenden zeitlichen Puffers“ entgegen zu wirken. Geeignete Simulationsmodelle sind auszuarbeiten.
Einen sonnigen Juni wünscht
Euer
JWR@coopXarch.
Hi!
AntwortenLöschenIch weiß gar nicht mehr wie oft wir beide uns über dieses Thema unterhalten haben (Wettpunkt) ;)
Hier sind meiner Meinung nach 2 unabhänige Dinge vermischt.
Zum einen Risiko-Management, dass jegliche Unternehmung betrifft.
Das zweite ist die simple alltägliche Arbeitsweise aller Beteiligten!
Und zwar die Arbeitsweise der IT-Arbeiter (Entwickler, Betriebsführer,...), der Domain-Experten, der Kunden aber vorallem die IT-Manager.
Qualitativ hochwertige Software entsteht nicht durch das sture einhalten von bestimmten Regeln oder Prozeduren.
Egal ob sie aus "dem Industrie-Standard", Clean Code, Code Complete, diversen Agile- oder Extreme-Programming Büchern oder anderen Quellen stammen.
Das Problem ist, dass Software nicht nach einem bestimmtem Schema - praktisch am Fließband - entstehen kann sondern Tagtäglich
hunderte oder tausende kleine Entscheidungen, von eben diesen, am Projekt arbeitenden, Menschen getroffen werden müssen.
Und bei jeder dieser Entscheidungen müssen für die Möglichkeiten die Konsequenzen abgewogen werden.
Darüber hinaus haben die wenigsten dieser Entscheidungen klare und sofort ersichtliche Vor- oder Nachteile sondern beinhalten immer einen gewissen
tradeoff oder es wird erst wesentlich später ersichtlich das ein anderer Weg überwiegende Vorteile gehabt hätte.
Daraus ergibt sich auch die eigentliche Problematik warum es so schwer ist qualitative Software zu erstellen:
Was ist qualitativ hochwertig? Was ist besser - A oder B?
Demzufolge ist es die Kompetenz und Arbeitsweise der Beteiligten aus der sich die Qualität des Resultats ergibt.
Wenn man von dieser Annahme ausgeht (und jetzt komme ich auf mein "vorallem IT-Manager" zurück) stellt sich hier die Hauptaufgabe
für den IT-Manager:
a) Zu verstehen was seine Mitarbeiter eigentlich leißten können müssen
b) Die "passenden" Leute in der "entsprechenden" Rolle am "richtigen" Ort zu haben
c) Eine entsprechende Umgebung zu schaffen so das die "richtigen" Leute die entsprechenden Entscheidungen treffen
d) Diese Entscheidungen auch umgesetzt werden
Das bedeuted natürlich auch, dass der Verantwortliche die "Qualitäts-Frage" nicht als "Kosten-Frage" an den Kunden weiter geben
darf. Es kann von einem Kunden nicht erwaret werden bewerten zu können "wie viel Qualität brauche ich" oder "wie viel Qualität
kann ich mir leisten" - schon alleine desswegen weil es keinen Massstab gibt der hier angelegt werden könnte.
Damit stellen sich für den IT-Manager zwei schwierige Probleme:
a) Wie findet man entsprechend Qualifiziertes Personal - Da man für das Resultat der Arbeit keinen Qualitäts-Massstab hat fehlt er hier ebenso!
b) Etwas das nicht messbar, vergleichbar oder von vornherein eindeutig definierbar ist - in diesem Fall Qualität von Software - lässt sich natürlich auch nur schwer Verkaufen!
br,
Markus