Gute Entscheidungen in IT-Projekten - Andreas Rüping - E-Book

Gute Entscheidungen in IT-Projekten E-Book

Andreas Rüping

0,0

Beschreibung

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

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 294

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Dr. Andreas Rüping ist freiberuflicher IT-Berater und lebt in Hamburg. Er favorisiert ein agiles Vorgehen im Projektalltag und unterstützt Unternehmen bei der Durchführung agiler Entwicklungsprojekte. Sein Schwerpunkt liegt dabei auf Tätigkeiten an der Schnittstelle zwischen fachlichen Anforderungen und technischer Umsetzung. Er ist aktives Mitglied der europäischen Pattern Community und Autor mehrerer Artikel und Fachbücher zu verschiedenen Themen der Softwareentwicklung.

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

Andreas Rüping

Gute Entscheidungenin IT-Projekten

Unbewusste Einflüsse erkennen,Hintergründe verstehen, Prozesse verbessern

Andreas Rüping

[email protected]

Lektorat: Melanie Feldmann

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Buch   978-3-86490-648-0

PDF     978-3-96088-727-0

ePub   978-3-96088-728-7

mobi   978-3-96088-729-4

1. Auflage 2019

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Entscheidungen prägen unser Leben. Richtige Entscheidungen helfen uns, erfolgreich zu sein, falsche Entscheidungen führen oft zu Misserfolgen, aus denen wir aber immerhin noch etwas lernen können. Ein solcher Lernprozess setzt aber auch eine Entscheidung voraus, nämlich die Bereitschaft, über die Vergangenheit zu reflektieren und daraus Schlüsse für die Zukunft zu ziehen. Entscheidungen sind dabei immer in einen bestimmten Kontext eingebunden. Dieser Kontext wird bestimmt durch das Ziel, das wir erreichen möchten. Eine gute Entscheidung bringt uns unseren Zielen näher, durch eine schlechte Entscheidung entfernen wir uns davon.

Gute Entscheidungen zu treffen und damit den richtigen Weg einzuschlagen, ist nicht immer einfach. Manchmal fehlt uns das notwendige Wissen, manchmal können wir uns nicht gegen die Meinungen anderer durchsetzen, die andere und möglicherweise konträre Ziele verfolgen. Oft ist gar nicht klar, welche Optionen wir überhaupt haben und wie sie zu bewerten sind. Auch der Zeitpunkt, zu dem es eine Entscheidung zu treffen gilt, ist oft alles andere als offensichtlich. Und manchmal handeln wir schlicht und einfach nicht rational: Wir lassen uns täuschen von kognitiven Verzerrungen, bei denen uns unsere Intuition einen Streich spielt, kommen zu falschen Einschätzungen und ziehen die falschen Schlüsse daraus.

IT-Projekte sind durch eine Vielzahl von Entscheidungen gekennzeichnet. Und natürlich sind auch die Entscheidungen, die wir in IT-Projekten treffen, nicht gegen diese Problematik immun. Wählen wir möglicherweise ein Design, nicht weil es gute Gründe dafür gibt, sondern weil wir damit am meisten vertraut sind? Sind Deadlines, die wir zusagen, realistisch oder möglicherweise viel zu optimistisch? Sind unsere Teamentscheidungen gut oder geben sie nur die Meinung der Wortführer wieder? Und wenn wir Zahlen vorlegen, um eine Entscheidung zu untermauern, sind diese Zahlen überhaupt sinnvoll und belastbar? Dies sind nur einige Beispiele – man kann sich leicht ausmalen, dass es noch viele weitere gibt.

Wir können nicht erwarten, dass es uns immer gelingt, perfekte Entscheidungen zu treffen. Niemand kann alles wissen und niemand kann die Zukunft vorhersagen. Daher wird es immer Unwägbarkeiten geben, die sich nicht abschätzen lassen. Es gibt aber Instrumente, mit denen sich die Entscheidungsfindung verbessern lässt. Entscheidungstheorie, Kognitionswissenschaft, Teampsychologie und Statistik bieten Erkenntnisse, die sich auch auf IT-Projekte anwenden lassen und die es uns erlauben, zu besseren Entscheidungen zu gelangen. Davon handelt dieses Buch.

