Gute Entscheidungen in IT-Projekten: Unbewusste Einflüsse erkennen, Hintergründe verstehen, Prozesse verbessern

Von Andreas Rüping

Unzählige kleine und große Entscheidungen prägen IT-Projekte. Sie beziehen sich auf ganz unterschiedliche Themen: die Priorisierung von Anforderungen, das Design und die Architektur oder auch das Vorgehen im Team. Allerdings werden Entscheidungen oft nicht so rational getroffen, wie dies eigentlich wünschenswert wäre. Die Ursachen dafür sind vielfältig.
Dieses Buch analysiert die möglichen Ursachen und schlägt praxisorientierte Instrumente vor, mit denen wir alleine oder im Team zu besseren
Entscheidungen gelangen können. Das Buch kombiniert dabei Erkenntnisse aus Entscheidungstheorie und Kognitionswissenschaft mit bewährten Praktiken aus IT-Projekten – allem voran aus dem agilen Umfeld.
Kernpunkte sind:

- Etablieren von Praktiken für rationale Argumentationen
- Methoden, um rationale Entscheidungen im Team zu fördern
- Einsatz quantitativer Verfahren zur Untermauerung von Entscheidungen
- Einbetten von Entscheidungen in IT-Prozesse

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 5. Juli 2019
• ISBN: 9783960887287

Buchvorschau

1Einleitung

1.1 Motivation

Wir alle kennen das Phänomen, dass im Projekt eine Entscheidung getroffen wird, die sich einige Zeit später als Fehlentscheidung herausstellt. Manchmal werden uns im Rückblick die Gründe dafür klar. Vielleicht lag der Entscheidung eine Fehleinschätzung zugrunde, vielleicht wurden bestimmte Aspekte der Entscheidung übersehen. Manchmal bleiben die Ursachen der Fehlentscheidung aber auch im Dunkeln.

Tatsächlich ist die Problematik aber noch komplexer. Entscheidungen, die wir als Fehlentscheidungen wahrnehmen, sind nur die Spitze des Eisbergs. Gelegentlich treffen wir Fehlentscheidungen – oder doch zumindest unglückliche Entscheidungen –, ohne uns dessen jemals bewusst zu werden. Wir denken, unsere Entscheidung sei gut und vernünftig gewesen, während sie in Wirklichkeit keine gute Entscheidung war. Woran liegt das? Schauen wir uns dazu eine typische Situation in einem IT-Projekt an und werfen wir einen Blick darauf, wie dort Entscheidungen getroffen werden.

Ein erstes Beispiel

Montagvormittag, 10:00 Uhr. Das Planungsmeeting für die Weiterentwicklung des Onlineshops steht an. Das gesamte Team ist anwesend, bestehend aus Projektleiterin, vier Entwicklern, einer UX-Expertin, einer QA-Expertin sowie den Kollegen aus den Fachbereichen. Die Diskussion beginnt damit, dass ein Fachexperte eine neue Funktion vorstellt, die es Kunden ermöglichen soll, unterschiedliche Lieferadressen zu hinterlegen. Es wird eine Aufwandsschätzung benötigt.

Als Erstes ergreift ein erfahrener Entwickler das Wort. Er erklärt, dass die Umsetzung sicher kein Hexenwerk sein wird, aber trotzdem etwas Aufwand darstellt, weil sich das Datenmodell ändert und mehrere Systemkomponenten davon betroffen sein können. Er vergleicht die Anforderung mit der Aufnahme einer neuen Zahlungsart, die das Team vor einigen Monaten implementiert hat, und argumentiert, dass die neue Funktion etwas einfacher sein wird. Er schätzt den Gesamtaufwand auf ungefähr fünf Personentage.

Ein anderer Entwickler ist von dieser Schätzung spontan überrascht, denn er hatte eigentlich eine Größenordnung von 20 Tagen erwartet. Sollte er sich mit seiner Einschätzung so sehr getäuscht haben? Allerdings ist ihm bewusst, dass der Kollege sich im Projekt sehr gut auskennt. Er selbst ist relativ neu im Team und war an der Implementierung der neuen Zahlungsart vor einigen Monaten nicht beteiligt. An fünf Personentage glaubt er trotzdem nicht, schließlich müssen mehrere Komponenten angepasst und auch getestet werden. Dieses Argument wirft er so auch in die Runde und nennt vorsichtig zehn Tage als mögliche Aufwandsschätzung.

