Tags

, ,

Warum reden eigentlich immer alle gleich von Schuld, wenn etwas schief geht? Kaum spricht einer das Wort aus, gehen alle in Hab-Acht-Stellung, bereit zur Verteidigung: „Das war nicht mein Fehler, da hat der da Schuld.“ Und schon ist es wieder soweit: Es wird nicht mehr über das gesprochen was da schief ging, sondern nur noch über den Verursacher. Selbst wenn man dann die Diskussion wenden möchte, wenn man zurück zum Thema möchte, wird jeder Satz kritisch beäugt – es könnte ja heimlich Kritik an meiner Person sein! … Es ist so mühselig.

Es ist verständlich, dass niemand seine Person in Frage gestellt sehen möchte. Man hat die Situation anders eingeschätzt, als wie sie sich nun herausstellt. Der Fehler ist trotz bester Absichten entstanden. Begegnet man einer solchen Situation, mit der man nicht gerechnet hat, dann muss man eine Neubewertung vornehmen. Meist muss nicht das gesamtes eigene Weltbild dafür angepaßt werden, aber doch Teile davon. Man selbst muss das eigene Deutungsschema auf Druck von außen in Frage stellen. „Who am I in this situation?“ schrieb  Anselm Strauss dazu in „Mirrors and Masks“. Denn wenn das eigene Deutungsschema in Frage gestellt wird, dann ist das auch immer eine Infragestellung der eigenen Identität. Und das wird mit Recht als Bedrohung angesehen.

So verständlich es also ist, dass jemand sich bedroht fühlt, wenn ein unerwartetes Problem auftritt. Die Frage nach der Schuld behindert die Suche nach der Lösung ungemein. Wie Peter Kruse schon im Video: „8 Regeln für den totalen Stillstand in Unternehmen“ sagte: „Finden Sie raus, wer wirklich Schuld ist. Analysieren Sie. Fangen Sie bloss nicht an zu ändern“ – sehr beliebt in deutschen Unternehmen :-)

 

Woher kommt denn diese Frage nach der Schuld?

Werfen wir mal einen kurzen Blick ins Strafrecht.1

„Von Laien wird Schuld regelmäßig mit Kausalität oder Vorsatz vermengt oder verwechselt.“, sagt Wikipedia über Schuld im Strafrecht. Beim Vorsatz geht es darum, ob man das Ergebnis seiner Tat absichtlich oder billigend in Kauf genommen hat. Kausalität ist die Frage nach einem – oder auch mehreren Gründen, ohne die das Problem nicht eingetreten wäre. Und Schuld ist die Frage nach der Wahlmöglichkeit – wußte ich überhaupt, dass ich Unrecht tue? Wenn ja, habe ich mich dafür entschieden?

Das ist, glaube ich, der Hauptgrund für mein Unbehagen bei der Frage nach der Schuld. Es ist nie, nie, nie, die Frage, ob jemand etwas mit Absicht falsch gemacht hat. Das habe ich noch nicht erlebt – zumindest nicht in der Softwareentwicklung. Niemand checkt einen Bug mit Absicht ein. Selbst Ex-Mitarbeiter, die sich mit Ihrem Chef verstritten haben, haben das nicht gemacht. Warum auch? Es bringt ja nichts. Am Ende trifft es nur die Kollegen oder einen selbst. Und für eine Handlung im Affekt muss man dabei dann doch zuviel überlegen… Mangelnde Erfahrung und Kompetenz, Vergesslichkeit und spontane Faulheit sind Verursacher, die man behandeln muss, aber Schuld? (Wie sagte Gott am siebten Tag? „Morgen ist Abgabe, ich lass das jetzt so…“)

Nein, Schuld im Sinne von Recht und Unrecht ist nicht gemeint.2 Wenn überhaupt, dann ist es die Suche nach dem Verursacher, nach der Kausalität, um die es geht. Aber warum sollte man danach suchen? Um daraus zu lernen, und es beim nächsten Mal besser zu machen.

Bugs machen missmutig

Natürlich sind Bugs nervig. Vor allem wenn der Termin drückt, und der Kunde funktionierende Software haben möchte. Da bleibe selbst ich nicht immer die Ruhe selbst. Vor allem, wenn ich der Meinung bin, dass man den Bug schon beim Programmieren bemerkt haben müsste oder zumindest scheinbar Faulheit und Vergesslichkeit die Ursache sind. Da fällt es manchmal schwer, nicht laut aufzustöhnen. Dennoch bin ich überzeugt davon: Auch in so einem Fall ist es nicht mit Absicht passiert. Jeder Beteiligte bemüht sich nach bestem Wissen und Gewissen seine Arbeit zu machen. Manche sind da eben von Natur aus sorgfältiger als andere…