Ich möchte dazu eine Reihe von Praktiken vorstellen, die sich in vielen IT-Projekten bewährt haben. Ich habe diese Praktiken über Jahre hinweg beobachten können, sie auf Konferenzen zur Diskussion gestellt und so sukzessive weiterentwickelt. Dabei geht es um ganz unterschiedliche Facetten der Entscheidungsfindung. Ich werde beleuchten, wie man qualitative Argumente stärken, aber auch wie man quantitative Verfahren sinnvoll einsetzen kann. Außerdem werde ich Praktiken vorstellen, die sich auf die Entscheidungen von Einzelnen beziehen, aber auch die Entscheidungsfindung im Team betrachten.

Im Prinzip lassen sich diese Praktiken unabhängig davon anwenden, welche Entwicklungsmethode zum Einsatz kommt. Allerdings werde ich vor allem auf Projekte im agilen Umfeld eingehen. Das liegt zum einen daran, dass agile Verfahren in der heutigen Softwareentwicklung weitgehend den methodischen Stand der Technik darstellen. Zum anderen besteht ein wesentlicher Aspekt der agilen Verfahren in der Bereitschaft, über Projektprozesse nachzudenken und diese zu verbessern. Dies schließt auch Entscheidungsprozesse ein. Das bedeutet nicht, dass agil durchgeführte Projekte gegen Fehlentscheidungen immun sind. Agile Teams finden aber in der Regel Wege, um aus Fehlern zu lernen. Agile Verfahren bieten daher eine gute Plattform für den Versuch, Entscheidungsprozesse kontinuierlich zu verbessern.

Praktisch jeder, der an einem IT-Projekt beteiligt ist, muss immer wieder Entscheidungen treffen. Insofern kann dieses Buch im Prinzip für alle Beteiligten an einem IT-Projekt von Bedeutung sein, unabhängig von der Rolle, die sie im Projekt einnehmen. In diesem Sinne wünsche ich Ihnen viel Erfolg bei der Anwendung der im Buch beschriebenen Praktiken.

Andreas RüpingHamburg, April 2019

Danke

Dieses Buch ist über viele Jahre hinweg entstanden. Die ersten Ideen dazu liegen 15 Jahre zurück. Während dieser Zeit habe ich in vielen Situationen beobachten können, wie Entscheidungen getroffen werden und in welchem Spannungsfeld man sich dabei bewegt.

In erster Linie waren dies Situationen in Projekten, an denen ich selbst beteiligt war. Mein Dank gilt ganz besonders denjenigen Kollegen, die ihre Einsichten und Erkenntnisse mit mir geteilt haben.

Viele der in diesem Buch beschriebenen Muster habe ich auf den europäischen Konferenzen zu Software Patterns (EuroPLoP und VikingPLoP) zur Diskussion gestellt. Von vielen Konferenzteilnehmern habe ich wertvolles Feedback erhalten, für das ich sehr dankbar bin. Die Anregungen und Vorschläge der folgenden Personen waren besonders hilfreich: Paris Avgeriou, Veli-Pekka Eloranta, Andreas Fießer, Elissaveta Gurova, Neil Harrison, Kevlin Henney, Christian Kohls, Christian Köppe, Marko Leppänen, Klaus Marquardt, Christopher Preschern, Jari Rauhamäki, Dietmar Schütz, Uwe van Heesch, Michael Weiss und Tim Wellhausen.

Claus Lewerentz und Mathias Schubanz danke ich für einen wissenschaftlichen Austausch im Februar 2017, bei dem einige der Themen dieses Buchs zur Sprache gekommen sind.