Die QA-Kollegin äußert sich ähnlich. Sie bestätigt den nicht unerheblichen Testaufwand und tendiert auch in Richtung der zehn Personentage. Der erfahrene Entwickler signalisiert ein Stück weit Zustimmung. Er erkennt an, dass seine Schätzung von fünf Tagen vielleicht etwas zu optimistisch war, findet zehn Tage aber doch zu viel. Vielleicht acht Personentage? Ja, das mag hinkommen. Angesichts dieses weitgehenden Konsenses sieht die Projektleiterin keinen weiteren Diskussionsbedarf. Sie möchte natürlich keine zu großen Zahlen sehen, aber auch keine unrealistisch kleinen, und der Konsens kommt ihr gerade recht. Es werden acht Personentage notiert.

Dies ist ein einigermaßen realistisches Szenario, wie es in Tausenden von IT-Projekten immer wieder vorkommt. Und einiges hat bei dieser Vorgehensweise gut funktioniert. Die Schätzung wurde nicht einfach aus der Luft gegriffen, sondern es wurde der Versuch gemacht, sich an einer vergleichbaren Aufgabe aus der Vergangenheit zu orientieren. Mehrere Personen aus dem Team haben eine Schätzung abgegeben. Niemand hat versucht, den anderen seine Meinung aufzuzwingen, sondern es wurde diskutiert und am Ende ein Konsens gefunden. Ist also so weit alles in Ordnung?

Nein. Denn auch wenn das Team einiges richtig gemacht hat, anderes hat nicht gut funktioniert:

Zwei der Entwickler haben überhaupt keine eigene Aufwandsschätzung abgegeben. Vielleicht hat ihnen der Mut gefehlt, vielleicht hatten sie nicht den Eindruck, zur Schätzung noch weitere Aspekte beitragen zu können. Aber möglicherweise wäre genau das der Fall gewesen. Eventuell hätten die beiden anderen Entwickler an Dinge gedacht, die nun unter den Tisch gefallen sind.

Außerdem kann man sich fragen, wie die Schätzung ausgesehen hätte, wenn die Wortmeldungen in anderer Reihenfolge erfolgt wären. Zunächst hätten die 20 Personentage zur Diskussion gestanden, die der neu ins Team gekommene Entwickler eigentlich hatte nennen wollen. Die QA-Expertin hätte dem vermutlich im Großen und Ganzen zugestimmt. Der erfahrene Entwickler hätte sicherlich argumentiert, dass 20 Personentage zu viel sind. Aber welche Zahl hätte er genannt? Vermutlich nicht nur fünf Personentage, sondern deutlich mehr. Letztlich wäre es auch in diesem Szenario auf einen Kompromiss hinausgelaufen, der aber vermutlich eher bei 15 Personentagen gelegen hätte, also fast das Doppelte der tatsächlichen Schätzung. Welche ist nun die richtige? Tatsache ist: Die Reihenfolge, in der die Schätzungen geäußert wurden, hatte einen Einfluss auf das Ergebnis.

Schließlich hat niemand hat die Frage aufgeworfen, inwieweit die Implementierung der variablen Lieferadresse von der Implementierung der zusätzlichen Zahlungsart abweicht. Denkbar wäre zum Beispiel, dass die GUI-Änderungen einiges an Aufwand im UX-Design nach sich ziehen. Natürlich hätte die UX-Expertin darauf hinweisen können. Sie hat dies aber nicht getan, vielleicht, weil die Argumentation des erfahrenen Entwicklers durchaus plausibel klang. Andererseits ist eine Einschätzung, nur weil sie plausibel klingt, nicht automatisch korrekt.

Die Schätzung ist also zumindest fragwürdig, und die Folge davon können Fehlentscheidungen sein. Welcher Aufwand ist gerechtfertigt? Soll die Funktion überhaupt implementiert werden? Und falls ja, wann soll den Kunden mitgeteilt werden, dass die Funktion demnächst zur Verfügung steht? All dies sind Entscheidungen, die im Projekt getroffen werden müssen und die unter einer möglicherweise fehlerhaften Schätzung leiden. Im Verlauf des Buchs werden wir Techniken kennenlernen, mit denen sich solche und ähnliche Fehleinschätzungen vermeiden lassen, allein und im Team. Schauen wir aber zunächst, wie das Meeting weitergeht.

Ein weiteres Beispiel