Das bringt mich zurück zur Kausalität: Wenn wir bei einem Bug schon nach der Kausalität fragen – nach dem Verursacher – dann ist das keine Frage nach der strafrechtlichen Kausalität: „Im Strafrecht wird eine Handlung dann als kausal angesehen, wenn sie nicht hinweggedacht werden kann, ohne dass der Taterfolg in seiner konkreten Gestalt entfiele.“ Diese Art von Kausalität bringt uns in der Firma nicht weiter.

Ein simples Beispiel: Jemand hat vor Monaten seinen Job verloren. Er hat Hunger und kein Geld. Er stiehlt um zu Überleben. Der Arbeitgeber, der ihn rausgeschmissen hat, ist hier strafrechtlich nicht kausal für den Diebstahl. Ganz klar, aber in der Softwareentwicklung hilft uns dieses Denken nicht weiter. Und nicht nur hier: auch in allen anderen Unternehmungen, in denen Menschen gemeinsam ein Ziel erreichen wollen: sei das eine Software, ein Auto zu produzieren oder einfach nur der Unternehmenserfolg.

Bugs treten auf, weil jemand diesen Bug verursacht hat – unabsichtlich. Es gibt aber nicht nur diesen einen Verursacher – es gibt viele (!):

  • Der Entwickler wurde vieleicht nicht richtig geschult.
  • Er kannte die Komponente nicht, an der er entwickelt hat.
  • Zwei Entwickler nutzen gegenseitigen Code und haben sich missverstanden.
  • Er hatte ein anderes Grundverständnis von der API die er bedient hat.
  • Er wollte die Stelle später nochmal „richtig“ machen und hat es vergessen.
  • Niemand anderes hat mehr über seinen Code geguckt.
  • Es gab keinen Unit-Test für diese Software-Stelle.
  • Die Zeit hat gedrückt, und der Entwickler war sich in der Eile sicher, dass es so funktionieren würde.
  • De Entwickler war in Eile und hat es später vergessen.
  • Er kannte die Querabhängigkeiten nicht.
  • Sein Verständnis von den Anforderungen war ein anderes, als das des Kunden, die Anforderungen waren nicht genau, der Entwickler kannte nur einen Teil der Anforderungen, es gab widersprüchliche Anforderungen, etc. etc.
  • Er ist Anfänger in bestimmten Bereichen (siehe meinen alten Artikel zu Absolute Beginners)

Damit will ich niemanden aus der Verantwortung nehmen.  Auch möchte ich nicht die Verantwortung allein auf den Projektleiter übertragen, der „Schuld“ hat, weil er dem Entwickler nicht die optimalen Arbeitsbedingungen bereitet. Ganz im Gegenteil: Jeder ist Teil dieses Systems und immer gefordert mitzudenken und zu überlegen, was man verbessern kann – vor allem an sich selbst! (Aber manchmal braucht man da ein wenig Input von außen…)

Ok, Schuld ist Quatsch – was machen wir also?

Mehr Zeit für Tests, Anforderungen besser beschreiben, Schulen, Reviews, tägliche Meetings, Komponenten besser dokumentieren, etc. etc. Es gibt viele Handlungsmöglichkeiten und sie sind alle immer einem Faktor unterworfen: Zeit (eigentlich Geld, aber Geld ist Zeit :-)

Man hat einfach nicht die Zeit alles ideal zu machen. Man hat nicht mal die Zeit über alles in idealer Form nachzudenken. Schon gar nicht hat man die Zeit, erstmal alles zu Lernen was es gibt, um überhaupt in idealster Form nachdenken zu können.

Das ist der Alltag, mit dem man umgehen muss: Ideal ist irreal. Letztlich führt es zu folgendem Prozess:

  1. Jeder Bug und jedes Problem das auftritt, müssen bewertet werden hinsichtlich ihrers Potentials, dass gleichartige Fehler auftreten können.
  2. Hält man die Wahrscheinlichkeit für hoch, dann muss man nach den Verursachern (Plural!) fragen, und überlegen, mit welchen Strategien man sie behandeln kann.
  3. Hat man die Strategien gefunden, dann muss überlegt werden, wieviel Zeit sie kosten und ob die Zeit (ergo das Geld) überhaupt da ist.
  4. Und die wichtigste Frage ist: Lohnt sich der Zeitaufwand die Verursacher abzustellen, oder ist die Zeit, die zur Behebung der Bugs anfällt, geringer? Denn natürlich kann ich im „Daily“3 jede Zeile Code des Vortags mit allen Entwicklern zusammen ansehen –  aber dann wird es dennoch Bugs geben, und die Zeit fehlt woanders.
  5. Dann gehts an die Einführung der Strategien, und da muss man aufpassen, denn neue Strategien können auch wieder neue Probleme verursachen. Dann lohnt sich die Strategie vielleicht doch nicht: Gehe zurück zum Start.4