Seitens des Verlags hat vor allem Melanie Feldmann zum Gelingen dieses Buchs beigetragen. Ich danke ihr für die Übernahme des Lektorats und für hilfreiche Anregungen und Kommentare zum Manuskript. Ebenso danke ich Christa Preisendanz für ihre Unterstützung. Mein Dank gilt außerdem Wolfgang Keller, Horst Lichter, Carola Lilienthal, Gerhard Müller und Stefan Roock, die als Gutachter des Manuskripts wertvolle Hinweise geliefert haben.

Schließlich spielt beim Schreiben eines Buchs immer auch die Unterstützung aus dem persönlichen Umfeld eine Rolle. Mein abschließender, aber nicht weniger herzlicher Dank geht daher an Freunde und Familie.

Inhaltsübersicht

1Einleitung

2Rationale Argumentation

3Entscheidungen im Team

4Quantitative Verfahren

5Entscheidungskultur

6Integration von Entscheidungen in IT-Prozesse

7Resümee

Anhang

AEntscheidungstheorie

BKognitive Verzerrungen

CListe kognitiver Verzerrungen

DStatistische Grundlagen

EKurzfassungen der Muster

FLiteratur

Index

Inhaltsverzeichnis

1Einleitung

1.1Motivation

1.2Welche Entscheidungen treffen wir in IT-Projekten?

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

1.4Muster

1.5Nutzung des Buchs

2Rationale Argumentation

2.1Zielexplikation

2.2Der Blick nach vorn

2.3Der Blick zurück

2.4Der Blick von außen

2.5Teilen und Tauschen

2.6Entscheidungsmatrix

2.7Experimentierfreude

2.8Analyse und Intuition

3Entscheidungen im Team

3.1Kooperativer Rollenmix

3.2Unabhängige Sichtweisen

3.3Advocatus Diaboli

3.4Diskurs und Konvergenz

3.5Die Zerschlagung des Gordischen Knotens

3.6Delegation

4Quantitative Verfahren

4.1Zahlen mit Sinn und Verstand

4.2Repräsentative Stichprobe

4.3Ceteris Paribus

4.4Mutige Experimente

4.5Experimentkalender

4.6Ehrliche Visualisierung

5Entscheidungskultur

5.1Dezentrale Entscheidungen

5.2Relative Informationsfreiheit

6Integration von Entscheidungen in IT-Prozesse

6.1Entscheidungsbacklog

6.2Die kritische Masse an Information

6.3Timebox

6.4Iterativer Entscheidungsprozess

6.5Inkrementelle Verbesserungen

6.6Faire Retrospektive

7Resümee

Anhang

AEntscheidungstheorie

BKognitive Verzerrungen

CListe kognitiver Verzerrungen

DStatistische Grundlagen

EKurzfassungen der Muster

FLiteratur

Index

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–1Typische Entscheidungen in IT-Projekten

1. Anforderungsmanagement

Themen:

■funktionale Anforderungen

■nichtfunktionale Anforderungen (Verfügbarkeit, Performance, Ergonomie/User Experience (UX), Sicherheit, Wartbarkeit)

Beispiele:

■Für eine Applikation sind mehrere neue Features vorgeschlagen worden. Welche Priorisierung legen wir für diese Features fest, d.h., in welcher Reihenfolge sollen die Features umgesetzt werden?

■Eine bestehende Webapplikation unterstützt bislang kein Responsive Design, das aus Sicht der UX-Experten aber gefordert ist, da viele Kunden mobile Geräte nutzen. Der Aufwand für die Umstellung ist erheblich. Sollen wir das Responsive Design trotzdem einführen?

■Welche Verfügbarkeit streben wir für unsere Webapplikation an? Welche Wartungsintervalle können wir den Kunden zumuten?

2. Architektur

Themen:

■Architekturstile

■Bibliotheken/Frameworks/Middleware

■Systemeigenschaften

Beispiele:

■Welcher Architekturstil ist für uns der richtige? Ein klassisches Schichtenmodell? Eine vertikale Architektur?