10:50 Uhr. Zum Schluss des Meetings berichtet die Projektleiterin, dass eine Funktion, die das Team vor einiger Zeit implementiert hat, wieder ausgebaut werden muss. Es handelt sich um die Einblendung von Kundenbewertungen auf bestimmten Produktseiten. Die Projektleiterin erklärt dazu, dass es seit der Livestellung vor zwei Wochen einen spürbaren Rückgang der Umsatzzahlen gebe. Obwohl die Umsatzzahlen über die einzelnen Tage schwanken, habe das Management entschieden, dass die Bewertungen nicht mehr angezeigt werden sollen. Die Entwickler sind etwas enttäuscht, müssen aber die fachliche Entscheidung akzeptieren.

Ist es eine gute Entscheidung, die Funktion zu deaktivieren? Es ist zumindest eine voreilige Entscheidung:

So objektiv und unbestechlich die Umsatzzahlen auf den ersten Blick wirken, so problematisch sind sie, wenn einfach nur Zeiträume vor und nach der Einführung einer Funktion verglichen werden. Vermutlich sind zum gleichen Zeitpunkt auch noch andere Features in Betrieb genommen worden. Dann kann niemand sagen, ob tatsächlich die Produktbewertungen für den Umsatzrückgang verantwortlich sind oder vielleicht einige der anderen Features. Möglicherweise hat der Umsatzrückgang mit den verschiedenen neuen Funktionen auch überhaupt nichts zu tun, sondern ist einfach die Folge eines geringeren Kundeninteresses. Es gibt kalenderbedingt eher umsatzstarke und eher umsatzschwache Zeiten: Vielleicht war der Umsatzrückgang einfach nur das Symptom des alljährlichen Sommerlochs?

Es ist nicht von vornherein klar, ob ein Zeitraum von zwei Wochen überhaupt ausreicht, um einen möglichen Effekt der Produktbewertungen auf den Umsatz zu beurteilen. Größen wie Umsatzzahlen unterliegen immer auch dem Zufall. Die Folge davon sind nicht unerhebliche Umsatzschwankungen. Um zu belastbaren Aussagen zu kommen, muss man einen ausreichend langen Zeitraum betrachten. Die Statistik hält Instrumente bereit, um anzugeben, wie lange ein solcher Zeitraum sein muss. Diese statistischen Instrumente wurden hier aber nicht einmal in Erwägung gezogen.

Schließlich hat sich niemand die Mühe gemacht, zu überlegen, was überhaupt als Erfolgskriterium dienen soll. Wirklich der Umsatz? Für einen Onlineshop spielen beispielsweise auch Retouren eine große Rolle, da sie oft erhebliche Kosten verursachen. Ein etwas geringerer Umsatz kann oft hingenommen werden, wenn dafür auch die Zahl der Retouren sinkt. Die Frage nach den Erfolgskriterien ist hier aber gar nicht gestellt worden. Es wurden, vermutlich etwas voreilig, die erstbesten Zahlen berücksichtigt, die zur Verfügung standen.

All das spricht nicht dagegen, quantitative Informationen, letztlich also Zahlen, zu nutzen, um Entscheidungen zu untermauern. Wir sehen aber an diesem Beispiel, dass Vorsicht geboten ist. Nicht alle Zahlen sind so hilfreich, wie es zunächst scheinen mag, und eine Entscheidung ist vermutlich nicht gut, wenn ihr fragwürdige Zahlen zugrunde liegen. Auch dies ist ein Thema, mit dem wir uns in diesem Buch beschäftigen werden.

Lassen wir damit das Projektmeeting zu Ende gehen. Es handelt sich dabei im Übrigen um ein fiktives Beispiel. Aber auch wenn es fiktiv ist, unrealistisch ist es nicht: Das beschriebene Meeting könnte sich in vielen Projekten genau in dieser Form abgespielt haben. Wir bekommen hier einen ersten Eindruck davon, welch unterschiedlichen Problemen wir in IT-Projekten begegnen, wenn wir Einschätzungen vornehmen und auf deren Basis Entscheidungen treffen.

1.2Welche Entscheidungen treffen wir in IT-Projekten?

Schauen wir uns zunächst einmal an, zu welchen Themen in IT-Projekten immer wieder Entscheidungen getroffen werden. Tabelle 1–1 nennt einige wichtige Themenkreise und jeweils eine Reihe typischer Beispiele in Form von Fragestellungen.

Tab. 1–1 Typische Entscheidungen in IT-Projekten