Diese fünf Punkte sind in etwa meine Hauptbeschäftigung. Das klingt, als wäre ich ein Feuerwehrmann in der Softwareentwicklung. Tauscht man aber das Wort „Bug /Problem“ in den fünf Punkten gegen „Kundenwunsch“ aus, dann passt es ganz gut ;-)5

Fazit

Die Frage nach der Schuld, gebiert eine Atmosphäre der Feindseligkeit. Vertrauen geht dabei verloren, dabei ist es so wichtig. Die Suche nach den Verursachern im Plural ist kaum noch möglich, wenn immer nur auf den letzlichen Verursacher gezeigt wird. Nicht nur, weil man die Zeit vergeudet über „Schuld“ zu reden, sondern weil niemand, der Angst hat angeprangert zu werden, überhaupt noch auf Probleme aufmerksam macht. Schlimmstenfalls werden sie vertuscht, um nicht angeklagt zu werden. Wenn es soweit kommt, dann sind wir allerdings tatsächlich wieder bei „Schuld“, denn wenn jemand vertuscht, dann hat er sich wirklich für das Unrecht entschieden…

… Erstaunlich oder? Die Frage nach der Schuld führt erst dazu, dass sich Menschen schuldig machen. Wer braucht die Schuld eigentlich noch?


 

Und hier nochmal Kruses Rede – sehr unterhaltsam, kann ich nur jedem empfehlen und ich bin sicher, dass jeder etwas aus seinem Job wiedererkennt :-)

  1. Wobei ich sagen muss, dass der kurze Blick mich neugierig gemacht hat – das Recht geht wirklich sehr behutsam mit Begriffen um und unterscheidet sehr fein. Das führt zu abstrusen juristischen Paragraphen und Floskeln, wie wir sie alle schon mal irgendwo gelesen haben, aber die grundsätzliche feinsinnige Unterscheidung der Begrifflichkeiten interessiert mich doch sehr… Kommt auf die Todo Liste :-) []
  2. Manch einer mag Faulheit oder Inkompetenz als Charakterschuld sehen. Aber auch diese Art von Schuld bringt uns ja nicht weiter – letztlich sind die „Charaktere“ auch nur Mit-Verursacher, mit denen man umgehen muss: Wenn es geht durch Review und Schulung, aber wenn nötig – weil es zu aufwändig wird – durch Ausschluss aus dem Projekt. Glücklicherweise ist das kaum je nötig. Und letztlich geht es nicht nur um das aktuelle Projekt und man muss sich als Projektleiter fragen, ob es auf lange Sicht sinnvoll ist die Motivation der Person und meine Zusammenarbeit mit ihr durch einen Ausschluss gravierend zu stören. Manch ein Chef mag es sich da einfach machen – ich finde das nicht einfach. []
  3. für die die Scrum nicht kennen: Daily Scrum =  tägliches Meeting der Projektbeteiligten []
  4. Ein simples Bespiel: Unit-Tests werden eingeführt, die aber auf Daten arbeiten die variabel sind, was zum Zeitpunkt der Einführung nicht bekannt war. Die Tests schlagen fehl und werden angepaßt. Kommt hinzu, dass niemand darüber redet und ein Entwickler deshalb an den Tests festhält, da sie ja „sinnvoll“ sind. Nach und nach summiert sich die vergeudete Zeit. []
  5. Ein Kundenwunsch kann man ähnlich einem Bug auch als wiederkehrendes Phänomen sehen – ist der Wunsch gefestigt, und nimmt der Kunde Geld in die Hand um den Wunsch abzustellen/zu befriedigen usw. – wobei ich wohl kaum dazu sagen muss, dass ich einen Kundenwunsch nicht als Problem sehe: Es geht hier nur um den Prozess, der ähnlich ist – und beides macht mir Spaß, sonst würde ich den Job ja nicht machen :-) []