■Bislang nutzen wir in unseren Projekten Java als Programmiersprache. Bleiben wir dabei oder können wir uns die Nutzung einer anderen Programmiersprache vorstellen?

■Welche Datenbank kommt zum Einsatz?

■Bislang ist in unseren Projekten Spring 4 im Einsatz. Ein Umstieg auf Spring 5 bietet eine Reihe von Vorteilen, ist aber mit Umstellungsaufwand verbunden. Wollen wir umsteigen?

■In unseren geplanten Applikationen werden Texte angezeigt, die von Fachbereichsmitarbeitern gepflegt werden sollen. Entwickeln wir eine eigene Komponente für die Verwaltung dieser Texte oder nutzen wir dafür ein kommerzielles Content-Management-System? Falls ein CMS genutzt werden soll, welches?

■Welche Testüberdeckung ist gefordert?

■Welches Deployment-Verfahren nutzen wir?

3. Entwicklung

Themen:

■Design

■Implementierung

■Test

■Deployment

Beispiele:

■Aufgrund einer funktionalen Erweiterung wird eine Klasse relativ komplex. Ist der Komplexitätsgrad noch akzeptabel oder wird ein Refactoring nötig?

■Wir haben die Wahl zwischen einer schnellen, aber sehr speicherintensiven Implementierung einerseits und einer speicherschonenden Implementierung andererseits, die aber etwas langsamer ist. Für welche entscheiden wir uns?

4. Team

Themen:

■Methodik

■Prozesse

Beispiele:

■Welche Methodik wenden wir an? Klassische Softwareentwicklung? Ein agiles Verfahren? Wenn ja, welches?

■Wir arbeiten nach Scrum. Wie lange sind die Sprints? Zwei Wochen? Drei Wochen? Ein ganz anderer Zeitraum?

■Ist im Team Pair Programming gefordert, gewünscht, freigestellt oder unerwünscht?

■Wir sind uns im Team einig darüber, dass die Livestellung von Code immer einen erfolgreichen Test voraussetzt. Es bleibt aber die Frage, wann die Tests entwickelt werden: nach der Implementierung der Funktionalität (das klassische Verfahren) oder vorher (test-driven)?

5. Management

Themen:

■langfristige/strategische Planung

■Budgetplanung

Beispiele:

■Ein Kunde hat eine neue Funktion in Auftrag gegeben und wünscht die Umsetzung idealerweise innerhalb von zwei Monaten. Die Schätzung der IT läuft auf vier Monate hinaus, durch Verschiebung anderer Projekte kann die Implementierung aber möglicherweise beschleunigt werden. Welchen Termin für die Fertigstellung eines neuen Features sagen wir dem Kunden zu?

■Um eine Webapplikation, die bislang nur einsprachig vorliegt, auch im Ausland anbieten zu können, muss sie um Mehrsprachigkeit erweitert werden. Welchen Gesamtaufwand sehen wir dafür als gerechtfertigt an?

■In der IT-Abteilung gibt es insgesamt vier Teams, von denen zwei dringenden Bedarf nach Teamverstärkung angemeldet haben. Ein neuer Kollege beginnt im nächsten Monat. In welchem Team soll er mitarbeiten?

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 oder doch zumindest erleichtern können. Dies setzt aber einen vernünftigen Umgang mit den ermittelten Zahlen voraus, der leider nicht immer sichergestellt ist, weil Menschen in der Regel keinen intuitiven Zugang zu statistischen Daten haben. Quantitative Verfahren werden daher oft falsch angewendet und ihre Ergebnisse fehlinterpretiert. Ein Erkenntnisgewinn ist dann nicht mehr gegeben. Bessere Entscheidungen können wir nur erwarten, wenn wir auch die wesentlichen Prinzipien beim Umgang mit Zahlen berücksichtigen.

Bessere Entscheidungen über Methodengrenzen hinweg