Die Liste der Beispiele erhebt natürlich keinen Anspruch auf Vollständigkeit. Die Beispiele zeigen aber, dass in IT-Projekten eine Vielzahl von Entscheidungen auftreten. Dabei überlappen sich teilweise die Themenkreise und die Entscheidungen hängen manchmal auch voneinander ab:

Der Wunsch nach hoher Verfügbarkeit ist natürlich Gegenstand des Anforderungsmanagements, kann aber nur im Rahmen der Architekturplanung entschieden werden.

Der prinzipielle Wunsch nach Mehrsprachigkeit wird im Rahmen der strategischen Planung diskutiert. Falls die Entscheidung zugunsten der Mehrsprachigkeit fällt, werden Detailfragen dazu zweifellos im Rahmen des Anforderungsmanagements entschieden.

Die Frage nach der Methodik ist primär eine Teamentscheidung. Denkbar ist aber auch, dass das Management hier eine Meinung vertritt und auf die Entscheidung Einfluss nimmt.

Die Frage nach einem möglichen Refactoring stellt sich im Rahmen der Realisierung. Eine allgemeine Richtlinie zu diesem Thema kann aber auch im Rahmen der Architekturdiskussion beschlossen werden.

Generell sind viele der Architekturentscheidungen nicht völlig voneinander losgelöst. Beispielsweise hat die Wahl der Programmiersprache Auswirkungen auf den möglichen Einsatz von Frameworks oder Bibliotheken.

Darüber hinaus zeigen die Beispiele sehr deutlich, dass alle Projektbeteiligten in irgendeiner Form Entscheidungen treffen müssen, sei es als Einzelpersonen oder im Team. Unabhängig davon, welche Rolle jemand an einem Projekt innehat, der Wunsch nach guten Entscheidungen betrifft alle.

Schließlich gibt es noch ein weiteres wesentliches Merkmal, das für die Charakterisierung von Entscheidungen sehr wichtig ist und das sich ebenfalls an den Beispielen sehr deutlich erkennen lässt:

Eine Entscheidung ist irreversibel, wenn sie, nachdem sie einmal getroffen wurde, nicht oder zumindest nicht ohne dramatische Auswirkungen wieder korrigiert werden kann.

Eine Entscheidung ist reversibel, wenn die Korrektur der Entscheidung grundsätzlich möglich ist.

Die meisten Entscheidungen in IT-Projekten sind reversibel. Nur wenige Entscheidungen sind tatsächlich in Stein gemeißelt. Allerdings ist die Korrektur von Entscheidungen mit Aufwand verbunden und in manchen Fällen ist dieser Aufwand erheblich. Es gibt allerdings auch Dinge, die mehr oder weniger problemlos eine Kurskorrektur zulassen. Gerade agil durchgeführte Projekte sind darum bemüht, hierfür die Voraussetzungen zu schaffen. In jedem Fall müssen wir im Auge behalten, ob eine Entscheidung reversibel ist oder nicht, und ebenso müssen wir ein Gefühl dafür entwickeln, wie gut sich die Entscheidung bei Bedarf korrigieren lässt.

1.3Wo können wir etwas über Entscheidungsfindung lernen?

Wir alle haben schon schwerwiegende Fehlentscheidungen in IT-Projekten erlebt. Sei es, dass die falsche Architektur gewählt wurde, sei es, dass die Rollen im Team falsch besetzt wurden, oder sei es, dass aufgrund einer falschen Aufwandsschätzung entschieden wurde, dem Kunden eine Deadline mitzuteilen, die letztlich unmöglich zu halten war – all das kommt immer wieder vor. Dem Projekterfolg sind solche Fehlentscheidungen natürlich nicht dienlich.

Es ist illusorisch zu glauben, dass wir Fehlentscheidungen immer und überall vermeiden könnten. Gerade die Unwägbarkeit vieler entscheidungsrelevanter Aspekte macht typische IT-Projekte zu einem schwierigen Terrain, was die Entscheidungsfindung angeht. Es gibt aber durchaus Instrumente, die wir nutzen können, um zu besseren Entscheidungen zu kommen. Dafür lohnt es sich, einen Blick auf Fachgebiete wie Entscheidungstheorie, Kognitionswissenschaft, Teampsychologie und Statistik zu werfen.

Entscheidungstheorie

Die klassische Entscheidungstheorie [Laux 2007; Eisenführ/Weber/ Langer 2010] ist vor allem aus dem Umfeld der Wirtschaftswissenschaften bekannt. Sie umfasst Modelle zur Strukturierung von Entscheidungsproblemen und schlägt Verfahren vor, um Handlungsalternativen rational zu vergleichen und zu bewerten.