Domänen wie Entscheidungstheorie, Kognitionswissenschaft, Teampsychologie und Statistik bieten Erkenntnisse, die auch für die Entscheidungsfindung in IT-Projekten von Bedeutung sein können. Indem wir diese Erkenntnisse nutzen, können wir unserem Ziel, bessere Entscheidungen zu treffen, ein Stück näher kommen.

Dies gilt im Übrigen unabhängig von der Methodik, die in einem Projekt zum Einsatz kommt. Ob klassische Softwareentwicklung oder agiles Vorgehen, von der Möglichkeit, Fehlentscheidungen zu reduzieren, können alle Projekte profitieren. Agil durchgeführte Projekte haben allerdings den Vorteil, dass sie die Frage nach möglichen Verbesserungen immer wieder stellen. Das offenkundige Beispiel dafür ist die Retrospektive, die in allen agilen Projekten regelmäßig durchgeführt wird. Aber auch darüber hinaus schaffen agile Verfahren ein Bewusstsein dafür, dass es sinnvoll ist, sich kontinuierlich um die Verbesserung der Projektprozesse zu bemühen. Erkenntnisse darüber, wie wir Fehleinschätzungen vermeiden und zu besseren Entscheidungen gelangen können, fallen in einer agilen Kultur auf fruchtbaren Boden.

1.4Muster

Ich möchte in diesem Buch eine Reihe von Praktiken vorstellen, die die Entscheidungsfindung in IT-Projekten verbessern können. Diese Praktiken liegen in Form von Mustern vor. Muster (patterns) sind seit einem Vierteljahrhundert in der praxisorientierten Literatur zur Softwareentwicklung weit verbreitet. Sie beschreiben bewährte Lösungen für wiederkehrende Probleme und diskutieren dabei auch den Kontext, in dem die Lösung angewendet werden kann, sowie die Faktoren, die Einfluss auf die Lösung nehmen.

Die Muster in diesem Buch sind das Ergebnis von Beobachtungen aus einer Vielzahl von IT-Projekten. Ich habe die Muster über Jahre hinweg zusammengetragen und auf Konferenzen und Workshops vorgestellt und diskutiert. In diesem Sinne sind hier nicht nur meine persönlichen Erfahrungen dokumentiert, sondern auch die vieler Kollegen. Die Muster sind durchweg praktischer Natur. Fraglos sind auch theoretische Erkenntnisse in die Muster eingeflossen, sie stammen aber alle aus der Praxis und sind in der Praxis anwendbar.

Sämtliche Muster in diesem Buch folgen einem einheitlichen Aufbau. Die einzelnen Abschnitte der Muster haben folgende Bedeutung:

Der

Kontext

beschreibt die Ausgangssituation, in der das Muster angewendet werden kann.

Das

Problem

beschreibt, wie es im gegebenen Kontext zu einer Fehleinschätzung oder Fehlentscheidung kommen kann.

Die Informationen zum

Hintergrund

erläutern, warum das Problem besteht und welche Faktoren Einfluss auf mögliche Lösungen nehmen.

Die

Lösung

beschreibt eine Technik, mit der sich das Problem vermeiden oder zumindest abmildern lässt.

Die

Details

zeigen, wie die Lösung umgesetzt werden kann, und schlagen dafür konkrete Schritte vor.

Bei den

Beispielen

handelt es sich um typische, wenn auch fiktive Situationen, wie sie in IT-Projekten anzutreffen sind, und in denen die skizzierte Lösung angewendet werden kann.

Die

Diskussion

nennt schließlich weitergehende Aspekte im Zusammenhang mit der beschriebenen Lösung, beispielsweise spezielle Konsequenzen, die sich aus der Anwendung ergeben, oder auch den Zusammenhang zu anderen Mustern.

Zum besseren Verständnis habe ich die Muster in diesem Buch noch um weiteres Material ergänzt. Da dieses Material über die eigentlichen Muster hinausgeht, ist es in grauen Infokästen dargestellt:

Unter dem Schlagwort

Wissenswert

habe ich Hintergrundinformationen zusammengestellt, die tiefergehende oder auch kontroverse Aspekte zu einem bestimmten Thema beleuchten.

Infokästen mit dem Titel

Aus der Praxis

bieten eine Reihe praktischer Tipps für den Projektalltag.

Kästen zum Thema

Typischer Fehler

zeigen, was passieren kann, wenn ein Muster nicht angewendet wird. Diese Beispiele stammen aus echten (wenn auch anonymisierten) Projekten und haben sich in der Realität genau so abgespielt.

Schließlich stelle ich unter dem Stichwort

Analogie

interessante Parallelen zu anderen Domänen vor.

Die verschiedenen Muster nehmen aufeinander Bezug und ergänzen sich gegenseitig. Sie stellen aber bewusst kein Prozessframework dar, das ein bestimmtes Vorgehen im Projekt einfordert. Stattdessen handelt es sich um eine Sammlung von Praktiken, die unabhängig davon verwendet werden können, welche Methodik im Projekt zum Einsatz kommt. Wie bereits angedeutet, sind agile Verfahren sicherlich besonders dafür geeignet, die in diesem Buch beschriebenen Muster zu nutzen. Prinzipiell ist eine Anwendung der Muster aber ganz allgemein in IT-Projekten denkbar.

1.5Nutzung des Buchs

Bevor ich mit der Präsentation der Muster beginne, kurz noch ein paar Worte zum Aufbau und zur Nutzung des Buchs.

Im Grunde genommen gibt es zwei verschiedene Arten, wie Sie dieses Buch lesen können. Die erste Möglichkeit besteht offensichtlich darin, der Reihenfolge der Kapitel und damit der logischen Struktur des Buchs zu folgen. Auf diese Weise lernen Sie die Muster in einer natürlichen Sequenz kennen und erhalten einen guten allgemeinen Überblick zur Entscheidungsfindung in IT-Projekten.

Es ist aber auch möglich, sich zunächst auf ein spezielles Thema zu konzentrieren. Tabelle 1–2 gibt einen Überblick über die einzelnen Kapitel und stellt einige zentrale Fragen vor, die dort diskutiert werden. Die Tabelle ermöglicht Ihnen so einen Schnelleinstieg ins Buch. Wenn Sie mit einem Kapitel beginnen, das Sie besonders interessiert, erhalten Sie beim Lesen auch Hinweise auf weitere relevante Punkte, da sich die einzelnen Muster gegenseitig referenzieren, und können so durch das Buch navigieren.

Tab. 1–2Inhalt des Buchs

Kapitel 2: Rationale Argumentation

■Welche Aspekte sind bei einer Entscheidung grundsätzlich zu berücksichtigen?

■Welche kognitiven Verzerrungen sind bei Entscheidungen immer wieder anzutreffen?

■Wie lassen sich diese kognitiven Verzerrungen vermeiden?

■Wie gelingt es, rationales Vorgehen und Intuition miteinander zu verbinden?

Kapitel 3: Entscheidungen im Team

■Welche Effekte treten auf, wenn in einer Gruppe Entscheidungen getroffen werden?

■Wie kann man von den unterschiedlichen Kenntnissen der verschiedenen Teammitglieder am besten profitieren?

■Wie gelingt es, alle Teammitglieder an den Entscheidungen zu beteiligen?

■Ist es möglich, einen Konsens zu erreichen? Ist es wünschenswert?

Kapitel 4: Quantitative Verfahren

■Wann können quantitative Methoden genutzt werden, um Entscheidungen herbeizuführen?

■Was muss bei quantitativer Argumentation berücksichtigt werden?

■Welche Rolle spielt der Zufall bei quantitativen Betrachtungen? Wie lässt sich damit umgehen?

■In welchen Situationen kann es sich lohnen, Expertenwissen zu Statistik an Bord zu holen?

Kapitel 5: Entscheidungskultur

■Wer sollte innerhalb einer Organisation an welchen Entscheidungen beteiligt sein?