Auch wenn sich die Entscheidungstheorie nicht primär an IT-Projekte richtet, können wir daraus trotzdem einige Erkenntnisse ableiten. Vor allem zeigt uns die Entscheidungstheorie, was eine objektive und systematische Entscheidung überhaupt ausmacht.

Kognitionswissenschaft

Die Frage, wie Menschen Entscheidungen treffen, ist ein zentrales Thema der Kognitionswissenschaft. Einen sehr guten Überblick gibt das Buch Schnelles Denken, langsames Denken des Psychologen und Mathematikers Daniel Kahneman, der darin richtungsweisende Erkenntnisse der Kognitionswissenschaft aus den letzten Jahrzehnten zusammenfasst [Kahneman 2012]. Ausgangspunkt ist die Unterscheidung zweier verschiedener Formen des Denkens. Zum einen gibt es das schnelle, intuitive Denken, das uns sofortige Reaktionen ermöglicht, aber gelegentlich unbewussten Täuschungen unterliegt und daher fehlerbehaftet ist. Zum anderen gibt es das langsame, rationale Denken, das oft bessere Ergebnisse liefert, aber dafür mehr Ressourcen im Sinne von Zeit und kognitivem Aufwand beansprucht.

Die Erkenntnisse der Kognitionswissenschaft ergänzen die Modelle der Entscheidungstheorie insoweit, als sie aufzeigen, wo diese Modelle an ihre Grenzen stoßen. Menschen handeln nicht immer so rational, wie es die Modelle der Entscheidungstheorie im Prinzip voraussetzen. Wir können uns zwar um ein systematisches Vorgehen bemühen, so wie es die Entscheidungstheorie beschreibt. In der Praxis werden wir dieses Ziel aber nicht immer und nicht vollständig erreichen.

Die Grenzen des rationalen Denkens haben auch für die Entscheidungsprozesse in IT-Projekten erhebliche Bedeutung. Gerade die kognitiven Verzerrungen, also die Täuschungen, denen Menschen unbewusst in ihrer intuitiven Wahrnehmung unterliegen, kann man in IT-Projekten immer wieder beobachten. Infolgedessen kommt es in typischen Projektsituationen häufig zu Fehleinschätzungen, die uns in der Entscheidungsfindung beeinträchtigen. Die Kenntnis dieser psychologischen Effekte kann uns helfen, Fehleinschätzungen und Fehlentscheidungen zu vermeiden, zumindest zu einem gewissen Grad.

Teampsychologie

In der IT wird sehr viel im Team gearbeitet. Entscheidungen im Team sind noch mehr kognitiven Verzerrungen unterworfen, als dies generell bereits der Fall ist. Natürlich können sich Personen in Teams ergänzen und gemeinsam zu guten Entscheidungen kommen, indem sie vom Wissen und der Erfahrung aller Beteiligten profitieren. Es gibt aber auch Situationen, in denen genau dies nicht funktioniert.

Ein bekanntes Schlagwort lautet Groupthink. Gemeint ist der Effekt, dass die Meinung einer Gruppe von einer Einzelperson dominiert wird, die bewusst oder unbewusst als Meinungsführer agiert. Gegen die vorherrschende Meinung haben abweichende Meinungen dann kaum eine Chance. Für Entscheidungsprozesse ist dies von Nachteil, weil bestimmte Aspekte einer Entscheidung dann unausgesprochen bleiben und nicht diskutiert werden. Daher sind Mechanismen hilfreich, die dazu führen, dass alle Beteiligten Wissen in eine Entscheidung einbringen und Argumente austauschen können.

Statistik

In der IT wird es immer mehr üblich, Entscheidungen durch Zahlen zu untermauern. Beispielsweise werden Messungen unternommen, um die Codequalität zu bewerten oder um die Antwortzeiten eines Systems zu ermitteln. Die Ergebnisse einer solchen Messung können für eine Design- oder Architekturentscheidung genutzt werden. Ein weiteres Beispiel findet sich im E-Commerce: Dort werden immer häufiger statistische Tests durchgeführt, um verschiedene Varianten eines Onlineshops miteinander zu vergleichen. Die Ergebnisse des Vergleichs entscheiden darüber, wie der Shop weiterentwickelt wird.

Für quantitative Verfahren spricht, dass sie rationale Entscheidungen ermöglichen