■Was kann eine Organisation tun, um die Qualität der Entscheidungen zu verbessern?

Kapitel 6: Integration von Entscheidungen in IT-Prozesse

■Wie lassen sich Entscheidungen in die Prozesse eines Projekts einbinden?

■Wann müssen Entscheidungen getroffen werden? Und wie viel Zeit muss man sich dafür lassen?

■Wie können wir Entscheidungsprozesse iterativ gestalten?

■Wie wirkt sich das in agilen Projekten übliche inkrementelle Vorgehen auf die Entscheidungsfindung aus?

■Wie können wir aus Entscheidungen der Vergangenheit lernen?

Die Muster in diesem Buch lassen sich auf Entscheidungen in unterschiedlichen Größenordnungen anwenden. Dies beginnt mit Entscheidungen, die eine Person allein trifft, und erstreckt sich bis hin zu Entscheidungen, die im Team getroffen werden und denen eine Diskussion oder sogar eine regelrechte Evaluierung der Handlungsoptionen vorausgeht. Entsprechend kann auch die praktische Anwendung der Muster unterschiedliche Formen annehmen. Im einfachsten Fall bedeutet die Anwendung der Muster vielleicht nur ein kurzes Nachdenken mit dem Ziel, sich die Praktiken für eine rationale Entscheidungsfindung ins Bewusstsein zu rufen. In den meisten Fällen wird es dabei aber nicht bleiben. Um die Muster im größeren Stil einzusetzen, ist eine Anpassung der Projektprozesse unumgänglich. Dies erfordert ein gewisses Maß an Reflexion und Bereitschaft zu Änderungen. Es bietet sich so aber auch die Chance, projektweit von besseren Entscheidungen zu profitieren.

2Rationale Argumentation

Stellen wir uns zunächst die Frage, was überhaupt eine gute Entscheidung ausmacht. Wie bereits angedeutet, ist eine Entscheidung nie isoliert zu betrachten, sondern immer im Kontext des Ziels, das man erreichen möchte. Eine Entscheidung ist dann hilfreich, wenn sie es uns erlaubt, unser Ziel zu erreichen oder zumindest unserem Ziel näher zu kommen.

Ein rationales Vorgehen ist dafür ein wichtiger Baustein. Die Bedeutung erkennt man schon daran, dass Intelligenz gelegentlich als die Fähigkeit definiert wird, Entscheidungen auf eine rationale Art und Weise zu treffen. So schreibt der Kognitionswissenschaftler Steven Pinker in seinem Buch How the mind works: »Intelligence [..] is the ability to attain goals in the face of obstacles by means of decisions based on rational (truth-obeying) rules« [Pinker 1997]. Der Fähigkeit zu einem rationalen Vorgehen wird hier also eine erhebliche Bedeutung zugeschrieben. Eine Entscheidung ist dabei als rational anzusehen, wenn sie in sich widerspruchsfrei ist und sich im Einklang mit der eigenen Zielsetzung befindet.

Über das Ziel selbst wird keine Aussage getroffen. Welche Ziele wir uns setzen, ist tatsächlich eine ganz andere Frage. Insbesondere ist es denkbar, verschiedene Ziele zu formulieren, die durchaus auch in Konkurrenz zueinander stehen können. So kann es in einem IT-Projekt technologische, wirtschaftliche, strategische, persönliche oder auch ethische Ziele geben. All das ist legitim. Falls Ziele miteinander konkurrieren, müssen wir sie gewichten und gegeneinander abwägen. Um genau dies zielgerichtet tun zu können, sind wir auf ein rationales Vorgehen angewiesen.

Die Frage nach guten Entscheidungen und insbesondere nach einem rationalen Vorgehen ist natürlich nicht neu. Die klassische Entscheidungstheorie geht dieser Frage nach und bietet eine Reihe mathematischer Modelle, um zu rationalen Entscheidungen zu gelangen [Laux 2007; Eisenführ/Weber/Langer 2010; Peterson 2009