Dynaxity: Management von Dynamik und Komplexität im Softwarebau

Dynaxity Patrick Hamilton Dynaxity Management von Dynamik und Komplexität im Softwarebau Mit 28 Abbildungen 123 P...

Author: Patrick Hamilton

51 downloads 2708 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Dynaxity

Patrick Hamilton

Dynaxity Management von Dynamik und Komplexität im Softwarebau

Mit 28 Abbildungen

123

Patrick Hamilton Am Grundweg 22 64342 Seeheim-Jugenheim [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN-10 3-540-31743-0 Springer Berlin Heidelberg New York ISBN-13 978-3-540-31743-2 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3100 YL – 5 4 3 2 1 0

Ich danke meinen Lufthansa-Kollegen, die mich in unseren gemeinsamen Projekten immer wieder dazu angeregt haben, Dinge neu zu hinterfragen und Zusammenhänge aus anderen Perspektiven zu beleuchten.

Inhaltsverzeichnis

1

Prolog ................................................................................................ 1 1.1 Sichten müssen sich ändern..................................................... 1 1.1.1 Lohnt sich dieses Buch für Sie? ................................... 2 1.1.2 Nicht Bits und Bytes, sondern Menschen .................... 2 1.2 Die drei INs ............................................................................. 3 1.3 Bilanz ist gefragt...................................................................... 4 1.4 Tote Pferde reiten .................................................................... 8

2

Basteln Sie oder produzieren Sie schon? ..................................... 11 2.1 Biographie eines Softwarelebens........................................... 11 2.1.1 Erste Ideen – vom Fischen in trüben Gewässern ....... 12 2.1.2 Angebissen! – die Geburtsstunde einer neuen Software.................................................. 13 2.1.3 Zeit für Verträge......................................................... 14 2.1.4 Erste Konzepte ........................................................... 15 2.2 Wer kauft Katzen im Sack? ................................................... 17 2.2.1 Erarbeiten Sie ganzheitliche Lösungen? .................... 17 2.2.2 Software-Legosteine................................................... 18 2.2.3 Arbeiten Sie nebeneinander oder als Team? .............. 19 2.2.4 Zeit ist Geld – oder von der Fähigkeit, Geld zu verbrennen .................................................... 20 2.3 Wenn fehlende Strategien teuer werden ................................ 22 2.3.1 Die Zukunft im Visier ................................................ 23 2.3.2 Ein Gedankenexperiment ........................................... 25 2.3.3 Das Imperium schlägt zurück..................................... 26 2.3.4 Probleme aussitzen..................................................... 26 2.4 Schlingerkurse ....................................................................... 28 2.4.1 Ordnungen der höheren Art........................................ 30 2.4.2 Elefantitische Eleganz ................................................ 30 2.4.3 Wenn Software zur Slowware mutiert ....................... 31 2.5 Produktionsmüll..................................................................... 32 2.5.1 Kompakte Informationen ........................................... 33 2.5.2 Nichts ist so ungetestet wie Software......................... 34 2.5.3 Alptraum der letzten Meile......................................... 35

VIII Inhaltsverzeichnis

2.5.4 2.5.5 2.5.6 2.5.7

Homo sapiens Rache .................................................. 36 Nutzbarkeit und andere Legenden.............................. 37 Zombie-Software........................................................ 39 Kleinvieh macht Mist ................................................. 40

3

Willkommen in der Wirklichkeit ................................................. 43 3.1 Vom Maßstab aller Dinge...................................................... 43 3.2 Softwerker ............................................................................. 46 3.3 Softwarekomplexität.............................................................. 48 3.3.1 Verursacherprinzip ..................................................... 49 3.3.2 Intellektuelle Phasen .................................................. 50 3.3.3 Formen der Komplexität ............................................ 53 3.3.4 Nutzbarkeit der Software ........................................... 54 3.4 Interaktives Arbeiten ............................................................. 56 3.4.1 Wertschöpfungskette.................................................. 57 3.4.2 Fertigungsstufen der IT .............................................. 58 3.5 Digitale Geschichte................................................................ 59 3.5.1 Was Römer mit Hightech verbindet........................... 59 3.5.2 Über die Pferdehintern der IT .................................... 60 3.6 Psychodynamiken.................................................................. 66 3.6.1 Software-Epiphyten.................................................... 67 3.6.2 Teamaspekte............................................................... 70 3.6.3 Kommunikationsebenen............................................. 72 3.6.4 Moribunde Projekte.................................................... 73 3.7 Glaubenskriege ...................................................................... 74 3.7.1 Prozessmodelle auf dem Prüfstand............................. 74 3.7.2 Jedem das seine .......................................................... 75 3.7.3 Soziale Dynamik ........................................................ 84 3.7.4 Massenprodukte oder Unikate?.................................. 85 Literatur ........................................................................................... 87

4

Von der Krisis zur Katharsis ........................................................ 89 4.1 Dynamik, Chaos und Komplexität ........................................ 89 4.1.1 Von der Konstanz der Komplexität............................ 90 4.1.2 Komplexität provoziert Fehler ................................... 92 4.1.3 Kurzausflug ins Gehirn .............................................. 95 4.1.4 Komplexität entwirren.............................................. 101 4.2 Systemisches Denken und Handeln..................................... 107 4.2.1 Wege des Denkens ................................................... 109 4.2.2 Ganzhirniges Arbeiten.............................................. 114

Inhaltsverzeichnis

IX

4.3

Emergente Meme................................................................. 118 4.3.1 Software-Emergenz.................................................. 119 4.3.2 Hauptsätze der Softwareentwicklung....................... 121 4.3.3 Geistesblitze ............................................................. 123 4.4 Und sie lebt doch!................................................................ 124 Literatur ......................................................................................... 128 5

Ganzheitlicher Softwarebau ....................................................... 129 5.1 „Coole“ Software................................................................. 129 5.2 Holismus pur ....................................................................... 134 5.2.1 Systemische Wissenserzeugung ............................... 135 5.2.2 Das Matruschka-Prinzip........................................... 139 5.3 Schlanke Produktion............................................................ 142 5.3.1 Automaten für alles .................................................. 147 5.3.2 Nachhaltigkeit .......................................................... 150

6

Arbeiten im Kollektiv .................................................................. 153 6.1 Psychologie des Softwarebaus............................................. 154 6.1.1 Grenzen der Arbeit ................................................... 161 6.1.2 Ganzheitlichkeit und Innovation .............................. 165 6.2 Kybernetiker und Kutscher.................................................. 168 6.2.1 Führung mit Stil ....................................................... 170 6.2.2 Gallionsfigur werden................................................ 173 6.2.3 Kutscher sein............................................................ 177 6.3 Artgerechte Haltung von Teams.......................................... 179 6.3.1 Humane Konglomerate ............................................ 181 6.3.2 Grundlagen der Kollaboration.................................. 182 6.4 Teampower .......................................................................... 186 6.4.1 Hochleistungsteams.................................................. 187 6.4.2 Co-Intelligente Teams .............................................. 191 Literatur ......................................................................................... 194

7

Showdown..................................................................................... 197 7.1 Der Auftrag.......................................................................... 197 7.2 Der Macher .......................................................................... 201 7.3 Projektvorlauf ...................................................................... 207 7.4 Projektbeginn....................................................................... 214 7.5 Projektumsetzung ................................................................ 217 7.6 Die Ausreifungsphase.......................................................... 218 7.7 Produktionsbetrieb............................................................... 219

X

Inhaltsverzeichnis

Epilog...................................................................................................... 221 Quellenübersicht ................................................................................... 223 Index....................................................................................................... 227

Abbildungsverzeichnis

Abb. 1.1. Ein Gedankenexperiment.......................................................... 6 Abb. 1.2. Auflösung des Gedankenexperiments und Übertragung auf die Softwareproduktion ...................................................... 7 Abb. 2.1. Softwareentwicklung und deren Folgekosten......................... 24 Abb. 2.2. Plan und Wirklichkeit – zwei Welten begegnen sich ............. 27 Abb. 3.1. Die fünfstufige CMM-Einteilung von Softwareproduktionsprozessen ............................................... 43 Abb. 3.2. Auswertung von Projekterfolgen und -misserfolgen (A) sowie Faktoren, die dies beeinflussen (B) .............................. 45 Abb. 3.3. Software-Engineering gesehen als Transformation von Komplexitäten ................................................................. 49 Abb. 3.4. Die intellektuellen Phasen im Softwarebau............................ 52 Abb. 3.5. Abhängigkeitsmodell zur Softwarekomplexität nach Nystedt ........................................................................... 55 Abb. 3.6. Zyklischer Arbeitsprozess zur Vermeidung von unnötigen Komplexitäten ........................................................................ 57 Abb. 3.7. Anwender und Hersteller – ein ephiphytisches System.......... 68 Abb. 3.8. Vier-Ohren-Modell nach F. Schulz von Thun übertragen auf den Softwarebau (vereinfacht).......................................... 71 Abb. 3.9. Prozess- vs. Team- und Eigenverantwortung ......................... 83 Abb. 4.1. Vom Chaos zur Ordnung...................................................... 103 Abb. 4.2. Wenn Komplexität zum Feind wird ..................................... 105 Abb. 4.3. Analytisches und systemisches Denken ............................... 113 Abb. 4.4. Systemisches Arbeiten begrenzt Komplexitätszuwachs....... 114 Abb. 4.5. Kosten und Gewinne in einem Software-Lebenszyklus ....... 125 Abb. 5.1. Was gute Software ausmacht................................................ 129 Abb. 5.2. Balance zwischen Projektsituation und Nutzbarkeit ............ 132 Abb. 5.3. Fünf-Phasen-Modell der Wissensbildung............................. 136 Abb. 5.4. Schalenmodell im ganzheitlichen Softwarebau.................... 141 Abb. 5.5. Lean Production im IT-Kontext............................................ 144 Abb. 6.1. Was an den Mitarbeitern zerrt und zehrt .............................. 156 Abb. 6.2. Teams auf dem Weg zur Höchstleistung .............................. 187 Abb. 6.3. Gruppenintelligenz – Gehirne arbeiten zusammen............... 193 Abb. 7.1. Kernbereiche im optimalen Softwarebau ............................. 199 Abb. 7.2. Kernbereiche im optimalen Softwarebau ............................. 212

1 Prolog

Wer sich nicht verändern will, wird auch verlieren, was er bewahren möchte. (Gustav Heinemann) Folgt man aktuellen Statistiken über Softwarebau, so belegen diese, dass zwischen 60% und 80% aller Projekte im strengen Sinne gesehen nicht erfolgreich sind, d. h., dass die drei Kriterien in-time, in-quality und inbudget nicht planungsgemäß erfüllt wurden. Nicht berücksichtigt sind hierbei die unnötigen Folgekosten, die Firmen dadurch entstehen, dass sie durch Unachtsamkeit und Mängel entstandene Fehler während der Planungs- und Produktionsphasen nachbessern müssen bzw. durch konstruktive Gründe dauerhafte Mehraufwände bei der Pflege oder Weiterentwicklung ihrer Software haben.

1.1 Sichten müssen sich ändern Sollten Sie sich die Frage stellen, ob, was und wie Dinge zum Besseren verändert werden können, so werden Sie in diesem Buch Antworten finden. Dabei wird nicht in erster Linie die Rede von Bits & Bytes, Objekten & Klassen oder irgendwelchen spezifischen Entwicklungsmethoden der Software sein. Hierzu gibt es vielfältige andere Fachliteratur. Zudem werden vermutlich Sie und Ihre Mitarbeiter ohnehin über viel Sachkenntnisse in diesem Bereich verfügen. Im Rahmen dieses Werkes möchte ich mich mit dem „nichtbinären“ Umfeld der Softwareentwicklung befassen. Der Tatsache, dass den größten Projektrisiken, nämlich Komplexität und Dynamik, nicht ausreichend oder rechtzeitig begegnet wird, soll besonderes Augenmerk gewidmet werden. Die Rede wird sein von all denjenigen Aspekten, die sich nicht mit Programmen und Prozessen abbilden lassen, sondern diesen zugrunde liegen müssen. Es geht um Menschen, die hierin aktiv handeln, persönliche Erfahrungen einbringen oder aufgrund persönlicher Unkenntnis Dinge verbergen oder verhindern. Dieses Buch versteht sich als ein hinterfragendes Werk und nicht als ein Text mit fertigen Rezepten. Es wird Ihnen viele Hintergrundinformationen anbieten und möchte Sie vor allem zum Nachdenken und Hinterfragen Ihrer aktuellen Vorgehensweisen einladen.

2

1 Prolog

1.1.1 Lohnt sich dieses Buch für Sie? Soweit zum Einstieg – jetzt sind Sie gefragt. Da ich Ihre Zeit nicht unnötig strapazieren möchte, schlage ich Ihnen drei Kategorien vor, die Ihnen dabei helfen sollen, für sich zu klären, ob dieses Buch es wert ist, dass Sie es zum jetzigen Zeitpunkt lesen: x Wenn Sie mit Ihren Resultaten als IT-Professional bzw. denen Ihrer ITMannschaft völlig einverstanden sind und Sie auf durchweg positive Resultate blicken können, so sollten Sie dieses Buch beiseite legen und sich wichtigeren Themen zuwenden. x Für den Fall, dass es bei Ihnen gewisse Anfragen oder Zweifel bzgl. der Effizienz Ihrer Softwareentwicklung geben sollte, so dürfte dieses Buch Sie an der einen oder anderen Stelle durchaus zum Nachdenken anregen. x Stellen Sie sich den entsprechenden Fragestellungen, bevor Sie dieses Buch wieder weglegen! Einen weiteren Punkt möchte ich Ihnen an dieser Stelle nicht vorenthalten. Dieses Buch hat die erklärte Absicht, nicht nur als eine Quelle für Sachinformationen zu fungieren. Vielmehr möchte ich Sie diskret dazu herausfordern einige Ihrer eigenen Handlungsparadigmen in diesem Kontext zu hinterfragen. Wenn Sie grundsätzlich bereit sind, selbst erste Schritte zu gehen, dann investieren Sie sinnvoll in diese Lektüre, andernfalls sind Sie gerade im Begriff, eine Fehlinvestition an Zeit und Geld zu leisten. 1.1.2 Nicht Bits und Bytes, sondern Menschen Nach diesen Anmerkungen sind noch einige Punkte klarzustellen und deutlich herauszuheben. Sollten Sie an dieser Stelle ein Buch erwarten, welches Ihnen sagt, wie man z. B. UML1, Java-Klassen oder Softwarearchitekturen erstellt, so wird Sie dieses Buch enttäuschen. – Natürlich wird in der einen oder anderen Form die Technik zu Wort kommen, erklärtes Ziel dieses Werkes ist es jedoch, die Menschen hinter diesen Technologien zu betrachten: die Entwickler, IT-Architekten, Fachspezialisten sowie die entsprechenden Manager. Der Schwerpunkt wird dabei auf dem Umgang mit der innewohnenden Komplexität bei der Erstellung von Software liegen und den Möglichkeiten, diese zu beherrschen. Es geht sowohl um Vorgehensweisen bei der Produktion wie auch deren Risiken, die durch diese Prozessbeteiligten hervorgerufen werden, und die Beleuchtung möglicher Fehlerquellen. Wir mögen inzwischen auf faszinierende Softwarewerkzeuge und 1

UML – „Unified Modelling Language“ – ist eine derzeit häufig verwendete Softwareentwicklungs-Standardsprache zur Spezifizierung, Visualisierung und Konstruktion von Softwarekomponenten.

1.2 Die drei INs

3

Entwicklungsmethoden blicken. Diese bleiben jedoch ineffizient, wenn die Menschen, die sie nutzen, zum Flaschenhals werden und nicht ausreichend in diese Vorgehensweisen integriert wurden. Da diese Techniken in enger Interaktion mit ihrem Umfeld, den eigenen Entwicklungsteams, dem Management und vor allem auch den Kunden, stehen, möchte ich mit Ihnen integrative Ansätze aufspüren und diskutieren. Ja, Sie lesen richtig: Dieses Buch stellt sich immer wieder der Frage, ob nicht gerade Sie und ich – oder aber Ihre und meine IT-Kollegen – zum zentralen Faktor des Erfolgs oder Misserfolgs eines Softwareprojektes werden! Haben wir eine genügend breite Sichtweise auf die wirklichen Probleme, die sich geschickt hinter dem Tagesgeschäft verstecken, oder haben wir diese eigentlichen Verursacher noch nicht in ausreichendem Maße als die eigentlichen Feinde erkannt und ihnen den Krieg erklärt? Diese Probleme werden nur dann gelöst werden können, wenn Sie und ich fundierte, aber pragmatische Lösungen in die Wege leiten.

1.2 Die drei INs Was erwartet Sie also in dieser Lektüre? Überall strebt man in der ITBranche nach Software, die IN3 gerecht wird, nämlich „in-time“, „inquality“ und „in-budget“. Die Software soll robust, am besten fehlerfrei und vor allem für die Nutzungsdauer leicht wartbar und erweiterbar sein. Aufgrund des hohen Kostendrucks soll die zu bauende Software dazu beitragen, die Unternehmensgewinne stabil zu halten. Viele andere Kostenfaktoren werden absehbar steigen, hier wurde jedoch mittels Unterstützung durch ein Softwareprodukt eine Nische erspäht, von der man sich bei sinkenden Stückpreisen immer noch steigende oder wenigstens gleichbleibende Erlöse erhofft. Ein solches Unterfangen ist grundsätzlich richtig, es verlangt jedoch einen hohen Reifegrad der jeweiligen Entwicklungsabteilungen. Diese müssen geprägt sein durch ganzheitliches, vorausschauendes und unternehmerisches Denken. Ist Ihre Organisation bereits so mündig? Der erfolgreiche Bau solcher Software ist nicht nur geprägt von den technischen Randbedingungen und dem Einsatz geeigneter Technologien, sondern die Resultate werden stark durch die darin mitwirkenden Menschen beeinflusst. So betrachtet gehen diese für die Zeit der Softwareentwicklung eine Art Symbiose mit der Technik ein, um auf diese Art und Weise ihr „Baby“ hervorzubringen. Auf diesen Seiten geht es somit um diejenigen Randbedingungen und Einflussfaktoren, die IN3 stören. In diesem Werk wird die Rede davon sein, welches die anfänglichen Einflussfaktoren sind, die Ihnen die Chance

4

1 Prolog

geben, auch noch gegen Ende eines Software-Lebenszyklus Kosten und Qualität zusammenzuhalten, bzw. für welche frühen Fehler Sie den Rest des Software-Lebenszyklus büßen müssen. Hierbei möchte ich Sie mit wirkungsvollen Ansätzen bekannt machen, die man im wahrsten Sinne als ganzheitlich Psycho-Logische Aspekte beim Bau von Software bezeichnen könnte. Jeder dieser drei Teilbegriffe steht hierbei für eine entscheidende Grundaussage: Unter Ganzheitlichkeit wird es in diesem Kontext um das Gesamtsystem Softwareentwicklung gehen. Die Rede wird von denjenigen Aspekten sein, die häufig unterschlagen werden, weil sie nicht unbedingt in ein ingenieurmäßiges Weltbild passen. Daneben wird immer wieder die Frage beleuchtet werden, was Software komplex macht und wie man dieses entschärfen kann. Der zweite Begriff, nämlich „Psycho“, steht für die Skills, Teamstrukturen und Eigenarten der Entwicklungsmannschaft. Als Letztes bezieht sich die „Logik“ auf all das, was wir ohnehin schon in der einen oder anderen Weise innerhalb der IT betreiben: auf Prozesse, Verfahren, Methoden und ingenieurmäßiges Vorgehen. Da der Ganzheitlichkeit in diesem Buch große Bedeutung zugeordnet wird, mag es Themen geben, die sie ansprechen, andere wiederum könnten Ihre eigenen Handlungsparadigmen betreffen und zuletzt wird es solche Ansätze geben, die Sie völlig anders sehen bzw. ablehnen. Jede dieser Positionen ist legitim! Im Fall der letzten Sichtweise hilft mir persönlich eine Einstellung des protestantischen Reformators Martin Luther weiter: Bei Aussagen, die er nicht verstand oder akzeptierte, so berichtet man über ihn, zog er innerlich seinen Hut, grüßte freundlich, ließ das Thema stehen und zog weiter. Diesen Ansatz halte ich persönlich für differenzierter und adäquater als solche Vorgehensweisen, bei denen man wegen divergenter Sichtweisen zu bestimmten Teilthemen den gesamten Ansatz verwirft.

1.3 Bilanz ist gefragt Sollte ich Sie jetzt neugierig gemacht haben, so möchte ich Sie zu einer Bestandsaufnahme in dem für Sie zutreffenden Kontext einladen. Im klassisch medizinisch-therapeutischen Sinne möchte ich hierbei im Wesentlichen folgende Schwerpunkte setzen:

1.3 Bilanz ist gefragt

5

Anamnese. Zunächst heißt es Inventur machen! Wie sieht es tatsächlich in Ihrer Organisation aus? Kennen Sie die kleinen und großen „Sünden“, die sich regelmäßig wiederholen? Das Augenmerk wird hier auf dem gesamten Lebenszyklus einer Software liegen. Ebenso geht es darum, einen Blick auf die Prozessbeteiligten zu werfen und die guten wie schlechten Einflüsse zu ergründen, welche diese auf Ihre Produkte haben. Analyse. Zunächst wird es darum gehen, die eigentlichen „Feinde“ im Softwarebau zu ermitteln und herauszufinden, durch welche Mechanismen diese wirksam werden. Hieran anschließend werde ich mit Ihnen verschiedene „Best Practices“, also bewährte Verfahren – auch aus anderen Industriezweigen –, betrachten und deren Verwertbarkeit für effizienten Softwarebau beleuchten. Es wird die Rede von Prozessmodellen sowie von gut untersuchten Be- und Entschleunigungsfaktoren aus dem Praxisalltag sein. Therapie. Mit diesem so ermittelten gemeinsamen Begriffshintergrund ist der letzte Teil dieses Werkes Praxisaspekten gewidmet. Anhand von Schwerpunktthemen aus dem Bereich Projekt- und Prozessmanagement werde ich solche Aspekte zusammenfügen, die m. E. zusammengehören. Es werden geeignete Methoden und „Werkzeuge“ vorgestellt und es wird darüber gesprochen werden, wie sich die beteiligten Menschen so integrieren lassen, dass hierdurch die Qualität eines Softwareproduktes und die Effizienz der Umsetzung deutlich gesteigert werden können. Zum Abschluss werden diese Elemente, Puzzleteilen ähnlich, zu einem praxistauglichen Gesamtmodell verbunden. Die hier zusammengestellten Vorgehensweisen verstehen sich als holistischer, also ganzheitlicher Ansatz, wobei diese Ganzheitlichkeit sowohl ingenieurmäßige wie auch personenorientierte Aspekte umfasst. Was dies bedeutet, lässt sich mittels eines kleinen Gedankenexperiments anhand von Abb. 1.1 beantworten: In dieser Abbildung sehen Sie unterschiedlich weite Röhren, die in verschiedener Weise kombiniert und übereinander gestapelt wurden. Nach Abschluss des Aufbaus wird nun z. B. Sand durch die jeweiligen Konstrukte hindurchgeleitet. (Ich unterstelle dabei, dass kein Sand zwischen den Rohrversatzstücken verloren geht!) Um eine solche „Sandmaschine“ zu bauen, müssen Sie Geld ausgeben: Dünne Rohre kosten wenig, mittlere Rohre mehr, dicke Rohre viel Geld! Die Gretchenfrage lautet nun: Mit welchem System machen Sie die größten Gewinne? – Nun, simpel wie das Beispiel aufgebaut ist, ergibt sich nachfolgende Lösung (vgl. Abb. 1.2, Experiment, Auswertung & Regeln). Sie lautet: Fall (C) hat das Rennen klar gewonnen, obwohl es NICHT die billigste Variante in der Erstellung war. Punktuelle Verbesserungen von abhängigen Prozessen mögen werbewirksam sein, sie verringern jedoch nicht per se die Stückkosten. – Um möglichst rasch eine

6

1 Prolog

Abb. 1.1. Ein Gedankenexperiment

messbare Steigerung des Durchsatzes bei möglichst geringen Gesamtkosten zu erreichen, müssen alle betroffenen Segmente zeitgleich, dafür aber in kleinen Schritten auf ein gemeinsames Maß gebracht werden. Um auf das Kernthema dieses Buches zu kommen, werde ich nun dieses kleine Röhrenexperiment auf IT-Entwicklungsabteilungen, wie sie vielfach zu finden sind, übertragen (vgl. Abb. 1.2, Übertragung): Die IT-Mitarbeiter kennen die neuesten Softwaretechnologien und brennen meistens darauf, diese einsetzen zu können. Unternehmen investieren stetig mehr in Testen und Qualität, um so zu qualitativ besseren Produkten zu gelangen. Unternehmensführungen investieren z. T. erhebliche Summen in Softwarewerkzeuge und bilden die Mitarbeiter hierin auch entsprechend aus, um hierdurch die Effizienz im Softwarebau zu steigern. Die Menschen mit ihren Grenzen und den hierdurch verursachten Störungen, die massiv auf die Produktion einwirken können, bleiben vielfach unberücksichtigt. Ihnen wird häufig unterstellt, dass sie als Professionals hierfür bereits alle notwendigen Skills besäßen. Vergessen werden dabei jedoch zwei Aspekte: x Der erste Aspekt besteht darin, dass die allerwenigsten IT-Werker diese Faktoren in ihren Ausbildungen vermittelt bekommen haben. x Zum Zweiten haben sehr viele IT-Entwicklungsmannschaften ein eher jugendliches Durchschnittsalter, weshalb sie neueste Technologien gut kennen und auch sehr schnell in deren Ausimplementierung sind, jedoch

1.3 Bilanz ist gefragt

7

fehlt es oftmals an der notwendigen Erfahrung in den anderen Bereichen. Hierbei ist nicht die Erfahrung zu kodieren gemeint: Dafür sind viele Softwaremitarbeiter schon seit ihrer Jugend mit diesem Medium vertraut. Die Erfahrung, von der ich hier spreche, hat mit ganzheitlichen Lösungen zu tun, denen erschwerte Randbedingungen in einer komplexen Gesamtsituation beigegeben sind. Das vorliegende Buch kann und will die aufgeworfenen Einzelthemen nicht in aller Tiefe ergründen. Es schließt sich nicht der FastfoodMentalität an, die oftmals einem „Kochrezept“ gleich, lautet: „How to get all your complexity related IT problems solved within 10 minutes.“ Untersuchungen bei Unternehmen, die solche oder ähnliche Veränderungsprozesse erfolgreich hinter sich gebracht haben und nun die Früchte ihrer Anstrengungen einsammeln, belegen, dass mit 35 Jahren harter Arbeit zu rechnen ist. Primäres Ziel dieses Buches ist es daher, Ihnen zu vermitteln, wie weit hier die wechselseitigen Abhängigkeiten reichen. Ich möchte Sie für diese Thematik sensibilisieren, um Ihnen danach

Abb. 1.2. Auflösung des Gedankenexperiments und Übertragung auf die Softwareproduktion

8

1 Prolog

schrittweise in ausgewählten Bereichen Verbesserungen vorzuschlagen. – Wie schon am Eingangsbeispiel ersichtlich, wird dies mit zusätzlichen Aufwänden verbunden sein, die sich nicht nur im kaufmännischen Sinne definieren lassen, sondern darin bestehen, dass persönliche Investitionen im Sinne von Engagement und Durchsetzungswille eingebracht werden müssen. Nur dann, wenn Sie bereit sind, großzügig alte Paradigmen und Klischeevorstellungen hinter sich zu lassen und neue Wege zu beschreiten, wird eine Umstellung gelingen. Genug der Vorrede. Ich lade Sie nun in die Wirklichkeit der Softwareproduktion ein, wie sie immer noch in vielen IT-Häusern anzutreffen ist.

1.4 Tote Pferde reiten Bei den Dakota-Indianern in Amerika gab es früher eine Stammesweisheit, die besagte: „Wenn Du feststellst, dass Du auf einem toten Pferd reitest, so besteht deine beste Strategie darin abzusteigen.“ Gerade in der IT-Branche gehen wir leider recht häufig anders mit dieser Thematik um, weil Projektdruck und Anforderungen an Management und Mitarbeiter ein Überleben auf Tagesbasis notwendig werden lassen. Daher betreiben wir oftmals mit Akribie Symptombehandlung, vergessen dabei jedoch sehr häufig, die eigentlichen Probleme wahrzunehmen und zu lösen. Nicht selten geschieht es dann, dass die Weisheit der Dakotas in eine oder mehrere eigene Weisheiten umgemünzt wird: x Wir besorgen uns eine stärkere Peitsche, um das tote Pferd anzutreiben. (Etwa indem Service-Level-Verträge mit Zulieferern abgeschlossen und diese vertraglich zur Besserung der Gesamtsituation gezwungen werden.) x Wir wechseln den Reiter, um mit frischem Elan voranzukommen. (Erfahrene Mitarbeiter werden durch weniger erfahrene Kräfte ausgetauscht. Die neuen Kräfte lassen sich – so hofft man wohl – besser durch das Linienmanagement steuern und leisten weniger Widerspruch?!) x Wir sagen: „So haben wir das Pferd immer geritten“ und bleiben bei Altbewährtem. (Man verschließt sich gegen echte Innovation. Es wird damit argumentiert, dass man ja nur „ein wenig“ neue Software haben wolle und keine Weltrevolution.) x Wir gründen einen Arbeitskreis, um das Pferd gründlich zu analysieren und all seine Leistungen der Vergangenheit akribisch zu dokumentieren. (Leitungskreise werden eingesetzt, die wiederum Mitarbeiterstäbe einsetzen, die wiederum akribisch jedes einzelne alte Bauteil bibliographisch erfassen.)

1.4 Tote Pferde reiten

9

x Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet, um zu neuen Erkenntnissen zu gelangen. (Man reist zu Schwester-, Nachbar- oder Referenzfirmen, um zufrieden festzustellen, dass man dort genauso arbeitet wie man selbst. Vergessen wurde bei der Auswahl der Firmen leider nur, dass alle besuchten Firmen aus dem Verzeichnis „Club der Halter toter Pferde“ stammen.) x Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde und führen hierfür sehr strenge Audits ein. (Qualität kommt ins Spiel und bewertet die Güte ineffizienter Vorgehensweisen – was in letzter Konsequenz oftmals nichts anderes heißt: Beim Audit ist herausgekommen, dass die (ineffizienten) Prozesse hervorragend gelebt werden. – Die Frage nach der Werthaltigkeit der Prozesse wird häufig nicht gestellt.) x Wir bilden eine Taskforce, um das tote Pferd wiederzubeleben. (Es wird viel Kraft und Kapital mobilisiert, um halbtote Software zu revitalisieren, ihr etwas Kosmetik zu verpassen oder dem Kunden gegenüber ein neues Produktimage aufzubauen. – Technisch gesehen bleibt die Software jedoch unverändert. Die Tour zum Kosmetiker bringt vielfach nur teilweise erfüllte Versprechungen für die Kunden und garantierte Zusatzaufwände für das eigene Haus mit sich!) x Wir schieben eine Trainingseinheit ein, um effizienter tote Pferde zu reiten. (Mitarbeiter werden in Prozessen oder auch Softwareproduktionen geschult – dumm dabei ist nur, dass das Ganze vielfach in den Köpfen der Mitarbeitet endet. Bis ans Licht der Wirklichkeit dringt es nicht vor, weil z. B. die hierfür notwendige Infrastruktur noch fehlt – und somit alles Theorie und unnützer Aufwand bleibt.) x Wir stellen Vergleiche zwischen unterschiedlich toten Pferden an, um die Wettbewerbschancen zu erhöhen. (Es werden Gremien gebildet, die sich Firmen mit ähnlicher Arbeitsweise anschauen, um herauszufinden, mit Hilfe welchen Mysteriums bestimmte marginale Verbesserungen erreicht werden konnten.) Langer Rede kurzer Sinn: Es werden viele Nebenaspekte betrachtet und diskutiert, die oftmals jedoch eher den Gesetzen blinden Aktionismus folgen, statt Probleme von den Wurzeln her grundsätzlich zu lösen. In diesem Sinne möchte ich Sie an dieser Stelle zu einer kurzen Selbstreflektion einladen. Nachfolgend habe ich Ihnen noch einige Aspekte zu toten Pferden offen gelassen. Die Frage an Sie lautet nun: Wie sehen Ihre Pferdekadaver aus? x Wir ändern die Kriterien, die besagen, ob ein Pferd tot ist. x Wir kaufen Leute von außerhalb ein, um das tote Pferd zu reiten. x Wir schirren mehrere tote Pferde zusammen an, damit diese schneller werden.

10

1 Prolog

x Wir machen zusätzliche Mittel locker, um die Leistung des toten Pferdes zu erhöhen. x Wir geben Studien in Auftrag, um zu sehen, ob es billigere Berater für tote Pferde gibt. x Wir kaufen etwas hinzu, das tote Pferde schneller laufen lässt. x Wir erklären, dass das Pferd „besser, schneller und billiger“ tot ist. x Wir bilden einen Qualitätszirkel, um eine Verwendung für tote Pferde zu finden. x Wir überarbeiten die Leistungsbedingungen für Pferde. x Wir richten eine unabhängige Kostenstelle für tote Pferde ein.

2 Basteln Sie oder produzieren Sie schon?

Wenn Sie zentrale Probleme Ihres Marktes dauerhaft sichtbar besser lösen als andere und Ihre Ziele konsequent verfolgen, dann können Sie Ihren Erfolg nicht verhindern. (Rolf-Bodo Brombacher, Ludwig-Erhard-Preisträger 2000) Folgt man Auswertungen z. B. der Gartner-Group über die Realisierung begonnener Softwareprojekte, so belegen deren Zahlen, dass weit über 60% all dieser Projekte als nicht erfolgreich zu betrachten sind. Erfolglos insofern, als sie entweder abgebrochen wurden, nicht die geforderte Qualität bzw. den Leistungsumfang erbrachten oder deutlich teurer ausfielen, als veranschlagt worden war. Anders herum gesprochen: Statistisch betrachtet verbrennen Sie mehr als die Hälfte Ihres Geldes, das Sie in die IT stecken! – Nun, das ist sehr plakativ und bedarf der Präzisierung. In diesem Abschnitt werde ich mit Ihnen einen Streifzug durch die Wirklichkeit der Softwareherstellung unternehmen und eine Bestandsaufnahme wagen.

2.1 Biographie eines Softwarelebens Lösungen auf der Basis von Vermeidung sind die Probleme von morgen. (Heinrich Fallner) Wie entsteht Software und wann vergeht sie wieder? – Welche Schritte finden bei Ihnen statt und welche werden unterschlagen? Welche frühen „Sünden“ wurden begangen und wo bringen gerade diese Entscheidungen Sie später in Schwierigkeiten? Um aus alten Fahrwassern aussteigen zu können, ist es notwendig die eigene Situation selbstkritisch zu betrachten. Niemand zwingt Sie dazu, Ihre persönlichen Erkenntnisse später öffentlich zu präsentieren! Ich möchte Sie an dieser Stelle einladen, mich auf einem Streifzug durch den gesamten Lebenszyklus einer Software – wenn Sie so wollen vom ersten bis zum letzten Atemzug – zu begleiten. Auf diesem „Lebensweg“ Ihrer Software werde ich an markanten Stellen immer wieder Stopps einlegen, um auf gewisse Dinge etwas genauer zu schauen, gegebenenfalls auch bereits

12


die Konsequenzen getroffener Entscheidungen zu betrachten. Dabei ist es klar, dass jede Software ihre Spezifika hat und somit nicht alles auf Sie exakt so zutreffen wird. Die wiedergegebenen Stationen sind aus meinen Beobachtungen heraus sehr regelmäßig anzutreffen und stets mit vergleichbaren Begleiterscheinungen gepaart. Wichtig ist mir in diesem Zusammenhang weder die Reihenfolge noch die Vollständigkeit der einzelnen Stationen dieses exemplarischen Lebenszyklus. Worauf es mir besonders ankommen wird, sind die vielen kleinen Fehler, die vom ersten Tag an begangen werden. Im Sinne des Fehlerfortpflanzungsgesetzes sind sie es, die sich konstant, aber zunächst unsichtbar kummulieren, bis sie in Summe zur Bedrohung für das Projekt werden, jedoch nicht mehr bereinigt werden können. 2.1.1 Erste Ideen – vom Fischen in trüben Gewässern Die Zukunft gehört denen, welche die Möglichkeiten erkennen, bevor sie offensichtlich werden. (Oscar Wilde) Lassen Sie mich ganz vorne anfangen und der eigentlichen „Zeugung“ eines neuen Softwareproduktes beiwohnen. Es ist der Zeitpunkt, an dem das erste Mal öffentlich darüber gesprochen wurde, bestimmte Abläufe oder Tätigkeiten mit einem Computer erledigen zu lassen bzw. ein vorhandenes Produkt durch einen viel genialeren Nachfolger zu ersetzen. Am Anfang steht dabei das Bedürfnis, bestimmte Probleme kostengünstig, flexibel und zukunftssicher per EDV zu lösen. Schnell fügen sich zu diesem ersten Gedanken weitere Ideen hinzu, was man mit dieser geplanten Software alles erreichen möchte und was alles zu integrieren ist. Je nach fachlichem Wissensstand der geistigen Väter entsteht so sehr schnell ein gedankliches Märchenschloss auf der Basis des eigenen Wissens, dessen Grenzen nur durch die Phantasie der Beteiligten festgelegt sind. Bleiben wir noch einen Augenblick bei den Fremdkunden. Hier stellt sich die Situation oft wie folgt dar: Sie haben als IT-Anbieter mittels intensiver Akquise, mit Messeständen, Besuchen von Consultants, Hochglanzdemos oder Prospekten Ihre Zielkunden und somit potentiellen Auftraggeber beackert, wohlwissend, dass die eigene Verkaufsprämie einzufahren ist. Letztendlich gelang es Ihnen, den Interessenten davon zu überzeugen, dass dessen geäußerte Vorstellungen durch Ihre Organisation realisierbar sind! Jetzt ist er reif! Sie haben den Zugang zum Kunden hergestellt und vermitteln auf unterschiedlichste Weisen, dass gerade Ihre Firma in eben diesem Marktsegment wirklich (fast) alle seine Wünsche realisieren kann. Die angedachte Software wird extrem viel leisten können, auf jeden Fall deutlich mehr als mögliche Wettbewerbsprodukte. Die Firma hinter der Software ist hochflexibel und kann selbstverständlich, falls notwendig, die

2.1 Biographie eines Softwarelebens

13

Besserstellungsmerkmale des Wettbewerbs kurzfristig ebenfalls realisieren. Liefertreue, Qualität und Support sind dabei kein Thema, immerhin präsentiert man sich dem Kunden als Profi. – Kurz: „Wir bauen für Sie die ideale Software in einer idealen Welt, bei der alle Bereiche perfekt zu einem Optimum zusammengefügt sein werden.“ Sollte der Kunde näheres Interesse zeigen, so wird ihm mit Hilfe von Geschäftsessen in gediegenem Ambiente oder Betriebsbesichtigungen mit Blick auf die vielen Monitore und fleißigen Mitarbeiter klar vermittelt: „Dies hier ist eine Softwarefabrik! Mit Routine und Perfektion werden wir Deine Probleme schnell und kostenkünstig lösen.“ Das Ganze – natürlich hypermodern – hat ein wenig den Charakter und auch den Charme eines mittelalterlichen Wochenmarktes. Auf der einen Seite sitzen die Marktfrauen, die marktschreierisch ihre Waren feilbieten. Auf der anderen Seite gehen die Hausfrauen, Diener etc. an den Marktständen auf und ab und suchen nach der für sie besten Ware. Dabei ist die Auswahl ziemlich groß und es sellt sich die Frage, warum die Äpfel gerade hier und nicht am qualitativ gleichwertigen Nachbarstand gekauft werden. Was aber ist die beste Ware? Was sind die Entscheidungsfaktoren dafür? Und was gibt am Ende tatsächlich den Ausschlag für einen speziellen Lieferanten. Sobald für den Kunden nachvollziehbar ist, dass diese Ware alle seine Wünsche erfüllt, wird er sich andere Kriterien suchen, um zu einer Lieferantenentscheidung zu gelangen. Diese Kriterien sind keineswegs immer nur der Preis, der angebotene Leistungsumfang oder die Qualität. Gerade bei Neukunden ist es zu einem erheblichen Anteil das Gefühl, hier gut aufgehoben zu sein, professionell bedient zu werden und vertrauenswürdigen Verkaufsberatern gegenüberzusitzen. 2.1.2 Angebissen! – die Geburtsstunde einer neuen Software Die meisten meiner Ideen gehörten ursprünglich anderen Leuten, die sich nicht die Mühe gemacht haben, sie weiterzuentwickeln. (Thomas A. Edison) Kommt es dann wirklich zur heißen Verkaufsphase, so spielen die Randthemen auch weiterhin keine geringe Rolle. Der umworbene Kunde möchte sich weiterhin gut bei Ihnen aufgehoben fühlen, Sie haben vieles getan, um ihm im Vorfeld genau dieses Gefühl zu vermitteln, und haben ihn regelrecht verwöhnt. Durch wiederholte Präsentation einer sehr positiven Wirklichkeit, durch Kontakte mit kompetenten und netten Menschen und durch verschiedene Formen von verkaufsfördernden Maßnahmen haben Sie eine Bindung zwischen der eigenen Firma und dem potentiellen Kunden aufgebaut.

14


Sie haben soeben Standards gesetzt, an denen Sie dauerhaft gemessen werden und auf die man in schwierigeren Zeiten im Zweifelsfalle missmutig verweisen wird. In diesem Zusammenhang haben Sie, falls Sie leichtfertig waren, dem möglichen Kunden bereits wichtige Versprechungen gegeben. Immer wieder ist dies die Phase, in der man dem Kunden zusagt, nahezu alles für ihn realisieren zu können, dabei nur unwesentlich mehr Aufwände für ihn zu erzeugen und die Ergebnisse in Rekordzeit zu erreichen. Mag sein, dass Sie an dieser Stelle einwerfen: Der Markt ist hart umkämpft, auch der Wettbewerb erzählt manches, was er hinterher so nicht einhalten kann – durch die kommenden Vertrags- und Anforderungsphasen werden diese „Großzügigkeiten“ ohnehin wieder nivelliert werden. – Dies ist sicherlich korrekt – worum es mir an dieser Stelle geht, ist die geweckte Erwartungshaltung für Dinge, von denen man als Lieferant weiß, dass sie sich nicht darstellen lassen. Es sind oftmals die ersten Schritte in eine unnötige Kompliziertheit zukünftiger Softwareprodukte, weil beim Kunden zu bestimmten Aspekten konkrete Erwartungshaltungen geweckt wurden, die nur unter großem Zusatzaufwand zu realisieren sind. Für alle unbemerkt beginnt der Kunde bereits an dieser Stelle, sich ein „Rabattmarkenheftchen“ anzulegen, in dem jedes Mal ein „Rabattmärkchen“2 verklebt wird, wenn Absprachen später nicht eingehalten wurden oder vereinbarte Ziele nicht in gewünschter Form zustande kamen. Bis dieses mentale Heftchen voll ist, kann eine ganze Weile dauern, sollten Dinge aber später nicht wunschgemäß verlaufen, so fallen dem Kunden auf einmal all die frühen Sünden wieder ein, und zwar meistens dann, wenn Sie es am wenigsten gebrauchen können! 2.1.3 Zeit für Verträge Nun ist es die Zeit der Verträge und Vereinbarungen und die ungeschönte Wirklichkeit hält Einzug. Es beginnt das Feilschen zwischen Anbieter und Kunden, in dem sich entscheidet, welches Leistungspaket zu welchem Preis an den Kunden geht. Gerade hier finden immer wieder Fehler im großen Stil statt. Die Rede ist hierbei nicht von den Verträgen an sich, sondern den Aspekten, die mit der späteren Software zu tun haben werden! Jede Software – insbesondere die speziell für Kunden entwickelte Individualsoftware – hat in gewisser Weise den Charakter einer Traum-Maschine. Dabei sieht das Ganze aus Sicht des Kunden etwa so aus: Er gibt eine Applikation in Auftrag, gibt vor, was er meint zu brauchen, und bekommt 2

Das Phänomen des „Rabattmarkenhefts“ stammt aus dem Bereich des Konfliktmanagements. Kommt es in Situationen dazu, dass „das Fass überläuft“, wie der Volksmund sagt, so entspricht all das, was das Fass angefüllt hat, den beschriebenen „Rabattmärkchen“.

2.1 Biographie eines Softwarelebens

15

(hoffentlich!) Entsprechendes geliefert. Indem er diese neue Anwendung in Betrieb nimmt, fällt ihm all das ein, was man hätte noch integrieren, effizienter gestalten oder besser umsetzen können. Je nach Charakter, Zeitdruck und Liquidität werden daraufhin weitere Zusatzkomponenten beauftragt, eine Dauerbaustelle beim Hersteller eingerichtet, das Ganze als kundenspezifische Änderungen weiter betrieben oder aus Bordmitteln nach dauerhaften Provisorien gesucht. Wenn das so absehbar ist, wie der nächste Sonnenuntergang, so frage ich Sie, was können Sie als Hersteller in dieser Phase unternehmen, um rasch und für Sie kostengünstig für die zu erwartenden Zusatzwünsche gerüstet zu sein? Möglich, dass Sie mir jetzt antworten würden: x Wir werden selbstverständlich nachweisliche Fehlprogrammierungen beseitigen. x Auch sind wir grundsätzlich bereit, das Produkt weiterzuentwickeln. x Gerne nehmen wir auch weitere Kundenwünsche auf und schaffen hierfür individuelle Lösungen. Das klingt gut, aber hierauf wollte ich nicht hinaus! – Worauf es mir an dieser Stelle ankommt, ist der „wir können alles für Dich machen, denn Du, Kunde, sollst ja König sein“ – Aspekt. Verkaufstechnisch mag so eine Aussage legitim sein. Aus Sicht der Softwareproduktion hingegen sind solche Sätze katastrophal, versprechen Sie doch ein magisches Stück Software, beim dem alle zukünftigen Änderungswünsche dem Kunden bereits im Vorfeld von den Augen abgelesen wurden und hierfür eine technische Plattform bereitgestellt sein wird. Sicherlich kennen Sie solche Software, bei der man schnell dem Kunden noch ein kleines Zugeständnis gemacht hat im Sinne von: „Ja, das bauen wir Ihnen selbstverständlich zusätzlich ein – das ist für uns kein großer Aufwand!“. – Die Wirklichkeit überholt Sie in sehr vielen Fällen bereits nach wenigen Monaten, wenn dieses kleine „Zugeständnis“ zur Geldverbrennungsanlage wird und man den erhofften Gewinn in eben diesem Zusatz-Softwaremodell in deutlichem Maß schmälern muss! 2.1.4 Erste Konzepte Dem Kunden Zugeständnisse zu machen ist selbstverständlich, allerdings werden diese zum Fallstrick, wenn sie, soweit es um technische Zugeständnisse geht, ohne Abstimmung mit den IT-Planern gemacht werden. Wenn Sie in der Phase der Traumhäuser Ihres Kunden nicht bereits interne strategische Überlegungen angestellt haben, ob, wie und wo technische Ergänzungen aus Ihrer Sicht gewollt sind, so grenzt dies an Fatalismus. Die Chance, dass Ihre Entwicklungsabteilung aus Unkenntnis dieser Fakten später

16


mit deutlich höheren Zusatzaufwänden die weiteren Kundenwünsche realisieren wird und dabei erheblich teurer produzieren muss, sind dabei sehr groß! Wie häufig kommt es vor, dass der Vertrieb viel zu wenig über die Möglichkeiten und Unmöglichkeiten dessen weiß, was die eigene Entwicklungsabteilung leisten kann und welche Zusatzaufwände an bestimmten Zusagen hängen. Man verkauft auf der Basis dessen, was man über das eigene Produkt zu wissen glaubt. Dabei kommt es immer noch vor, dass der Vertrieb zusammen mit dem Kunden in die fachliche Projektplanung einsteigt. Im Rahmen der Vertragsgespräche finden auf Servietten, Notizblöcken oder Notebooks technische Skizzen Platz. Gemeinsam erarbeitet man schon einmal schnell technische Strukturen, plant all die bereits bekannten Wünsche in ein solches Konzept ein und lässt den Kunden mit der Überzeugung zurück, dass hier bereits die fertige Lösung steht. Der neugierige Betrachter solcher Szenen ist zutiefst beeindruckt von dem, was hier gerade stattfand. Zurück von einer erfolgreichen Verkaufsreise landen dann genau diese technischen Abmachungen auf den Schreibtischen der fachlich Verantwortlichen und bewirken, dass diese jetzt einen Parcours von Widersprüchlichkeiten auflösen müssen, um mit viel Phantasie, jedoch oftmals nicht mehr gradlinig ein Konzept zu erarbeiten. Die Rede ist an dieser Stelle von schlechten Absprachen zwischen Vertrieb und Entwicklung. Wissen die jeweiligen Mitarbeiter, wie weit sie in ihrem Aufgabenfeld gehen können? Tun sie es auch tatsächlich – oder gibt es geheime Kompetenzrangeleien, wer in welcher Form was mit dem Kunden verabredet? Etwa gleiche Qualität haben Inhouse-Projekte, bei denen das Management öffentlich und für alle überraschend neue und sehr viel weiter gesteckte Ziele formuliert als ursprünglich vereinbart. Waren solche neuen Ziele in dieser Form und Größe nicht Bestandteil bisheriger Projektplanungen, so sind die meisten Vorarbeiten hinfällig. Insbesonders einseitiges Kürzen ohnehin schon knapp kalkulierter Zeitpläne bergen hier vielfach katastrophale Folgekosten in sich, die allerdings in vollem Umfang erst im Laufe der kommenden Jahre sichtbar werden. Ebenso gehören in diesen Kontext begriffliche Gleichstellungen. In Vorstandsetagen werden Projekte in strategisch globaler Weise betrachtet und bewertet. Hier werden Begriffe zu Schlagworten umgemünzt und dann das Ganze an die Basis weiterdelegiert. – Hier wiederum benutzt man andere Begriffe, die sehr viel präziser sein müssen, um das zu beschreiben, was fachlich notwendig ist. – Leider neigt mancher Manager dazu, der Einfachkeit halber zwei unterschiedliche Dinge für identisch zu erklären, ohne dabei ausreichend zu realisieren, dass beide Begriffe zwar ähnlich, jedoch nicht deckungsgleich sind. Im fachlichen Sinne kann hierdurch eine enorme inhaltliche Verschiebung stattfinden, die entweder neue Unklarheiten hervorbringt oder aber den gesamten Projektinhalt verlagert.

2.2 Wer kauft Katzen im Sack?

17

2.2 Wer kauft Katzen im Sack? Irren ist menschlich. Aber wenn man richtig Mist bauen will, braucht man einen Computer. (Dan Rather) Lassen Sie mich wiederum einen Schritt weitergehen! Die Aufgabe ist platziert, der Kunde hat Liefertermine avisiert bekommen und mit großem Enthusiasmus geht man daran, die Software zu realisieren. – Was wird da eigentlich realisiert? Wird diese Frage an das Management gerichtet, so lautet in vielen Fällen die Antwort: „Nun ja, die Software, wie sie mit dem Kunden definiert wurde.“ Diese Aussage ist sachlich richtig, erlaubt aber mindestens eine Randbemerkung: Haben Sie sich einmal gefragt, wie diese Definition im eigenen Hause oftmals zustande kommt? – Haben Sie selbst in solchen Veranstaltungen – wenn sie denn überhaupt stattfinden – als aktiv Beteiligter oder stiller Beobachter beigewohnt? Heißt Anforderungserfassung in Ihrem Haus, dass sich die entsprechenden Mitarbeiter zum Kunden begeben und dieser ihnen feierlich einen Wunschzettel überreicht? Weiß Ihr Kunde selbst überhaupt genau genug, was er will und braucht? Sind Sie sicher, dass Sie hinreichend gut verstanden haben, was die grundsätzliche Problemsphäre des Kunden ist, für die er eine Software sucht? – Fragen über Fragen lassen sich speziell an diesem fast alles entscheidenden Punkt aufwerfen! Hiermit steht darüber hinaus Folgendes in Verbindung: Da Software in ihrer Herstellung oftmals so unberechenbar ist, verlangen immer mehr Kunden feste Preise und ebenso feste Lieferdaten. Das ist eine feine Sache und durchaus nachvollziehbar – aber: Wie kommen Sie zu diesen Daten? – Die eine Firma sagt: „Die Preisgestaltung macht bei uns der Chef!“ und will damit ausdrücken: Politik und Bauchgefühl bestimmen den Preis. Andere wiederum berufen sich auf ihre tradierten Verfahren und Rechenmodelle. Was bleibt, ist die Tatsache, dass diese Art von Abschätzungen und die damit verbundenen tatsächlichen Aufwände vielfach wenig Bezug zueinander aufweisen. 2.2.1 Erarbeiten Sie ganzheitliche Lösungen? Zwei weitere Aspekte sind im Begriff, sich unmerklich an Ihnen vorbeizumogeln, um nach erfolgreichem Abschluss Ihrer gerade in Planung befindlichen Applikation an Ihren zukünftigen Gewinnen zu nagen. Die Rede ist zum einen von dem, was man unter dem Begriff Domainwissen versteht, das andere bezieht sich auf das Thema Produktlinien. Hier zunächst einmal eine Erläuterung des ersten Begriffes: Um auch auf längere Sicht den Kunden mit der kommenden Software zufrieden zu stellen und im Gegenzug dazu die eigenen Gewinne zu maximieren, muss der

18


fachliche Bereich Ihres Kunden gründlich sondiert worden sein. Egal wie viel oder wenig Sie im Augenblick softwaretechnisch realisieren werden. Eines ist gewiss: Wenn der Kunde mit Ihren Leistungen zufrieden ist (was ja eines der angestrebten Ziele sein sollte) und liquide bleibt (was wir ihm wünschen), dann wird er Sie höchstwahrscheinlich mit weiteren Ergänzungen zu der jetzt beauftragten Applikation beehren. Sind Sie darauf vorbereitet? – Wie viel wissen Sie über die Wissensdomain ihres Kunden tatsächlich? – Sind Sie in der Lage – wenigstens grob –, das Thema abzugrenzen? Können Sie möglicherweise den Bereich, den der Kunde Ihnen gerade präsentiert hat, so gut abschätzen und abgrenzen, dass Sie auf mögliche spätere Zusatzwünsche eingerichtet sind bzw. sie bereits jetzt mit dem Kunden ausdiskutieren können? Der zweite Begriff hat zunächst nichts mit Ihrem Kunden zu tun, sondern mit der eigenen Organisation. Sie bauen Software! Das ist sehr erfreulich! – Sind Sie dabei eine Art „Tante Emma“-Laden, der jeden nur denkbaren Auftrag an Land zieht, oder haben Sie eine interne Strategie, aus der hervorgeht, was Sie tun und wie weit Sie dabei gehen wollen? Haben Sie einen Baukasten, aus dem heraus Sie Ihr Zielklientel mit für Sie reduzierten Aufwänden bedienen können, oder müssen Sie mit jeder Neuentwicklung wieder ganz von vorne anfangen? – Sie verstehen nicht, was ich meine? – Nun, dann lassen Sie mich das Ganze an einem Beispiel konkretisieren. 2.2.2 Software-Legosteine Darf ich davon ausgehen, dass Sie Legosteine kennen, vermutlich früher selbst benutzt haben? Was ist das Besondere an diesen bunten Plastikklötzchen, die sich jetzt schon seit über einem halben Jahrhundert am Markt halten? – Ich denke, die wohl markanteste Eigenschaft besteht darin, dass diese Steinchen, selbst wenn diese inzwischen dreißig oder vierzig Jahre alt sind, immer noch mit den Teilen zusammen verbaut werden können, die später neu erfunden wurden oder gerade erst vom Band gelaufen sind. – Die zweite signifikante Eigenschaft sehe ich darin, dass wohl kaum ein Kind auf die Idee käme, diese Normbausteine zu zersägen, nur um passende Komponente zu erhalten. Dabei haben sich die Erfinder dieser Technik ein ganz simples Stecksystem erdacht, für das sie die bekannte Vielfalt an unterschiedlichen Klötzchentypen entwickelt haben. Sie als Endanwender denken nicht über die Art des Plastiks, die Größe der Verbindungstypen oder die Farbstabilität nach, sondern verbauen diese Teile zu lustigen Häuschen, Flugzeugen, Skulpturen oder sonstigen Dingen. Darüber hinaus gibt es eine dritte interessante Tatsache: Kennen Sie Legosteine, die als Verbinder zu anderen Baukastensystemen dienen? Ich nicht! – Hier also meine Fragen: Sie bauen Software, weil Sie damit Geld verdienen wollen! Haben Sie eine Art softwaretechnisches Stecksystem,


19

mit dem Sie Ihre Kunden bedienen können? (Ich rede nicht von Programmiersprachen, sondern einer deutlich höheren Abstraktionsstufe!) Sind Sie in der Lage – weil Sie eine Strategie haben –, bestimmte Kundenwünsche abzulehnen, dafür aber solche, die in den Rahmen Ihres Baukastens passen, schnell, preisgünstig und unkompliziert zu realisieren? Derzeit ist wohl einer der prominentesten Vertreter dieser Konstruktionsprinzipien der Flugzeugbauer Airbus. Durch gründliche Marktstudien, die wiederholte Nutzung von Normelementen sowie ein sehr hohes Maß an Bedienungsähnlichkeit hat diese Firma in den vergangenen Jahren ganz erheblich ihre Marktführerschaft ausgebaut, da sie zum einen effizient produzieren kann und andererseits die Kunden mit erheblich geringeren Umschulungsaufwänden auf neue Flugzeugtypen auskommen. 2.2.3 Arbeiten Sie nebeneinander oder als Team? Ein Verband ist eine Vereinigung von Personen, die entweder gemeinsam Krach machen oder untereinander Krach haben. (Gerhard Uhlenbruch, dt. Aphoristiker) Statt weiter auf das entstehende Produkt zu blicken, möchte ich nun ein paar Betrachtungen über die Entwicklungsmannschaft anstellen: Eine Truppe von Leuten also, die Sie im Laufe der Zeit als Fachspezialisten aus der IT und anderen Bereichen angeworben haben und die diese neue Aufgabe in vorgegebener Zeit stemmen sollen. Wie gut kennen Sie Ihre Mannschaft? Waren es ausschließlich fachliche Gründe, nach denen Sie die Mitarbeiter einst ausgewählt haben, oder hatten Sie damals auch die sozialen und andere weiche Skills im Auge? Statistiken belegen, dass eine überdurchschnittlich hohe Quote an IT-Fachleuten autistische Züge trägt und demzufolge nicht sonderlich leicht in real existierende Teams zu integrieren ist. Stellen Sie sich Ihre IT-Truppe im Geiste vor Augen! Wie viele Ihrer hochbegabten Mitarbeiter schaffen es kaum, Sie auf dem Flur zu grüßen, oder würden es vorziehen, einen Umweg zu gehen, nur um einem speziellen Menschen auszuweichen? – Wer Ihrer Mitarbeiter ist in der Lage, eigenaktiv die Sicht anderer Spezialisten einzuholen, und wer würde wohl alleine, ohne den Austausch mit anderen, so lange unbemerkt „basteln“, bis irgendein Ergebnis vorliegt. (Was Sie viel Zeit kosten kann und vielfach nicht die notwendige Qualität liefert.) Softwareprojekte unterliegen einer eigenen Dynamik, wonach gerade zu Beginn sehr viel Enthusiasmus sichtbar wird, während die letzte Meile solcher Projekte eher einer Galeerensituation gleicht: Viele Überstunden, durchgearbeitete Nächte und Wochenenden im Büro sind in diesen Phasen fast regelmäßig anzutreffen. Gerade aber auf dieser letzten Wegstrecke rächt es sich, wenn die beteiligten Mitarbeiter nicht rechtzeitig und ausreichend

20


kommunizieren gelernt oder erfahren haben, was es heißt, gemeinsam um tragbare Lösungen zu ringen. Gerade hier ist der Projektabschnitt, in dem aus vielen Einzelteilen ein großes Ganzes entstehen muss. Dieses riesige Puzzle gilt es nun passgenau und möglichst verlustfrei zusammenzusetzen, was nur dann gut gelingt, wenn von Beginn des Projektes an dieser Phase ausreichend Aufmerksamkeit geschenkt wurde. Meine Fragen an Sie lauten daher: Wie viel wissen Sie über die Teamfähigkeit und Streitkultur ihrer Truppe? – Können Ihre Mitarbeiter Standpunkte ausfechten oder werden sie ihre Sichten aussitzen bzw. totschweigen, um anschließend genau das zu machen, was sie ohnehin schon für sich entschieden hatten? Sind Sie, falls Sie der Projektmanager dieser Entwicklungscrew sind, in der Lage, Ihre Mitarbeiter zu einem echten Team zusammenzuschweißen, oder zählen Sie nur die fachlich prozessualen Dinge zu Ihrem Aufgabenbereich? Auch hier mag Ihnen die Frage auf den Lippen liegen: Warum ist dies wichtig? – Ich wollte doch eigentlich nur Software bauen und nicht zum Psychotherapeuten meiner Mitarbeiter werden! – Keine Angst, mein Ziel besteht nicht darin, Sie zum Therapeuten Ihrer Entwickler zu mutieren. Auch möchte ich hier keine gruppendynamischen Wohlfühlgruppen für softige Informatiker propagieren! Mir geht es darum, Ihnen einige Ecken in Ihrer Projektlandschaft aufzuzeigen, die Sie möglicherweise aus einem Performanceblickwinkel wahrnehmen sollten. Dies ist umso wichtiger, als die hohe Dynamik innerhalb der IT-Branche, verbunden mit der hohen Komplexität dessen, was Sie produzieren, es notwendig macht, dass Sie auf ein Team und nicht einen zusammengewürfelten Haufen an Individualisten zurückgreifen können. Dabei entstehen Teams nicht dadurch, dass man eine Gruppe von Leuten in einer Organisationseinheit zusammenfasst, sie anlächelt und ihnen sagt: „Ab heute seid ihr ein Team!“ Vielmehr muss viel Kraft investiert werden, damit ein solches Team sich finden kann, zusammenwächst und jeder seine individuelle Position findet. Eines ist hierbei klar, und dies belegen Studien eindeutig: Nur wenn es Ihnen gelingt, eine solche Gruppe mit überdurchschnittlich vielen einzelgängerisch veranlagten Mitarbeitern zu einem echten Team zusammenwachsen zu lassen, dann haben Sie eine realistische Chance, gute oder sogar hervorragende Software in einem realistischen Zeitfenster realisiert zu bekommen. 2.2.4 Zeit ist Geld – oder von der Fähigkeit, Geld zu verbrennen Du kannst den Teufel aus deinem Garten verjagen, doch im Garten deines Kindes findest du ihn wieder. (Alice Miller) Auch Kunden haben ihren eigenen Zeitplan und so ist es oftmals Realität, dass die eigene Entwicklungsmannschaft bereitsteht, aber die finale


21

Projektfreigabe des Kunden fehlt. Alle sind bereit, vielleicht auch angespannt, ob man den neuen Auftrag im ohnehin schon sehr engen Zeitfenster schaffen wird. Es wurde bereits lange gewartet – und dann auf einmal muss alles unwahrscheinlich schnell gehen! Hat man den Auftrag erst in der Tasche, so wartet wiederum der Kunde vielfach ungeduldig auf das zugesagte Resultat, zumindest aber auf Zwischenergebnisse, ja er versucht, die geforderte Software sogar in weniger als der vereinbarten Zeit zu erhalten, um so eigene Verzögerungen intern wieder ausgleichen zu können. Folgerichtig sind die Lieferzeiten sehr kurz, um nicht zu sagen vielfach zu kurz. Die Mitarbeiter werden aus anderen Aufgaben abgezogen und der Chef steht ab Tag zwei in seiner Entwicklungsabteilung und möchte sehen, dass Code entsteht! – Denn, so scheint oftmals dessen Logik zu sein: Ich habe einen ziemlich großen Haufen an Code am Markt verkauft und muss diesen zeitnah liefern. Wann kann ich endlich sehen, wie dieser Codehaufen vor meinen Augen wächst. Was dabei immer wieder geschieht, entspricht einer Vorstellung, wonach sofort damit begonnen werden muss, die Objekte, Klassen, Module oder Interfaces zu implementieren. Machen Sie das beim Hausbau eigentlich auch so? Sie haben sich zum Bauen entschieden, eine Baugenehmigung brauchen Sie nicht, irgendwo haben Sie ein paar Handzeichnungen darüber, was Sie bauen wollen und los geht’s! – Sie bestellen, sagen wir, 10 LKW-Ladungen mit Backsteinen, heuern 7 Maurer an und sagen ihnen, dass jeder schon mal in einer Ecke des Grundstücks mit dem Hochziehen von Mauern beginnen kann, damit das Haus möglichst rasch fertig wird. Dabei gehen Sie davon aus, dass diese zentralen Mauerwerke sicherlich am Ende gebraucht werden und man auf diese Art und Weise schon mal ein gutes Stück Wegs zurücklegen kann. – Wie viel Prozent dieser Arbeiten werden wohl hinterher nicht passend sein? Vermutlich hätten Sie Ihr Haus deutlich eher und ökonomischer fertig gestellt bekommen, wenn Sie ein paar Tage später mit den praktischen Arbeiten begonnen hätten, dafür aber erst einmal das Gebäude, die einzelnen Gewerke und den zeitlichen Ablauf der Maßnahmen sauber geplant hätten. Zurück von den „Maurern“ zu den Programmierern: Irgendwie haben diese sich selbst organisiert und jeder baut fröhlich an einer Lieblingsecke. – Wussten Sie eigentlich, dass EDV-Spezialisten auch nur Menschen sind, d. h. vielfach genauso lustgetrieben arbeiten wie andere Menschen auch? Man fängt (oft) genau bei dem an, worin man gut ist, wo man Erfahrungen gesammelt hat und wo somit sehr schnell beeindruckende Dinge sichtbar werden. Der Bau schießt zu Anfang nur so in die Höhe. … Leider kommt es dann aber regelmäßig vor, dass aufgrund dieser Vorgehensweise wirklich entscheidende Themen zurückgestellt werden und man spät, viel zu spät feststellen muss, dass genau diese Themen auf der Zielgeraden des Projektes zum Verzug der ganzen Sache führen.

22


Möglicherweise würden Sie mich jetzt mit schmalen Lippen anlächeln und mir erwidern: „Wissen Sie, das passiert uns nicht, wir haben eine Designphase, erstellen vorher die IT-Architektur und haben alles in einen Prozess eingebettet!“ – Wunderbar, dann sind Sie auf jeden Fall ein gutes Stück weiter als mancher andere. Obschon Design und IT-Architektur im heute verstandenen Sinne sehr wichtig sind und Sie hierdurch in die Lage versetzt werden, geplant vorzugehen, haben Sie dennoch nicht unbedingt alle oben angerissene Probleme aus dem Wege geräumt. Wie gut haben Sie eigentlich Ihre Planungsarbeiten gemacht? Können später tatsächlich verschiedene Teams an unterschiedlichen Ecken Ihres Softwareprojekts arbeiten, ohne sich zu behindern, mehr noch: so arbeiten, dass die gebauten Einzelkomponenten hinterher genau zusammenpassen? In welcher Weise wurde dafür gesorgt, dass alle verwendeten Softwarekomponenten möglichst lose gekoppelt und damit möglichst reibungsarm zueinander in Bezug gesetzt werden können. Wie wurde dieses Zusammenspiel aufeinander abgestimmt? – Wer koordiniert die verschiedenen Teams und vor allem: Wer legt am Anfang fest, wie die Einzelthemen zu schneiden sind und wo die Grenzlinien verlaufen werden?

2.3 Wenn fehlende Strategien teuer werden Wer dem Geld hinterher rennt, wird es nicht bekommen. Wer sich weiterentwickelt, kriegt es automatisch. (Felix Magath) „Wir sind ein Software produzierendes Unternehmen“ ist ein Satz, der immer wieder impliziert, man habe diesen ganzen Themenkomplex fest im Griff. Mit diesem Slogan haben Sie möglicherweise Ihren neuen Auftrag an Land gezogen, der Kunde empfand, dass er bei Ihnen ein „Rundumsorglos-Paket“ geordert hat – und alles wird gut! Wie sieht es derweil in vielen Entwicklungsabteilungen aus? Wir sind uns darüber einig, dass Sie mit dem neuen Auftrag Geld verdienen wollen, möglichst rasch, möglichst nachhaltig und möglichst risikoarm. Es ist kaum zu erwarten, dass Sie Softwareentwicklung aus reinem Altruismus betreiben. Wenn Sie kaufmännisch sauber arbeiten oder keine weiteren strategischen Ziele mit diesem Projekt verfolgen, so ist klar, dass dieser neue Auftrag die entstehenden Kosten decken und danach – wenn irgend möglich – Folgeaufträge nach sich ziehen muss. Dieses eigentlich so leicht nachvollziehbare Ziel birgt allerdings ein paar sehr unangenehme Stolpersteine in sich! An dieser Stelle unterstelle ich, dass Sie kein Produkt zu veräußern haben, das in einer Stückzahl wie z. B. Microsoft Windows oder die Office-Produkte aus gleichem Hause den Markt versorgen wird. Wie viel der vereinnahmten

2.3 Wenn fehlende Strategien teuer werden

23

Gelder werden Sie tatsächlich als Gewinn verbuchen können und wie hoch werden Ihre realen Deckungsbeiträge dabei sein? Die zentrale Frage lautet somit: Wie viel Zeit investieren Sie für die Ertragsplanung der Software, die gerade entsteht? Hierbei beziehe ich mich nicht auf politische Forecasts oder hochgerechnete Business Opportunities, die so oft, während das Kalenderjahr fortschreitet, schrittchenweise nach unten korrigiert werden. Auch stütze ich mich hierbei nicht auf die GewinnZielvorgaben der Firmeneigner. Worauf ich mich allerdings beziehe ist die Folgekostenabschätzung einer Software und die damit eng verbundene Optimierung der Folgekosten durch weitsichtige technische Planung. Was haben Sie bzw. Ihre Entwicklungsmannschaft getan, um die später zu erwartenden Gewinne nicht unnötig zu schmälern? Ist Ihnen bewusst, dass Sie bereits heute über die Erträge der kommenden Jahre anteilig mitentscheiden – zum Guten wie zum Schlechten? – Lassen Sie mich das ein wenig erklären: Im Rahmen dieser Bestandsaufnahme wurde bereits einigen Stationen im typischen Lebenszyklus eines Softwareprodukts ein kurzer Besuch abgestattet. Dabei war stets das jetzt zu bauende Produkt im Fokus. Weniger wurde auf das geschaut, was solch ein Produkt im Laufe seines Lebenszyklus an Konsequenzen oder Folgekosten vorraussichtlich nach sich ziehen wird. Daher ergeben sich an dieser Stelle ein paar ganze einfache Fragen: Wie viel wird in Ihrer Entwicklungsmannschaft jetzt, zu einem sehr frühen Zeitpunkt der Softwareentwicklung, darüber diskutiert, wie sich die letzte Meile Ihrer Applikationsentwicklung darstellen soll. Die zweite Frage ist, was die Folgekosten anbelangt, noch viel wichtiger: Was wurde planungstechnisch unternommen, um die Folgekosten für auftretende Fehler oder auch Änderungswünsche in, sagen wir, fünf Jahren möglichst gering zu halten? 2.3.1 Die Zukunft im Visier Damit verbunden stellt sich die Frage, was Ihre Mannschaft tut, um im Rahmen des zu entwickelnden Produktes der extrem hohen Dynamik innerhalb der IT gerecht zu werden. Wie wird verhindert, dass die genialen Lösungen von heute, die Sie in vielleicht zwei oder drei Jahren fertig gestellt haben werden, dann immer noch technisch aktuell sind? Welche Maßnahmen haben die Planer ergriffen, um der Software so lange als möglich die entsprechende Aktualität zu verleihen, um dadurch – zumindest technisch gesehen – den Lebenszyklus zu verlängern? – Mag sein, dass dies für Sie im Augenblick sehr abstrakt klingt. Aus diesem Grunde gebe ich Ihnen ein konkretes Beispiel: Während ich diese Zeilen schreibe, ist die IDE-Plattform Eclipse in der Version 3.1.2 der aktuelle Stand. Wenn Sie Ihre neue Software auf dieser Plattform konzipiert haben und sich nun vor Augen halten, wie sich das Ergebnis bei der Endauslieferung

24


in z. B. zwei Jahren darstellen wird, so ergibt sich hieraus eine ganz einfache Logik. Haben Sie keine entsprechenden planerischen und technischen Vorkehrungen getroffen, um Eclipse schrittweise in Ihrer Applikation aktuell zu halten, so werden Sie eine bis dahin überholte Software ausliefern, die Sie entweder sofort einem Refactoring unterziehen oder aber auf einem dann bereits technisch alten Stand einfrieren müssen. – Daraus ergibt sich die Frage, was für Vorkehrungen aktiv eingeplant wurden, um im Sinne der Nachhaltigkeit dafür zu sorgen, dass der oder die Kunden bei Auslieferung tatsächlich eine brandaktuelle Software erhalten und Sie nicht umgehend mit Renovierungsarbeiten beginnen. Um eine lange Geschichte kurz zu machen: Die Rede ist von unterschiedlichen Vorgehensweisen, wie sie Abb. 2.1 wiedergibt: Die erste lautet – plakativ gesprochen: „Denke ein wenig, habe relativ niedrige Erstellungskosten und wundere Dich ansonsten, dass Du später vieles von Deinem erhofften Gewinn in Folgekosten investieren musst.“ Die zweite Variante lautet: „Bevor Du zu kodieren anfängst, leiste Dir den Luxus, ein wenig länger nachzudenken, sei Dir bewusst, dass die Projektkosten höher als im ersten Fall ausfallen werden, aber sei guten Mutes, da mit geringeren Folgekosten zu rechnen ist, wird der Ausgleich nicht ausbleiben!“

Abb. 2.1. Softwareentwicklung und deren Folgekosten


25

Hintergrund dieser Betrachtung ist die sogenannte „10er-Regel“ bei Fehlerkosten. Diese Regel besagt, dass die Kosten für die Behebung auftretender Fehler in jeder Phase der Erstellung und Nutzung um den Faktor 10 steigen! Konkret: Wenn Fehler nicht bei Planung und Entwicklung vermieden werden, sondern erst in der Designphase, so ist der Korrekturaufwand 10fach höher als in der Planungsphase. Werden Fehler erst bei den Abnahmetests entdeckt, so sind die Aufwände bereits 100mal höher als zu Projektbeginn, und treten die Fehler am laufenden System beim Kunden auf, so verzehnfacht sich das Ganze noch einmal. Zugegeben: Diese Aussagen basieren auf Erfahrungswerten und weichen auch schon einmal zugunsten des Produzenten ab! Was allerdings bleibt, ist die Gewissheit, dass spät entdeckte Fehler teure Fehler sind! 2.3.2 Ein Gedankenexperiment Aus diesem Grunde erlaube ich mir eine kleine gedankliche Veranschaulichung. Gesetzt den Fall diese Regel ist korrekt und nehmen wir weiter an, Sie benötigen einen Tag, um einen beim Kunden aufgetretenen Fehler Ihrer Software zu korrigieren und anschließend die korrigierte Software wieder beim Kunden neu einzuspielen. Ein Arbeitstag hat 8 h u 60 min u 60 sec = 28 800 Sekunden. Wenn dieses Gesetz korrekt ist, so hätten Sie 28,8 Sekunden, also knapp ½ Minute mehr Zeit zum Planen benötigt, um solch einen Fehler zu vermeiden! – Nun, das ist natürlich eine rein rechnerische Aussage – und das Leben spielt oftmals anders. Die Wahrheit, die sich hierin jedoch verbirgt, ist ganz simpel: Je mehr Augenmerk Sie und ich auf die frühen Phasen eines Projektes legen, umso mehr lassen sich die Dinge entzerren und systematische Fehler vermeiden. Es gelingt dann mit einem verhältnismäßig geringen Einsatz zusätzlicher Mittel, auch solche Bereiche sehr früh zu durchdenken, an die meistens erst spät, zu spät, gedacht wird und die dann eine ganze Menge Probleme und Zusatzaufwände nach sich ziehen. Gerade wenn Sie nicht nur Produktneuentwicklung betreiben, sondern auch ältere Produkte „am Leben“ erhalten müssen, können dort sehr schnell hunderte von Fehlerreports auflaufen, deren Behebung ganz erhebliche Ressourcen binden. Hätte man z. B. bei der Erstellung dieser jetzt gealterten Software über Verfahren und Vorgehensweisen nachgedacht, wie man sich die Fehlersuche und Behebung derselben im fortgeschrittenen Softwarealter erleichtern kann, dann hätte dies mit Sicherheit zum damaligen Zeitpunkt Mehraufwände zur Folge gehabt. Zum jetzigen Zeitpunkt würde es Ihnen jedoch im großen Stil Aufwände ersparen – doch hierfür ist es bereits deutlich zu spät!

26


2.3.3 Das Imperium schlägt zurück Ein Erfolgsrezept kann ich Dir nicht geben, aber ein absolut sicheres Misserfolgsrezept. Versuche allen Anwesenden zu gefallen. (Samy Molcho) Planung und Realität liegen bei vielen Softwareprojekten deutlich messbar auseinander. – Zumindest sind mir recht wenige Projekte begegnet, die so genau vorausgesagt werden konnten, wie es den Projektsponsoren vermittelt wurde. Das ist durchaus nachvollziehbar, wenn man sich klarmacht, was hier eigentlich geschieht: Indem Sie den Auftrag, eine neue Software zu bauen, übernommen haben, müssen Sie in sehr vielen Fällen über weite Strecken hinweg nahezu hellseherische Fähigkeiten besitzen. Dies gilt mit Sicherheit für den avisierten Preis, mehr aber noch für die erwarteten zeitlichen Aufwände: Mitarbeiter liefern Ihnen hierzu Zahlenmaterial an und meinen, Sie müssten in der Lage sein, bis dann und dann das und das zu leisten. Möglich, dass die Mitarbeiter recht mit ihrer Einschätzung haben, möglich aber auch, dass sie einer erheblichen Fehleinschätzung unterliegen. Spannend wird es immer dann, wenn die Mitarbeiter mit Aufwandsabschätzungen kommen und der Chef z. B. sagt: „Ist mir zu hoch, ich möchte die gleiche Leistung in 80% der Zeit haben!“ – Hier genau wird im Kontext dieses Buches die Sache interessant, fragt man sich doch als interessierter Beobachter: Wer treibt hier eigentlich mit wem welches „Spiel“? Sind es die Mitarbeiter, die – da sie ohnehin wissen, dass hinterher deutlich gekürzt werden wird – ausreichend viel „Luft“ in die Abschätzungen einbauen? Ist es der Chef, der seine „Pappenheimer“ zu kennen glaubt und daher die stillen Reserven wieder aus dem Projekt entfernt? Wissen Sie, was hier betrieben wird? Definitiv keine wirkliche Projektabschätzung oder sachliches Arbeiten – egal wie viel Formeln Sie in Ihr ExcelSheet einbauen! Was hier vielmehr stattfindet, ist im psychologischen Sinne „ein Spiel unter Erwachsenen“: Wer schlägt wen mit welchen Tricks und Methoden, damit am Ende die Werte, die man selbst möglicherweise schon vorher im Kopf hatte, sich am Ende bestätigen. – Ich weiß nicht, ob Sie sich in diesem Moment bewusst sind, dass Sie mit diesen sehr frühen Entscheidungen die Salamitaktik der letzten Meile Ihres gerade anlaufenden Projektes in die Wege geleitet haben. Natürlich, es gilt die alte Weisheit: „Egal, wie viel Zeit ich einem Projekt gebe, sie wird immer verbraucht werden!“ – Das ist wahr, aber keineswegs dass, was ich ausdrücken möchte! 2.3.4 Probleme aussitzen Falls ich Sie an dieser Stelle verloren haben sollte: Kennen Sie das Problem des Aussitzens? Wenn auch in anderem Kontext, so stammt folgende Aussage von Benjamin Franklin: „Mit kleinen Hieben fällt man auch große


27

Bäume.“ – Es wird eine Entscheidung gefällt, etwa Ihre Produktionsverfahren umzustellen oder ein neues Werkzeug einzuführen. Dies findet naturgegeben nicht nur Freunde, sondern es wird auch solche geben, die das Alte lieben (vielleicht, weil diese Personen es einmal selbst eingeführt haben). Vielleicht erscheint den Betreffenden das Neue auch nur zu teuer. – Was tut man in so einem Fall: Man fängt an, in einer Weise zu argumentieren, dass man ja im Prinzip sehr wohl das Neue wolle, aber … man brauche noch mehr Details, noch mehr Untersuchungen, noch mehr Sicherheit – immerhin gehe es um das Wohl der Firma und man wolle ja nur deren Bestes. – Langer Rede kurzer Sinn: Mit dem freundlichsten Lächeln aller Zeiten auf den Lippen führt man einen erbitterten Kampf, um im Zweifelsfall etwas so lange zu verzögern, bis dessen Umsetzung nicht mehr möglich ist oder man sich selbst eine deutlich bessere Position verschafft hat! Nun zurück zum Projektalltag: Gerade im Vorfeld von innovativen Projekten sind Salamitaktiken äußerst beliebt und meist schwer zu durchschauen, da der Nutzen solcher Innovationen zu diesem Zeitpunkt oftmals nicht sofort wahrgenommen wird. – Somit bleibt die Frage: Wie klar kennen Sie Ihre Ziele und hoffentlich diejenigen Ecken in Ihrem Verantwortungsbereich, die zu Grabenkriegen einladen? Die Summe dieser und anderer Fehleinschätzungen führt unweigerlich – und dafür muss man kein Hellseher sein – zu dem, was Abb. 2.2 ausdrückt! Ihre Planung und die daraus resultierende Wirklichkeit weichen deutlich voneinander ab, selbst wenn der Projektumfang an sich relativ gut definiert wurde. Die beiden Kurven verdeutlichen ein Weiteres: Gerade die letzte

Abb. 2.2. Plan und Wirklichkeit – zwei Welten begegnen sich

28


Meile Ihres Projektes wird in den allermeisten Fällen Ihre wohl geordneten Organisationsstrukturen durchbrechen und es gilt dann nur noch: Wie kann man überleben und Ziele grob erreichen, die in der Nähe dessen liegen, was eigentlich vereinbart war. Viele Softwareprojekte verlaufen immer noch nach dem stets gleichen „Drehbuch“, wie es in Abb. 2.2 zu sehen ist. Am Anfang herrscht (oft) die Begeisterung, Zuversicht und die Erwartung, das neue Projekt im gewünschten Zeitrahmen zu bewältigen. Nach einer arbeitsreichen Phase, meist unterbrochen durch unerwartete Nebenaufgaben, nähert man sich mit großer Geschwindigkeit dem gesetzten Zeitlimit. Dies ist in sehr vielen Fällen mit der Tatsache gepaart, dass man doch noch nicht so weit mit der Softwareentwicklung vorangekommen ist, wie man gehofft hatte: Es treten Verzögerungen bei der Entwicklung auf. Gleichermaßen geht die Quote an Fehlern gerade jetzt nach oben, was auch sehr verständlich ist, denn jetzt findet zumeist das Testen in maximaler Intensität statt. Vieles andere strömt auf die Entwickler ein und die häufig sehr widersprüchlichen Aussagen erzeugen viel Unruhe und Unsicherheit. – Genau in dieser Phase ist Motivation und Ausgleich von zentraler Bedeutung.

2.4 Schlingerkurse Man kann einen Birnbaum nicht mit der Peitsche antreiben, damit er vorzeitig Früchte trägt, oder den Weizen an den Wurzeln kitzeln, dass er schneller reift. Sollten wir Menschen um so vieles anders geschaffen sein? Ich glaube nicht. Auch in ihm wirkt ein ordnendes Gesetz, ihm allein eigen und gemäß. Er kann vieles in der Welt durcheinander bringen, zu seinem Vorteil, wie er meint, aber an jenes Gesetz darf er nicht rühren. (Karl Heinrich Waggerl) Alles soll bei dem neuen Projekt besser werden, Sie haben viele gute Vorsätze gefasst, die Planung steht, die Mitarbeiter sind eingeplant. – Wenn es jetzt die böse Wirklichkeit nicht gäbe, die besagt, dass Sie auch noch andere Verpflichtungen haben, die Sie bedienen müssen. Vielleicht sind es die Fehler der Vergangenheit, denen Sie Tribut zollen müssen, indem Sie ständig in größerem Stil Mitarbeiter an das Ausbessern von Fehlern in den Altapplikationen setzen müssen, nicht pünktlich fertig gewordene Vorprojekte immer noch am Laufen haben oder Ihre Projektplanung mal wieder zu knapp ausgefallen ist, weshalb Sie zugesagte Liefertermine in anderen Projekten riskieren. In dieser Situation ist es eine beliebte Vorgehensweise des Managements, die Mitarbeiter aus einem gerade anlaufenden Projekt noch einmal „kurz“ zu entleihen – die Deadline für das neue Projekt ist ja ohnehin noch so weit weg, dass man diesen temporären Mitarbeiterschwund mit

2.4 Schlingerkurse

29

Sicherheit wird im Projekt ausgleichen können. Die Situation ist absolut verständlich, gleichwohl betreiben Sie durch diese Vorgehensweise ein mehrfaches Spiel mit dem Feuer. Der erste Fall wurde bereits angesprochen: Ohnehin knapp mit Personal bestückte Projekte werden noch einmal ausgedünnt oder kurzfristig Mitarbeiter abgezogen. Immerhin ist man ja bereit, zu Projektende aus anderen Teams kurzfristig Mitarbeiter in das aktuelle Projekt zu verlagern. Die Sache hat nur einen gewaltigen Pferdefuß, der unter dem Begriff „Brooks'sches Gesetz“ in die Softwareentwicklung Einzug gehalten hat. Die sich immer wieder bestätigende Beobachtung dieser Aussage lautet: Fügt man einem sich verspätenden Softwareprojekt weitere Mitarbeiter hinzu, so wird hierdurch die Verspätung nur noch größer. – Die Ursachen dafür liegen in der wachsenden Komplexität der Arbeitsteilung und Kommunikation. Hinter diesem Gesetz verbirgt sich Fred Brooks, ein Manager aus dem IBM OS/360-Projekt, der seine Erfahrungen in dem Buch „The Mystical Man-Month“ (Brooks 1995) niedergelegt hat. In diesem Zusammenhang ist übrigens der technische Roman von DeMarco „Der Termin“ (DeMarco 1997) eine wunderbare Bettlektüre für IT-Projektmanager, um diese Aussagen zu belegen. Warum, meinen Sie, steht auf den meisten Rechnungen Ihrer Autowerkstatt ein Betrag für Rüstzeiten? Natürlich: Ihre Informatiker arbeiten am selben Rechner, vermutlich sogar mit derselben Entwicklungssoftware – im einen wie im anderen Projekt. – Dies ist nicht das Problem. Was Sie sich aber sehr rasch als Folgeprobleme einhandeln werden, ist in wenigstens zwei Teilbereichen zu finden: Zum einen müssen sich Ihre Mitarbeiter – psychologisch gesehen – in das jeweils andere Thema erneut „eindenken“. Nicht mehr alle Details haben sie so präzise wie es notwendig wäre vor Augen bzw. die menschliche Natur neigt dazu, Teilaspekten aus jeweils anderen Projekten mit dem aktuellen Thema zu vermischen. – Die Folge ist, dass sie letztendlich mehr zusätzliche Zeit verbrauchen, die sie bei durchgängiger Arbeitsweise in diesem Maß nicht hätten investieren müssen. – Hinzu kommt, dass gerade solche Mitarbeiter – ich nenne sie liebevoll „Erbsenzähler“ – die sehr detailgenau und gründlich arbeiten, mit solch einer Vorgehensweise aus ihrem Arbeitsrhythmus gebracht werden – infolgedessen wird die Leistung dieser Mitarbeiter noch einmal sinken. – Dies stellt folgerichtig Ihre Planung zusätzlich in Frage, da Sie mit aller Wahrscheinlichkeit keinen Aufschlag für demotivierende Faktoren eingeplant hatten. In gleicher Weise ist die Realisierung desselben Projektes in kürzerer Zeit keine wirklich gute Lösung. In seltenen Fällen hatten Sie vielleicht einen guten Riecher und das Problem löste sich schneller als gedacht. In der Mehrheit der Fälle tritt das Gegenteil ein! Dinge brauchen ihre Zeit und wenn der (Termin-)Druck zu hoch wird, steigen die Mitarbeiter mental

30


aus. Das heißt, sie werden weiter ihre Arbeit machen, aber da sie die gesetzten Ziele für unrealistisch halten, ist ein Endspurt mit solchen Kollegen fast nicht mehr möglich, da sie sich letztlich innerlich aus dem Zeitplan des Projektes verabschiedet haben. 2.4.1 Ordnungen der höheren Art Bis hierhin sind mehrere Kostentreiber auf dem Weg zu neuer Software eingekreist worden. Fast durchweg war dabei der Blick auf das Umfeld der IT-Entwicklung gerichtet worden, nicht aber auf den Softwarecode bzw. die Projektdokumentation. Egal, wie die Entwicklungsumstände und Verfahren sind, am Ende eines Projektes wandern die eigentlichen Projektdokumente in irgendwelche voluminösen Verzeichnisstrukturen, die häufig so angelegt wurden, dass das Wiederfinden von Dokumenten nahezu aussichtslos ist, während die entstandene Software ihre Reise durchs Produktleben antritt. Lassen sich bei Ihnen gezielt Informationen zu einem Thema wiederfinden oder gehören Sie zu demjenigen Organisationstypus, der alle Projektinformationen akribisch gesammelt hat und auf – sagen wir – 10.000 Worddokumente verweisen kann. Die schriftstellerische und inhaltliche Bandbreite dieser Dokumente reicht von kappen Listen bis zu romanhaften Erzählungen, sie enthält alte und neue Entwicklungsstände, Fiktion und Wirklichkeit – und niemand weiß genau, wie man die adäquaten Informationen zeitnah wiederfindet. Wie leicht werden hierdurch die besten Voraussetzungen geschaffen, um später verzweifelt und aufwändig nach Nadeln im Heuhaufen zu suchen? Welche Konsequenzen hat dies für die spätere Fehlersuche bzw. Weiterentwicklung? Wie viel Überlegungen und Vorarbeiten wurden zu Projektbeginn investiert, um nicht nur einen teuren Datenfriedhof zu gründen, sondern Wege zu etablieren, diese Informationen auch wiederfinden zu können. Informationstechnisch gesehen ist ein großer Haufen Dokumente ohne geeignete Suchmechanismen etwa genauso viel wert wie der komplette Verzicht auf Dokumentation. Der einzige Unterschied zwischen dem Datenfriedhof und der fehlenden Dokumentation besteht darin, dass diese Art letzter Ruhestätte in aller Regel sehr viel Zeit und somit Kapital gebunden hat. – Ganz offenbar keine sonderlich gute Investition! 2.4.2 Elefantitische Eleganz Zuletzt soll hier noch ein kurzer Blick in das geschaffene Labyrinth kodierter Logik geworfen werden. Dieser Code trägt so eindeutig die individuelle Handschrift seiner Erschaffer, wie der Pinselstrich einen bestimmten Maler identifiziert. Viel wurde über „richtiges“ oder „falsches“ Kodieren

2.4 Schlingerkurse

31

geschrieben – was bleibt, ist jedoch dieses sehr individuelle Kunstwerk aus Bits und Bytes. Die einen bauen mit Genialität und Akribie wahre Meisterwerke in sich verschachtelter Codesequenzen, die nur sie selbst verstehen. Die anderen kodieren mit enormer Schreibleistung große Mengen an Code und bezeichnen diesen als selbsterklärend, weshalb auf Kommentare verzichtet wurde. Wiederum andere kopieren Codesequenzen aus verschiedenen Ecken der Organisation und dem Internet zusammen, da sie mit diesen nun mehrfach vorkommenden Codes bereits anderswo gute Erfahrungen gesammelt haben. Langer Rede kurzer Sinn – auch bei guten Planungsdokumenten und entsprechenden Werkzeugen ist hier immer noch ein extrem hohes Maß an Individualität wiederzufinden. Gerade dies macht aber eine ohnehin schon komplizierte Materie noch ein wenig schwieriger. Neben diesen individuellen Ausprägungen, die im Zweifelsfall das Leben nachfolgender Programmierer deutlich erschweren, gibt es einen mehr psychologischen Aspekt, der sich immer wieder finden lässt. Softwareerstellung hat oft etwas mit eigenem „Herzblut“ zu tun, dementsprechend wird man sein Baby schrittweise verbessern, schöner machen und entsprechend ausgestalten. Diese Vorgehensweise, die sich übrigens klar von dem später in diesem Buch noch eingeführten „Refactoring“ unterscheiden lässt, wird als „Creeping Elegance“ bezeichnet: Viel Arbeit und oftmals neue Fehler entstehen nur dadurch, dass irgendjemand irgendwelche Codesequenzen hübscher machen wollte. Nebenbei bemerkt ist hierzu ein enger Verwandter der „Creeping Featurism“. Hier werden immer mehr Funktionen einer entsprechenden Routine mit auf den Weg gegeben. Die Folge ist wachsende Unübersichtlichkeit sowie ein krebsartiges Wuchern quer durch große Teile der Applikation. Wie bei Krebsgeschwulsten wird zunehmend mehr „gesundes“ Material durchsetzt und infiziert. Ebenso wird eine vorausschauende Planung hierdurch heftig torpediert oder sogar zunichte gemacht, da es nicht mehr ohne weiteres möglich ist, die Gesamtsoftware in Modulen mit genau umrissener und zugleich loser Kopplung der Einzelelemente zu errichten. 2.4.3 Wenn Software zur Slowware mutiert Diese Punkte wiederum stehen in direktem Bezug zu einem letzten Thema dieser Art. Trotz guter Planung, hervorragender Konzeptionierung und guter Implementierung stirbt so manches Softwareprojekt kurz vor seiner Übergabe an den Kunden. Warum? Es war nicht performant genug oder es zwingt z. B. das Betriebssystem regelmäßig in die Knie! – Was ist geschehen? Es wurde ein neues Projekt gestartet, kein kleines, sondern ein durchaus komplexes. Zur Realisierung der Software wurde eine gängige objektorientierte Programmiersprache eingesetzt. Die Software entsteht nach allen

32


Regeln der Kunst und wächst unaufhaltsam ihrer Vollendung entgegen. Indem immer mehr Features, möglicherweise sogar aus einer komplexeren Domainstruktur stammend, sich zu den bereits vorhandenen Teilen hinzugesellen, werden die anfänglichen Startzeiten des Programms immer gemächlicher. Je mehr hinzufügt wird, desto mehr geschieht allerdings auch hinter der Bühne: Das System bindet Unmengen an internem Speicher und verbraucht einen immer größeren Stapelspeicher für den Prozessor. Irgendwann meldet sich auch das toleranteste Betriebssystem zu Wort und bemängelt den zur Neige gehenden Speicher immer lauter. Was hieran deutlich wird, ist ein eklatanter Mangel in der IT-Architektur. Es wurde ein System aufgebaut, bei dem zwar über Komponenten, Schichten und Ähnliches nachgedacht wurde, zu keinem Zeitpunkt aber die Elementarfrage gestellt wurde nach benötigten internen Ressourcen und eng damit verknüpft nach Speicher und somit Volumen- und Performanceoptimierung! Diese Versäumnisse aus frühen technischen Planungsphasen lassen sich später nicht mehr wieder gutmachen und werden als eine Art Stigma dieses Produkt durch den gesamten Lebendszyklus begleiten.

2.5 Produktionsmüll Wer etwas ändern will, sucht Wege. Wer nichts ändern will, sucht Gründe. (überliefert) Softwarearbeitsgruppen schwören auf unterstützende Tools, sie verwenden Prozess- bzw. Dokumentationswerkzeuge – sei es für wenig oder kein Geld (z. B. als Freeware), sei es für viel Geld, erworben bei namhaften Anbietern. Wie immer Ihre Paradigmen auch sein mögen, vorausgesetzt Sie entwickeln dokumentierte Software: Wissen Sie eigentlich, wie viel Zeit in Ihrem Bereich verloren geht, weil Arbeit im buchstäblichen Sinne doppelt gemacht wurde oder aber mit großem Aufwand von Hand synchronisiert werden muss? – Es geht um redundante bzw. überflüssige Arbeiten. Ja, Sie lesen richtig! Die Rede ist von vielen Stunden investierter Zeit, die Sie bzw. Ihre Mitarbeiter in ein Projekt einbringen, um später zu erkennen, dass genau diese Arbeit in eben dieser Form mit all den damit verbundenen Nachtschichten letztendlich nicht den gewünschten Zweck erfüllte, sondern eigentlich neu erstellt werden muss! Falls Ihnen diese Situation nicht bekannt vorkommt, so möchte ich hier ein wenig konkreter werden: Ich denke an reale Situationen, in denen Mitarbeiter mit unendlichem Fleiß sehr lange Spezifikationen verfasst haben: vollständig, akribisch, umfassend und ausführlich! – Die Frage, die sich die Mitarbeiter allerdings erst bei Folgetätigkeiten stellten, lautete: Wer soll diese vielen Seiten Papier eigentlich lesen? – Spezifikationen und sonstige Dokumente werden haufenweise

2.5 Produktionsmüll

33

produziert: ausführlich, langatmig, vollständig oder auch unvollständig. Wie viele Ihrer fleißig schreibenden Mitarbeiter sind sich bewusst darüber, dass hier etwas geschrieben wird, das nur einem Zweck dienen soll, nämlich dass andere möglichst eindeutig und klar verstehen, worum es geht und wie Sachen zu machen sind! Wie viele Ihrer Mitstreiter haben sich aktiv damit auseinander gesetzt, ob sie das Dokument um des Dokuments willen verfassen, oder es deshalb schreiben, weil sie gerade eine Serviceleistung für andere erbringen? Haben Sie sich selbst schon einmal gefragt, ob die Dokumente, die Sie verfassen, so geschrieben sind, dass andere – seien es Entwickler, Tester oder Projektmanager – in möglichst kompakter Form die Information erhalten, die sie brauchen, um einen guten Job zu machen? Was meinen Sie wohl, erzeugt beim Leser mehr Fehler in der Umsetzung: 10 Seiten kompakte oder 100 Seiten breitgetretene Information? Persönlich tippe ich auf das zweite, weiß ich doch von mir selbst, dass ich für 100 Seiten Lesestoff zu einem speziellen Thema kaum die notwendige Zeit zum Lesen aufbringen werde, somit viel eher „querlese“ und Inhalte überspringe! Hier wird also bewundernswerter Elan in eine Tätigkeit investiert, die am Ende das Fehlermachen unterstützt! Warum? Weil möglicherweise niemand Ihren Mitarbeitern klar gemacht hat, für wen sie diese Arbeit leisten, bzw. ihnen vermittelt hat, wie man Qualität und Masse in Balance hält! 2.5.1 Kompakte Informationen Einmal angenommen, dass Sie Software bauen, die hohen Qualitätsstandards genügen soll, vielleicht sogar zu zertifizieren ist. Des Weiteren sei angenommen, dass Ihnen ein Team von Mitarbeitern zur Verfügung steht, welches genau dieses auch so realisieren möchte. Das Team hat verstanden, dass nur dann gute Software abgeliefert werden kann, wenn diese ausreichend getestet wurde und samt den zugehörigen Dokumenten qualitätsgesichert ist. Angenommen, jeder im Team schafft es, jegliche Änderung an Entwicklungsinfrastruktur, Planungsdokumenten und Projektdokumentation komplett und zeitnah in den definierten Dokumenten nachzutragen. – Wissen Sie, an wie vielen Stellen derselbe Inhalt in nahezu derselben Weise hinterlegt ist, oder haben Sie im Vorhinein Wege gefunden, um diese Art von Redundanz zu vermeiden? – Haben Sie sich einmal gefragt, wie viele Manntage Sie regelmäßig in Doppelarbeiten investieren, die durch nichts anderes entstanden sind als ungenügende Vorausplanung? Im Zusammenhang mit der Projektdokumentation sind dabei zwei Punkte von Bedeutung: Im ersten Fall handelt es sich um die gezielte Vermeidung von Informationsredundanz. Jede wichtige projektbezogene Information muss schriftlich, aber nur an einer Stelle hinterlegt sein. Diese wiederum muss für alle Projektbeteiligten eindeutig und schnell aufzufinden sein,

34


wobei jegliche Form von Änderung zu diesem Thema nur hier erfolgen darf. Im zweiten Fall geht es um „Traceability“: Jede Information und jede Aktion muss auf eine nachvollziehbare Beauftragung bezogen werden können. Auf diese Weise ist es möglich, eine Taxonomie aufzubauen und zu pflegen, deren zentraler Startpunkt in der spezifischen Projektvereinbarung wiederzufinden ist. 2.5.2 Nichts ist so ungetestet wie Software Es ist besser, eine Sache zu 90 Prozent gut zu machen, als sie zu 100 Prozent gar nicht zu machen. (B. Unperfect) Es würde mich nicht wundern, wenn Sie mir im Weiteren heftig widersprechen werden! Sie haben Testmanagementpläne, Ihnen liegen lange Testberichte vor und Sie wissen, dass sehr viele automatische Plausibilitätskontrollen in Ihre Software eingebaut wurden. – All das mag sein, trifft aber nicht den Punkt, den ich hier machen möchte! – Die obige Aussage über ungetestete Software enthält verschiedene Aspekte. Natürlich: Wie kann man sagen, dass Software ungetestet sei. – Selbst schlecht getestete Software hat vermutlich mehr Überprüfungen erfahren als die meisten anderen kaufbaren Artikel. – Und dennoch gehen bei Software die Uhren anders! Anders als bei einem Kleidungsstück oder Haushaltsgut, bei dem eine gewisse Rate kleiner Fehler absolut tolerabel ist, gilt aus Anwendersicht streng betrachtet das Null-Toleranz-Prinzip für Software. – Wie ist das zu verstehen? Würden Sie eine Konserve zurückbringen, wenn die Füllmenge ein wenig zu hoch oder zu niedrig wäre bzw. das Etikett nicht absolut korrekt sitzt? – Würden Sie dauerhaft eine Software als gut empfinden, bei der bestimmte Randfunktionalitäten nicht korrekt funktionieren? Mag sein, dass Sie diese Software nutzen, Sie auch vor Dritten rechtfertigen – dennoch aber bleibt der Makel eines unvollkommenen Produktes. – Natürlich, dies ist die harmlose Seite der Münze. Viel dramatischer sieht es da aus, wo eine fehlerhafte Zeile Code, verborgen innerhalb von Millionen anderer Zeilen, gewaltige materielle Schäden oder sogar den Verlust von Menschenleben bewirken kann. Als drastisches Beispiel sei hier an den Start der Ariane 5 am 4. Juni 1996 erinnert: Hier schaltete das Haupttriebwerk 37 Sekunden nach dem Start aufgrund eines falsch konvertierten Messwertes ab, was zur Folge hatte, dass ein Schaden von ca. 600 Mio. Euro entstand. – Mehr noch: Amerikanische Untersuchungen beziffern den jährlichen Schaden durch ungetestete Software auf ca. 59 Mrd. US-Dollar! Dies sind gigantische Zahlen gelassen ausgesprochen! – Selbst wenn Ihre IT-Mannschaft sehr viel kleinere Brötchen bäckt, es bleibt Tatsache: „Alles was eingestellt und eingegeben werden kann, muss auch funktionieren“. Genau hier aber liegt die Schwierigkeit für den Hersteller: Wie überprüft man


35

dieses „Alles“ – wo es doch gerade eine der Stärken von Software ist, in beliebig viele Varianten und Unterfälle zu differenzieren? Immerhin ist die meiste Software ein Kontinuum aus sehr vielen frei kombinierbaren Funktionen, Einstellungen, Werten und Optionen. – Wie bewusst sind Sie sich selbst dieser Tatsache – und vor allem, wie eingehend haben Sie diese Thematik schon einmal mit Ihren Mitarbeitern durchgearbeitet? –Testen Sie immer noch nach Augenmaß oder haben Sie Strategien entwickelt, mit deren Hilfe Sie auch große und komplexe Systeme recht flächendeckend testen können? – Immerhin wird gerade Testen nicht selten als ein notwendiges Übel betrachtet, das man am Ende einer genialen Programmierung noch nachliefern muss. Noch immer ist eine gewisse Mentalität bei vielen Entwicklern festzustellen, die darin besteht zu sagen: „Ich habe meine Software beim Bau getestet – ganz klar, dass mein Stück Software geht!“ – Schön, wenn dem so ist! Noch schöner aber, wenn man nicht nur behaupten, sondern auch belegen kann, dass gerade dieses Stück Software in der großen Symphonie aller gebauten Komponenten genau die ihm zugedachte Rolle spielt. 2.5.3 Alptraum der letzten Meile Niemand darf aus den Augen verlieren, was er wirklich will. Selbst wenn er manchmal glaubt, die Welt und die anderen seien stärker. (Paulo Coelho) Ich komme nun zum Ende der Projektphase, dem Zeitraum also, bei dem sich alles um die anstehende Auslieferung der Applikation dreht. Zunächst möchte ich den Blick noch einmal auf Abb. 2.2 (S. 27) lenken. Neben den bereits diskutierten Aspekten verweist die Grafik auf eine weitere Tatsache, nämlich das Mysterium, warum Projekte vorzugsweise zum Ende hin die meisten Fehler produzieren. Über lange Strecken hinweg hatten Entwickler und Planer immer wieder alles im grünen Bereich gemeldet und plötzlich ändert sich das Ganze! Natürlich: Sobald die Erstellung einer Software dem Ende entgegengeht, beginnt das Testen erst richtig. Folgerichtig werden nun viele Probleme sichtbar, die man bis dato nicht sehen konnte. Dies ist eine logisch sinnvolle Erklärung. Sie kann aber auch ein Indikator für die Qualität oder deren Gegenteil in früheren Planungsarbeiten sein. In welchem Maß wurde z. B. David L. Parnas „Geheimnisprinzip“3 in frühen 3

Das Geheimhaltungsprinzip nach Parnas besagt, dass sich Programmierer an einem größeren Softwareprojekt nur über die Schnittstellen, nicht jedoch über die Implementationsdetails ihrer Module austauschen sollen. Damit soll verhindert werden, dass unvorhersehbare und undokumentierte Abhängigkeiten zwischen Modulen entstehen, die unter Umständen zu riesigen Kosten für Debugging führen können.

36


Planungen berücksichtigt und in welchem Maß wurde stattdessen ein anderes Geheimnisprinzip angewandt. Letzteres erfreut sich durchaus großer Beliebtheit innerhalb der IT-Branche und lautet: Tue gewisse Dinge oder führe bestimmte Vorgehensweisen in das Projekt ein, aber verrate es niemandem! Auch wenn dieser Satz sicher stark überzeichnet, so ist sein Wahrheitsgehalt oft leider höher als vermutet und hat in vielen Fällen etwas mit der Art und Qualität der Teamzusammenarbeit zu tun. Vermutlich ist Ihnen folgende Situation nicht unbekannt: Mühsam wird, z. B. über mehrere Standorte hinweg, ein technisches System aufgebaut oder Verabredungen getroffen. Alles fängt an zu funktionieren – und auf einmal klemmt das Ganze, vorzugsweise, wenn andere Themen dringlich werden. Keiner kennt die Ursachen, es werden viele Stunden Arbeit in Ursachenforschung investiert, Zeit also, die Ihnen an anderen Stellen komplett verloren geht. Endlich findet man nach langem Suchen die Auflösung und stellt mit Erstaunen fest, dass irgendein Projektmitarbeiter vergessen hatte, darüber zu informieren, dass er vielleicht nur eine IP-Adresse oder eine Firewall-Einstellung aus nachvollziehbaren Gründen verändert hat. Er schaut Sie mit großen unschuldigen Augen an und ist sich überhaupt nicht bewusst, wie viele Projektstunden durch sein unbedachtes Handeln gerade verloren gegangen sind. Vielleicht war es ein einmaliges Versehen und wird nicht wieder vorkommen, vielleicht aber ist es auch der bereits erwähnte leicht autistische Zug – und Sie werden denselben Kollegen möglicherweise schon morgen Ähnliches tun sehen – und wieder wird er Sie mit großen unschuldigen Augen anschauen! – War das Zeit, die in der ohnehin schon engen Projektplanung vorgesehen war? Oder andersherum gefragt: Was tragen Sie insgesamt dazu bei, um solche Situationen einzudämmen? (Hoffentlich nicht das eine, nämlich noch mehr Regeln in Ihr ohnehin schon kompliziertes Regelwerk einzuführen!) 2.5.4 Homo sapiens Rache Irrtümer muss man teuer bezahlen, wenn man sie loswerden will. (Johann Wolfgang von Goethe) Egal ob Sie neue Regeln einführen oder nicht, auf jeden Fall ist Ihnen wertvolle Zeit verloren gegangen, die Ihnen jetzt in der kritischsten Phase des Projektes fehlt, weil Sie früher im Projekt z. B. sich nicht ausreichend Gedanken über das Zusammenspiel Ihrer Mitstreiter gemacht haben! In Summe rächen sich sehr viele der kleinen und größeren Versäumnisse, die Sie im Laufe des Projektes eingebracht haben, gerade auf dieser verflixten letzten Meile! Buchhalterisch genau summieren sich nun all die aufgelaufenen


37

Unplanmäßigkeiten als großer Haufen vor Ihren Füßen und blockieren den Weg zur pünktlichen Erreichung der festgelegten Ziellinie. Zwar gibt es vielerorts immer noch dieses geheimnisumwitterte Syndikat, diese eingeschworene Schicksalsgemeinschaft von Softwareanwendern, die sofort größtes Verständnis aufbringen, wenn die Software nicht funktioniert und dadurch eigene Termine ins Rutschen kommen. Dort wirkt es immer noch wie das Kismet des IT-Zeitalters: „Meine Software geht mal wieder nicht“ – und ein Großteil der Betroffenen bedauert Sie und zeigt Verständnis. Lassen Sie uns ganz offen und ehrlich die Wirklichkeit anschauen. Egal, welche projekttechnischen Taschenspielertricks Sie nun gegenüber dem Kunden oder dem Management aus dem Hut ziehen, um zu beweisen, dass Sie es geschafft haben. Trotz aller Beschönigungen bleibt die Tatsache bestehen, daß Sie nicht termingerecht fertig wurden oder möglicherweise qualitätstechnisch ungeprüfte Software an den Kunden ausliefern, in der Hoffnung, dass die Software das tut, was sie soll! – Was äußerst mutig von Ihnen ist und russischem Roulette mit sechs Kugeln gleichkommt. – Wäre es da nicht an der Zeit, in kleinen Schritten die tatsächlichen Verursacher aus dem Wege zu räumen? 2.5.5 Nutzbarkeit und andere Legenden Der Stein der Weisen sieht dem Stein der Narren zum Verwechseln ähnlich. (Joachim Ringelnatz) Inzwischen befindet sich Ihre Software bei den Anwendern. Der Kunde hat die georderte Leistung abgenommen und fängt nun an, dieses Produkt modernster Technik zu benutzen. – Wie werden wohl seine Eindrücke sein? Wird er Sie in den nächsten Wochen und Monaten mit ständigen Nachforderungen bombardieren, um die Korrektur für gefundene Mängel zu erhalten? Wird der Endanwender mit dem, was Sie gebaut haben, wirklich zufrieden sein? – Erfüllt die erstellte Software tatsächlich alle in sie gesteckten Erwartungen – und vor allem –, ist sie so konstruiert, dass ein Teil der menschlichen Arbeitsleitung sinnvoll auf den Computer übertragen werden kann? An dieser Stelle kommen all diejenigen Fragen auf, die darüber befinden, ob die von Ihnen entwickelte Software nur ihren Zweck erfüllt oder tatsächlich als „gut“ betrachtet wird. – Inzwischen gibt es messbare Größen darüber, ob und wann eine Software später vom Anwender als „gut“ empfunden werden wird. (Mehr darüber werden Sie auf S. 129 ff. finden.) – Sicherlich geben Sie mir Recht, wenn ich behaupte, dass es nun ein wenig spät ist, sich jetzt am Ende der Softwareerstellung diese Gedanken zu machen.

38


Die Software ist bereits fertig gebaut, wurde beim Kunden installiert – und nun kommen Sie mit diesen Punkten! – Völlig richtig, aber wer hat bei Ihnen – trotz aller Usecases und Softwaredesign-Themen in der Planungsphase des Projektes eigentlich systematisch über die Nutzbarkeit der kommenden Software nachgedacht? Wessen Aufgabe war es oder hätte es sein sollen, sich zu fragen, ob die Anordnung der Steuerelemente, deren Funktion und Zusammenwirken intuitiv ist und hausbacken? Sicherlich merken Sie schon, worauf ich hinaus will: In sehr vielen Fällen neigt moderner Softwarebau dazu, dass man sich die Nutzungsfälle betrachtet, ebenso wie die passende technologische Lösung. Was immer wieder ausgespart wird, ist die Betrachtung des Informationsflusses im Sinne einer Informationsarchitektur oder gar die Optimierung dieser Mensch-Maschine-Schnittstelle. Eigentlich schade, vielleicht auch fatal! Immerhin ist diese „GUI“4 der einzige tatsächliche Berührungspunkt zwischen Anwender und Technik. Fehlerfreiheit und ausreichende Geschwindigkeit Ihrer Software einmal vorausgesetzt: Sind es nicht gerade die Anwendermasken und deren Nutzbarkeit, die diesem Produkt das eigentliche Gesicht verleihen und zum zentralen Qualitätselement avancieren?

Drosophila und Co Wenn der Wind des Wandels weht, bauen die einen Windmühlen, die anderen bauen Mauern. (chinesisch) Noch einmal möchte ich Ihren Blick auf die Projektorganisation richten und mich dabei einer Allegorie aus der Tierwelt bedienen. Es geht an dieser Stelle um die netten Tierchen, die mit sechs Beinen, sehr großen Augen und der Fähigkeit zu fliegen ausgestattet sind. Stellen Sie sich dazu die folgende Situation vor: Aus Ihren tiefsten Träumen werden Sie wegen dieser kleinen ungebetenen Besucher aufgeschreckt. Mit einer raschen Bewegung vertreiben Sie das herannahende kleine Biest, das sich deutlich summend kurz zuvor bei Ihnen ankündigte. Keine 20 Sekunden später kommt genau derselbe kleine Plagegeist mit genau demselben Anliegen wieder auf Sie zugeschossen. Schon etwas entnervt vertreiben Sie diesen Störenfried erneut, um bereits nach kürzester Zeit genau dieselbe Prozedur wieder durchlaufen zu müssen! – Klingt das nicht irgendwie vertraut? – Immer wieder finden sich IT Unternehmen (und nicht nur dort), die nach langem und zähen Ringen endlich zu eigenen Prozessen z. B. bei der Erstellung von Software gelangt sind (was gut ist), diese dann quasi in Beton gegossen haben und es zum Sakrileg erklären, wenn die einmal definierten Vorgehensweisen nicht ganz genau eingehalten werden. Die Folgen 4

GUI = „Graphical User Interface“ – die Grafikschnittstelle zum Anwender


39

können ähnlich dem Fliegenhirn sein: Die statische Regelung der eigenen Vorgehensweise macht vielfach blind für eigene Schwachstellen und verhindert leicht situativ schnelle Reaktionen. Keine Angst, ich möchte Ihre Prozesse nicht hinterfragen. Worum es mir allerdings geht, ist die Frage, wie Sie den Sinn oder Unsinn von Prozessen bewerten und hinterfragen, um das eben umrissene Fliegen-Phänomen zu verhindert? Bewerten Sie regelmäßig Ihre Prozesse? – Gibt es bei Ihnen eine Unternehmenskultur, die gemachte Erfahrungen proaktiv auswertet und in Prozessmodifikationen entsprechend berücksichtigt? Welche kurz-, mittel- und langfristigen Steuergrößen nutzen Sie, um aufgetretene Fehler kein zweites Mal zu machen bzw. öfter zu Erfolgsgeschichten zu gelangen. – Es geht darum, ob Ihre Organisation aktiv lernfähig ist – oder immer nur dann über diese Fähigkeit verfügt, wenn buchstäblich das Kind schon in den Brunnen gefallen ist. Wie stark sind Ihre Mitarbeiter darauf eingestellt, Verbesserungsvorschläge zu formulieren und auch zu erleben, dass diese zügig den Weg in die Wirklichkeit finden können? Was tun Sie, um das im Rahmen eines Projektes aufgebaute Mitarbeiterwissen so festzuhalten, dass bestimmte Lernschleifen kein zweites Mal durchlaufen werden müssen? Und zuletzt: Sammeln Sie diese Informationen nur, um diese dann zu horten, oder wie verwerten Sie diesen stetig wachsenden Berg an Erfahrungswissen? Kurz: Wie sehr ist Wissensmanagement und die Fähigkeit, als lernende Organisation zu operieren, Teil Ihrer Unternehmenskultur? 2.5.6 Zombie-Software Es ist nicht unsere Aufgabe, die Zukunft vorauszusagen, sondern auf sie gut vorbereitet zu sein. (Perikles) Ihre Software läuft. Sie haben die Kinderkrankheiten dieses Produktes überwunden, die Kunden sind zufrieden. Eigentlich könnten Sie doch im Hinblick auf das Projekt nun rundum glücklich sein – Ihre Kunden sind es ja offensichtlich auch. – Leider trügt der Schein, denn Software hat die unangenehme Eigenschaft, genauso zu altern, wie Sie und ich es tun – nur ein wenig schneller. Halten Sie sich bitte noch einmal Abb. 2.1 (S. 24) vor Augen. Hier war unter anderem die Rede von den Folgekosten, die dadurch entstehen, dass bei der Erstellung von Applikationen das Augenmerk fast ausschließlich auf die Realisierungsphase gerichtet war, nicht aber auf die Zeit danach. – Was ist mit den möglicherweise zwei, vielleicht aber auch mehr als zehn Jahren, in denen diese Software im Einsatz sein

40


wird. Wurde hierüber in Ihrer Planung zur Betriebsperiode nachgedacht? – Hierzu ein paar Beispiele: x Zunächst ein millionenschweres, wenn auch schon fast vergessenes Beispiel: Erinnern Sie sich an Y2K5? Haben die Berufskollegen der 70er oder 80er Jahre nicht gewusst, dass irgendwann ein neues Jahrhundert kommen wird – oder haben sie nur und ausschließlich auf die optimierte Nutzung des damals noch recht knappen Datumsspeichers geblickt? x Oder was ist mit solcher Software, die selbst heute noch (!) auf uralten Rechnern künstlich am Leben gehalten werden muss, nur weil man es versäumte, die Drittanbieterkomponenten zeitnah zu aktualisieren? x Und ein letztes Beispiel: Wie viel Zeit verbrennen Sie bei der Weiterentwicklung alter Software, nur weil bei der Erstellung alles ganz schnell gehen musste und sich niemand die Mühe machte, die geleisteten Arbeiten wenigstens einigermaßen zu dokumentieren. Was damals als vermeidbarer Aufwand angesehen wurde, da es dringende Lieferfristen einzuhalten galt, wird zur Milchmädchenrechnung und rächt sich teuer. Diese Beispiele sind aus Sicht eines Projektverantwortlichen durchaus dazu geeignet, sich regelmäßig den Schlaf rauben zu lassen, da dieser in längst als abgeschlossen geltende Projekte nicht unerhebliche Ressourcen ertraglos investieren muss. – Die Tatsache, dass man mit dererlei Aktivitäten kein Geld verdient, ist an sich schon schlimm genug. Schlimmer aber ist, dass diese Tätigkeiten gleichzeitig Personal binden, welches sonst in ertragbringenden Projekten eingesetzt würde. Niemand wird wirklich wissen, ob und wann Kunden wieder neue Fehler oder Änderungswünsche platzieren werden. Von Ihnen wird erwartet, dass sie diese neben bereits anderen angelaufenen Projekten bearbeiten. 2.5.7 Kleinvieh macht Mist Auf den vergangenen Seiten habe ich Ihnen mit Hilfe der dort beschriebenen Software-Biographie bereits eine ausführliche Liste mit Themen zusammengetragen. Ich möchte Sie an dieser Stelle einladen, das Gelesene noch einmal für sich zu reflektieren und die größten Mängel der eigenen Entwicklungsorganisation hier aufzulisten.

5

Y2K = Year 2000 Problem – Die weltweiten Anstrengungen in der Softwarebranche um zu verhindern, dass sich alte Software ab Jahreswechsel 2000 unkontrolliert verhält. – Die Ursache hierfür lag in der auch in Programmen bis dahin vielfach üblichen Verwendung von zweistelligen Jahreszahlen.


41

Tabelle 2.1. Hauptschwachstellen in Ihrer Softwareorganisation

Für den Fall, dass auch Sie zu denjenigen Menschen gehören, die Übersichten und Checklisten lieben, habe ich Ihnen die wichtigsten Schwerpunktthemen noch einmal tabellarisch zusammengetragen: Tabelle 2.2. Übersicht der Hauptrisikobereiche im Softwarebau Frühe technische Versprechungen an Kunden

Mangelndes Wissen über die Fachdomain des Klienten

Ungenügende Aufnahme von Anforderungen

Mangelnde Projektstruktur und Analyse

Strukturschwächen in der Organisation

Mangelnde Lebenszyklus-Planung der Software

Statisches Methodendenken

Nur projektgetriebene Sichtweise

Unstrukturiertes Aufhäufen von Dokumenten

Mangelndes Teammanagement

Mangelnde Strategie zur Handhabung der Komplexität im Projekt

Fehlende Betrachtungen zu den Folgeaufwänden

Im Rückblick auf das Gesagte lade ich Sie dazu ein, diejenigen Felder zu markieren, die Ihrem Entwicklungsalltag entsprechen. Wie viele dieser Fragen treffen wohl auf Ihre Organisation zu?

3 Willkommen in der Wirklichkeit

3.1 Vom Maßstab aller Dinge In der IT-Welt gilt CMM6 als Messlatte, an der festgelegt wird, wie gut – oder auch schlecht eine Organisation Software produziert. Abbildung 3.1 zeigt als Schaubild die verschiedenen Stufen dieses Modells. Wenn Sie Ihre eigene Auswertung von S. 41 zur Hand nehmen, so können Sie hiermit eine ganz grobe Selbsteinschätzung vornehmen. Verstehen Sie dabei diese Bewertung ausschließlich als Indikator und nicht als ein sauberes Assessment Ihrer Organisation!

Abb. 3.1. Die fünfstufige CMM-Einteilung von Softwareproduktionsprozessen 6

CMM steht für „Capability Maturity Model for Software“ und wurde vom Software Engineering Institute (SEI) an der Carnegie Mellon University entwickelt.

44


Sollten Sie überall oder nur mit sehr wenigen Ausnahmen auf Mängel in Ihrer Organisation gestoßen sein, so sind Sie entweder sehr selbstkritisch gewesen, hatten in Ihrer Organisation einen schlechten Tag oder sind vermutlich mit Ihrer Organisation im Bereich von CMM-Level 1 anzusiedeln! Auch wenn Heroismus bei den alten Germanen gut ankam: Mit industriell produzierter Software im Sinne von CMM hat Ihre Vorgehensweise recht wenig gemeinsam! Im Auftrag von „IT Volvo“, Schweden, wurden mehrere Studien zur Frage der realen Kosteneinsparung durch Prozessverbesserungen ausgewertet. Unter Zugrundelegung von zwei Studien aus den Häusern „IT Metrics Strategies“ (Rifkin 2001) und „Quantitative Software Management Inc.“ (Putnam 2000) erhielt man bei Volvo folgendes Ergebnis: Ausgehend von Applikationsgrößen mit ca. 50.000 Codezeilen und bei einer Auswertung von 2500 Projekten ergaben sich bei einem Wechsel von CMM-Level 1 auf CMM-Level 2 folgende Verbesserungen: x 17% Zeitersparnis x 46% Aufwandsersparnis x 51% weniger Fehler Eine weitere Verbesserung von CMM-Level 2 auf CMM-Level 3 verbessert gemäß dieser Studie die Aufwands- und Fehlersituation noch einmal um 50%.

Mehr als Methodenverbesserung Auch von IBM existieren vergleichbare Aussagen, deren Fokus ein wenig anders ausgerichtet ist als der eben beschriebene. Dort ging es um die Auswertung des hauseigenen „Rational Unified Process (RUP)“ und dessen Einfluss auf eine Verbesserung des CMM-Levels. In dieser Studie vom Dezember 2005 (Grundmann 2005) wurden die Schwierigkeiten, denen sich moderne Entwicklungsteams ausgesetzt sehen, noch einmal zusammengefasst. Insbesondere stehen dort die sich während der Entwicklung verändernden Anforderungen im Mittelpunkt. Anders als beim Haus- oder Brückenbau, bei dem fast alle Planungsaspekte rechtzeitig und stabil festgelegt werden können, ist dies beim Softwarebau bekanntlich nicht der Fall. Da zudem Software-Engineering eine recht junge und noch dazu hochdynamische Disziplin ist, kann auch nicht auf bewährte und stabile Vorgehensmodelle zurückgegriffen werden. Zwar haben sich „Best Practices“ etabliert, diese ersetzen aber letztendlich nicht Vorgehensmodelle mit vielen Jahrzehnten Hintergrunderfahrung! Unter anderem sind es diese Punkte, die einer Auswertung der Standish Group zufolge dazu führten, dass immer noch weit weniger als 50% aller Softwareprojekte als erfolgreich

3.1 Vom Maßstab aller Dinge

45

eingestuft werden können. Auch wenn hier ein Zeitraum zwischen 1994 und 2000 betrachtet wird (vgl. Abb. 3.2(A)), so wird deutlich: Softwareentwicklung steckt in einer Dauerkrise, aus der sie sich noch nicht wirklich befreit hat. Dabei gehen die Ursprünge dieser krisenhaften Situation bereits bis in die späten 60er Jahre zurück (vgl. S. 64 ff.) und wurden trotz vielfältiger Anstrengungen noch immer nicht wirklich überwunden. Es lohnt sich, an dieser Stelle noch ein wenig zu verweilen und eine ganz andere Sicht auf diese Dinge zu werfen. Mit dem Wissen, dass spätere Änderungen zunehmend teurer werden, und in Verbindung mit einer statistischen Auswertung von Barry W. Boehm, dem Altvater des Softwareprojektmanagements (vgl. Abb. 3.2(B)), ergibt sich folgende wichtige Beobachtung. Boehm wies mit seinen Studien nach, dass derjenige Faktor, der am meisten die Qualität (negativ) beeinflusst, immer noch der Mensch selbst ist: Menschliches Versagen, mangelnde technische Fähigkeiten und ungenügende Sachkenntniss sind gemäss seiner Studie die Hauptquellen für schlechte Endqualität von Software. Zusätzlich haben Teamfähigkeiten einen überdurchschnittlich starken Einfluss auf das Gesamtergebnis. In

Abb. 3.2. Auswertung von Projekterfolgen und -misserfolgen (A) sowie Faktoren, die dies beeinflussen (B)

46


Verbindung mit der Fehlerkostenregel (vgl. S. 25 ff.) ergibt sich hieraus ein äußerst wichtiger Zusammenhang. Wenn eine frühe Würdigung beobachteter Aspekte und Phänome das sehr viel größere Maß an negativen Folgekonsequenzen und Aufwänden in späteren Projektphasen minimieren, so ist es notwendig, Ursachenforschung der Hauptstörgrößen zu betreiben. Hiermit ist es möglich, statt dauerhafter Symptombehandlung auf echte Ursachenbehandlung umzuschwenken, und damit Probleme grundsätzlich an ihren Wurzeln zu bekämpfen und auszuräumen. Andersherum ausgedrückt: Was sind die Gründe und Mechanismen, die als Auswirkung z. B. mangelnde persönliche Fähigkeiten haben; welche Faktoren liegen der Teamproblematik zugrunde?

3.2 Softwerker Du kannst vor dem davonlaufen, was hinter Dir ist, aber was in Dir ist, das holt dich ein. (aus Afrika) Um der Aussage von Boehm auf die Schliche zu kommen, ist es sinnvoll, einen Blick auf viele derjenigen Zeitgenossen zu werfen, die noch vor wenigen Jahren Spitzenlöhne erhielten und denen das Arbeitsleben durch „Goodymen“ verschönt wurde. Es sind diejenigen, die in der Zeit des ITBooms Ende der neunziger Jahre und zu Beginn dieses Jahrhunderts von den Hochschulen weg äußerst lukrative Angebote erhielten, um Software zu schreiben. Es herrschte eine Stimmung ähnlich derjenigen zu Zeiten der großen Goldgräberperioden in den USA, wo man bereit war, für das Gold der Gegenwart (die Bits und Bytes) an die Clondykes der IT-Gesellschaft (heute sind dies die Silicon-Valleys dieser Erde) zu wechseln, um dort sein Glück oder Vermögen zu machen. Statt Spaten und Sieb führten sie die Nachweise über spezifische Softwaretechniken im Handgepäck. Inzwischen scheint diese Goldgräberstimmung in der Softwarebranche einer gewissen Ernüchterung und ingenieurmäßigen Versachlichung gewichen zu sein. Zwar sind noch immer Heerscharen an IT-Fachleuten weltweit in Bewegung, werden im Rahmen von Offshore-Projekten in andere Länder verschoben oder dort in Projekten eingesetzt, aber die Sturm- und Rangphase scheint vorüber zu sein. Was zählt, sind die kühlen Rechenstifte der Controller und die Zeiterfassung der Projektmanager. Es geht um Outputmaximierung und Kostensenkung. Dabei wird das Wissen um die einzusetzenden Techniken vorausgesetzt und mehr und mehr sind Prozesskenntnisse und effiziente Arbeitsmethodiken gefragt. Kurz: Für viele stellt sich eine Fließbandsituation ein, in der es darum geht, mit vorgegebener Taktrate definierte Softwarekomponenten zu erstellen und ingenieurmäßig zu dokumentieren.

3.2 Softwerker

47

Diesem Heer an Programmierern, Designern und Entwicklern steht eine kleine, oft überforderte Gruppe an Projektleitern gegenüber, die diese Truppen führen und formen sollen. Ihnen wird abverlangt, dass sie die gesetzten Projektziele pünktlich erreichen. Die Frage stellt sich, ob die beteiligten Akteure über die notwendigen Fähigkeiten verfügen, um den hohen Projekterwartungen gerecht zu werden. Dieser Frage möchte ich im späteren Verlauf dieses Buches nachgehen. Zunächst aber sehen sich alle Beteiligten einer riesigen Herausforderung gegenübergestellt.

Erfolgsdruck im Softwarebau Irrtümer entspringen nicht allein daher, weil man bestimmte Dinge nicht weiß, sondern weil man sie zu beurteilen unternimmt, obgleich man noch nicht alles weiß, was dazu gefordert wird. (Immanuel Kant) Jedes Softwareprojekt unterliegt einem ganz erheblichen Druck sowohl durch die Projektsponsoren wie auch Kunden. Oftmals gilt die entstehende Applikation als letzte Hoffnung, den eigenen Kostendruck zu senken oder mittels neuer Medien den eigenen Marktanteil auszubauen (z. B. InternetApplikationen). Daher müssen in möglichst kurzer Zeit brauchbare Anwendungen erstellt werden, die spezifische, allerdings komplexe Aufgaben übernehmen sollen. Dieser Druck, gepaart mit den bereits postulierten Versprechungen vieler Verkäufer, oftmals auf die Formel „Wir können alles – über Nacht“ reduziert, hat erhebliche Konsequenzen. Druck und Komplexität stehen meist im Widerspruch zueinander. Aus der Psychologie ist bekannt, dass Stress unsere Fähigkeiten zum komplexen Denken und Handeln einschränkt! Somit wird der oft gehörte und gut gemeinte „Ansporn“ vieler Manager zur Farce und hohe Qualität zum Paradoxon. Softwarebau ist sehr personalintensiv und damit teuer. Welcher Verantwortliche, der länger in der Branche tätig ist, hat nicht schon Projekte beerdigen müssen. Zugleich ist es ein riesiger Markt, auf dem allerdings Unsummen an Geld verbrannt werden. Für das Jahr 2001 belegen Statistiken, dass ca. 250 Mrd. US-Dollar Kapital eingesetzt wurden, um damit ca. 175.000 Applikationen zu erstellen. Für das besagte Jahr geht man davon aus, dass von der eingesetzten Summe ca. 140 Mrd. US-Dollar vergeudet wurden, weil Projekte sich verspäteten, gestoppt werden mussten oder außer Kontrolle gerieten. Somit hat statistisch betrachtet jedes Projekt durchschnittlich 1,4 Mio. US-Dollar gekostet, wovon 800.000 US-Dollar verloren gingen! – Für diesen Betrag hätten Sie sich beträchtliche Gewinnausschüttung oder Re-Invest leisten können. Stattdessen wurde Software-Bugs nachgejagt, schlecht definierte Anforderungen nachgebessert oder schlecht abgestimmte Komponenten neu implementiert.

48


3.3 Softwarekomplexität Wir vermarkten nicht bereits entwickelte Produkte, sondern wir entwickeln einen Markt für die Produkte, die wir herstellen. (Akio Morita, jap. Unternehmer) Es herrscht breite Übereinstimmung darin, dass sich Software vor allem durch ihre Komplexität auszeichnet. Dabei halten manche Fachleute Computerprogramme für das komplexeste Produkt des menschlichen Genius (Brooks 1995). Obschon der IT-Alltag dies zu bestätigen scheint, sind die Aussagen darüber, was diese Komplexität eigentlich ausmacht rar. Um hier einen Überblick zu erhalten, gehe ich im Folgenden von einer wissenschaftlichen Arbeit über Softwarekomplexität von Nystedt (Nystedt und Sandros 1999) aus, die in ihren Grundaussagen immer noch ihre Gültigkeit hat. Bereits Konrad Zuse stellte sich der Komplexitäts-Thematik, indem er diese durch das Maß an Schwierigkeit zu beschreiben versuchte, das man zu überwinden habe, um ein softwarerelevantes Problem zu analysieren, es danach zu kodieren bzw. zu modifizieren und es darüber hinaus in Betrieb zu halten. Der Ansatz von Nystedt ist hier klarer: Bei ihm erfolgt eine Aufspaltung zwischen der innewohnenden Komplexität des Problems und der Komplexität der Lösung. Beide sind über eine schrittweise Transformation, den eigentlichen Engineeringprozess, miteinander verbunden. Für mich stellt sich Softwareproduktion aus Engineeringsicht, wie in Abb. 3.3 wiedergegeben, dar. Innerhalb der Prozesskette gibt es verschiedene Schritte, über die das Problem in eine Lösung transformiert wird. Dabei habe ich in diese Grafik nur diejenigen Aspekte aufgenommen, die aktiv zur Umwandlung in das Produkt beitragen. In diesem Sinne gehören z. B. Testen oder Konfigurationsmanagement auf die passive Seite. Hierbei sind die passiven Aspekte in keiner Weise unwichtiger als die aktiven; sie tragen nur weniger oder gar nicht zu dem eigentlichen Transformatioinsprozess während der Softwareerstellung bei. In den aktiven Schritten wird das vorhandene Problem schrittweise analysiert und in eine Form der Beschreibung überführt. Ähnlich, wie bei dem Kinderspiel „Stille Post“7 wird etwas in einer ersten Vorstellungswelt wahrgenommen, entsprechend den eigenen Paradigmen interpretiert und in einer anderen Vorstellungswelt wiedergegeben. Diese Vorgehensweise wiederholt sich über alle beteiligten Teilschritte. 7

Bei dem Kinderspiel „Stille Post“ flüstert der Erste seinem Nachbarn leise ein Wort ins Ohr, der wiederum flüstert das, was er verstanden hat, dem nächsten Nachbarn ins Ohr etc. Der letzte Spieler in dieser Reihe wiederholt das Wort laut für alle.

3.3 Softwarekomplexität

49

Abb. 3.3. Software-Engineering gesehen als Transformation von Komplexitäten

3.3.1 Verursacherprinzip Ein Beispiel: Der Requirementsingenieur muss die Wissensdomain des Auftraggebers sehr gut kennen, damit er weiß, wovon dieser redet. Gleichzeitig muss er aber auch sein Gegenüber hinreichend genau wahrnehmen, damit der weiß, was diese Person spezifisch möchte. Nur die Wissensdomain zu kennen oder sich nur auf die jeweilige Person einzustellen wird dazu beitragen, das Problem verstümmelt aufzunehmen. Aus dieser Gesamtsicht betrachtet, hat dies später zur Folge, dass Dinge – gerade auch in nachgeordneten Prozessschritten – komplizierter werden. Als Nächstes muss derjenige, der die Anforderungen bearbeitet, sich ein eigenes mentales Bild davon machen, was er aufgenommen hat. Wurde das Problem tatsächlich verstanden? Liegen die eigenen domainspezifischen Paradigmen dicht genug an denen des Auftraggebers? In diesem inneren Prozess kann es zu weiteren Verkomplizierungen des eigentlichen Problems kommen, da Abweichungen nicht (rechtzeitig) erkannt bzw. korrigiert werden. Der dritte Teil betrifft die Weitergabe des erarbeiteten Themenkreises: In welcher Darstellungsform (Text, Tabellen, Grafiken) oder sprachlichen Form und mit welchen Begrifflichkeiten können die Inhalte so beschrieben werden, dass die nachgeschaltete Instanz diese eindeutig versteht? Wie groß ist das gemeinsame Verständnis mit den Inhabern des nächsten

50


Prozessschrittes und wie werden dessen fachliche Inhalte sauber von den eigenen getrennt, sodass Verwaschungen der Teiltransformationen möglichst klein gehalten werden können? Auch hier birgt jeder Teilaspekt die Gefahr in sich, halbverstandene Aufgaben durch schlechte Formulierungen und uneindeutige Begrifflichkeiten weit weg von der Ursprungsfragestellung zu führen. Dies sorgt dafür, dass bei Erkennen von Unzulänglichkeiten nachgebessert und geflickt werden muss, was jeweils eine Steigerung der Komplexität und zugleich der internen Unordnung zur Folge hat. Somit kann Komplexität in direkten Bezug zum vorliegenden Maß an Unordnung gesetzt werden: Vergleicht man zwei gleich große Projekte, so wird das Projekt mit größerer struktureller Unordnung auch die größere Komplexität aufweisen und demzufolge auch fehlerträchtiger sein. 3.3.2 Intellektuelle Phasen Intelligenz lässt sich nicht im Weg, sondern nur am Ergebnis feststellen. (Garry Kasparow) Im Rahmen der Kognitionswissenschaften, die sich interdisziplinär vor allem aus Psychologie, Philosophie, Neurophysiologie, Linguistik und KIForschung zusammensetzt, sucht man die natürlichen Denkprozesse zu ergründen, um diese mit maschinellen Datenverarbeitungsprozessen vergleichbar zu machen: Mensch und Computer haben dabei gemeinsam, dass sie als sogenannte Informavoren, also „Informationsfresser“ (Wegener 2001), Informationen aufnehmen und diese weiterverarbeiten. Die Maschinen – oder besser gesagt die Programme, welche die Maschinen steuern – sind darauf angelegt, Informationen aufzunehmen und diese unter Berücksichtigung der Begleitumstände zu transformieren. Dies kann eine simple mathematische Formel sein, aber genauso kann es sich um einen komplizieren Steuer- und Regelungscomputer handeln. Softwarebau bildet hierbei eine wichtige Brücke zwischen diesen Welten, da mit Hilfe der kognitiven Prozesse des Menschen strukturiert die quasikognitiven Prozesse eines bestimmten Programms geplant und realisiert werden. Es liegt daher nahe, die von dem Psychologen und Informatiker David Marr aufgestellten Grundlagen der Kognitionswissenschaften, wie er sie in seinem Buch „Vision“ (Marr 1983) beschrieb, mit den für den Softwarebau notwendigen kognitiven Schritten in Bezug zu setzen. Marr, der als Vater der künstlichen Intelligenz gilt, beschreibt in diesem Werk über das visuelle System des menschlichen Gehirns drei Ebenen des Wahrnehmungs- und Verarbeitungsprozesses.


51

Rechenebene (computational level). Hier wird festgelegt, wofür ein informationsverarbeitender Prozess dient und welches die Prozessschnittstellen nach außen sind. Und wofür bestimmte Aufgaben wichtig sind. Repräsentation (algorithmic level). Hier wird nach den eigentlichen Verarbeitungsschritten und den damit verbundenen Regeln bzw. Transformationen gefragt. Wie kann also die Strategie der Rechenebene implementiert werden, d. h., wie können genau Eingangs- und Ausgangsdaten dargestellt werden und wie lautet der Algorithmus, der die Eingangsdaten in die Ausgangsdaten transformiert? Realisierung. Als Letztes folgt die Ebene der pysikalischen Realisierung. Alle drei Regelebenen sind lose miteinander gekoppelt und stehen demzufolge in Bezug zueinander. Will man wissen, warum ein Vogel fliegt, so reicht es nicht aus, die Anatomie eines Flügels zu bestimmen, vielmehr braucht man parallel dazu auch die Gesetze der Aerodynamik, um dieses zu verstehen. Geeignetes Parallelwissen ist also notwendig, um den gesamten Vorgang hinreichend zu verstehen und dann auch nachbauen zu können. Übertragen auf den Softwarebau sind es genau diese Schritte, die vollzogen werden müssen, um eine Fragestellung auf einem technischen System abzubilden! Ein Transformationsprozess ganz ähnlicher Art muss also während des Softwarebaus vollzogen werden. Dabei müssen jeder der genannten Transformationsstufen spezifische intellektuelle Leistungen zugeordnet werden, die wiederum für die jeweilige Folgestufe notwendig sind. Diese Stufen – und das wird anhand von Abb. 3.4 deutlich – überschneiden sich in einem gewissen Maß. Erst muss der inhaltliche Rahmen des Projektes mitsamt seinen Anforderungen und Abläufen erforscht sein. Daran schließt sich die eigentliche „Erfindung“ einer hierfür geeigneten technischen Gesamtlösung, nämlich die Erstellung von IT-Architektur mit Prototypen oder Pilotprojekten, an. Zuletzt kommt es zur Erstellungsphase, in der die Realisierung des Ganzen stattfindet. Jede dieser Phasen grenzt sich spezifisch gegen die nächste Phase ab. Ist der Schwerpunkt bei der „Erforschung“ in der Grenzziehung und vollständigen Erfassung des realen Problems zu suchen, so zeichnet sich die zweite Phase, „Erfindung“, durch Kreativität und technischen Weitblick aus. Hier entsteht entweder ein technisches Konzept, das, falls nicht weitsichtig genug geplant, in der Entwicklung und im Verlauf des eigentlichen Softwarelebens viele Folgeprobleme und -kosten nach sich ziehen wird. Als Beispiel sei hier an spätere Erweiterungen der Software erinnert. Dies ist übrigens die Phase, in der die eigentlichen Innovationen in eine entstehende Software gelangen. Es ist der Zeitpunkt, zu dem z. B. folgende Aspekte eingebracht und geklärt werden müssen: Ist es möglich,

52


den Auftraggeber von der Nutzung moderner Interaktionsschnittstellen zu überzeugen, oder können neue Produktionsverfahren ins Projekt eingebracht werden. Kurz: Das, was hier in das Projekt durch IT-Architekten eingebracht wird, hat eine ganze Menge Ähnlichkeiten mit dem, was Namenskollegen aus dem Baufach tun. Hier entscheidet sich, ob es ein Standardgebäude von der Stange geben wird oder ob eine geniale Konstruktion das Licht der Welt erblickt. Somit ist diese Phase im Idealfall neben technischem Wissen und Erfahrung geprägt durch echte Kreativität und Innovation. Gerade die beiden letztgenannten Aspekte sind dabei Faktoren, die den Komplexitätszuwachs des Gesamtsystems gering halten können, vielfach aber klar unterschätzt werden. Die letzte Transformationsstufe ist die „Erstellung“. Auch sie zeichnet sich durch ganz eigene Fähigkeiten aus. Hier geht es an erster Stelle um „handwerkliches“ Können, um Genauigkeit und Korrektheit, somit also um Qualitätsarbeit. Zuletzt noch eine Anmerkung zu den Übergängen zwischen den Transformationsphasen. Wie anhand von Abb. 3.4 deutlich wird, sind die Übergänge zwischen den Phasen sensible Punkte. Hier sind die wechselseitigen Abhängigkeiten am stärksten ausgeprägt. Schlecht vollzogene Übergänge von einer Phase zur nächsten erfordern Nacharbeiten und somit unerwartete Kosten, zusätzliche zeitliche Aufwände, Qualitätsverluste und vor allem Komplexitätssteigerungen.

Abb. 3.4. Die intellektuellen Phasen im Softwarebau


53

3.3.3 Formen der Komplexität Somit trägt jeder aktive Teilschritt im Sinne der Fehlerfortpflanzung multiplikativ dazu bei, dass die Komplexität des Endergebnisses steigt. – Nachdem die Verursacher identifiziert worden sind, ist zu fragen, in welchen Aspekten sich diese Komplexität niederschlägt. Diese lässt sich auf vier wesentliche Bereiche herunterbrechen (Nystedt und Sandros 1999): Problemkomplexität. Hier geht es um die Komplexität des eigentlichen Problems. Die Komplexität eines Taschenrechners mit mathematischen Grundfunktionen ist mit Sicherheit erheblich geringer als diejenige eines Flugplanungsprozesses. Strukturelle Komplexität. Wie sieht die IT-technische Gesamtlösung aus. Bedarf es nur einer Java-Installation auf einem beliebigen Rechner oder müssen viele technische Geräte über Interfaces, Queues miteinander in Bezug gesetzt werden? Algorithmische Komplexität. Dahinter verbirgt sich die Kompliziertheit des zu implementierenden Lösungsweges. Wie sauber strukturiert ist der Code oder wie sehr entspricht er eher einem wilden Gestrüpp sich gegenseitig aufrufender Funktionalitäten? Kognitive Komplexität. Dieser Punkt bezieht sich auf den Aufwand des Anwenders, das fertige Programm in seinen Funktionen zu verstehen und zu bedienen. Hier stehen also sehr stark wahrnehmungspsychologische Aspekte im Mittelpunkt, die einen direkten Bezug zur Informationsarchitektur des Benutzerinterfaces haben.

Die Größe der Software Die Problemkomplexität hat einen direkten Bezug zur Größe der projektund softwaretechnischen Lösung. Komplexe Projekte brauchen mehr Arbeitsstunden und mehr Rechenleistung. Dabei ist es in einem gewissen Maß möglich, diese Arbeitsvolumina zwischen Menschen und Maschinen hin- und herzuschieben: Schlecht konstruierte Software in einem armseligen Entwicklungsumfeld wird erheblich mehr Arbeitsmonate binden als durchdachte Software in einem hochmechanisierten Entwicklungsumfeld. Im zweiten Fall werden die Rechner erhebliche Leistungen innerhalb des jeweiligen Projekts automatisch abarbeiten, ohne dass Menschen hier noch händisch eingreifen müssten (vgl. Volvo-Studie, S. 44). Auch hier gibt es mehrere Bereiche, die davon direkt beeinflusst sind. So betrifft es die Testbarkeit und Wartbarkeit der Software. Große und

54


unübersichtliche Software ist nahezu untestbar und kann nur mit erheblichen Aufwänden in Betrieb gehalten werden. Des Weiteren existiert ein Bezug zwischen Performance und Codegröße. Fast immer stehen große Codemengen in reziprokem Verhältnis zur Performance. Der wohl wichtigste Faktor an dieser Stelle ist jedoch der Mensch selbst: Aufgrund seiner eigenen intellektuellen Grenzen wird die Quote an Fehlern in neuem oder geändertem Code proportional zur Größe der gesamten Codebasis stehen. Ursache hierfür ist, dass die Entwickler bei ihrer Arbeit sowohl die Zusammenhänge wie auch das vorhandene Material im Blick haben und verstehen müssen, was bei großen und ausufernden Projekten im schwieriger wird bzw. nur mit sehr viel Erfahrung erreicht werden kann.

Fehlerhaftigkeit der Software Somit ist ein Softwarebug die Folge eines menschlichen Fehlers während der Softwareentwicklung. Bedingt durch die strukturelle und algorithmische Komplexität wurde etwas übersehen oder nicht klar genug kommuniziert. Infolgedessen wird die Software irgendwann in einer bestimmten Konstellation sich nicht so verhalten, wie es geplant wurde oder durch Nebenbedingungen nicht zugelassen ist (z. B. eine Division durch den Wert 0). Die Folge ist eine Fehlfunktion, die im Zweifelsfalle dem Benutzer einen Programmabsturz beschert. Kompliziertheit und fehlerträchtige Komponenten stehen dabei in direktem Bezug zueinander. So gibt es mindestens drei Abhängigkeiten zwischen „buggy code“ und Qualität, nämlich die Nutzbarkeit der Software (erfüllt nicht den erwarteten Zweck), die Zuverlässigkeit (stürzt zu oft ab) und die Nachbesserungswürdigkeit (viele Fehler generieren viele Trouble-Tickets und diese wiederum viele Zusatzaufwände für den Hersteller) – besonders der letzte Punkt hat zur Folge, dass die Produktivität der eigenen Organisation sinkt, da man Fehler beseitigen muss und sich nicht um neue Aufträge kümmern kann. 3.3.4 Nutzbarkeit der Software Zwar kann kognitive Komplexität direkt mit der Nutzbarkeit der Anwendung in Bezug gesetzt werden, aber es gibt weitere Faktoren, die letztendlich nur individualpsychologisch zu verstehen sind. Dies hat sehr viel mit der Wahrnehmung des Ganzen zu tun, also der Frage, wie intuitiv oder kompliziert, wie arbeitserleichternd oder verspielt diese Software vom Anwender wahrgenommen wird. Somit wird gerade die Berücksichtigung der menschlichen Wahrnehmung zu einer notwendigen Vorgabe. Wie sonst lässt sich erklären, dass sich tief im Inneren eines Tabellenkalkulationsprogramms ein


55

Abb. 3.5. Abhängigkeitsmodell zur Softwarekomplexität nach Nystedt

Flugsimulator8 versteckte? Programme erhalten somit die persönliche Note des Entwicklers, was schön für die persönliche Individualität, schlecht aber für die Vermeidung von zusätzlichen Komplexitäten ist. So betrachtet bewegen wir uns hier auf einer Grenzlinie. Computer „handeln“ in diesem Sinne menschlich, einfach weil Menschen mit ihren Fähigkeiten, Denkweisen und Vorstellungswelten diesen Systemen mit Hilfe von Programmiersprachen ihre eigene Paradigmenwelt ein Stück weit übersetzen. Abbildung 3.5 fasst die auf den letzten Seiten formulierten Abhängigkeiten des mehr ingenieurwissenschaftlichen Teils noch einmal zusammen. Dabei stehen verschiedene Arten von Metriken zur Verfügung, mit deren Hilfe Quantifizierungen zu verschiedenen Aspekten der Komplexität möglich werden. Im Einzelnen sind diese in den folgenden Bereichen zu finden (Nystedt und Sandros 1999): x Kosten und Aufwandsabschätzungsmodelle x Produktionsmodelle und deren Bewertung 8

Für den Fall, dass Sie dies nicht glauben wollen und Sie Microsoft Excel’97 besitzen, kommt hier der Beweis: Starten Sie Excel’97 neu, öffnen Sie ein neues Dokument, drücken Sie F5, eine Referenzbox öffnet sich, tragen Sie X97:L97 ein und drücken Sie die ENTER-Taste. Drücken Sie dann die TABTaste, so dass der Cursor in Zelle M97 springt. Drücken Sie nun noch auf den Wizard-Button, um Charts zu erstellen, während Sie die Tasten Shift und Ctrl gedrückt halten. … Guten Flug!

56


x Qualitätsmodelle und deren Bewertung x Modelle über die Zuverlässigkeit des Produktes x Struktur und Komplexitätsmetriken

3.4 Interaktives Arbeiten Ich möchte nun zwei bereits angerissene Aspekte näher betrachten, da diese in direktem Bezug zu den Aussagen von Barry W. Boehm über Projekterfolge stehen (vgl. S. 45). Dazu war in den Erläuterungen zu Abb. 3.3 die Rede davon gewesen, dass der Transformationsprozess zwischen Problem und Produkt stufenweise stattfindet. Ich hatte Ihnen die Einzelschritte exemplarisch am Anforderungsmanagement vorgestellt und hatte von den Kommunikationshürden zwischen den einzelnen Prozessschritten gesprochen. Was dort nicht zur Sprache kam, waren Interkommunikationsaspekte zwischen den Transformationsnachbarn. Offen ist dabei die Frage geblieben, ob es ausreicht, gleiche Begrifflichkeiten (z. B. mit Hilfe eines Glossars) auszuhandeln oder ob hier deutlich mehr getan werden muss, um die Komplexität an diesen Schnittstellen möglichst gering anwachsen zu lassen. Das Zweite ist der Fall! Somit ist das wechselseitige Aushandeln von Regeln, das Nachfragen oder auch Optimieren von Teilaspekten durch Kommunikation äußerst wichtig. Dabei handelt es sich um rein psychologische Aspekte, die etwas mit interpersoneller Kommunikation zwischen den beteiligten Personen zu tun haben und nicht dadurch gelöst werden, dass unreflektiert zu einem wie auch immer gearteten Kommunikationstool gegriffen wird, egal ob es sich hierbei um E-Mails, ContentManagement-Systeme oder Collaboration-Tools handelt. Entscheidend ist dabei die Tatsache: je unzureichender diese Kommunikationsprozesse ablaufen, umso weiter divergiert die ursprüngliche Aufgabenstellung vom Ziel. An diesen Bruchstellen wird folglich umso stärker Komplexität in ein solches Gesamtsystem eingebracht werden. Hierdurch wird wiederum einem „Flickwerk“ Vorschub gegeben, wie es bereits an anderer Stelle diskutiert wurde. Hätte Software so etwas wie eine Motorhaube, die man öffnen kann, so würde sicherlich so mancher Auftraggeber erschrocken zurückweichen, ob all der Provisorien, freien Verdrahtungen und improvisierten Verbundstücke. Iterativ-inkrementelle Prozessmodelle haben den letzten Punkt aufgegriffen und versuchen ihn entsprechend prozessual abzubilden. Mit Blick auf Abb. 3.6 lassen sich zusammenfassend mehrere Aussagen treffen: Um aus einem Problem (= Aufgabenstellung) des Auftraggebers eine Lösung (= die Software) zu erstellen, die dem Anspruch genügt, für möglichst geringen Zuwachs an Komplexität zu sorgen, ist ein Transformationsprozess (= Softwareentwicklungsprozess) notwendig, dessen Schwerpunkte

3.4 Interaktives Arbeiten

57

Abb. 3.6. Zyklischer Arbeitsprozess zur Vermeidung von unnötigen Komplexitäten

auf ganzheitlichem Wissen in den einzelnen Teiltransformationen sowie einer hochentwickelten Kommunikationskultur beruhen müssen. Vorgehensweisen, die darauf basieren, dass die eigene Arbeit an die nächste Instanz „abgeworfen“ wird, entsprechen demzufolge diesen Forderungen nicht. – Hierbei wird deutlich, dass die jeweilige Vorstufe aktiv über die Komplexität der Folgestufe nachdenken muss, da sich andernfalls systematische Fehler durch alle Transformationsstufen hindurch kumulieren. – Dies macht übrigens die ganze Thematik Offshoring äußerst interessant, da aufgrund der räumlichen Trennung noch größeres Augenmerk auf die Schnittstellen zwischen den Teiltransformationen gerichtet werden muss. 3.4.1 Wertschöpfungskette Software-Engineering geschieht zum Zwecke des Geldverdienens. Organisationen bieten ihre Dienste an, um den oben beschriebenen Transformationsprozess im Kundenauftrag durchzuführen. Da es hier um Geld, um sehr viel Geld geht, muss die Frage grundsätzlich beantwortet werden, in welcher Form die eigentliche Wertschöpfung erfolgt. – Um es nicht zu kompliziert zu machen: Es herrscht allgemeine Einigkeit darüber, dass die Wertschöpfung in der Herstellung von Ablaufsteuerungen (= Software) für definierte Aufgaben besteht. Somit wäre das Ende dieser Wertschöpfungskette nichts anderes als eine Sammlung (digitaler) Artefakte, die an den

58


Kunden gehen. Sie könnten nach Volumen bemessen und entsprechend ihrer spezifischen Aufgaben unterschieden werden. Unter diesen Artefakten würde es dann auch solche geben, die den Titel „Programmcode“ für eine spezielle Systemplattform tragen. Ein weiteres Artefakt kann die Bedienungsanleitung sein usw. Im Sinne industrieller Wertschöpfung reicht eine solche Umschreibung nicht, da es nicht um eine mengenmäßige Quantifizierung, sondern um eine qualitative Bewertung geht. Dies ist z. B. im Automobilbau ganz anders (Womack und Jones 2005). Hier lassen sich solche Wertschöpfungsketten eindeutig beschreiben und anschließend optimieren. Nehmen Sie z. B. ein Stück Glas, das schrittweise zu Sicherheitsglas veredelt wird, um am Ende zu einer Frontscheibe für einen ganz speziellen PKW-Typ verwendet werden zu können. Im Gegensatz dazu ist das Material der IT letztendlich stets gedanklicher Natur, das z. T. in Dokumenten als Regeln, Beschreibungen oder Spezifikationen niedergelegt wurden aber nach wie vor zum größeren Teil in den Köpfen der Beteiligten existiert. Dieses „Ausgangsmaterial“ ist damit in hohem Maße flüchtig bzw. intransparent. Möchte man nun in der IT zu einer höheren Produktivität und somit zu einem besseren Kosten-Nutzen-Verhältnis kommen, so muss die Frage nach der Wertschöpfung und deren Bewertbarkeit als Erstes beantwortet werden. Erst dann ist man in der Lage, unter Beibehaltung oder Steigerung dieser Größe zu kostengünstigeren Produktionsverfahren zu gelangen. Aus diesem Grunde ist die Qualität der eigentlichen Softwarefertigung in der Effizienz der betrachteten Transformationsschritte zu suchen. 3.4.2 Fertigungsstufen der IT Damit jede dieser „Fertigungsstufen“ eine möglichst hohe Qualität erzeugt – und gleichzeitig hocheffizient arbeitet –, muss also die Effizienz der Transformationen ins Auge gefasst werden. Am Beispiel der Glasscheibe in der Autoindustrie ist das leicht ersichtlich: Hier gibt es große Maschinen, die das Glas heiß machen, es verkleben, es in Form schneiden oder biegen. Dabei sind die Geräte das Mittel zum Zweck, um schnell und kostengünstig zu den gewünschten Stückzahlen zu gelangen. Im Software-Engineering ist dies nicht ganz so leicht ersichtlich. Die hier eingesetzten Transformatoren sind nämlich in erster Linie die intellektuellen und sozialen Leistungen der jeweils beteiligten Menschen in den jeweiligen Prozessschritten. In der Terminologie von oben gesprochen: Da die wichtigsten Leistungen nicht durch Kraftmaschinen (z. B. Glaspressen) erbracht werden, muss eine Fertigungsoptimierung in der IT neben der Unterstützung durch geeignete Werkzeuge vor allem die Optimierung des wichtigsten „Produktionsfaktors“, nämlich des Menschen, im Auge haben.

3.5 Digitale Geschichte

59

Hier aber herrscht vielfach ein gedankliches Ausweichen auf Prozesse und Werkzeuge. Um diese Prozesse zu unterstützen, werden Hilfsmittel aller Art wie z. B. UML oder Tools zur Erfassung der Anforderungen eingesetzt. Der wichtigste Faktor in seiner spezifischen Form wird jedoch häufig zu wenig beachtet, obschon die bereits zitierten Untersuchungen die ITMitarbeiter als schwächstes Glied in der Kette ausweisen. Wenn Softwareentwicklung von unnötiger Komplexität abspecken soll, so ist genau hier der Hebel anzusetzen. Warum sich die IT hier schwer tut, stärker in diese Richtung zu schauen, hat u. a. historisch gewachsene Gründe. Diese möchte ich mit Ihnen im folgenden Kapitel näher erörtern.

3.5 Digitale Geschichte Lassen Sie mich dieses Kapitel mit einer Geschichte beginnen, die zwar mit Hightech, aber nicht direkt mit der IT zu tun hat! Es ist die Beziehung zwischen dem Spaceshuttle und einem römischen Pferdewagen. Indem ich Ihnen diese Zeilen als Einstieg in die Historie wiedergebe, möchte ich Sie für wenigstens einen Punkt sensibilisieren: Sind Sie sich bewusst, dass viele heute vorhandenen Paradigmen und Modelle historisch gewachsen sind und dabei in Zeiten entstanden, als bestimmte Maschinenleistungen oder auch Erkenntnisse noch nicht vorlagen. Diese Ansätze wirken vielfach bis heute. Nicht selten werden sie wie Ikonen behandelt, die nicht hinterfragt werden dürfen. (Sätze wie: „Wir wollen nur ganz klassisch Software bauen und nicht so viel Innovation in diesem oder jenem Bereich“ sind hier meistens recht gute Indikatoren.) – Hier also die Geschichte: 3.5.1 Was Römer mit Hightech verbindet Fast überall in der Welt haben Eisenbahnen eine Standardspurweite von 1,485 mm oder 4 Fuß und 8,5 Zoll. Das ist eine sehr seltsame Zahl. Warum wurde diese Spurweite verwendet? Die ersten Eisenbahningenieure kamen aus England und von dort kannten sie diese Spurweite. Wie kamen nun die Engländer auf dieses Maß? Die Handwerker, die die Eisenbahnwaggons bauten, waren dieselben, die auch Kutschen und Karren bauten und da war diese Abmessung üblich. Aber warum hatten die Kutschen dieses seltsame Maß? Nun hätten sie ein anderes gehabt, wären sie auf den damaligen Straßen sehr schnell zerbrochen. Es war genau der Abstand zwischen den Spurrillen auf den Fernstraßen. Und wer baute diese alten, zerfurchten Straßen? Die ersten Fernverkehrsstraßen in Europa (und England) wurden vom kaiserlichen Rom für seine Legionen gebaut. Da die römischen Streitwagen alle ziemlich ähnlich konstruiert waren, kerbten sie

60


allmählich in die Straßen Spurrillen ein. Um keinen Radbruch zu erleiden, musste sich jeder Straßenbenutzer dieser Spurweite anpassen. Die Standardspurweite der Eisenbahn leitet sich also von den Abmessungen der römischen Streitwagen ab! Und die römischen Streitwagen wurden so breit gebaut, dass zwei Pferdehintern bequem hineinpassten. – Wenn wir ein Spaceshuttle auf seinem Startplatz betrachten, sehen wir links und rechts die zwei Feststoff-Booster. Sie werden von der Thiokol-Fabrik in Utah hergestellt. Vielleicht hätte der Entwurfsingenieur sie gerne etwas dicker gehabt, aber auf dem Weg von der Fabrik zum Startplatz werden die Booster mit dem Zug befördert. Die Eisenbahnlinie muss auf ihrem Weg durch einen Tunnel fahren. Der Tunnel ist etwas weiter als die Gleise und die Gleise sind so breit wie zwei Pferdehintern. Das heißt, ein wesentliches Element des fortschrittlichsten Transportmittels unserer Zeit wurde schon vor zweitausend Jahren durch die Breite eines Pferdehinterns festgelegt. (n.n. 2003) 3.5.2 Über die Pferdehintern der IT Als Nächste werde ich mit Ihnen einen Blick auf den „Siegeszug“ der EDV werfen. – Zunächst: Tatsache ist, dass in sehr wenigen Jahrzehnten technische Maschinen entwickelt und gebaut wurden, deren Rechenleistung – pro Stück gesehen – größer ist als die gesamte Rechenleistung, die für eine erste Landung auf dem Mond zur Verfügung stand. Der Computer der Mondlandefähre Apollo hatte 1969 einen Hauptspeicher von 77.832 Bytes! – Auch Bill Gates war Anfang der 80er Jahre noch der Überzeugung gewesen, dass 640 KB für jeden Rechner ausreichend Speicherkapazität sein müssten. Heute stehen in fast jedem Kinderzimmer PCs mit mindestens 64 MB. Beeindruckend – gleichzeitig aber auch erschreckend: Eine geballte Power an Rechenleistung mit immer schnelleren Chips, immer kürzeren Arbeitszyklen und immer komplexeren Abläufen mechanisiert unser Leben. Was aber sind trotz dieser enormen Leistungsdaten die uralten Aspekte. Wenn ich von uralt spreche, so beziehe ich mich auf alles, was in und nach dem 2. Weltkrieg entstand. Sollten Sie weiterführende Ambitionen in die Geschichte haben, so habe ich Ihnen hierzu am Ende dieses Kapitels einige Quellen zusammengestellt.

ENIAC Die ENIAC war der erste echte Digitalcomputer ohne mechanische Bauteile. Mit seinen 18.000 Radioröhren, verstaut in 40 schwarzen Wandschränken hatte er eine enorme Heizleistung. Dieses Maschinenmonster wurde den ersten Programmierern zur Verfügung gestellt, ohne dass diese über Anleitungen oder Handbücher verfügten. Ihr Job war echte Knochenarbeit


61

und so wundert es nicht, dass in den Stellenausschreibungen Personen gesucht wurden, die bereit waren, schwere körperliche Arbeit zu leisten, dabei aber geistig kreativ und vor allem aber geduldig sein sollten. – Diesen Personen oblag es, die ca. 3000 Schalter, Dutzende von Kabeln, Speichereinrichtungen und anderen Bauteilen manuell so zu verbinden, dass am Ende mit Hilfe dieses Monstrums ballistische Flugbahnen berechnet werden konnten. – Eine Sache, die Sie heute auf jedem noch so alten PC mit einer geeigneten Programmiersprache und den notwendigen physikalischen Vorkenntnissen in kürzester Zeit selbst absolvieren könnten!

UNIVAC Nach dem 2. Weltkrieg entstand mit der UNIVAC der erste allgemein nutzbare Computer. Diese Maschine musste durch diskrete Schalterstellungen dazu gebracht werden, bestimmte Handlungsschritte zu vollziehen. Eine damals noch junge Programmiererin namens Betty Holberton arbeitete in diesem Projekt mit. Diese Frau leistete im Laufe der 50er Jahre wichtige Beiträge zur Entwicklung der Programmiersprachen und der damit fortschreitenden Trennung von Hard- und Software. 1952 entwarf und programmierte sie für die UNIVAC den „Sort-MergeGenerator“, ein geradezu legendäres Programm, das zur effizienten Umsortierung riesiger Datenmengen aus Verwaltungsanwendungen genutzt wurde. Das Programm gab ein Ablaufschema zum Sortieren vor, in dem andere Programmierer nur noch einzelne Parameter festlegen mussten. Das Generator-Programm produzierte daraus das spezielle maschinensprachliche Programm zum Sortieren, Mischen und Speichern bzw. Laden. Damit hatte Holberton die komplexen Sortierprobleme vollständig beschrieben und es war klar, dass Computer tatsächlich zum Schreiben von Programmen genutzt werden können. Es entstanden weitere Generatoren und irgendwann kam der Wunsch auf, den Code anderer im eigenen Kontext nutzen zu können. – Eine gemeinsame Kunstsprache musste hierfür geschaffen werden. Nach Ende des 2. Weltkriegs entstand so der C-10Steuercode, mit dessen Hilfe die Ablaufsteuerung des ersten tastaturgetriebenen Computers möglich werden sollte. Statt wie bisher mit Schaltern und Wählscheiben die Befehle an die Maschine abzusetzen, hatte man nun eine Schreibmaschinentastatur, über die man all diese Anweisungen zentral an das Gerät senden konnte.

Software – ein eigenes Arbeitsfeld Seit Ende der 50er Jahre war Software zu einem zur Hardware komplementären Forschungs- und Arbeitsfeld herangewachsen. Es wurden Programmiersprachen bzw. Übersetzerprogramme entwickelt, Betriebssysteme gebaut

62


und vor allem Anwendungssoftware implementiert. Mit Hilfe von standardisierten Programmen konnte man vor allem im Versicherungs- und Bankenbereich frühzeitig fertige Software von Drittanbietern erwerben. Schnell gab es Firmen in Amerika, die über 1000 Programmierer – Männer wie Frauen – beschäftigten. Auch im Bereich kleiner und mittlerer Unternehmen entstanden neue Möglichkeiten. Software- und Beratungshäuser fanden immer neue Aufgaben und boten ihre Dienste beim EDV-Einsatz an. Diese neuen Tätigkeitsfelder drängten in den späten fünfziger Jahren auch immer mehr nach Deutschland und ließen hier eine vergleichbare Infrastruktur wie in den USA entstehen. Insgesamt setzte ein Boom auf immer neue Softwareapplikationen ein, da man immer mehr erkannte, wo diese programmierbaren Rechenmaschinen eingesetzt werden konnten. Bis Mitte der 60er Jahre setzte sich dieser Trend recht reibungslos fort: Man hatte gelernt mit der Programmierung von bis zu 10.000 Codezeilen gut zurechtzukommen. – Mehr und mehr bürgerte sich der neue Begriff „Software“ ein. Es gab allerdings keine klare Abgrenzung zwischen den Maschinen und deren Programmen.

Probleme kündigen sich an Zur selben Zeit war aber auch die Leistungsfähigkeit der Hardware um das Zehnfache gestiegen. Damit erreichte man Grenzen bei der Codegenerierung, die nicht mehr dadurch hinausgeschoben werden konnten, indem man die Zahl der Programmierer in einem entsprechenden Projekt drastisch erhöhte. Durch die immer leistungsfähigeren Maschinen drang man in Bereiche vor, für die man bis dahin keine Vorgehensweisen und Antworten hatte. Mehr und mehr wurde klar, dass die Entwicklung der Software nicht nur virtuoses Programmieren möglichst ausgefeilter Algorithmen umfasste, sondern dass man lernen musste, diese Komplexität als Ganzes zu beherrschen. Es wurden erste organisatorische Arbeitsteilungen notwendig, neue Teamstrukturen entwickelten sich und man fing an, sich in neuer Weise mit dem Thema Qualität auseinander zu setzen. Kurz: Die Komplexität dieser Materie gewann einen Umfang, der an immer mehr Stellen schmerzlich spürbar wurde und die Arbeiten behinderte. Unterstützt durch Wissenschaft und Industrie begann man einen theoretischen Unterbau zur Programmierung zu entwickeln. Algorithmentheorie oder strukturierte Programmierung hielten Einzug in die entsprechenden Ausbildungsgänge. Edsger Dijkstra war nicht nur federführend an der Entwicklung der strukturierten Programmierung beteiligt, sondern entwickelte auch die sogenannten „abstrakten Datentypen”, aus denen sich die Prinzipien der Modularisierung und Datenkapselung ableiten. Dazu zerlegte er ein kompliziertes System in kleine, handhabbare Teile. Was jedes einzelne dieser Teile tut, ist für die anderen Komponenten dabei unsichtbar. Nur


63

über eine definierte Schnittstelle findet die Außenkommunikation statt. Diese Entwicklung war für die 70er und 80er Jahre eines der wichtigsten Hilfsmittel.

Von der Bauindustrie lernen Eine weitere wichtige Persönlichkeit dieser Zeit war Alan Kay. Er verglich Software mit Lebewesen und leitete hiervon seine Idee ab, einzelne „Objekte“ zu definieren und ihnen spezifische Funktionen mit auf den Weg zu geben. Diese Objekte konnten selbst neue Zellen erzeugen und kommunizierten ähnlich wie bei Dijkstra über definierte Kanäle. Aus seinen Ideen und Überlegungen entstanden die Grundlagen für die objektorientierte Programmierung. Für beide Forscher galt als Paradigma ein Hauptproblem direkt in viele Teilprobleme zu zerlegen und diese dann im ingenieurwissenschaftlichen Sinne zu lösen. Bereits früh versuchte man die Programmierung anderen Ingenieurwissenschaften gleichzustellen und schuf somit das „Software-Engineering“. Man hoffte aus den anderen Ingenieurdisziplinen Anleihen machen zu können, um mit deren Erfahrungsschatz an Standards und Entwicklungsmethodiken Ergebnisse besser vorhersagbar zu machen und definierbare Qualität zu erreichen. Warum sollte es nicht möglich sein, eine Software genauso zu planen, wie einen Hausbau? Hier werden zunächst die Anforderungen gesammelt, dann werden Pläne zunehmender Granularität erstellt und mit dem Auftraggeber abgestimmt. Ist dies geschehen, so werden die einzelnen Gewerke an Spezialfirmen vergeben, während ein Bauleiter alle Aktivitäten koordiniert. Konsequent umgesetzt sollte es möglich sein, dass Software mit der gleichen Zuverlässigkeit und Kostentreue hergestellt wird, wie dies für Gebäude gilt. Die Verheißung pünktlicher und kostentreuer Softwarelieferungen mit Hilfe von Techniken, die man sich aus der Bauindustrie abschaute, hatte Charme. Der bis dato üblichen eher künstlerischen Vorgehensweise bei der Entwicklung von Software wurde nun ein definierter Entwicklungsprozess entgegengestellt. Dieser sorgte dafür, dass das System pünktlich ausgeliefert werden würde – so zumindest die Theorie. Prozesse, die dieser Philosophie folgen, definieren eine Reihe von Dokumenten – auch Artefakte genannt –, die vor der eigentlichen Programmierung zu erstellen sind. Hier werden die einzelnen „Gewerke“ erfasst, genau beschrieben, terminiert und überwacht. In großen Projekten sind diese Dokumente nicht nur für das gesamte System zu verfassen, sondern auch für die Entwicklungsumgebung, die Testumgebung, für das Konfigurationsmanagement sowie für Produkteinführung und Wartung. Dies ist letztendlich eine komprimierte Zusammenfassung dessen, was die zentralen Elemente in verschiedenen Prozessmodellen ausmachen.

64


Dieser Hoffnung folgt man bis heute mit recht mäßigem Erfolg. Die dabei immer wieder aufkommende Frage lautet, ob Softwareentwicklung tatsächlich im Sinne einer Ingenieurwissenschaft verstanden werden darf. Aus den Aussagen der letzten Kapitel über Komplexität ist diese Frage durchaus berechtigt!

Softwarekrise Trotz all dieser Bemühungen lösten sich die Probleme nicht auf. In den späten sechziger Jahren machte der Begriff der so genannten „Softwarekrise“ die Runde. Erstmalig überstiegen die Produktionskosten für Software die Anschaffungskosten der Rechner selbst. Nicht nur dies, sondern eng hiermit verbunden scheiterten erste wirklich große Softwareprojekte. Immer öfter mussten angesetzte Aufträge wieder abgesagt werden, weil der Kunde die bestellte „Ware“ nicht mehr bezahlen konnte oder wollte. Auf der anderen Seite wollten jedoch die hochqualifizierten Programmierer für ihre Arbeit angemessen entlohnt werden. Die damaligen Großkunden der Softwareindustrie initiierten daraufhin eigens hierfür Konferenzen mit den Fachleuten auf Anbieterseite. Edsger Dijkstra fasste die Ursachen der Softwarekrise auf einer NATO-Tagung im Jahr 1968 wie folgt zusammen: „Die Hauptursache für die Softwarekrise liegt darin begründet, dass die Maschinen um einige Größenordnungen mächtiger geworden sind! Um es umgangssprachlich auszudrücken: Solange es keine Maschinen gab, stellte die Programmierung kein Problem dar; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem kleineren Problem und nun, da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.“ (Dijkstra 1972) Ein weiteres Problem der späten 60er Jahre bestand darin, dass der Bedarf an immer neuen Anwendungen größer war als das Angebot. Infolgedessen setzte an vielen Orten eine Art Akkordarbeit ein, um in möglichst kurzer Zeit Lösungen zu produzieren. Interne Qualität im Sinne von ingenieurmäßigem Vorgehen und Dokumentation war vielfach unbekannt. – Die Folgen hieraus sind wohl am deutlichsten zum Jahresende 1999 sichtbar geworden. Aberwitzige Aufwände wurden erbracht, um das Y2K9- Problem

9

Y2K-Problem: Im Jahrtausendwechsel musste für viele Anwendungen sichergestellt werden, dass die Jahresangabe in Datenbanken und Programmen nicht zwei-, sondern vierstellig zu sein hatte. Dies war vor allem bis in die frühen 80er Jahre z. B. aus Platzgründen keineswegs selbstverständlich gewesen.


65

in den Griff zu bekommen, Regierungen entwickelten Notfallpläne für den Fall, dass Rechnersysteme im großen Stil ihren Dienst quittieren würden.

Stigmatisierter Softwarebau Vieles ist seither in dieser Branche technisch geschehen, dennoch ist das Stigma der Krise nie mehr von der Softwareherstellung gewichen, was nicht zuletzt die bereits zitierten Zahlen über die Erfolgsquote von auftragsgemäß fertiggestellter Software belegen. Die Komplexität der Softwaresysteme steigt weiter und damit nehmen auch die Probleme zu. Dies gilt, obwohl in der Entwicklung verschiedener Entwicklungsprozesse große Fortschritte zu verzeichnen sind. Die Lösung dieses Problems ist keineswegs trivial, da selbst einfache Programme mit einer Länge von unter 500 Programmcodezeilen derart komplex aufgebaut sein können, dass sie mathematisch selbst ansatzweise nicht einmal mehr verstanden werden können. Jetzt, fast 40 Jahre später, sind diese Probleme der damaligen Krisenzeit immer noch höchst aktuell; auch hätte deren Hintergrund durchaus ins 21. Jahrhundert verlegt werden können: Oft wollten und wollen Manager aus Kosten- oder Termingründen „Quick & Dirty“-Lösungen sehen, vergessen aber vielfach die hieraus resultierenden enormen Folgekosten. Auf Berater und Vordenker wurde und wird nicht ausreichend gehört, während viele Ausbildungsstätten die notwendigen Praxiszusammenhänge in vielen Fällen nicht ausreichend vermitteln.

Blick in die Zukunft Man hat inzwischen durch den Einsatz visueller Werkzeuge, hoch entwickelter Programmiersprachen und entsprechend abstrahierter Darstellungsformen (z. B. UML) versucht, die Komplexität innerhalb der Programmierung einzugrenzen. Sicherlich ist dies zu einem nicht unerheblichen Teil auch gelungen. Allerdings gilt hier dasselbe wie im Bereich des Wissensmanagements: Wir sind noch ziemlich am Anfang! Dort kann man sagen: Wir haben gelernt, Daten zu erheben, und diese zu verknüpfen. Mit geeigneten Logiken können Informationen herausgefiltert werden. Aber, um es kurz zu machen, wir haben es noch nicht geschafft, komplexe Zusammenhänge eigenständig von autonomen Systemen analysieren, beurteilen und entscheiden zu lassen. Genau dasselbe trifft auch auf den Softwarebau zu: Wir haben Programmiersprachen jenseits des Maschinencodes, wir haben gelernt, grafisch gestützte, interaktive Werkzeuge zum Softwarebau einzusetzen, aber wie haben bei weitem noch keine Maschine, die in der Sprache eines Domänenspezialisten dessen Gedankengut übernimmt und daraus eine sinnvolle Software baut. Die Entwicklung von Rapid-ArchitectureSystemen oder der Einsatz von Ontologien weisen in diese Richtung, aber

66


es wird noch einige Zeit vergehen, bis diese Ansätze zu standardisierten Methoden avanciert sind. Auf dem Weg dorthin wird ein immer höheres Maß an automatischer Programmierung Einzug halten müssen. Dies verlagert jedoch die Komplexitätsfrage noch stärker auf die Entwickler und deren fachliche wie psychologisch-soziale Qualifikationen.

3.6 Psychodynamiken Wer unter Druck und mit der Angst vor Versagen ein Problem lösen will, ist zu fixiert. Er springt aus dem Fenster, statt nach der Feuerleiter zu suchen. (Klaus Linneweh, dt. Kreativitätsforscher) Was macht die Dynamik innerhalb des Softwarebaus aus? – Dieser Abschnitt wird hierzu Antworten liefern. Ich stelle dabei die folgende These voran: Die Dynamik eines Softwareprojektes – zum Guten wie zum Schlechten – wird nahezu ausschließlich durch Faktoren beeinflusst, die sich aus dem Wechselspiel der direkt am Projekt beteiligten Personen ableiten. Um dies zu belegen, werde ich mit Ihnen einige konkrete Schlüsselbereiche betrachten. Diese sollen verdeutlichen, dass hier der Faktor Mensch zur treibenden Kraft wird und dabei vielfach alle ingenieurmäßige Planung in eigener Weise dynamisiert oder sogar über den Haufen wirft. Wenn z. B. der Projekteigentümer oder ein entsprechendes Kontrollgremium (z. B. ein Steering-Comittee) alle bis dato geleisteten ingenieurmäßigen Planungen mit einem Satz kippt, indem Ressourcen reduziert, Fristen gekürzt oder elementare Projektziele redefiniert werden, so wird dies zwangsläufig ein Projekt in meistens sehr ungesunder Weise dynamisieren, da die Planung von gestern die Makulatur von heute ist. Solche kurzfristigen Kursänderungen können sehr leicht einen Schneeballeffekt auslösen. Software wird durch Menschen erfunden und ist in den meisten Fällen für menschliche Anwender bestimmt. Im Maschinenbau können einzelne Bauelemente nach genau festgelegten Regeln berechnet und geplant werden. Arbeiter können danach diese Blaupausen umsetzen und es ist vielfach möglich, die Qualität der Ergebnisse sofort mit der Schiebelehre oder dem Zollstock nachzumessen. Dies ist bei Software so nicht möglich! Wie bereits diskutiert findet mit jedem Transformationsschritt eine spezifische Art der „Veredelung“ statt, die äußerst anfällig gegenüber äußeren Störfaktoren ist. Durch eine ganz einfache Selbstbeobachtung wird dies nachvollziehbar: Sie sollen eine komplizierte intellektuelle Leistung vollbringen, z. B. algorithmische Probleme lösen oder ein Buch schreiben (nicht dieses!) – und haben aus verschiedensten Gründen keine Lust dazu oder arbeiten unter

3.6 Psychodynamiken

67

hoher innerer Anspannung, etwa wegen Zeitdrucks. – Was geschieht? Vermutlich wird das Ergebnis armselig oder unvollständig sein – oder Sie erreichen mit eiserner Härte gegen sich selbst das Ziel, dann aber wahrscheinlich erheblich zu Ungunsten Ihrer eigenen Kreativität. In Summe werden also solche Randbedingungen in massiver Weise Einfluss auf die Resultate nehmen. 3.6.1 Software-Epiphyten Erfolg besteht darin, dass man genau die Fähigkeiten hat, die im Moment gefragt sind. (Henry Ford) Software bringt zwei unterschiedliche Gruppen über lange Zeit in eine „Schicksalsgemeinschaft“, bei der man sich, ähnlich den Epipyten in der Pflanzenwelt, auf einer „Wirtspflanze“ (dem jeweiligen Gegenüber) ansiedelt, um möglichst lange von dieser zu partizipieren. Dies sollte dabei in einem solchen Maß geschehen, dass beide Seiten daraus Gewinne ziehen. Geschieht dies nicht, so werden alle in einen Strudel an Problemen gerissen werden, bei dem die Applikation (vgl. Abb. 3.7, S. 68), ursprünglich das verbindende Glied, oftmals zum Zankapfel degradiert. Dies geschieht immer dann, wenn die beteiligten Parteien die Grenzen zu weit zum eigenen Vorteil verlagern wollen. Wird einer der Beteiligten dabei „über den Tisch“ gezogen, so wird er entweder mittelfristig daran kaputtgehen – und beide Seiten haben verloren – oder er wird über kurz oder lang aussteigen, was ebenfalls einen Verlust für alle Seiten zur Folge hat! Meistens wird die ausgenutzte Seite zu einem geeigneten Zeitpunkt auf ihre Weise zurückschlagen, z. B. durch Aussitzen oder versteckten Boykott. Auf einmal werden unter massivem Krafteinsatz Stellvertreterkriege an Sachobjekten ausgetragen, während die tatsächlichen Gründe verschleiert bleiben. Über so genannte Sachargumente wird, oftmals unbewusst, versucht, Revanche für die eingesteckte Schlappe zu erlangen. Statt voneinander konstruktiv zu partizipieren, hält man sich gegenseitig im Würgegriff. Dies wird z. B. über Preisdiktate auf der einen Seite und Leistungseinschränkungen bzw. den Entzug kostenloser Unterstützung auf der anderen Seite ausgetragen. Dabei fügt man sich gegenseitig erheblichen Schaden zu und erzeugt zudem massive Kollateralschäden. In aller Regel werden gerade Softwareprojekte durch solche Situationen stark in Mitleidenschaft gezogen. Dieses Wechselspiel der Kräfte gilt sowohl zwischen Hersteller und Kunden wie auch zwischen Sublieferanten und Produzenten.

68


Wechselspiel der Kräfte Der Kunde hat sich genau für diesen Softwarelieferanten entschieden, weil er sich hier ein Produkt bzw. Leistungen verspricht, mit deren Hilfe er eigene Tätigkeiten oder Geschäfte besser, effizienter oder gewinnträchtiger glaubt abwickeln zu können. Damit dies möglich wird, erwartet er von dem Lieferanten niedrige Fehlerraten bei kurzen Reaktionszeiten im Falle von Betriebsstörungen oder Applikationsfehlern. Des Weiteren will er eine hohe Nutzbarkeit der Software bei sicherer Anwendbarkeit verwirklicht sehen. Das erworbene Produkt muss zudem leistungsstark und flexibel sein und – der Kunde ist König – möglichst rasch zur Verfügung stehen. Als letztes, aber wichtigstes Kriterium kommt die Frage nach dem Preis für die gewünschte Leistung ins Spiel. Der Hersteller hat seinerseits ganz andere Interessen. Er stellt sich in einem gewissen Maß auf die Bedürfnisse des Kunden ein und versucht diesen zu befriedigen. Da er normalerweise mehr als einen Kunden hat, muss er bereits hier Kompromisse eingehen und seine Aufmerksamkeit zwischen seinem Klientel teilen: Der eine möchte ein Neugeschäft, ein zweiter Änderungen und ein dritter Fehlerbehebung – wer ist da für den Lieferanten am wichtigsten und warum? Das Maß hierfür wird vorwiegend über zwei Faktoren gesteuert: Der Lieferant versucht so zu kalkulieren, dass er auf seine Kosten kommt (was, keineswegs selbstverständlich ist!) – Kosten können hier durchaus auch

Abb. 3.7. Anwender und Hersteller – ein ephiphytisches System

3.6 Psychodynamiken

69

sehr subtiler Natur sein: Nicht ungewöhnlich sind Situationen, in denen ein politischer Sieg mehr wert ist als Kostendeckung. – Da mit wenigen Ausnahmen nicht beliebig hohe Preise angesetzt werden können, ist der Hersteller gezwungen, den Leistungsumfang auf das absolut Notwendige zu reduzieren. – Ein Blick in verschiedene Ausprägungen des Anforderungsmanagements belegt dies: Sicherstellung, dass nur solche Dinge realisiert werden, die auch tatsächlich vereinbart wurden.

Innenansichten Darüber hinaus hat der Lieferant seine Interessensphären in ganz anderen Bereichen als der Kunde. Zeit ist Geld, und so möchte er – vor allem wenn feste Abnahmepreise mit dem Kunden vereinbart wurden – die Applikation möglichst rasch und fehlerarm an diesen übergeben. Je schneller und effizienter er diesen Auftrag abgeschlossen hat, umso schneller kann die eigene Mannschaft in neuen Projekten eingesetzt werden. Dabei spielen geringe Stückkosten bei gleichzeitig hoher Wiederverwendbarkeit bei anderen Kunden eine nicht zu unterschätzende Rolle. – Spätestens an dieser Stelle spalten sich jedoch auch die hausinternen Interessen gewaltig: Eine silberne Scheibe mit Begleitdokumentation und die Beratungsleistung oder ein Download ist alles was der Kunde erhält. Aus diesem Grund lebt die Branche davon, dass um jedes Produkt herum das notwendige Image entsteht – und sofern man Software in Umverpackungen kauft, diese all das ersetzen muss, was materielle Produkte von selbst haben. Man kann sie anfassen, wahrnehmen und betrachten. Anders bei der Software: Hier verbindet ein immaterielles Produkt Hersteller und Nutzer – und diese virtuelle Realität muss vermarktet werden. Gleichzeitig muss die Führungsspitze zunehmend mehr das Bild einer hochprofessionellen und erfahrenen Firma nach außen kommunizieren, obschon man nach innen hin – vielleicht aus Kostengründen – sehr viele junge und unerfahrene Mitarbeiter hat, denen nur wenige erfahrene Kollegen gegenüberstehen. Fachlich gesehen denkt man hier in ganz anderen Kategorien. Leiter der Entwicklungsabteilungen wünschen sich klare Produktstrategien seitens der Geschäftsführung, sodass sie aufgrund dieser Planungsvorgaben mit ausreichend Zeit eine Art Lego-Baukasten aufbauen können, aus dem heraus sie mittel- und langfristig eingehende Kundenwünsche rasch bedienen können und auch den geforderten Qualitätswünschen in entsprechender Weise gerecht werden. Sie brauchen Zeit, mehr Ressourcen und wollen eigene technische Aspekte realisieren. Auch sie blicken auf die Mitarbeiter und deren Wissens- bzw. Erfahrungsstand. Was auf ihnen allerdings meistens sehr viel schwerer lastet, sind die Image- und Verkaufsaussagen derjenigen, die nicht täglich ihren Platz in der Produktion haben.

70


Diese Situation ist der ideale Nährboden für etwas, das auf den ersten Blick so gar nicht zur kühlen, wenn auch hektischen Atmosphäre der Softwareentwicklung passt. In seinem Klassiker „Spiele für Erwachsene“ (Berne 1999) beschreibt der amerikanische Psychiater Eric Berne (1910– 1970) diejenigen Prozesse, die zwischen Gruppen mit unterschiedlichen Interessenlagen stattfinden. Berne stellt in diesem Kontext vor, wie sich unterschiedliche Personengruppen auf immer wieder gleiche, wenn auch variantenreiche Interaktionsmuster einlassen, die infolgedessen zu immer wieder ähnlichen Ergebnissen führen. Dabei verhalten sich die Beteiligten als hervorragende Schauspieler, denen es intuitiv gelingt, die tatsächlichen Ursachen im Verborgenen zu halten. Diese personenabhängigen Interaktionsmuster müssen aufgespürt und so modifiziert werden, dass deren innewohnende Energie in positiver Weise einem Projekt zukommt und nicht destabilisierend oder gar zerstörend wirkt. Kurz: Es ist nicht damit getan, Prozesse zu definieren und diese am Leben zu halten. Viel wichtiger ist die Frage: Was läuft hinter den Fassaden der unterschiedlichen Parteien. Und wie können diese Interessenkonflikte in konstruktive Bahnen überführt werden? Es geht dabei nicht um Gleichmacherei: Die Interessenlagen sind höchst unterschiedlich und sollen es auch bleiben. Worum es allerdings geht, ist das rechtzeitige Aufspüren dieser Stereotypen und das Entschärfen solcher Tretminen im Sinne einer Konflikttransformation (Conrad, Jacob et al. 2003). Nur so wird fehlgeleitete Dynamik, die ansonsten einen heftigen Schlingerkurs für Managemententscheidungen und somit auch Projekte zur Folge hat, in solch einer Weise umgeleitet, dass alle Beteiligten die freiwerdenden Kräfte in das alles verbindende Element, nämlich die Software, stecken können. Geschieht dies nicht, so werden latente Konfliktpotentiale möglicherweise irreparabel chronifizieren. Die Produktivität wird durch solche innewohnende Eigendynamik fast immer eingeschränkt. 3.6.2 Teamaspekte Bis hierhin habe ich nur die Außenaspekte um das eigentliche Projektteam herum betrachtet. Wenn Sie an die Aussagen über den Zuwachs an Komplexität innerhalb von Softwareprojekten zurückdenken (vgl. S. 48), so war dort die Rede von den äußerst empfindlichen Schnittstellen zwischen den einzelnen Teiltransformationen. Sehr viel stärkeren Einfluss auf ungewollte Eigendynamiken haben diejenigen psychologischen Prozesse, die innerhalb des Teams stattfinden. Softwarebau ist ein hoch kreativer Akt, der nur dann effizient erfolgen kann, wenn ein hohes Maß an Teamkultur und -skills aktiv im Team vorhanden ist. Neben Werkzeugen und Prozessen, die in diesem Kontext eine

3.6 Psychodynamiken

71

Abb. 3.8. Vier-Ohren-Modell nach F. Schulz von Thun übertragen auf den Softwarebau (vereinfacht)

nachgeordnete Rolle spielen, sind vor allem kommunikatorische und soziale Skills die entscheidende Voraussetzung. Die einzelnen Teammitglieder müssen, trotz unterschiedlicher Tätigkeitsprofile und Sichtweisen in der Lage sein, die Sprache des jeweils anderen mindestens korrekt zu deuten, besser noch sie in einem hohen Maß tatsächlich zu verstehen. Dies betrifft dabei nicht nur die verschiedenen Fachtermini und deren einheitliche Nutzung, sondern hat noch sehr viel mehr mit den Aspekten zwischenmenschlicher Kommunikation zu tun.

Warum ist Kommunikation so schwer Auch wenn wir alle in der Lage sind, zu reden und zuzuhören, so hapert es dennoch leicht an der Kommunikation. Das, was der eine sagt – oder sagen will, wird vom anderen ganz anders wahrgenommen. Warum dies so ist, wurde durch den klassischen Ansatz von F. Schulz von Thun (Schulz von Thun 1981; Schulz von Thun 1989; Schulz von Thun 1998) gut nachvollziehbar (vgl. Abb. 3.8). In seinem Kommunikationsmodell spricht Schulz von Thun davon, dass zwischenmenschliche Kommunikation stets auf vier Ebenen stattfindet. Sein „Vier-Ohren-Modell“ beschreibt die Sachebene,

72


die Selbstoffenbarungsebene, die Beziehungsebene sowie die Appellebene. Sprecher wie Zuhörer senden bzw. empfangen dabei auf allen vier Ebenen. Mit welcher Betonung was wahrgenommen wird und ob Sender und Empfänger über ähnliche Kanäle (= Ohren) austauschen, hat sehr viel mit der Kontextsituation zu tun. Und so ist es nicht ungewöhnlich, wenn z. B. der Projektleiter einen Mitarbeiter darum bittet, eine bestimmte Sache zu tun, dass dieser im Sinne von Schulz von Thun aufbrausend darauf reagiert. Was dieser Kollege für sich wahrgenommen hat, könnte sich dabei so anhören: Die Wahrnehmung auf der Sachebene lautete: Er hat mich beauftragt, das und das zu tun. Bedingt durch die anderen Ebenen könnte daraus entstehen: Eh, was will der den jetzt schon wieder von mir? – Was bildet der sich eigentlich ein? – Hab ich nicht schon genug zu tun? – Auf dem nächsten Ohr hätte ankommen können: Wie redet der denn eigentlich mit mir! Wir wissen doch alle, dass er der Boss ist. Und auf dem letzten Ohr: Wie verhalte ich mich jetzt aufgrund dieser Botschaft richtig? Protestiere ich oder schlucke ich diese Kröte? Je nach eigenem Befinden werden diese anderen Stimmen lauter oder leiser wahrgenommen. Wie stark der soziale Verbund im Team ist und die Fähigkeit besteht, solche falsch interpretierten Nebentöne auszugleichen, spielt eine wichtige Rolle. Ich denke an diesem einfachen Beispiel wird sehr klar, dass der Kontext – selbst für eine reine Sachkommunikation – von hoher Wichtigkeit ist. Aus Sicht vieler Prozessmodelle wird Kommunikation jedoch rein auf die Sachebene reduziert, alle anderen Aspekte bleiben unberücksichtigt und finden sich bestenfalls andeutungsweise in Rollendefinitionen wieder. Dies ist aus kommunikatorischer Sicht äußerst statisch und lässt viele Aspekte unberücksichtigt. 3.6.3 Kommunikationsebenen Anders als oft angenommen, ist es im Softwarebau nicht ohne weiteres möglich, ausschließlich auf einer Ebene der Sachkommunikation zu arbeiten. In ihr wird letztlich Information zwischen Menschen so weitervermittelt wie zwischen Mensch und Maschine. Ohne die Berücksichtigung der anderen Kommunikationsebenen entarten Entwicklungsteams zu Gruppen parallel arbeitender Sachbearbeitern, die einen Auftrag aus dem Eingangskörbchen nehmen, diese Arbeit erledigen und das Ergebnis anschließend im Ausgangskörbchen ablegen. Von dort wird es irgendjemand zur nächsten Instanz weitertransportieren. Untersuchungen hoch performanter Teams belegen die Notwendigkeit, alle Kommunikationsebenen integral zu nutzen. Hierauf werde ich im weiteren Verlauf dieses Buches noch detaillierter eingehen.

3.6 Psychodynamiken

73

Im Sinne der zu erbringenden Transformationsleistungen ist die reine Sachkommunikation, gepaart mit einem statischen Rollenkonzept, mit Sicherheit keine effektive Vorgehensweise. Dabei unterstützt unsere so stark E-Mail-getriebene Unternehmenskultur die Ebene dieser Art von Kommunikation in erheblichem Maße. Die Konsequenz ist, dass immer wieder unerklärliche, auf Missverständnissen beruhende Probleme entstehen, die allzu oft als unprofessionelles Handeln abgetan werden. In vielen Fällen liegt ihnen jedoch mindestens ein systematischer Fehler zugrunde, nämlich das mangelnde Verständnis der einzelnen Kommunikationsebenen bzw. deren Berücksichtigung. – Arbeiten Sie überdies in internationalen Teams, möglicherweise sogar über länderübergreifende Standorte hinweg, so vergrößert sich dieses Problem noch einmal, da zusätzliche kulturelle Unterschiedlichkeiten – die für das ungeschulte Auge zunächst kaum auffallen – sich dem Ganzen überlagern und ihre Wirkung hinzufügen. Zusammenfassend lässt sich bereits hier feststellen, dass Teams, die es gelernt haben, breitbandig miteinander zu kommunizieren, ein wirkungsvolles Mittel gegen unkontrollierte Eigendynamik verwenden, welches zum entdynamisierenden Faktor eines Projektes werden kann. 3.6.4 Moribunde Projekte Das erste Gesetz des schlechten Managements: Wenn etwas nicht funktioniert, tun Sie das Gleiche immer wieder. (Tom DeMarco) Statistische Auswertungen von Boehm und Versteegen haben die Topkandidaten für den Misserfolg von Softwareprojekten ans Tageslicht befördert. Somit gibt es Gründe, die immer wieder Softwareprojekten den Todesstoß erteilen. Im Folgenden habe ich die Auswertungen ein wenig zusammengefasst. Sie unterstreichen in harten Fakten, die zuvor getroffenen Aussagen: Die Untersuchungen ergaben, dass unkontrollierbare Komplexitäten ebenso wie mangelnde Kommunikation, die in direktem Bezug zu unsauberem Anforderungsmanagement und anschließenden Inkonsistenzen bei der technischen Umsetzung stehen, viele Projekte scheitern ließen. Zu dieser Liste zählt übrigens auch „zu hoher Dokumentationsaufwand“. Dahinter verbirgt sich m.E. in vielen Fällen wiederum fehlgeleitete Binnenkommunikation. Die Frage, wem ich mit meinem Dokument dienlich sein möchte und wer daher in welcher Form einen Nutzen daraus zieht, wird oft nicht gestellt. Auch wechselnde Technologien und unkontrolliertes Änderungsmanagement im Sinne des bereits diskutierten Schlingerkurses zählen zu den regelmäßigen Projektmördern. Neben fehlender Beachtung durch das Management werden mangelnde Ausbildungsstände und mangelnde Ressourcen ins Feld geführt. Boehm

74


und Versteegen führen des Weiteren eine Liste mit Punkten auf, die sich allesamt unter ein Begriffspaar einordnen lassen: mangelnde Umsicht und Struktur. Daraus leiten sich konkrete Probleme wie z. B. fehlende Prozessmodelle, schwache IT-Architektur, unzureichende Tests und Qualitätssicherung, Vernachlässigung von Risiken und Fehleinschätzung von Aufwänden ab. In den folgenden Abschnitten werde ich daher sowohl auf Softwareprozesse an sich wie auch auf Ganzheitlichkeit eingehen. Beide Bereiche sind Bezugskoordinaten und daher für einen effizienten Softwarebau ungemein wichtig.

3.7 Glaubenskriege 3.7.1 Prozessmodelle auf dem Prüfstand Aus der Erkenntnis heraus, dass Softwarebau nur dann geordnet ablaufen kann, wenn er durch geeignete Prozesse unterstützt wird, hat man seit Anfang der frühen 1970er Jahre Modelle entwickelt und vielfach eingeführt. Aus den Projekterfahrungen heraus wurden diese Prozessmodelle über die Jahre hinweg an die Gegebenheiten angepasst. Hierbei etablierten sich zwei Hauptphilosophien. Schwerpunkt der einen Richtung ist das durchgängig strukturierte Arbeiten, bei dem vor allem ingenieurmäßig vorgegangen wird. Schwerpunkt der anderen Ausrichtung ist eine starke Orientierung an durchgängiger Kundenzufriedenheit, bei der oftmals ein eher intuitiver Arbeitsstil zu finden ist (z. B. bei extreme Programming mit seiner Einstellung: Code muss ständig verändert werden). Während Prozessspezialisten einen Glaubenskrieg darüber führen, welcher der beiden Ansätze zielführender sei, möchte ich Ihnen folgende Auflösung dieses Dissens vorschlagen: Im wirklichen Leben gibt es auf der einen Seite Menschen (z. B. Künstler), die in großer Genialität und wenig Planung wahre Meisterwerk schaffen. Auf der anderen Seite gibt es Menschen, die schlaflose Nächte bekommen, wenn ein Projekt nicht haargenau geplant worden ist. Beide Formen haben somit ihren Platz und sind sehr stark von der individuellen Persönlichkeit bzw. dem Kontext abhängig. An dieser Stelle hilft eine Anleihe aus der Gehirnforschung. Das Gehirn muss ständig sehr komplizierte Aufgaben lösen, die von Maschinen in gleicher Qualität bisher oftmals nicht geleistet werden können. Denken Sie zum Beispiel an die Echtzeit-Bildverarbeitung des Gehirns oder die Tatsache, dass Sie in einem Raum mit sehr vielen Geräuschen die Stimme Ihres Lebenspartners heraushören können. Um dieser Aufgaben gerecht zu werden, bedient sich das Gehirn beider Methoden! Zum einen wird die Information durch relativ statische Prozesselemente geführt, um dann im Anschluss dynamische Prozessstufen zu durchlaufen. Dieser Vorgang,

3.7 Glaubenskriege

75

d. h. der Wechsel zwischen Statik und Dynamik, wiederholt sich innerhalb eines gesamten Prozessablaufes mehrfach. – Nicht umsonst sind daher Ansätze, wie z. B. Larman (Larman 2004) postuliert, in denen z. B. ein agiler RUP vorgestellt wird, durchaus sehr erfolgreich. Vorgehens- und Prozessmodelle sind abstrakte Handlungsanweisungen für Standardsituationen bei der Herstellung von z. B. Applikationen. Nur sie, ähnlich einem Kochrezept, anzuwenden, führt keineswegs zu den gewünschten Erfolgen. Nur wenn solche Modelle durch die praktischen Erfahrungen von Projektleitern mit Leben gefüllt und in gewissen Maßen dynamisiert werden, sind die geforderten Projekterfolge erreichbar. Auch wenn moderne Prozessmodelle sich auf „Best Practices“ berufen, was nichts anderes bedeutet als die Einbeziehung evolutionär gewachsenen Erfahrungswissens, so ersetzen sie dennoch nicht die „Real World“-Erfahrung dieser Projektverantwortlichen, die oftmals über ein breites Repertoir an Varianten, Tricks und Vorgehensweisen verfügen, um in kritischen Situationen dennoch zu gewünschten Erfolgen zu gelangen. In diesem Sinne ist die anschließende Betrachtung verschiedener Prozessmodelle immer nur als eine Seite einer Münze zu werten. Wie wichtig die Erfahrenheit der Führungspersönlichkeit als zweite Seite dieser Münze ist, wird im Rahmen jüngerer Prozessmodelle explizit ausgedrückt. 3.7.2 Jedem das seine Am Markt finden sich sehr verschiedene Softwareentwicklungs-Philosophien, die in vielen Fällen eine Zusammenstellung von Prozesselementen darstellen, um so durch zielgerichtetes Vorgehen ein Entwicklungsprojekt planbar zu machen und definierte Meilensteine hieraus ableiten zu können. Je nach Modell existieren sehr stark vorstrukturierte Modelle auf der einen Seite und sehr dynamische Modelle auf der anderen Seite. Ehe ich mit Ihnen jedoch eine vergleichende Betrachtung der gängigsten Vorgehensmodelle vornehmen möchte, will ich Ihnen diese mit ihren Hauptparadigmen kurz vorstellen.

Wasserfallmodell Im Wasserfallmodell ist der Entwicklungsprozess für Software so organisiert, dass aufeinander folgende Phasen mit jeweils verbindlichen Phasengrenzen den Prozess der schrittweisen Transformation abbilden. Somit existieren klar einzuhaltende Start- und Endpunkte für jede einzelne Phase. Die Grundidee dieser Vorgehensweise geht auf das Jahr 1970 zurück. In Anlehnung an andere Ingenieurdisziplinen existieren Lasten- und Pflichtenhefte, in denen Ziele und Aufgaben festgeschrieben sind. Insgesamt gibt

76


es eine ganze Reihe Varianten und Modifikationen zu diesem wohl immer noch am weitesten verbreiteten Vorgehensmodell. Es hat sich gezeigt, dass dieses Modell für einfach strukturierte Projekte gut geeignet ist, bei denen Anforderungen, Leistungen und Abläufe bereits früh, nämlich in der Planungsphase, gut beschrieben werden können. Kommt es allerdings zu nachträglichen Änderungen, so gerät dieses Vorgehensmodell an seine Grenzen, da nachträgliche Änderungen nur mit deutlichen Zusatzaufwänden eingebracht werden können. Ein weiterer Nachteil besteht darin, dass wirklich erst ganz am Ende des Prozesses ein Ergebnis vorgestellt werden kann und somit verschiedene Risiken (z. B. Fehler im Code, Akzeptanz durch den Kunden) erst sehr spät mitigiert werden können.

V-Modelle Das V-Modell wurde im Auftrag der öffentlichen Hand in Deutschland sowohl für den Militär- wie auch den Zivilbereich entwickelt. Man wollte mit Hilfe dieses Modells Kostentransparenz erreichen, Angebote vergleichbar machen und vor allem eine durchgängige Mindestqualität der gelieferten Software erzielen. Das V-Modell wurde und wird bei Ausschreibungen aus diesen Bereichen nach wie vor verbindlich vorgeschrieben. Anders als beim Wasserfallmodell werden hier Aufgaben und Ergebnisse festgelegt, nicht aber deren zeitliche Abfolge. Im Kern kennt dieses Modell vier zentrale Rollen, nämlich Projektmanagement, Qualitätssicherung, Konfigurationsmanagement sowie Problem- und Änderungsmanagement. Mit Hilfe sehr umfangreicher Handbücher und Beschreibungen wurde der Prozess sehr umfassend definiert und dokumentiert. Gleichzeitig wurde eine schrittweise Aktualisierung des Modells vorgenommen, um z. B. mit dem „V-Modell 97“ objektorientierten Ansätzen besser gerecht werden zu können oder mit dem „V-Modell XT“ agile und inkrementelle Methodiken stärker zu berücksichtigen. Gerade die letztgenannte Variante ist durchaus beachtenswert, berücksichtigt sie doch neuere Erkenntnisse aus dem Projektmanagement.

Spiralmodell Das Spiralmodell geht auf Barry W. Boehm und das Jahr 1978 zurück. In ihm wird ein iterativer Prozess mehrfach durchlaufen. Nacheinander werden Ziele bzw. Alternativen festgelegt, danach folgt die Bewertung der Alternativen mit Abschätzung der Risiken, wonach Realisierung und Überprüfung der Zwischenergebnisse stattfinden. Ist dies geschehen, so wird die Fortsetzung des Projekts geplant, die wiederum in die Formulierung neuer Ziele mündet. Jeder Durchlauf des Spiralmodells entspricht

3.7 Glaubenskriege

77

einem kleinen Wasserfallprozess. Durch dieses iterativ-inkrementelle Vorgehen ist es möglich, das gesamte Projekt in Teilprobleme zu zerlegen und diese Teile am Ende der entsprechenden Iteration fertig bewerten zu können. Dies gleicht verschiedene Schwächen des klassischen Wasserfallmodells aus, insbesondere die späte Möglichkeit zur Bewertung der Ergebnisse bzw. die schwierige Integration von Änderungen.

Unified-Prozessmodelle (UP) Bei den Unified-Prozessmodellen, deren prominentester Vertreter der RUP aus dem Hause IBM ist, handelt es sich um aufeinander abgestimmte Vorgehensmodelle, die auf der Nutzung verschiedener „Best Practices“ aufsetzen und diese zusammen mit vorstrukturierten stark parallelisierten Arbeitsanweisungen verbinden. Im Fall von RUP stehen dabei die folgenden sieben „Best Practices“ im Mittelpunkt: x x x x x x x

Konfigurations- und Changemanagement Modellierung der Architektur Anforderungsverwaltung Iterative Entwicklung Visuelle Modellierung Qualitätskontrolle Komponentenarchitektur

Die Realisierung der einzelnen Transformationsschritte wird hier auf den Phasen Inception (Projektvorbereitung), Elaboration (Planung der Lösung), Construction (Realisierung der Lösung) und Transition (Finalisierung und Auslieferung der Lösung) abgebildet. Es findet eine iterativinkrementelle Vorgehensweise statt, um so überschaubare und danach überprüfbare Arbeitspakete schrittweise realisieren zu können und zu frühen Teillösungen zu gelangen. Im Allgemeinen werden die UPProzessmodelle dem strukturiert statischen Lager zugeschlagen. Wichtige Elemente in diesem Vorgehensmodell sind dabei: x x x x

Risikogetriebenes Arbeiten Rückverfolgbarkeit von Entscheidungen Vorgegebene Struktur von Artefakten Vorgegebene Rollen und Aufgaben zu bestimmten Zeiten in der Entwicklung

Um die Statik des RUP und die hiermit verbundenen Grenzen des Prozesses aufzuweichen, wird zunehmend mit sogenannten „agilen RUP“ Modellen gearbeitet (Larman 2004). Sie gestatten eine behutsame Flexibilisierung der prozessualen Vorgehensweisen ohne dabei die Grundparadigmen des RUP außer Kraft zu setzen.

78


Agile Prozessmodelle Agilität heißt Beweglichkeit, d. h. zum richtigen Zeitpunkt die angemessenen und richtigen Dinge tun. Der agilen Vorgehensweise liegt das sogenannte „agile Manifest“ zugrunde. Hierin wurden die wichtigsten Grundprinzipien dieser Vorgehensweise als Minimalkonsensus aller agilen Vorgehensweisen definiert. Diese Grundsätze lauten dabei wie folgt: 1. Individuen und Interaktionen sind für agiles Vorgehen wichtiger als Prozesse und Werkzeuge. 2. Wichtiger als umfangreiche Dokumentation ist am agilen Modell, dass die Software funktioniert. 3. Im Rahmen des agilen Manifests ist die Zusammenarbeit mit dem Kunden wichtiger als vertragliche Abmachungen. 4. Als letzter Punkt gilt, dass Reaktionen auf Änderungswünsche wichtiger sind als das Abarbeiten eines festgelegten Planes. Aus diesen Grundaussagen leiten sich die agilen Prinzipien ab (Larman 2004), die man als Handlungsrichtlinien betrachten kann. 1. Unsere oberste Priorität besteht darin, den Kunden zufrieden zu stellen, indem er frühzeitig brauchbare Software erhält und diese kontinuierlich verbessert an ihn weiter ausgeliefert wird. 2. Sich verändernde Anforderungen werden begrüßt, selbst wenn diese erst sehr spät eintreffen. Agile Prozesse lassen solche Veränderungen zu, um des Kunden willen. 3. Es wird regelmäßig funktionsfähige Software ausgeliefert. Dies kann alle paar Wochen oder aber auch Monate stattfinden. – Vorzugsweise sollten die Abstände eher kurz gehalten werden! 4. Geschäftsleute und Entwickler müssen während des gesamten Projektes täglich zusammenarbeiten. 5. Platziere Projekte um motivierte Mitarbeiter. Gib Ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertraue ihnen, dass sie das schon hinbekommen werden! 6. Die effektivste Art und Weise, Informationen in einem Projektteam auszutauschen, geschieht durch direkte Kommunikation. 7. Funktionierende Software ist das wichtigste Projektziel. 8. Agile Prozesse unterstützen nachhaltige Entwicklung. 9. Die Projektsponsoren, Entwickler und Anwender sollten dauerhaft ein gleichbleibendes Tempo einhalten. 10. Beständige Aufmerksamkeit auf technische Exzellenz und gutes Design unterstützt Agilität. 11. Einfachheit – die Kunst, den Anteil nicht zu machender Arbeit zu maximieren – ist notwendig.

3.7 Glaubenskriege

79

12. Die besten Architekturen, Anforderungen und Designs ergeben sich aus selbstorganisierenden Teams. 13. In regelmäßigen Abständen hält das Team inne, um herauszufinden, wie es effektiver werden kann, und setzt das dann um!

Scrum Scrum ist eine Sonderform agiler Softwareentwicklung, bei der eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement bereitgestellt wird. Das Vorgehensmodell ist einfach und macht wenige Vorgaben. Es ist den Teams im Wesentlichen selbst überlassen, wie sie sich organisieren bzw. welche Methoden sie einsetzen. Vorgehen und Methoden können hierbei fortlaufend den aktuellen Erfordernissen angepasst werden.

Extreme Programming Beim Extreme Programming (XP/Xtreme) handelt es sich um ein iteratives, evolutionäres und agiles Vorgehensmodell. Unter evolutionärem Vorgehen versteht man in diesem Kontext, dass kein Pflichtenheft bzw. keine vollständige Spezifikation zu Anfang vorliegt. Wie im agilen Manifest beschrieben, werden die Kundenwünsche berücksichtigt, wobei man unterstellt, dass der Kunde erst im Laufe des Entwicklungsprozesses tatsächlich weiß, was er wirklich will. In sehr kurzen Iterationen, deren Länge im Bereich von ca. einer Woche liegen, werden Mikrowasserfallprozesse durchlaufen. Ziel des XP ist es, eine Linearität zwischen dem Zeitpunkt einer Anforderung und den damit verbundenen Kosten herzustellen. Extreme Programming wird von den folgenden Grundprinzipien getragen: 1. 2. 3. 4. 5. 6. 7. 8.

Respekt vor anderen Teammitgliedern. Intensive Kommunikation zwischen den Teammitgliedern. Akzeptanz von Kritik und anderen Meinungen. Zwei Programmierer teilen sich Computer, Monitor, Tastatur und Maus. Der eine kodiert, während der andere mitdenkt (PairProgramming), dabei werden regelmäßig die Rollen getauscht. Änderung des Quellcodes, wenn immer es notwendig erscheint. Der Quellcode ist kollektives Eigentum, darf also von jedem überall verändert werden. Die einzelnen Komponenten werden in kurzen Zeitabständen zu einem lauffähigen Gesamtsystem integriert. Die Entwicklung ist testgetrieben. Erst werden die Unit-Tests geschrieben, danach wird die Funktionalität programmiert. Nach jedem Programmierschritt werden die Tests durchlaufen.

80


9. Es findet eine laufende Verbesserung der IT-Architektur statt. 10. Die Release-Zyklen sind kurz, um so dem Kunden in regelmäßigen Zeitabständen einen neuen lauffähigen Zwischenstand des Produkts zu liefern. 11. Insgesamt ist der Kunde sehr stark einbezogen, muss also oft anwesend oder zumindest verfügbar sein. Es kann seine zusätzlichen Anforderungswünsche in Form kurzer Geschichten beisteuern. 12. Damit die Freude an der Arbeit und die Konzentrationsfähigkeit erhalten bleiben, gilt die 40-Stunden-Woche. Überstunden sind zu vermeiden. Auf diese Weise soll verhindert werden, dass die Qualität des Produkts leidet. Der Nutzen für den Kunden besteht darin, dass er jederzeit steuernd in das Projekt eingreifen kann. Dieser Nutzen steigt mit der Projektgröße oder -dauer, zumal dadurch erreicht werden soll, dass das Produkt sich aktuellen Anforderungen anpasst. Durch die kurzen Iterationen und engen Release-Zyklen erhält der Kunde sehr rasch ein zwar unvollständiges, jedoch funktionstüchtiges Produkt.

Adaptive Software Development (ASD) Beim ASD handelt es sich um einen Softwareentwicklungsprozess, der aus dem „Rapid Application Development“ entstand. Diesem Vorgehensmodell liegt die beständige Anpassung des Prozesses an die jeweilige Arbeit zugrunde, dabei wurde dieser Ansatz von seinem Erfinder als Ersatz für das Wasserfallmodell betrachtet. Iterativ werden dabei die drei Phasen „Speculate“, „Collaborate“ und „Learn“ durchlaufen. Die Hauptmerkmale des ASD sind: x x x x

Iteratives Arbeiten mit festen Iterationslängen (= “timeboxed“) Feature-Orientiertheit Risikogetriebener Ansatz Tolerant gegenüber Veränderungen

Vor allem auf dem letzten Punkt liegt ein besonderes Gewicht, da ASD für sich in Anspruch nimmt, eine ganze Organisation darauf vorzubereiten, dass sich Anforderungen ändern und entsprechende Flexibilität notwendigig ist. Dementsprechend wird angestrebt, Organisationen so umzustellen, dass diese den evolutionären Prozess einer Softwareentwicklung unterstützen können.

Crystal-Methoden Die Crystal-Methoden wurden von dem Miterfinder des agilen Softwareprozesses Alistair Cockburn, entwickelt und haben direkte Bezüge zum

3.7 Glaubenskriege

81

ASD. Sie stellen eine Familie von Entwicklungsmethoden dar. Die Mitglieder dieser Methodenfamilie sind durch Farben gekennzeichnet; wobei der einfachste Typ ‘Crystal Clear’ lautet. In Abhängigkeit von Projektgröße und Risiken finden sich andere Farbnamen (z. B. Crystal Yellow, Crystal Orange, Crystal Red, Crystal Magenta, Crystal Blue). Hierbei drückt die Farbe primär die Anzahl der beteiligten Personen aus. Neben der Personenzahl ist das Risiko, hier „Kritikalität“ genannt, die zentrale Größen, die den Crystal-Typ bestimmt. Zur Festlegung des Crystlal-Typs lautet eine der zentralen Fragen: „Wie groß ist der Schaden, wenn das Projekt scheitert“, wobei dieses Scheitern auf einer Skala abgebildet wird, die von Imageverlust bis zum Verlust von Menschenleben reicht. Ähnlich dem agilen Manifest, setzen auch die Crystal-Methoden auf einer festgelegten Reihe von Prinzipien auf: x Durch räumliche Nähe und Freiräume für Gespräche wird informeller, „passiver“ Wissenstransfer gefördert. x Kritik und Befürchtungen dürfen ohne Repressalien geäußert werden. x Es werden laufend Verbesserungsvorschläge gesucht, gesammelt und die Wichtigkeit ihrer Umsetzung bewertet. x Die Mitarbeiter wissen genau, was ihr Ziel ist, und werden nicht abgelenkt oder für andere Projekte abgezogen. x Durch häufige Herausgabe von Zwischenversionen an den Kunden oder andere Projektbeteiligte wird vermieden, dass Erwartungen angestaut werden und größerer Erklärungsbedarf entsteht. Gleichzeitig kann eine höhere Sicherheit für das Team durch Zwischenabnahmen entstehen. x Dadurch, dass ständig ein erfahrener Benutzer des künftigen Produktes erreichbar ist, können Detailfragen schnell und formlos geklärt werden. Dies vermeidet unter anderem, dass Missverständnisse zu Problemen auswachsen. x Durch Unit Testing wird für dauerhaft stabilen Programmcode gesorgt, was auch das Vertrauen des Teams in die eigene Arbeit stärkt. x Nicht nur der Programmcode wird getestet, es wird auch regelmäßig (z. B. täglich und automatisiert) eine lauffähige Testversion erstellt. x Konfigurationsmanagement oder zumindest eine Versionsverwaltung wird eingesetzt.

Bewertung Prozessmodelle – wie immer sie auch gelagert sein mögen – sind Organisationshilfen, um das Zusammenspiel, die Überschaubarkeit und Projektrisiken besser zu steuern. Die inhaltliche Güte der zu erstellenden Software ist jedoch von weiteren Faktoren abhängig. Was letztlich zählt, ist der Projekterfolg und nicht das Vorgehensmodell. Da Anbieter oftmals ihr

82


eigenes Modell als das Allheilmittel hinstellen, schleicht sich in Organisationen immer wieder eine Vorgehensweise ein, bei der man Kunden und Beteiligten vermittelt, dass der Erfolg in der möglichst genauen Einhaltung der vorgegebenen Regeln besteht. Statt Eigenverantwortlichkeit zu postulieren, geht es darum, Checklisten abzuarbeiten – und das möglichst präzise. Genau daran aber scheitern Projekte sehr leicht. – Dem Modell wird dann Versagen vorgeworfen – dem eigentlichen Verursacher jedoch nicht ins Gesicht geschaut. Ein Vergleich der verschiedenen Prozessmodelle liefert zunächst die folgende Tabelle.

Risikogetrieben Strukturiert

+++

Dynamisch

++

Crystal

ASD

XP

Scrum

Agile

UP

Spiral

V-Modell10

Wasserfall

Tabelle 3.1. Prozessmodelle im Vergleich (+ – schwacher / ++ – mittlerer / +++ – starker Bezug)

+

+++ +++ +++ +++ +++ +++

++

++

++

Prozessflexibilität

+

+++ +++ +++ +++ +++

+

+++ +++

++

+++ +++

++

++

+++ +++ +++ +++ +++

++

+++

++

+

++

+

++

++

++

++

++

+

+

+

++

+++ +++ +++ +++ +++

Zusammenarbeit im Team

++

++

++

+++ +++ +++

Parallelisierung

++

++

++

++

Iterativ Vordefiniert

++

+++

Teamaspekte Prozesstreue

+++ +++

Späte Requirementsänderungen

Codestrukturierung

10

++

++

+

+

+++ +++

++

++

++

Die Aussagen beziehen sich auf die älteren V-Modelle. Wie erwähnt hat das V-Modell XT agile Aspekte berücksichtigt.

3.7 Glaubenskriege

83

Entsprechend dieser Tabelle ergibt sich eine Polarisierung der Prozessmodelle. In der einen Gruppe finden sich solche Modelle, die sehr frühe strukturierte Planung aufweisen (Wasserfall, V-Modell) und die, zumindest in ihren frühen Ausprägungen, späte Veränderungen nur sehr schwer berücksichtigen können. In der anderen Gruppe finden sich Prozessmodellen, die eher in einer Art Kontinuum zwischen Requirementserfassung und Realisierung arbeiten. Sie haben stark die aktuelle Zufriedenheit des Kunden und dessen Mitwirkung im Blick. Auffällig – gerade auch im Sinne dieses Buches – ist die Tatsache, dass Aspekte der Teamzusammenarbeit, etwa die Aussage, dass niemand wegen anderer fachlicher Ansichten kritisiert oder Code von allen verändert werden darf (Xtreme), eine wachsende Bedeutung erlangen. Gleiches gilt für Aspekte der Selbstorganisation (z. B. ASD, Crystal). Dies sind psychologische Faktoren und keine ingenieurmäßigen! In Abb. 3.9 ist dies noch einmal grafisch zusammengefasst. Wird dies im Zusammenhang mit der Frage nach der Zunahme der Komplexität betrachtet, so ergibt sich ein etwas anderes Bild. Bei den Prozessmodellen auf der rechten Seite von Tabelle 3.1 gibt es nur einen Kandidaten, der explizit für sich in Anspruch nimmt, den Code und die technischen Strukturen während des Projektes zu verbessern (Xtreme). Im Übrigen ist hier eine eher evolutionäre Vorgehensweise zu finden. Die Prozesstypen der linken Seite kennen durch die Art der eigenen Methodik dieses Problem

Abb. 3.9. Prozess- vs. Team- und Eigenverantwortung

84


nicht, da hier im ingenieurmäßigen Sinne erst geplant wird und dann die Umsetzung entsprechend Plan (zumindest auf dem Papier) erfolgt. Im Folgenden möchte ich diese beiden Aspekte näher betrachten und hinterfragen. 3.7.3 Soziale Dynamik Anhand von Studien weiß man, dass ein Drittel aller Probleme in Projekten fachlich-methodisch begründet sind, während die restlichen zwei Drittel aus dem sozial-emotionalen Bereich stammen. Es sind also keineswegs, wie oft vermutet, die falschen Pläne, Prozesse, Technologien oder Werkzeuge, sondern die persönlichen, sozialen und kommunikativen Probleme der beteiligten Menschen und Organisationen untereinander. Subtile Themen menschlichen Seins wie Macht, Anerkennung, Prestige und Besitzstände wirken in diesem fragilen Kontext ebenso stark wie Autoritätsprobleme oder Tabus. Somit bedarf es mehr als nur eines definierten Satzes an Regularien und Prozessen, um erfolgreich produzieren zu können. Was als zweites Standbein neben der prozessualen Sicht unbedingt gebraucht wird, ist die Erstellung und Aufrechterhaltung eines ausbalancierten Sozialsystems unter den beteiligten Mitarbeitern. In einem solchen Kontext werden die oben genannten konfliktären Aspekte maximal bekämpft. Gleichzeitig wird der Forderung, die sich aus den Fragen zur Komplexität in Kap. 3.3, S. 48 ff. ergeben hatten, nach möglichst ungestörten kommunikativen Übergängen zwischen den einzelnen Stufen in optimaler Weise Rechnung getragen. Je mehr eine dedizierte Gruppe an Mitarbeitern zu einem Team zusammenwächst, umso einfacher werden Abstimmungsprozesse, da z. B. viele Themen sehr viel informeller angegangen werden können. Ebenso wird ein gut eingespieltes Team sehr viel geringere Verluste durch mangelnde Kommunikation hinnehmen müssen, da das Zusammenspiel des Teams zur tragenden Säule avanciert. Somit scheint es einen direkten Bezug zwischen einem funktionierenden Team und der Möglichkeit agilen Handelns zu geben. Dabei gestaltet sich Teamarbeit oft als schwierig. Für eine wirklich effektive Zusammenarbeit ist es zunächst wichtig, die natürlichen Prozesse in Teams zu erkennen und diese sich nutzbar zu machen (Nothdurft 2000). Es lohnt sich, in diesem Sektor von formalen Vorgehensweisen einmal wegzublicken und stattdessen auf die Mechanismen der Teamdynamik zu schauen. Dort zeigt sich rasch, dass durch geeignete Entwicklung und Führung dieser Gruppe völlig neue Kapazitäten freigesetzt werden können. Aus einem Konglomerat von Spezialisten, die für ein Projekt zusammengewürfelt wurden, lassen sich so Hochleistungsteams bilden (Katzenbach und Smith 2003), die allein schon durch ihre Zusammenarbeit im Team einen erheblichen Teil der Komplexitätshürden niedrig halten. Über die Dynamik und Randbedingungen solcher Teams wird später ausführlich die Rede sein.

3.7 Glaubenskriege

85

3.7.4 Massenprodukte oder Unikate? Inzwischen war mehrfach davon gesprochen worden, Software müsse ingenieurmäßig sauber geplant und realisiert werden. Dann wiederum schien eher der Eindruck zu entstehen, dass man Computercode im Sinne eines Unikates betrachten müsse. Dies entspricht eher einem gemeinschaftlich entstandenen handwerklichen Einzelstück mit der Option dauerhafter Weiterentwicklung. (Dank der Kopietechnik ist diese Sicht unabhängig von der Anzahl der verkauften Einheiten!) Es stellt sich somit die Frage: Ist Softwarebau eher im Sinne von Manufakturen oder besser im Sinne von Fabriken zu sehen. Zur Klärung dieses Sachverhaltes ist es notwendig, den Unterschied zwischen beiden Paradigmen herauszuarbeiten:

Gleichheit in Variationen Wenn Sie an die intellektuellen Stufen im Softwarebau denken (Abb. 3.4, S. 52 ff.), so war dort die Rede von den drei Phasen der Softwareerstellung, nämlich Erforschung, Erfindung und Erstellung. Fabrikproduktion zeichnet sich dadurch aus, dass Produkte so entwickelt werden, dass sie mit Hilfe von geeigneten Prozessen und Automaten beliebig oft und vor allem kostengünstig reproduziert werden können, wobei in modernen Produktionen hier durchaus Varianten möglich sind. Entscheidend ist, dass auf einem konstruktiv breit angelegten Basismodell mit Eigenschaften, die für alle Mitglieder dieser Produktfamilie gleich sind (= „Commonalities“), definierte individuelle Ausprägungen (= „Variabilities“) hinzugenommen werden. Um eine Fließbandproduktion zu ermöglichen, muss in größerem Stil ein technisches Umfeld geschaffen werden, das ab einer bestimmten Produktionsleistung kostengünstiger und qualitativ besser arbeitet als z. B. der Mensch. Durch Nutzung dieser „Fertigungsstraße“ werden alle Commonalities im Rahmen definierter Toleranzen gleich sein. Varianten sind nur im definierten Rahmen zulässig. Für nachträgliche Änderungen gilt Ähnliches, da das ganze Produktionssystem auf einen möglichen Produktrahmen ausgelegt ist. Damit so etwas realisierbar wird, muss der Hersteller mehrere Voraussetzungen schaffen, die es im Folgenden näher betrachten gilt.

Produktstrategie Nur wenn eine Produktstrategie vorhanden ist, die präzise Produktaussagen über die nähere Zukunft, mittelfristige Zielmärkte und Nischen ausweist und solche Bereiche definiert, die man nicht betreten möchte, ist es möglich, hieraus ein Productline-Engineering-Konzept zu erstellen, etwa so, wie es durch das Software Enginering Institute (= SEI) der Carnegie

86


Mellon University vorgeschlagen wird11. In diesem Zusammenhang wird deutlich, dass diese Art von Produktion ihre eigene Dynamik aufweist. Kurzfristige grundsätzliche Änderungen bei Anforderungen – wie sie z. B. durch verschiedene Prozessmodelle im agilen Bereich möglich sind, werden dann nicht mehr funktionieren – es sei denn, dass sie sich im Scope der Produktlinie befinden. In solch einem Fall kann binnen kurzer Zeit eine neue Produktvariante geschaffen werden. Neben der maschinellen Ausstattung ist es überdies notwendig, dass die Arbeitsprozesse für die Varianten und auch deren Komponenten sehr stark aufeinander angeglichen sind, um so mit durchgängigen Arbeitsmodellen und dem Einsatz von „Normteilen“ die Effizienz zu erhöhen. All dies muss dann ergänzt werden durch die Durchgängigkeit und hohe Interaktivität der eingesetzten Werkzeuge im Sinne des CIM12. Im hier verstandenen Sinne ist es dazu gedacht, Zwischenergebnisse ohne Format- oder Toolplattformwechsel von einem Transformationschritt zum nächsten weiterzugeben. Am Beispiel Kraftfahrzeug wird noch ein weiterer Effekt der Massenproduktion deutlich. Fahrzeuge unterliegen Verschleiß und müssen daher regelmäßig gewartet bzw. repariert werden. Weite Anteile der Produktplanung müssen sich in Abstimmung mit den konstruierenden Abteilungen damit befassen, wann welche Teile zu prüfen, überholen oder zu ersetzen sind. Auch müssen hierfür Vorgehensweisen erarbeitet werden, die dies kostengünstig ermöglichen. Vor der Auslieferung des Produktes wurden bereits Dokumente und Zeichnungen für die Werkstätten angefertigt, damit diese möglichst rasch und sicher die entsprechenden Arbeitsschritte ausführen können. – Gerade weil viel Wert auf die Werterhaltung durch Instandsetzung gelegt wurde, kann der Hersteller nur durch Modellwechsel zu definierten Zeitpunkten größere Veränderungen an seiner Konstruktion vornehmen. – Summarisch ergeben sich daraus die folgenden Schwerpunkte: Eine Produktionsstraße zeichnet sich durch einen hohen Automatisierungsgrad aus sowie durch Dokumente, die den gesamten Lebenszyklus des Produktes im Blick haben. Es bedarf einer nicht unerheblichen Infrastruktur, damit das Produkt hinreichend günstig reproduziert werden kann.

Ähnliche Kunstwerke Anders sieht die Welt bei Manufakturen aus. Hier entstehen ausschließlich Einzelstücke oder Kleinserien, wobei diese zwar ein hohes Maß an Ähnlichkeit aufweisen, jedoch nicht im Sinne einer Massenfertigung identisch 11 12

Siehe hierzu die Arbeiten am SEI: http://www.sei.cmu.edu/programs/pls. CIM steht für Common Information Model und ist ein Standard für das Management von IT-Systemen. Durch ihn soll es vor allem verteilten Anwendungen möglich sein, eine einheitliche anbieter- und plattformunabhängige Managementschnittstelle zur Verfügung zu stellen.

Literatur

87

sind. Typisch für solche „Handwerksbetriebe“ ist dabei, dass der Auftraggeber ein Gewerk nach seinen speziellen Wünschen realisiert bekommt. Damit spielt er oder sein Vertreter (z. B. beim Hausbau der Bauleiter oder Architekt) einen aktiven Part bei der Realisierung. Es wird mit erprobten Maschinen gearbeitet und meistens Planungsdokumente verwendet. Die Planung oder deren Korrekturen bzw. Ergänzungen können vielfach während der Herstellung erfolgen. Ein Team mit aufeinander eingespielten Mitarbeitern wird das entsprechende „Werkstück“ gemäß bewährter Methodiken realisieren. Sollten Defekte auftreten, so ist es genau dieses Erfahrungswissen, was in den meisten Fällen zu schnellen Lösungen führt, da Planungsdokumente nicht unbedingt den aktuellen Produktstand reflektieren. Somit wird in diesem Fall der Faktor Erfahrenheit in Verbindung mit eingespieltem Teamworking eine Schlüsselrolle innehaben.

Quintessenz Ganz offensichtlich liegen hier zwei sehr unterschiedliche Strategien vor, die jeweils in einem eigenen Kontext zum Optimum gebracht werden können. Was bei beiden Herstellungsmethoden allerdings bisher nicht genannt wurde, ist das Produkt selbst. Ob das gebaute Produkt eine geniale Glanzleistung ist oder vor Mittelmäßigkeit strotzt, ist von der Vorgehensweise weitgehend unabhängig. (Dies gilt nicht notwendigerweise für die gefundenen Fehler!) Hier in der Mitte des Transformationsprozesses muss eine möglichst kreative und von Weitblick geprägte Planungsleistung erbracht werden, die den vorhandenen Anforderungen, der kommenden Realisierung und den Rahmenbedingungen wie Kosten, Zeit und Qualität gerecht wird.

Literatur Asendorpf, J. (1996). Psychologie der Persönlichkeit – Lehrbuch. Berlin, Heidelberg, New York, Springer-Verlag. Beck, K. und D. Andres (2004). Extreme Programming Explained, Embrace Change. Reading, Mass. ; Harlow, England, Addison-Wesley. Black, E. (2001). IBM and the Holocaust. London, Crown Publishers. Cockburn, A. (2005). Crystal Clear. Agile Software-Entwicklung für kleine Teams. Bonn, mitp-Verlag. Ganzhorn, K. W., Wolfgang (1965). Die geschichtliche Entwicklung der Datenverarbeitung. Augsburg, IBM Deutschland. Gates, B. (1995). The road ahead. New York, Penguin books. Hellige, H. D. et. al. (2004). Geschichten der Informatik. Berlin, Heidelberg, New York, Springer-Verlag. Highsmith, J. A. (1999). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York, Dorset House Publishing Company.

88


Kruchten, P. (2003). The Rational Unified Process – An Introduction. Reading, Mass., Addison-Wesley. Larman, C. (2004). Agile & Iterative Development – A managers guide. Boston, Pearson Education. Lefrancois, G. R. (1994). Psychologie des Lernens. Berlin, Heidelberg, New York, Springer-Verlag. Mérö, L. (2002). Die Grenzen der Vernunft, Kognition, Intuition und komplexes Denken. Reinbek, rororo. Polzer, J. (2004). Creating teams with an edge. Boston, MA, Harvard Business School Press. Rainwater, J. H. (2003). Katzen hüten. Bonn, mitp-Verlag. Schwaber, K. (2004). Agile Project Management with Scrum. Redmond, Wash., Microsoft Press. Subramaniam, V. (2006). Practices of an Agile Developer. Pragmatic Programmers. Raleigh, NC, Pragmatic Bookshelf.

4 Von der Krisis zur Katharsis

4.1 Dynamik, Chaos und Komplexität Today’s problems come from yesterdays solutions.13 (Senges Gesetz) Ich stelle diesem Abschnitt eine Geschichte über nichtlineares Denken voran: „Till Eulenspiegel wurde auf einer Wanderung von einem am Wegesrande stehenden Kutscher angehalten und gefragt, wie weit es wohl bis in die nächste Stadt sei. Eulenspiegel erwiderte dem Fragenden: wenn Sie die Strecke in Ruhe zurücklegen, dann dauert es ½ Stunde, wenn Sie eilen, so brauchen Sie ½ Tag. Der Kutscher konnte mit dieser Aussage überhaupt nichts anfangen, griff nach der Peitsche und trieb seine Kutschpferde zu höchster Eile an. – Till Eulenspiegel aber zog seines Weges. – Nicht lange danach trafen sich die beiden wieder: Der Kutscher stand fluchend am Wegrand, während Eulenspiegel gemütlich an Ihm vorbeischlenderte. Der Weg war so schlecht gewesen, dass sich der Kutscher einen Achsbruch zugezogen hatte!“ Diese kleine Geschichte enthält eine wichtige Analogie in Bezug auf den Umgang mit Komplexität im Softwarebau und deren Planung. Aus Managementsicht wird es immer notwendiger, dass Technik – auch Software – in immer kürzeren Zyklen einsetzbar wird. Projektdruck und Fertigstellungsverpflichtungen erfordern von fast allen Softwareprojekten eine enorme Geschwindigkeit. Die Managementanforderung ist aus kaufmännischer Sicht nachvollziehbar, wirft aber Fragen darüber auf, wie Dinge projektseitig entschleunigt werden können, um zu vermeiden, dass schnelle, zu wenig durchdachte Lösungen zum IT-technischen Achsbruch führen, weil eine komplexe Materie nicht richtig verstanden wurde. Bisher war viel von Komplexitätstransformationen und deren Dynamik die Rede gewesen. Was jedoch bisher offen geblieben ist, betrifft eine nähere Analyse der Komplexität an sich. Was ist Komplexität eigentlich und was haben komplexe Systeme, seien es nun Termitenstaaten, unser Gehirn 13

Die Probleme von heute sind die Lösungen von gestern.

90


oder große Softwareprodukte, gemeinsam? In allen Fällen handelt es sich um Systeme, die aus vielen Objekten bestehen. Komplexität ist dabei die Gesamtheit aller Merkmale dieser Objekte und deren Wechselwirkungen. Im Alltag ist dann die Rede von komplexen Systemen, wenn die folgenden Merkmale in Kombination auftreten: Der Umfang eines Problems zeichnet sich durch eine Vielzahl von Aspekten aus, die untereinander in nicht auf den ersten Blick durchschaubaren Abhängigkeiten zueinander stehen. Häufig verändern sich diese Wechselwirkungen über die Zeit und weisen somit eine Eigendynamik auf. Diese kann sich mit unerwünschten Nebenwirkungen überlagern, wodurch das Ganze unkalkulierbar wird und schwammig zu sein scheint. 4.1.1 Von der Konstanz der Komplexität Komplexität unterliegt eigenen Gesetzmäßigkeiten, die durch keine noch so pfiffige Programmierung außer Kraft gesetzt werden können. Wenn ein System in der Weise kontrollierbar gemacht werden soll, dass es mittels einer Applikation nachgebildet oder steuerbar ist, so gelingt dies nur, wenn die Komplexität des gegebenen Systems unter Kontrolle gebracht wurde. Dabei ist der Komplexitätsgrad des Ursprungssystems eine gegebene Konstante. Die entscheidende Frage beim Softwarebau lautet somit nicht in erster Linie: „Wie vereinfachen wir die Abbildung der Wirklichkeit?“, sondern sie muss lauten: „Was sind die relevanten Freiheitsgrade und wie kann diese Komplexität in einem technischen System abgebildet werden, sodass die Anwender die vollständige Kontrolle darüber erlangen?“ Statt also nach Wegen der Reduktion zu suchen, ist es notwendig, die Komplexitätsgrade des gegebenen Systems möglichst gut zu erfassen, um sie dann entsprechend abzubilden. Dabei gilt grundsätzlich: Je höher die Fähigkeiten eines Ursprungssystems sind, desto höher wird auch dessen Komplexität sein. Komplexität ist messbar, und zwar mit Hilfe des Komplexitätsmaßes, genannt „Varietät“. Hierbei kann Varietät in erster Näherung definiert werden als die Anzahl möglicher, unterscheidbarer Zustände eines Systems. Aus dieser Definition ergibt sich das Gesetz der erforderlichen Varietät, welches durch den britischen Neurophysiologen und Kybernetiker Ross Ashby aufgestellt wurde. Das nach ihm benannte „Ashby’s Gesetz“ besagt: „Nur Varietät kann Varietät zerstören“ (Ashby 1974). Dies bedeutet für die Praxis zweierlei: Das Ausmaß, in dem es möglich ist, ein System unter Kontrolle zu bringen, also zu steuern oder nachzubauen, hängt von dessen eigener Komplexität und derjenigen des zur Verfügung stehenden Regelungssystems ab. Zum anderen bedeutet es, dass nur dann ein System unter Kontrolle gebracht oder hinreichend genau nachgebaut werden kann, wenn

4.1 Dynamik, Chaos und Komplexität

91

das Zielsystem mindestens so viel Varietät besitzt, wie das Ursprungssystem. Kommt es hingegen zu einem Varietätsdefizit, so ist solch ein System nur begrenzt kontrollierbar oder unvollständig abgebildet. Übertragen auf den Softwarebau kann dies bedeuten: Es wurden Nutzungsfälle übersehen oder nichtfunktionale Anforderungen vergessen, die somit in der Planung unberücksichtigt blieben. Durch deren zusätzliche Aufnahme müssen erhebliche Teile der Software umgearbeitet werden und machen diese komplizierter. Ein Beispiel: Stellen Sie sich eine Applikation vor, bei der man zunächst vergaß, dass mehrere unterschiedliche Benutzer mit verschiedenen Rechten das System gleichzeitig betreiben dürfen. Darüber hinaus gilt allgemein: x Der weit verbreitete Slogan „Keep it simple“ hat daher seine klare, jedoch eng umrissene Berechtigung. Gelingt es, Dinge einfach zu halten, so wird die resultierende Software ebenfalls überschaubar sein. x Simple Software wird allerdings nur simple Lösungen gestatten – nicht mehr! Zwar können Sie eine Applikation unnötig verkomplizieren, diese jedoch einfacher zu gestalten als das Ursprungssystem wird nicht gelingen. (Ich beziehe mich hierbei auf die Gesamtapplikation und nicht auf die Masken die der Anwender sieht!) Stattdessen sind geeignete Maßnahmen notwendig, um hierdurch einen möglichst geringen Anstieg der Ursprungskomplexität zu erreichen. x Ist das operative Umfeld komplex, so muss der Softwarehersteller auf mindestens gleichem Komplexitätsniveau reagieren können wie der Auftraggeber bzw. die Zielgruppe. Dabei gilt der Wahlspruch „Learn to cope with complexity“: Je besser Sie in Ihrer Entwicklungsorganisation mit Komplexität umgehen umso besser werden Sie reagieren können. Zwar können komplizierte Systeme nicht einfacher gemacht werden, dennoch lässt Ashby’s Gesetz andere Freiheitsgrade zu. – Statt nur nach den Abhängigkeiten in einem Ursprungssystem zu fragen, sind Aussagen darüber, wie ein solches System effizient gesteuert und reguliert werden kann, von großer Bedeutung. – Dies gilt sowohl für die zu bauende Software wie auch für die notwendigen Vorgehensweisen bei der Umsetzung. (Hierüber werden Sie in den kommenden Kapiteln mehr erfahren.) Bezogen auf die Applikation liegen die Schlüssel in den Bereichen der Informationsarchitektur: der Benutzerschnittstelle und der Ablaufautomatisierung. Hierbei gilt: Bei „dummen“ Programmen muss der Benutzer viel tun (z. B. viele Eingaben und damit viele Fehler machen), bei „klugen“ hingegen muss der Benutzer nur das informationstechnisch absolute Minimum an Eingaben oder Clicks leisten – den Rest ergänzt die Anwendung. In beiden Fällen bleibt die Gesamtkomplexität gleich, sie wird jedoch im zweiten Fall sehr viel stärker auf die Maschine verlagert.

92


4.1.2 Komplexität provoziert Fehler Bei Personen, die in eine komplex wahrgenommene Situation geraten und sich hierdurch überfordert fühlen, treten immer wieder bestimmte charakteristische Verhaltensmuster auf, die – übertragen auf den Softwaretransformationsprozess – fatale Folgen haben. Die wichtigsten fehlerauslösenden Begleiterscheinungen bestehen darin, dass nicht hinreichend Neben- und Fremdwirkungen des vorliegenden Systems betrachten werden. Lineares Denken und die Notwendigkeit, schnell handeln zu müssen, bieten einen hervorragenden Nährboden für Fehler der dritten Art: Man kümmert sich schlichtweg um die Lösung der falschen Probleme, ohne sich dessen bewusst zu sein. Statt die zeitlichen Veränderungen des Systems zu betrachten, steht auf einmal nur noch der aktuelle „Stand der Dinge“ im Mittelpunkt – was aufgrund der zeitlichen Abhängigkeiten eines komplexen Systems sicherlich keine gute Ausgangsposition ist. In solchen Situationen versucht man durch lineares Denken auf Kausalketten zu stoßen: Bei der Planung von Maßnahmen in komplexen Systemen wird daher gewöhnlich nur der angestrebte Haupteffekt der Maßnahme betrachtet. Die auftretenden Nebeneffekte werden vielfach vernachlässigt oder ignoriert. Ebenso gelingt es nur schwer, versteckte Wechselwirkungen zwischen mehreren Teilen wahrzunehmen und deren Gesamtwirkung auf das System zu identifizieren. Dabei kann das heute oft gefragte Spezialistentum zur Falle werden: Durch die Fokussierung auf Einzelprobleme und deren Lösung geht der Gesamtzusammenhang verloren. Die Folge ist, dass Sie Mitarbeiter haben, die von kleinen Teilbereichen des Gesamtproblems enorme Detailkenntnisse haben. Sie beachten jedoch nicht, wie der jeweilige Teilkomplex mit anderen Bereichen in Wechselwirkung steht; auch werden zu selten die Konsequenzen für andere Bereiche abgeleitet, falls sich im eigenen Bereich Veränderungen ergeben. Viele sogenannte Systemanalysen haben hier übrigens deutlich erkennbare Schwachstellen. Es werden vielfach zwar verschiedene Teilkomplexitäten ausgewertet, die Analyse des Gesamtsystems wie auch die Analyse dynamischer Komplexitäten bleiben jedoch aus und erzeugen in Folge bei der Lösung unberücksichtigtes Fehlverhalten des Gesamtsystems bzw. undefinierte Zustände. Softwaretechnisch sind dies diejenigen Fälle, in denen z. B. bestimmte Systemzustände in der Planung unberücksichtigt blieben und somit technisch nicht abgebildet wurden.

Denkfehler in komplexen Situationen Komplexität wird subjektiv wahrgenommen: Wenn ein erfahrener Pilot ein Flugzeug landet, so wird er die vielen Schalter, Prozeduren und Abstimmungsprozesse mit dem Boden als vielfältig, nicht aber als kompliziert


93

wahrnehmen. Er hat die innewohnende Logik und die wechselseitigen Abhängigkeiten durchschaut und bewegt sich mental durch dieses Netzwerk aus vielen Einzelfaktoren. Befänden Sie sich in derselben Situation (ich unterstelle, dass Sie keine Pilotenausbildung haben) und würden Sie versuchen, eine Simulatorlandung durchzuführen, so wären Sie einer ganzen Reihe persönlicher Effekte in unterschiedlich starker Form als Reaktion auf diese Situation ausgesetzt, während das virtuelle Flugzeug auf die Landebahn zurast. Eigene Handlungskompetenz. Ein zentrales Merkmal des unzureichenden Umgangs mit komplexen Situationen ist die niedrige Einschätzung der eigenen Handlungskompetenz. Es besteht ein Zusammenhang zwischen der persönlichen Selbstsicherheit und der Güte des eigenen Handelns. Es werden Selbstzweifel laut, ob Sie diese Situation überhaupt meistern können. Im Fall des Flugsimulators könnte das Ganze für Sie so aussehen, dass Sie zunächst der Ehrgeiz packt. Ist man jedoch nicht erfolgreich, so neigen viele Menschen dazu, das Ganze abzubrechen, da man sich insgeheim für nicht geeignet hält. Je nach Persönlichkeitstypus wird man spätere Experimente dieser Art meiden oder nach geeigneten Vorwänden suchen. Vagabundieren und Detailverliebtheit. Gesetzt den Fall, dass Sie im Simulator durchhalten und über längere Zeit sich auf die vielfältigen Signale und Handlungen konzentrieren sollen, um das Flugzeug stabil zu halten, so wird sich in den meisten Fallen Folgendes beobachten lassen: Sie als Betroffener werden relativ schnell und oft die Themen der Beschäftigung wechseln, ohne ein Thema vernünftig abzuschließen. In solchen Situationen ist es typisch, von der oberflächlichen Behandlung eines Themas zum nächsten Thema zu wechseln, früher behandelte Themen wieder aufzugreifen, jedoch nichts wirklich zum Abschluss zu bringen. Gleichzeitig ist die Chance, sich in kleinen Details zu verlieren, sehr groß. Diese werden oft sehr eingehend und liebevoll behandelt und binden sehr viel Aufmerksamkeit. Entscheidungs- und Verantwortungsbereitschaft. Um Misserfolge zu vermeiden, werden Entscheidungen immer wieder nach hinten verschoben. Damit verbunden sinkt die Bereitschaft, Verantwortung für Entscheidungen zu tragen, stattdessen versucht man, diese so weit als möglich an voroder nachgelagerte Instanzen zu delegieren.

Kognitive Notstandsgesetze Wird eine komplexe Situation subjektiv als bedrohlich wahrgenommen, so erzeugt dieser gefährliche Umstand generell eine kognitive Notfallsituation.

94


Das gesamte eigene Handlungssystem wird auf schnelle Reaktionsbereitschaft umgestellt. Dabei wird die notwendig hohe Reaktionsbereitschaft durch ein zu hohes intellektuelles Niveau behindert, da es jetzt die Zeit zum Handeln und nicht zum Denken ist! Infolgedessen gibt es keinen Raum mehr, eigenes Tun und Denken zu rekapitulieren oder kritisch zu hinterfragen. Dabei ist das menschliche Verhalten in bestimmten Situationen oft davon geprägt, bestimmte Dinge gedanklich vorwegzunehmen. „Erst tue ich das, dann tue ich jenes. Falls das und das eintritt, werde ich das und das tun müssen!“ Der weitgehende Ausfall solcher Vorwegnahmen hat die Zersplitterung des eigenen Denkens zur Folge und führt in unzusammenhängendes und unzureichendes Denken! Stattdessen stehen schnelles, unüberlegtes Handeln sowie stereotype Denkmuster immer mehr im Mittelpunkt: Es werden immer wieder dieselben Denksequenzen durchlaufen, „bewährte“ Handlungsschemata werden konstant angewandt. Es wird dabei nicht wahrgenommen, dass dies Anzeichen für das Absinken der Selbstkontrolle sind. Um sich in einer Situation angepasst verhalten zu können, ist es jedoch notwendig zu wissen, von welcher Beschaffenheit die Situation ist, um darin vernünftig handeln zu können. Dies ist in kognitiven Notfallsituationen nicht mehr der Fall, was zur Folge hat, dass automatisch nach globalen, stark vereinfachten Teilhypothesen gesucht wird. Aus diesen wird eine globale Gesamthypothese abgeleitet, in der alles auf eine zentrale Ursache zurückgeführt werden kann. Solche „reduktiven“ Hypothesen sind in diesem Augenblick äußerst attraktiv für den Betroffenen. Sie beseitigen auf einmal die eigene Unsicherheit und erwecken den Eindruck, dass man das ganze Problem nun durchschaue. Da der rettende Strohhalm gefunden wurde, versteift man sich auf diese Hypothese und sucht in solchen Notfallsituationen nur noch nach deren Bestätigung, nicht aber deren Widerlegung. Die Folge ist, dass man sich hinter den eigenen Ideen verschanzt und nicht mehr offen ist für Alternativen; eigene Erfahrungen, welche die aufgestellte These widerlegen könnten, werden nicht mehr wahrgenommen.

Auswirkungen Zwar sind Softwareprodukte – ähnlich wie Flugzeuge – auch absturzgefährdet, jedoch werden Sie mir an dieser Stelle möglicherweise entgegnen, dass dieser Vergleich zwischen IT-Entwicklung und dem Stress im Flugsimulator überzogen sei. Dies mag in einem bestimmten Maß der Fall sein. Allerdings schleichen sich gerade in der Softwareentwicklung durch die Latenz der Komplexität regelmäßig mehrere Feinde ein, die das Feuer der Produktkomplexität erneut anschüren:


95

x Die persönlichen Rückzugseffekte und Vereinfachungen als Folge von Überforderung finden sich regelmäßig bei Mitarbeitern wieder und werden zu oft und zu schnell als „Flurgerede“ umgemünzt. Dass hier vielfach ein ganz anderes Phänomen existiert, was durch zu stark vereinfachte Hypothesen zu Nicht-Beachten von Zusammenhängen führt und damit Fehlern auf allen Stufen der Softwareentwicklung Tür und Tor öffnet, bleibt unberücksichtigt. x Das Erfassen von größeren Zusammenhängen, wie auch die interne Kommunikation hierüber, von deren immenser Bedeutung bereits die Rede war, wird rückläufig sein. Alle Welt ist nur noch an schnellen Lösungen interessiert, das eigene Tun im notwendigen Maß zu hinterfragen bzw. diskutierbare Hypothesen zu bilden, bleibt aus. Die Folge sind die berühmten Quick-and-Dirty-Lösungen, die zwar Resultate liefern, aber gleichfalls für dauerhafte Probleme während des Lebenszyklus sorgen (Versteegen et al. 2003). Hierdurch kommt es zum späten Erkennen von Problemen. Da die wechselseitigen Abhängigkeiten intransparent geblieben sind und jeder Eingriff Fremd- und Nebenwirkungen an anderen Stellen auslöst, werden Fehler begangen, die nicht mehr zu korrigieren sind. Das System bewegt sich dabei auch ohne äußeres Zutun kontinuierlich weiter und entwickelt dabei seine eigene, oftmals unerwünschte Dynamik (Dörner 2006). 4.1.3 Kurzausflug ins Gehirn Man kann ein Problem nicht mit den gleichen Denkstrukturen lösen, die zu seiner Entstehung beigetragen haben. (Albert Einstein) War im letzten Abschnitt die Rede von den reaktiven Effekten auf wahrgenommene Komplexität, so geht es nun um einige Aspekte des menschlichen Gehirns, einem wahren Meister bei der Bewältigung komplexer Aufgaben. Ein einfaches Beispiel: Sie gehen am Strand spazieren, Abermillionen von Nervensensoren bzw. Sinnesorganen registrieren dabei Ihre Umwelt, Ihre Körperhaltung, Ihre Gangart oder mögliche Gefahren. Diese werden in Echtzeit als Hintergrundprozesse ausgewertet und lassen Ihnen alle Freiheiten, über schöne Sonnenuntergänge oder nette Menschen zu philosophieren. Trotzdem laufen diese Wahrnehmungssysteme auf vollen Touren, was Sie sehr schnell an Ihren eigenen Reaktionen merken, wenn Sie z. B. auf einen spitzen Gegenstand treten: Auf einmal interessiert die Philosophie nicht mehr, stattdessen spüren Sie, was unter Ihnen stattfindet, denken auch nicht mehr an die hübsche Sonne, sondern reißen Ihren Fuß hoch und betrachten den entstandenen Schaden. 99% der eingehenden Informationen wurden dabei zwischenzeitlich ausgewertet und gefiltert.

96


Alles, was Ihr Bewusstsein erreicht, ist nur noch das impertinente Signal „stechender Schmerz an der Fußsohle“. Da es den Rahmen dieses Buches bei weitem sprengen würde, in die Gehirnforschung in der notwendigen Tiefe einzusteigen, werde ich hier nur einige relevante Prinzipien zusammenfassen, die für die Lösung komplexer Aufgabenstellungen von Bedeutung sind.

Dynamik und Statik im Wechselspiel Wie schafft es das Gehirn, dass Sie in Echtzeit diese Zeilen lesen und gleichzeitig die Inhalte bewerten können, ohne dass Ihnen dabei der Kopf raucht? Ihr Gehirn ist in der Lage, aus vielen auf der Netzhaut registrierten Bildpunkten Buchstaben, Wörter und Sinnzusammenhänge in Echtzeit zu erfassen und auszuwerten. Dabei muss die Information noch nicht einmal vollständig sein. Sie können Wörter auch dann spontan erkennen, wenn nur der erste und letzte Buchstabe richtig sind und der Rest der Buchstaben in etwa darin vorkommt. Das Gehirn arbeitet dabei sehr ökonomisch, indem es schrittweise Informationen abstrahiert und diese danach in verdichteter Form zusammensetzt. Auf dem Weg zum Ziel ist dabei die Architektur und das Zusammenspiel der einzelnen Gehirnareale ein wichtiger Lösungsbestandteil. Immer wieder gleichartige Datenanalysemethoden sind hintereinander geschaltet und wandeln die eingehenden Sinneswahrnehmungen schrittweise in einen internen Symbolismus um. Dabei arbeitet das Gehirn mit hierarchischen Metabeschreibungen, die sich inkremetell iterativ voneinander ableiten. Im Rahmen dieser Prozessschritte alternieren dynamische und statische Komponenten mit hoher Effizienz über diverse Stufen hinweg (Hamilton 1995). Eine strenge Trennung der Überarbeitungsschritte fehlt insofern, als Metainformationen späterer Prozessstufen durchaus mit sehr viel früheren Prozessstufen zusammengeschaltet werden können. Ob Sie nun einen Gegenstand fühlen, riechen, sehen oder hören – Sie wissen jeweils, dass es sich um ein und dasselbe Objekt handelt (Singer 2006). Am Beispiel des Sehens werden die Nervensignale der Augen nach bestimmten Gesichtspunkten zerlegt, um aus bestimmten Mustern Zwischenergebnisse zu synthetisieren. Dieses Raster aus Zwischenergebnissen wird dann wiederum einer nächsten Schicht zur Analyse übergeben, um auf einem nächsthöheren Abstraktionsniveau den gleichen Prozess zu wiederholen (Fukushima 1987). Statt also von einer Menge Bildpunkte direkt auf die entsprechenden Lösungen zu kommen, werden relativ einfache statische Filter mit lernfähigen Komponenten gekoppelt und suchen z. B. aus dem Rohbild alle Striche einer bestimmten Ausrichtung heraus. – Dieses „Strichbild“ dient dann einer nächsten Verarbeitungsstufe, die z. B alle sich kreuzenden Striche ausfindig macht. Hier


97

wieder könnte eine nächste Stufe darin bestehen, dass aus diesen sich kreuzenden Strichen alle Rechtecke gefunden werden etc. Insgesamt sind die Strukturen des Gehirns sehr konservativ aufgebaut. Bewährte Methoden werden durchgängig eingesetzt. Dadurch wird eine hohe Kompatibilität zwischen den einzelnen „Baugruppen“ erreicht. Auch wenn die Grundparadigmen festliegen, so ist die Vorgehensweise des Gehirns niemals statisch, sondern stellt ein ausgewogenes Gleichgewicht zwischen festen Regeln und dynamischem Verhalten zur Verfügung. Dabei wirken kurz-, mittel- und langfristige Steuergrößen als beeinflussende Faktoren des Gesamtsystems. – Als Projektmanager würde ihr Gehirn niemals ausschließlich auf kurzfristige Kundenwünsche reagieren, weil daraus ein Zickzackkurs entstünde. Vielmehr würde eine grundsätzlich veränderbare mittelfristige Planung zugrunde liegen, mit deren Hilfe kurzfristige Änderungen bewertet werden, ehe sie zur Realisierung kommen. Gleichermaßen werden aber viele Kurzfriständerungen Einfluss auf die mittelfristige Strategie nehmen und diese schrittweise modifizieren.

Datenspeicher Da unser Gehirn ein gigantisches Speichermedium ist, existieren zwei stark voneinander abhängige Mechanismen von höchster Wichtigkeit, um dieses Wissen zu sammeln und auch wieder nutzbar zu machen. Dieser Punkt ist mittlerweile durch das moderne Wissensmanagement erschlossen worden, es entsteht jedoch immer noch der Eindruck, dass er nicht bis in alle Entwicklungsabteilungen Einzug gehalten hat. Die Rede ist von Speicher- und Suchstrategien. Auf der einen Seite bedarf es Strukturen, die rasch und ökonomisch Informationen aufnehmen, auf der anderen Seite ist es jedoch notwendig, dass diese Informationen möglichst rasch und eindeutig wiedergefunden werden. Für unser Gehirn gilt dabei Ähnliches wie für Datenbanken: Informationen, denen ein „Suchschlüssel“ beigefügt ist, sind sehr viel einfacher zu finden, als solche, bei denen dies nicht der Fall ist. Zwei Beispiele hierzu: Denken Sie an die berühmten Eselsbrücken (= Suchschlüssel), mit deren Hilfe Sie sehr rasch bestimmte Informationen parat haben. Wie anders ist doch die Situation, wenn Sie Ihren Haustürschlüssel verlegt haben und krampfhaft Ihr Gehirn durchforsten, um herauszubekommen, wo der Schlüssel abgelegt wurde. Haben Sie ihn dann endlich gefunden, so wird es Ihnen meistens wieder einfallen, dass Sie diesen genau dort abgelegt hatten. Auch wenn allgemein gesagt wird, man habe den Ablageort des Schlüssels „vergessen“, so ist korrekt, dass Sie sich keine Assoziation gemerkt haben, als Sie den Schlüssel dort abgelegt haben. Spätestens der „Ach ja, ich erinnere mich“-Effekt verdeutlicht dies. Apropos Assoziation, – dies ist eine der ganz starken Seiten des Gehirns:

98


zu assoziieren, also Aspekte, die irgendwie etwas miteinander zu tun haben, zueinander in Bezug zu bringen. Systeme wie das Gehirn sind nur dann flexibel und adaptiv, wenn Lernen und Vergessen im Gleichgewicht bleiben. Im Gegensatz zum Beispiel zuvor bedeutet Vergessen an dieser Stelle, dass Sie aufgrund neu gemachter Erfahrungen alte Suchschlüssel gewissermaßen „wegschmeißen“ und damit Informationen quasi löschen. Haben Sie es mit Systemen zu tun, die ausschließlich lernen, so werden Sie binnen kurzer Zeit einen gigantischen Parcours an Regeln vor sich haben, bei der jede einzelne Regel (oder Erfahrung) in Erinnerung gebracht und angewandt wird, ehe man zum entsprechenden Resultat gelangt. In Folge entsprechen solche Systeme sehr schnell einem völlig starren Neu-Preussischen Beamtenstaat mit schwindender Flexibilität und vielen zeitintensiven bürokratischen Zwischeninstanzen. Dynamik und Optimierung werden mehr und mehr zu Fremdworten – und auch gelegentliches Ausmisten von Regeln trägt wenig zur Verbesserung des Gesamtzustandes bei, da bedingt durch die grundsätzliche Vorgehensweise sehr schnell neue Regeln die entstehenden Lücken wieder auffüllen. – Haben Sie andererseits keine Möglichkeit zum Lernen, so werden Sie Fehler immer und immer wieder machen – eine Verbesserung des Ist-Zustandes ist nicht möglich. Aus diesem Grunde ist auch hier das Gehirn ein hervorragendes Vorbild, hält es doch – es sei denn, Sie sind schwer dement – beides im Lot: Im Sinne der oben erwähnten reflexiven Rückkopplungen können alte Erfahrungen durch neue graduell verändert und schrittweise ersetzt werden. Auf diese Weise lernen wir aus unseren eigenen Fehlern und optimieren kontinuierlich unsere eigenen Vorgehensweisen, ohne (meistens) ein immer kompliziertes Regelwerk an Benimmregeln aufzustellen. Auf diese Weise können wir uns als Menschen sich verändernden Situationen flexibel anpassen. Übertragen auf den projekttechnischen Alltag bedeutet dies, dass neue Regeln immer dann aufgenommen werden, wenn gleichzeitig geprüft wurde, welche alten Regeln hierfür gestrichen werden können. Dadurch wird auch die eigene Organisation lernend und somit adaptiv (Senge 1994).

Umgang mit Informationen Informationen, die mehr als einmal im System vorkommen, erzeugen Zweideutigkeiten. Denken Sie an die berühmten Vexierbilder, bei denen – je nach Blickweise – für den einen dies und für den andern jenes zu sehen ist. Künstler wie Dali, Escher oder Arcimboldo haben sich dies in ihren Gemälden zunutze gemacht (Seckel 2004). Wir werden nur das eine oder das andere sehen – oder Kopfschmerzen bekommen. Das Gehirn hat somit Mechanismen zum Assoziieren, gleichzeitig aber verlangt es eindeutige Festlegungen in der einen oder anderen Richtung, was übrigens die Voraussetzung für


99

logisches Denken und Handeln ist! Nur so ist es möglich, dass die verschiedenen Sinneskanäle sich am Ende der Verarbeitungskette auf dasselbe Objekt referenzieren. Genau diese Ökonomie der Informationen ist ein wichtiges Risikokriterium innerhalb von Projekten. Liegen Planungsdaten oder technische Angaben mehr als einmal vor, so können diese Informationen binnen kürzester Zeit z. B. wegen Vergesslichkeit hinhaltlich divergieren. Im Nu bezieht sich der eine Mitarbeiter auf Aussage A und der andere auf Aussage B. Die Folgen sind hinreichend bekannt. Um die vorhandenen Informationen sinnvoll zu nutzen, arbeitet das Gehirn „ganzheitlich“. Dabei belegt die Gehirnforschung, dass ohne das Vorhandensein von Emotionen (z. B. weil die für die Emotionen verantwortlichen Teile des Gehirns zerstört wurden) eine Folgerichtigkeit des Denkens und das Urteilsvermögen in sozialen Situationen nicht gegeben ist. Dies gilt selbst dann, wenn die Intelligenz, sofern es sich um Faktenwissen handelt, nicht betroffen ist (Ratey 2003). Dies macht deutlich, dass selbst für reine „Sachprojekte“ die Emotionalität einen wichtigen Einfluss hat, da sie direkt mit der mittel- und langfristigen Güte des Resultats in Bezug zu setzen ist. Gerade die Fähigkeit sinnvoller Entscheidungsfindung ist hiervon stark betroffen. – Somit entsteht eine direkte Beziehung zwischen effektivem Erarbeiten logischer Zusammenhänge und dem emotionalen Kontext, in welchem dieses stattfindet. Um ein Problem auszutüfteln, ziehen sich viele Menschen gerne in ein für sie ungestörtes und entspannendes Umfeld zurück und versuchen auf diese Weise, Spannungen und Unruhe auszuweichen. – Bezogen auf Softwareprojekte entsteht somit sehr schnell die Frage, in welcher Weise solch eine „Ruhe“ in ein Projekt eingebracht werden kann.

Modellhaftes Denken Die Art und Weise, wie wir Informationen verarbeiten, geschieht mit sogenannten mentalen Modellen (Dutke 1994). Dieser Begriff wurde 1983 vom Psychologieprofessor Philip N. Johnson-Laird (Princeton University) geprägt. In seinen grundlegenden Forschungsarbeiten zur Kognitionspsychologie stellte er hiermit ein neues Konzept zur Erklärung der Wirklichkeitswahrnehmung, der Problemlösung und der Informationsverarbeitung im Gehirn auf. Simpel gesprochen entspricht das Konzept der mentalen Modelle und der kognitiven Landkarten folgender Aussage: „Ein Bild sagt mehr als tausend Worte.“ Somit ist ein mentales Modell das Abbild der Wirklichkeit in der menschlichen Wahrnehmung. Gedächtnis, Wirklichkeitswahrnehmung, Problemlösung und alle anderen Denkleistungen beruhen auf der Anwendung dieser Abbilder. Vor allem aber begründet der Ansatz der mentalen Modelle die überragende Bedeutung von Visualisierungsmethoden. Insbesondere für zeitliche Abläufe besitzen wir keine Sinneswahrnehmung,

100 4 Von der Krisis zur Katharsis

so dass wir sie ausschließlich über abstrakte mentale Modelle planen und gestalten können. Folgerichtig haben nicht von ungefähr grafische Editoren oder Darstellungsformen (etwa UML) längst ihren Platz in der ITEntwicklung gefunden. – Im Gegenschluss ließe sich hier auch fragen: Wo setzen wir im Entwicklungsalltag noch zu wenig diese grundlegende Erkenntnis ein und nutzen innerhalb der IT-Prozesskette zu wenig Visualisierungsmittel? Insgesamt gilt, dass Menschen nach den von ihnen konstruierten mentalen Modellen handeln. Je besser diese Modelle und deren Fähigkeit zur Modellbildung sind, desto besser ist die Fertigkeit in der Handlung selbst (Baumgartner 1993). Dabei werden, das belegt die Forschung, komplexe Situationen mit anderen Modellen gelöst als einfache. Personen die Erfahrung mit komplexen Situationen haben, sind im Allgemeinen deutlich erfolgreicher, als diejenigen mit wenig Erfahrung (vgl. Pilot im Landeanflug versus fliegerischer Amateur im Simulator). Für den Projektkontext leiten sich hieraus folgende Punkte ab: Zum einen ist zu fragen, was konkret getan wird, um bei den Mitarbeitern diese Modellbildung und deren aktive Adaption und Nutzung zu fördern. Zum anderen ist festzustellen, dass der aktiv unterstützte Transfer von Erfahrungen zwischen erfahreneren und weniger erfahreneren Projektmitgliedern zwecks Steigerung des Projekterfolgs eine wichtige Rolle spielt. Dies findet übrigens in gut funktionierenden Teams nahezu automatisch ohne Anstoß von außen statt. In diesem Sinne wird teaminternes Coaching zum wichtigen Baustein.

Wert der Kreativität Um noch ein wenig bei der menschlichen Informationsverarbeitung zu bleiben: Eine der besonderen Stärken des menschlichen Genius ist seine Kreativität. Durch Verknüpfen von nicht ganz alltäglichen Aspekten entstehen neue Gedankenkonstrukte und Ideen. Edward deBono hat in diesem Zusammenhang eine Theorie des kreativen Denkens und Handelns entwickelt (deBono 2005), in der er das sogenannte laterale Denken dem vertikalen Denken (logisches Schlussfolgern, Auswählen und Bewerten von Alternativen, Konzentration auf das Relevante) gegenüberstellte. Dabei ist für deBono laterales Denken dem kreativen Denken gleichgesetzt. Der erste Schritt zur Kreativität ist das Verstehen des kreativen Prozesses und das Überwinden von kreativitätshemmenden Faktoren. Vertikales Denken ist dabei selektiv, analytisch und folgerichtig. Scheinbar Belangloses wird ausgeschlossen, dafür wird jedoch kategorisiert, klassifiziert und Kenngrößen vergeben, um daraus den erfolgreichsten Weg abzuleiten. Auf dem Hintergrund der bereits vermittelten Fakten über die Natur der Komplexität wird schnell klar, dass hiermit zwar ein Weg, nicht notwendigerweise aber

4.1 Dynamik, Chaos und Komplexität 101

ein Gesamtoptimum gefunden wird, da versteckte Muster und Abhängigkeiten weiterhin verborgen bleiben. Laterales Denken hingegen ist generativ und versucht Richtungen und Trends zu finden. Dabei muss nicht sofort jeder Schritt korrekt sein, auch die Betrachtung sehr exotischer Wege ist legitim. Nach deBono geht es darum, eingefahrene Denkgewohnheiten zu überwinden, indem beherrschende Vorstellungen und Denkwege erkannt und Alternativen gesucht werden. Aufgrund der unübersehbaren Fülle der im menschlichen Gehirn ständig zu verarbeitenden Informationen folgen die Wahrnehmung und Informationsverarbeitung normalerweise den bereits erwähnten eigenen mentalen Modellen, also bestimmten bevorzugten und „eingefahrenen“ Wegen der Problembehandlung, die sich über die Zeit bewährt haben. Laterales Denken (und damit Kreativität) bedeutet nun: Statt gewohnheitsmäßig auf diesen „Datenautobahnen“ zu fahren, wird nun mit einem lateralen Sprung auf ein Nebengleis gewechselt. Hiermit werden die üblichen Wege der Problembearbeitung verlassen und es kann zu ungewöhnlichen Lösungen kommen. Dabei helfen die Techniken der mentalen Provokation und des lateralen Denkens. Auf diese Art und Weise soll ein Denken in Gang gesetzt werden, das nicht von bestimmten, bereits festgelegten Prinzipien ausgeht und auch nicht zu nur einem einzigen richtigen Schluss kommt. Während das vertikale Denken die herkömmliche Denkweise mit aufeinander folgenden und logischen Schritten repräsentiert, beschreibt laterales Denken also einen Prozess und steigert zugleich die Wirksamkeit des vertikalen Denkens, indem es ihm alternative Lösungsansätze aufzeigt. Beide Denkstile ergänzen sich somit! Laterales Denken verändert dabei die eigenen Denkmuster und schafft so eine Neustrukturierung des vorhandenen Wissens. Statt nach der „richtigen“ Antwort zu suchen, werden so ganz andere, bisher unberücksichtigte Lösungswege sichtbar. Indem vertikales Denken die Ideen weitertreibt, die das laterale Denken hervorgebracht hat, können neue Lösungswege gefunden werden. 4.1.4 Komplexität entwirren Das Kunsturteil des Dilettanten und des Meisters unterscheiden sich darin, dass ersterer dabei das Kunstwerk mit sich in Einstimmung zu bringen sucht; letzterer sich mit dem Kunstwerke. (Franz Grillparzer, österr. Schriftsteller) Soweit der Ausflug in die Welt des menschlichen Geistes! Konkret gilt es nun zu klären, wie der Komplexitätsproblematik praktisch begegnet werden


kann. Den einfachsten Lösungsweg zur Vermeidung von Komplexität gebe ich Ihnen in Anlehnung an eine Zeitungsannonce weiter: x x x x x x

Machen Sie keine Geschäfte mehr. Reduzieren Sie Ihre Erledigungen auf null. Gehen Sie nicht mehr aus dem Haus. Kommunizieren Sie mit niemandem mehr. Hören Sie auf zu atmen. Schließen Sie sich in einen Raum ein.

Mit anderen Worten: Sie haben keine Möglichkeit der Komplexität zu entfliehen. Auch ist es nicht sehr wahrscheinlich, dass Sie den Grad an Komplexität a priori senken können. Statt also Mauern gegen diesen Ansturm der Komplexität zu errichten, sollten Sie vielmehr Windmühlen bauen, um diese Kraft der Komplexität zu nutzen. – Natürlich: Jeder liebt die Vielfalt, aber nicht unbedingt die Komplexität.

Lösungsansätze Um also der Komplexität z. B. bei der Erstellung einer passenden ITArchitektur so zu begegnen, dass nicht am Ende alles noch komplizierter wird, bedarf es einiger Werkzeuge. Kommen Techniken, wie z. B. das laterale Denken, zum Einsatz, so ist es möglich, die Probleme hinter den Problemen zu ermitteln und so zu den eigentlichen Fragestellungen zu gelangen. Auf diese Weise ergeben sich Möglichkeiten, Metamodelle im Sinne ihrer Wortbedeutung zu bilden und aus ihnen technische Lösungen zu abstrahieren. Was nützt es, wenn Sie von Ihren Stakeholdern eine Liste von Wünschen in Bezug auf das neue Produkt erhalten und Sie nicht ausreichend darüber nachgedacht haben, was die eigentlichen Wünsche des Kunden hinter den beschriebenen Fragestellungen sind. Indem Sie diese Denkprozesse unterlassen und zu schnell in den technischen Lösungsbereich wechseln, haben Sie in den meisten Fällen bereits die Fundamente für übermäßig komplizierte und unelegante Lösungen gelegt. Was für die Erfassung der Anforderungen galt, gilt in synonymer Weise für die Planung einer technischen Lösung. Anhand von Abb. 4.1 wird dies verdeutlicht. Es lassen sich dabei mehrere Effekte studieren. Gesetzt den Fall Abb. 4.1(1) gibt buchhalterisch genau alle Wechselwirkungen in einem Projekt wieder, so ergibt dies ein Meer aus Strichen, die letztendlich in ihrer Gesamtheit für den Betrachter nicht mehr handhabbar sind, da ihre interne Logik nicht zu durchschauen ist. Wenn jedes Element mit fast jedem anderen irgendwie in Beziehung steht, dann wird es undurchschaubar und extrem kompliziert (Gerok 1989). Dies ist übrigens das klassiche Problem bei der Erfassung von Anforderungen in großen Projekten. Die vielen einzelnen Wünsche, Randbedingungen und


auch widersprüchlichen Aussagen der befragten Stakeholder eines Projektes liefern genau diese Situation. Wie sollen hier Strukturen herausgearbeitet, Absprachen über die Anpassung von Anforderungen geführt oder eine Basisarchitektur abgeleitet werden? Unser Gehirn ist, wie wir sahen, so gebaut, dass es nach Mustern sucht und aus diesen Grundmustern wiederum Metaformen zusammensetzt, die ihrerseits die Grundmuster für noch kompliziertere kognitive Wahrnehmungsmuster bilden. Im Sinne der oben beschriebenen Prozesse geht es also darum, schrittweise (Abb. 4.1(2)) zu erkunden, was wichtig oder unwichtig ist. Dies ist exakt die Vorgehensweise, wie sie bei der Aufnahme und Vereinfachung von Anforderungen sowie der Erarbeitung einer IT-Basisarchitektur in komplexen Projekten notwendig ist. Durch eine Art des „Try and Error“ werden in einer iterativen Vorgehensweise geeignete Lösungsansätze herausgeschält. Schrittweise und in Verbindung mit der Fähigkeit zum Abstrahieren (= vertikales Denken) sowie der Fähigkeit, aus völlig anderen Blickwinkeln ein Problem zu betrachten (= laterales Denken), wird allmählich dieser wechselseitige Beziehungsurwald gerodet und konsolidiert. Am Ende dieses Prozesses (Abb. 4.1(3)) werden die tatsächlich wichtigen Strukturen ersichtlich. Indem diese Vorgehensweise z. B. in der Anforderungserfassung genutzt wird, tritt ein wichtiger Nebeneffekt ein. Wenn Sie einen Blick auf

Abb. 4.1. Vom Chaos zur Ordnung


Abb. 4.1(3) werfen, so finden Sie auch hier Striche – jedoch nur noch die wesentlichen. Beim näheren Betrachten der Zeichnung z. B. im Sinne von: „wer darf wem was sagen“, fällt auf, dass diese Abbildung nicht schlüssig ist, weil sie eine zirkuläre Befehlskette enthält! Somit hat reifes Anforderungsmanagement einen prozessinternen Widerspruch aufgedeckt und kann nun, statt sklavisch alle gelieferten Anforderungen zusammenzuschrauben, erst für die Auflösung dieses Widerspruchs sorgen. Ist dies geschehen, so können sehr viel klarere Anforderungen samt deren Abhängigkeiten für eine IT-technische Planung zur Verfügung gestellt werden. Um zu diesem Ergebnis zu gelangen, waren mehrere wichtige Prozessschritte notwendig: Das Durcheinander wechselseitiger Abhängigkeiten musste auf die wirklich wichtigen Abhängigkeiten reduziert werden, was keine triviale Aufgabe war. Aus den so freigelegten Abhängigkeiten, die auf den ersten Blick nicht aufgefallen wären, konnte dann auf einer höheren Abstraktionsebene das wirkliche Problem herausgeschält werden. Je klarer eine Struktur ist, desto weniger komplex erscheint sie uns. Bei diesem Vorgehen sollte idealerweise ein zweiteiliger Prozess – eine Art iterativ-inkrementelles Arbeiten – stattfinden: Aus der Vielzahl der Möglichkeiten werden in einem Entdeckungsprozess mögliche Kandidaten ausgewählt. In einem zweiten Akzeptanzschritt (Gigerenzer 2000) wird entschieden, ob dies ein Muster ist, das man behalten möchte. Auf diese Art und Weise werden aus einer unstrukturierten Gemengelage an Informationen, also einer komplexen Struktur, schrittweise die signifikanten Strukturen ermittelt und somit transparent gemacht. Vielfach wird diese Vorgehensweise intuitiv angewandt. Sie trifft übrigens in synonymer Weise auch für die Entwicklung einer IT-Architektur zu! Statt bereits in frühen Projektphasen technische Modelle zu malen, wird es auf diese Weise möglich, sehr früh generelle Strukturen zu erarbeiten, mit denen grundsätzliche Konzepte für Themen wie Stabilität, Nutzbarkeit, Wartbarkeit etc. geklärt werden können, ehe die Detailarbeit an Modulen, Objektstrukturen etc. beginnt. – Wie viel effektiver wäre wohl Softwareentwicklung, wenn Mitarbeiter aktiv in solchen Vorgehensweisen ausgebildet wären und sie zum Einsatz brächten! Softwareplanung und Realisierung heißt somit, unter Verwendung iterativer Prozesse die verborgenen Grundstrukturen möglichst klar freizulegen. Je sauberer dies in allen Teilschritten geschieht, umso klarer wird die technische Lösung und umso geringer der Komplexitätszuwachs sein. Der Grundgedanke an sich ist dabei keineswegs neu. Bereits Dijkstra forderte 1976 die Modularisierung von Programmen, um so der Komplexität begegnen zu können. Diese Modularisierung, wie sie in jeder höheren Programmiersprache bekannt ist (Programmierung von Unterprogrammen), bezieht sich jedoch in erster Linie auf funktionale Aspekte. Mir geht es an dieser Stelle darum, den beschriebenen Ansatz in ganzer Breite zu betrachten und dies nicht auf Untermengen, wie Objektorientierung oder Schichtenmodelle


der IT, zu begrenzen. In der Informatik sind manche Schritte in dieser Richtung bereits getan worden, dennoch bilden sie erst die Spitze des Eisbergs.

Projektalltag Zum Abschluss dieser Betrachtung komme ich noch einmal anhand von Abb. 4.2 auf Aspekte des Projektmanagements zu sprechen. Zunächst eine allgemein gültige Beobachtung: Fast jedes Projekt neigt dazu, dass es zum Ende hin, bedingt durch Unwägbarkeiten, Termindruck oder Kostendruck, in unterschiedlichem Maß Kompromisse und Abkürzungen eingeht. Nur selten werden klare technische oder planerische Strukturen durchgängig beibehalten. Stattdessen treten Verwaschungen in allen Aspekten des Projektes auf, da Änderungen notwendig wurden, Fehler auftraten oder unberücksichtigte Aspekte integriert werden mussten. Kurz: Projekte haben im Sinne der Abbildung einen gewissen Haloeffekt, der sie mehr oder minder stark in weniger strukturierte Bereiche, also entsprechend der Grafik nach rechts oben zieht. Wie aus der Gegenüberstellung verschiedener Prozessmodelle in Tabelle 3.1 (S. 82) deutlich wurde, gab es dort zwei Cluster von Prozessmodellen. In der einen Gruppe mussten alle Anforderungen früh und vollständig

Abb. 4.2. Wenn Komplexität zum Feind wird


vorliegen. Die andere Gruppe, bestehend aus den agilen Prozessmodellen, arbeitete bewusst mit zunächst unvollständigen Anforderungen. In der Ecke rechts oben von Abb. 4.2 finden sich solche Vorgehensweisen bei der Softwareproduktion wieder, die ohne Planung, also unstrukturiert und ungeplant ablaufen. In hohem Maße sind sie in ihrer Projektstruktur extrem kompliziert bis anarchisch. Es sind diejenigen Projekte, auf die die Volvo-Studie (S. 44) referenzierte, als von hohen Einsparungen durch Verbesserung des CMM-Levels die Rede war. Gerade solche Software, deren Entwicklung durch z. B. den nachfolgenden Hintergrund ausgelöst wurde, ist für spätere anarchische Zustände ein besonders prädestinierter Kandidat. Die Geburtsstunde solcher Applikationen lässt sich häufig auf folgenden Satz zurückführen: „In unserem Fachgebiet gab es keine entsprechende Software, also haben sich unsere Fachspezialisten in Programmiersprachen und Datenbanken selber eingearbeitet und angefangen, schnell das zu programmieren, was sie brauchen.“ Was zunächst nur als schnelles und vorübergehendes Provisiorium gedacht war, etablierte sich zur Dauerlösung. Nicht ungewöhnlich ist es dann, wenn andere Anwender aus derselben Sparte Interesse an diesem „Produkt“ zeigen – und schon ist die Improvisation zur Qualitätssoftware avanciert. In Folge werden Weiterentwicklungen und Ergänzungen notwendig, die das Ganze immer komplizierter werden lassen und einem evolutionären Wildwuchs in den Folgejahren Raum geben. Es liegt in der Natur der Softwareentwicklung – und dies gilt für statische, agile und unstrukturierte Projekttypen (vgl. Abb. 4.2) –, dass Applikationen aus Sicht der Anforderungen und der Technologien im Laufe der Zeit langsam nach rechts oben diffundieren: Die Strukturiertheit der Anforderungen ist aufgrund von Sonderfällen oder unsauberem Nachdokumentieren rückläufig. Die Technik veraltet langsam, sodass Herstellerpatches, Workarrounds oder Ersatztechnologien die ursprünglich klaren Linien aufweichen. Wichtig ist an dieser Stelle vor allem, dass fehlende Planung, Unerfahrenheit und mangelnde ganzheitliche Betrachtungsweisen signifikanten Einfluss darauf haben, wie schnell sich vorhandene Software und Infrastruktur dorthin bewegen. Wurde z. B. eine unreife IT-Basisarchitektur im oben beschriebenen Sinne erarbeitet oder überhaupt nicht eingebracht, sondern sofort Lösungen kodiert, so werden rasch unzulängliche Komponenten offenbar. Auch werden sehr früh Software-Komponenten ergänzt oder erweitert werden müssen. Da sich fast jede Softwarekomponente weiterentwickelt, setzt eine deutliche Driftbewegung in vage Technologieaspekte ein. Dies geht mit ganz erheblichen produkt- und projektbezogenen Risiken einher. Insgesamt entsteht hierbei immer wieder der Eindruck, dass hochkarätige Fachleute, die nicht aus der IT stammen, sich eine Lösung basteln, wobei sie keineswegs geplant vorgehen, sondern nach intuitiven Lösungen suchen.

4.2 Systemisches Denken und Handeln 107

Im Sinne ingenieurmäßigen Vorgehens ist unten links der stabilste Bereich anzusiedeln: Mit großer Systematik wird nach Erstellung eines Pflichtenhefts erst konstruktuiert und anschließend die Software gebaut. Alles was nicht im Pflichtenheft vorkommt, wird im Idealfall nicht realisiert. Der Vorteil: Projekte werden überschaubar und bleiben steuerbar. Ebenfalls liefern diese Vorgehensweisen, wenn umsichtig gearbeitet wurde, eine klare und saubere „Konstruktion“ der kommenden Software. Was allerdings nachgeordnet ist, sind späte Änderungs- oder Ergänzungswünsche durch den Auftraggeber. Wenn das primäre Ziel darin besteht, dem Auftraggeber möglichst lange die Chance zu geben, Dinge zu ändern oder zu ergänzen, so müssen unspezifizierte Teile und somit Dynamik in Kauf genommen werden. Dies leitet sich schon aus der Definition agiler Prozesse ab. Wie Abb. 4.2 zu entnehmen ist, sind agile Projekte von vornherein aufgrund der unscharfen Startbedingungen als schwierig oder komplex zu betrachten. Somit ist es in gewisser Weise ein Spiel mit dem Feuer der Eigendynamik eines Projektes, sich auf Agilität einzulassen, da durch diese Vorgehensweise letztendlich die projekttechnische Drift in Richtung Komplexität und Chaos aktiv unterstützt wird. Nicht ohne Grund weisen daher verschiedene agile Verfahren darauf hin, dass hier erfahrenes Projektmanagement äußerst wichtig ist, um nicht die sensible Balance zwischen Statik und Dynamik aus dem Lot zu bringen.

4.2 Systemisches Denken und Handeln Wenn es einen Weg gibt, etwas besser zu machen: Finde ihn! (Thomas Alva Edison) Sozio-technische Systeme werden immer komplexer. Um unter diesen Voraussetzungen optimale Lösungen zu finden, sind dynamische (Verhalten) und komplexe (Vielfalt) Aspekte zu berücksichtigen. Verfahren der Modellierung (Reduktion der Vielfalt) und Simulation (Berücksichtigung der Dynamik) unterstützen die Lösung solcher Fragestellungen insbesondere dann, wenn viele Einflussgrößen zusammenspielen. Um den eben beschriebenen Spagat zwischen Statik und Dynamik bewerkstelligen zu können, aber auch die eigentlichen Probleme oder Lösungswege effektiv zu finden, ist ganzheitliches Denken und Handeln notwendig. In den meisten Alltagssituationen haben wir es mit Problemen zu tun, die sich ohne Schwierigkeit mit gesundem Menschenverstand und Logik lösen lassen. Gesellschaftliche, wirtschaftliche und auch IT-technische Probleme weisen jedoch, wie bereits diskutiert, vernetzte Zusammenhänge, Abhängigkeiten und die Wechselwirkung vieler Einflussfaktoren auf. Ebenso


wurde bereits deren Veränderungsdynamik über die Zeit erwähnt. Diese macht es oft unmöglich, durch lineares Denken und normales Wissen die Zusammenhänge hinreichend gut zu erkennen. Genau dieses leisten jedoch Ansätze des systemischen Denkens, um die es im Weiteren gehen wird. Ein Beispiel, an welchem sich der Unterschied zwischen traditioneller Analyse und dieser Art zu Denken klar aufzeigen lässt, sind Ernteausfälle durch Insektenbefall. Fallen Insekten ein und zerstören so die Ernte, dann besteht die klassische Reaktion darin, Pestizide zur Tötung des Ungeziefers zu versprühen. Um die Sache nicht unnötig zu verkomplizieren, gehe ich hier von einem idealen Pestizid aus, das genau diese Insektenart vernichtet und dabei keine Boden- oder Wasserverschmutzung hervorruft. Das, was auf den ersten Blick logisch und sinnvoll erschien, führt gemäß Langzeitstudien des MIT14 zu völlig anderen Ergebnissen! Faktoren, die sich in folgendem einfachen Zusammenhang wiederfinden: „Du beseitigst die eingefallenen Insekten, indem du Pestizide versprühst, danach ist dein Problem gelöst“, haben eine mittelfristige janusköpfige Antwort: Durch den Einsatz der Pestizide gegen Insektentyp A wurde ein Freiraum für Insektentyp B geschaffen mit der Folge, dass sich B jetzt sehr viel schneller verbreiten kann und in mindestens gleicher Größe Ernteschäden anrichtet! Wird nun die gleiche Denkweise wie zu Anfang eingesetzt, so kommt die nächste chemische Keule zum Einsatz und das Ganze wiederholt sich in ähnlicher Weise. Zwar sind die Insekten der IT virtueller Natur (= Bugs), dennoch gibt es im Softwarebau durchaus vergleichbare Probleme. Über eines wurde gerade erst gesprochen: Wenn ich meine Kunden schnell zufrieden stellen kann, so werde ich ihnen viel Raum für Änderungswünsche geben. Ich riskiere damit jedoch einen extra Zuwachs an Komplexität, weil ich nicht sauber ingenieurmäßig arbeite. Erhöhte Komplexität bedeutet höhere Fehlerwahrscheinlichkeiten und Folgeaufwände. Diese wiederum können mein Zeitoder Kostenbudget gefährden. Ist daher schnelle Kundenzufriedenheit in meiner konkreten Situation tatsächlich die beste Lösung?

Vernetztes Denken Die Ansätze, in dieser Art zu denken, gehen zurück auf das Jahr 1956, als Prof. Jay Forrester vom MIT feststellte, dass es Ähnlichkeiten bei der Überprüfung von neuen Ideen im sozialen wie auch technischen Kontext gibt. Systemisches Denken erlaubt es den Beteiligten, ihr eigenes Verständnis über soziale Zusammenhänge explizit zu machen und diese Fähigkeiten in gleicher Weise auszubauen, wie dies in der Technik geschieht. Hierbei unterscheidet sich die methodische Vorgehensweise grundsätzlich 14

Massachusetts Institute of Technology. Hochschule für Ingenieurwissenschaften in Cambridge bei Boston


von den traditionellen Formen der Analyse. Beim analytischen Arbeiten konzentriert man sich darauf, größere Einheiten in immer kleinere Teile zu zerlegen. Im Gegensatz hierzu geht es beim vernetzten Denken darum, dass vor allem festgestellt wird, wie Dinge miteinander interagieren. Daraus leitet sich das Zusammenspiel einer Gruppe von Elementen ab und wie dieses zu einem bestimmten Verhalten führt. Statt immer kleinere Teile voneinander zu separieren und hieraus z. B. Taxonomien zu bilden, geht es beim systemischen Denken darum, Wirkzusammenhänge zu verstehen und die beeinflussenden Stellgrößen immer besser kennen zu lernen. Auf diese Weise können völlig andere Schlussfolgerungen über ein Systemverhalten gezogen werden, als dies durch den analytischen Ansatz möglich ist. 4.2.1 Wege des Denkens Um Begriffsverwirrungen vorzubeugen, werde ich als Nächstes einige ähnlich lautende Begriffe definieren und gegeneinander abgrenzen. Die Frage lautet: Was sind die Unterschiede zwischen systematischen, synthetischem und systemischem Denken oder dem Denken in Systemen – und was zeichnet diese Formen jeweils aus? Systematisches Denken. Hierbei wird methodisch über Dinge nachgedacht und aus den Ergebnissen Kausalabhängigkeiten abgeleitet. Wenn immer Sie sich überlegen, welche Attribute Sie einer Liste mit Aufgaben geben sollen, um bestimmte Problemkreise zu überwachen oder abzuarbeiten, denken Sie systematisch. Ein wichtiger Bestandteil dieser Denkweise sind Kausalketten: Wenn A = 1 und B = 2, so ist A + B = 3. Am Rande bemerkt: Jedem Programmierer sind solche Kausalketten in Fleisch und Blut übergegangen, da die logischen Konstrukte der verschiedenen Programmiersprachen genau solche Kausalketten abbilden. Der wohl plakativste Vertreter ist die „if … then … else“-Anweisung, die es in allen Programmiersprachen gibt. – Die Welt aus einer anderen Brille zu betrachten ist daher für viele Softwareentwickler keineswegs trivial, sondern muss oftmals im Sinne eines echten Changeprozesses mühsam erlernt werden. Synthetisches Denken. Nein, hierbei geht es nicht um Denkvorgänge einer intelligenten Maschine, auch wenn der Name dazu verführt. Mit einer kurzen Anleihe bei der modernen Medizin erklärt sich schnell, worum es sich hierbei tatsächlich handelt. Das Fundament der Medizin besteht aus dem dualistischen Konzept des kausal-analytischen Zugangs einerseits und dem intuitiv-synthetischen Verständnis andererseits. Analytisches Denken führt, wie wir sahen, zu objektiven, rational einsehbaren Erkenntnissen. Intuitiv-synthetisches Denken hingegen sucht die Ganzheit einer Situation und tritt dazu wieder einen Schritt von der Detailebene zurück. Richtig


verstandene Formulierung von Vision-Dokumenten in IT-Projekten machen sich übrigens diese Vorgehensweise ebenfalls zunutze. – Diese Art zu Denken ist nicht identisch mit der bereits behandelten Kreativität, obwohl es hier eindeutige Schnittmengen gibt. Systemisches Denken. Wie bereits kurz dargestellt handelt es sich hierbei um das Aufspüren von Wechselwirkungen. Es wird darüber nachgedacht, nach welchen Regeln Dinge aufeinander Einfluss nehmen. Ein Beispiel: Sie haben ein Programm gebaut, das aufgrund seiner Funktionalität vom Kunden sehr geschätzt wird. Da diese Applikation für einen überschaubaren, abgeschlossenen Zielmarkt gedacht ist, kennen sich viele Kunden und reden miteinander über dieses Produkt. Wird die Software von den Anwendern als gut und nützlich empfunden, so werden diese mit Kollegen anderer Firmen aus dieser Community positiv darüber reden. Wenn alles gut geht, entsteht durch diese Mund-zu-Mund-Propaganda ein Schneeballeffekt, durch den Sie recht schnell mehr und mehr Einheiten absetzen können. Der gleiche Mechanismus wird aber auch funktionieren, wenn die Software oder der Support qualitativ nicht mehr stimmen. Wiederum wird geredet. Dieses Mal jedoch negativ! Die Folge ist der Teufelskreis einer Abwärtsspirale, bei der Sie mit jeder verkauften Einheit den Kreis der negativ redenden Nutzer erweitern. Denken in Systemen. Das letztgenannte Beispiel geht fließend in den Bereich des Denkens in Systemen über. Dabei definiert sich ein System als ein Arrangement aus Regeln und Prinzipien, die miteinander in Bezug stehen, interagieren und voneinander abhängen. (Ihr Softwareproduktionsprozess für einen speziellen Kundenauftrag ist ein solches System.) Alle Bestandteile eines Systems stehen in Bezug zu dem übergeordneten Thema. Gleichzeitig unterscheiden sich die Bestandteile eines Systems in hohem Maße voneinander und befinden sich in teilweise komplexen Wechselwirkungsbeziehungen. – Somit ist hier nicht nur die Frage nach den Wechselwirkungen von Objekten zu klären, sondern vor allem auch herauszufinden, wo die tatsächlichen Systemgrenzen verlaufen. – Genau hiermit haben Sie den Brückenschlag zu dem vollzogen, was in Abb. 4.1 (S. 103) über das Abstrahieren der wesentlichen Grundmuster gesagt wurde. Letztendlich wurde dort Denken in Systemen so eingesetzt, dass das eigentliche System herausgearbeitet und isoliert wurde, um danach das freigelegte Wissen über das System weiter nutzbar zu machen. Systemtheorie. Am besten wird dieser Begriff mit einer Beschreibung aus dem Jahr 1956 definiert. Dort beschrieb A. D. Hall Systemtheorie wie folgt: „Es handelt sich hierbei um eine Anzahl von Objekten und den Beziehungen zwischen den Objekten sowie deren Eigenschaften.“ Die Systemtheorie ist


also eine Theorie, die versucht, die Erscheinungen und Gesetzmäßigkeiten unterschiedlichster komplexer Systeme mit Hilfe einheitlicher Begriffe und Werkzeuge verstehbar und bearbeitbar zu machen. Dazu verwendet sie die folgende Definition: „Eine Menge von meist recht vielen Elementen, die in ihrer Verschiedenheit zusammenarbeiten und als Ganzes ein bestimmtes Verhalten, nämlich das des Systems, aufrechterhalten.“ Hierbei spielt die Komplexität in unterschiedlichen Graduierungen eine wichtige Rolle. So ist immer dann von Detailkomplexität die Rede, wenn ein Problem mehrere Variable aufweist, die gleichzeitig zu beachten sind. Von dynamischer Komplexität spricht man dann, wenn Situationen auftreten, in denen Ursache und Wirkung nicht in direkt sichtbarem Bezug zueinander stehen. (Senge 1994, S. 71–72). Senge definiert dabei dynamische Komplexität so, dass diese vorhanden ist, wenn ein sehr deutlicher Unterschied zwischen kurzfristigen und langfristigen Effekten sichtbar wird. Systemische Vorgehensweise. All diese Bereiche stehen in engem Bezug mit der Kybernetik. Dieser Begriff wurde von Norbert Wiener, dem Vater dieser Disziplin, festgelegt und wie folgt definiert: „Es ist die Kunst, sehr komplizierte Systeme zu handhaben und zu lenken.“ – An dieser Stelle schließt sich der Kreis und liefert eine mehr technische Definition zum systemischen Ansatz. Diese lässt sich, abstrakt gesprochen, in folgender Formel zusammenfassen: Systemtheorie + Kybernetik = Systemische Vorgehensweise Etwas weniger formelhaft wurde es von J. de Rosnay, einem prominenten Zukunftsforscher am MIT beschrieben. Seine Definition lautete: „The systemic approach should, from invariant, properties and behaviours of complex systems, lead to general rules helping to better understand systems and to act on them.“ – Nach J. de Rosnay folgt der systemische Ansatz den folgenden drei Schritten: 1. Systemanalyse: Sie identifiziert die Grenzen, die wichtigsten Komponenten, sowie deren Interaktionen. 2. Systemmodellierung: Ausgehend von der Systemanalyse findet diese statt und legt die Abhängigkeiten und Beziehungen zwischen den einzelnen Objekten fest. 3. Systemsimulation: Hier wird das zeitliche Verhalten eines Systems studiert. Versteht man Softwareentwicklung als ein systemisches Gebilde, so lässt sich dieser Dreischritt nahezu direkt auf den Entwicklungsprozess übertragen, bestehend aus Anforderungserfassung (= Systemanalyse), ITArchitektur (= Systemmodellierung) sowie Bau und Verifikation der Software (= Systemsimulation).


Mit einer Gegenüberstellung der analytischen und systemischen Vorgehensweisen (Tabelle 4.1) schließe ich diese begrifflichen Abgrenzungen: Tabelle 4.1. Unterschied zwischen analytischem und systemischem Ansatz Analytischer Ansatz

Systemischer Ansatz

Konzentration auf isolierte Elemente

Konzentration auf das Zusammenspiel der Elemente

Konzentration auf die Art des Zusammenspiels

Konzentration auf die Effekte des Zusammenspiels

Das Augenmerk liegt auf den Details

Das Augenmerk liegt auf der globalen Perspektive

Man ändert immer nur jeweils eine Größe Es werden mehrere Systemgrößen gleicham System zeitig verändert Jedes Element wird unabhängig betrachtet Es wird das ganze System betrachtet Der Vorgang ist reversibel

Der Vorgang ist nicht reversibel

Systemisches Denken – praktisch Mit Bezug auf Abb. 4.3 geht es nun um die Konkretisierung dieser Art des Denkens. Entsprechend der gegebenen Definition ist analytisches Denken auf die Untergliederung und Systematisierung eines Themenbereiches ausgerichtet: In diesem Analyseprozess wird nach kleineren Bestandteilen gesucht. Beim synthetischen Denken werden diese Bausteine wieder zu einem Größeren zusammengesetzt. Kombiniert man beides (Abb. 4.3(1)), so ergibt sich hieraus systemisches Denken. Eine Ursprungsthematik wird hierbei durch kausal-analytische Prozesse in verschiedene Unterthemen zerlegt (Abb. 4.3(1A)), wobei die Bildung dieser Unterthemen dadurch stattfindet, dass ähnliche Muster als solche erkannt und zu verallgemeinerten Sichten zusammengefasst werden. Betrachtet man ein Problem z. B. aus unterschiedlichen Blickwinkeln, so entstehen mehrere parallele Sichten zu einem Ursprungsthema (Abb. 4.3(1B)). Diese Themen werden während der Synthese durch intuitiv-synthetisches Vorgehen miteinander verglichen (Abb. 4.3(1C)), um so die wahrscheinlichste Sicht (Abb. 4.3(1D)) zu ermitteln. Da diese Vorgehensweise alleine nicht ausreicht, muss sie in einen zirkulären Prozess eingebettet sein (Abb. 4.3(2)). Indem diese Kombination in einem iterativen Prozess durchlaufen wird, gelangt man zu einem systemischen Regelkreis. Am Ende ist eine solche Abstrahierung nur dann gut, wenn sie tatsächlich die Wirklichkeit in geeigneter Weise beschreibt. Hierzu müssen Ursprungsthematik und abstrahierte Thematik, also Wirklichkeit und Hypothese,


Abb. 4.3. Analytisches und systemisches Denken

miteinander verglichen und bewertet werden. Je nachdem, wie diese Bewertung ausfällt, ist der Prozess zu wiederholen, zu verfeinern oder kann beendet werden. Diese Vorgehensweise an sich, die letztlich auch wissenschaftlichem Arbeiten entspricht, muss von dem Deming-Zyklus15 (Abb. 4.3(3)), der sich hinter der iterativ-inkrementellen Arbeitsweise der IT verbirgt, klar abgegrenzt werden. Dies ist von großer Bedeutung in der Realisierungsphase des Projektes. Werden diese Einzelteile zu einem Ganzen zusammengesetzt (vgl. Abb. 4.4), so wird deutlich, dass mit Hilfe dieser Vorgehensweisen die vielfach unstrukturierten Kundenwünsche im Rahmen der Anforderungserfassung konsolidiert werden. Frühzeitig sind sowohl auf Seiten der Anforderungen wie auch auf Seiten der IT-Architektur Hypothesen möglich, die es zu überprüfen gilt. Gleichzeitig erfolgt eine Abstrahierung und Verdichtung auf die signifikanten Themenbereiche des Kunden. In Interaktion mit diesem werden hier die tatsächlichen Problemfelder herausgearbeitet. – Durch diesen zwischengeschalteten Bereich (Abb. 4.4, Mitte) gehen Anforderungserfassung und Architektur Hand in Hand miteinander voran, 15

W. Edward Deming war der Schöpfer des PDCA-Zyklus (Plan-Do-Check-Act), weshalb dieser synonym auch als Deming-Zyklus bezeichnet wird.


Abb. 4.4. Systemisches Arbeiten begrenzt Komplexitätszuwachs

befruchten sich dabei wechselseitig und gestatten eine maximale Optimierung der kommenden Lösung. Insgesamt erfolgt hierdurch eine starke Systematisierung der Aufgabenstellung. Schrittweise werden so Hypothesen zu konsolidierten Anforderungen und Lösungskonzepten, wobei die Kundenwünsche in Form der identifizierten Anforderungen Eingang finden. Zugleich kommt es zu einer Optimierung im Sinne einer Vermeidung unnötiger Komplexität. Die so konsolidierten Anforderungen und Lösungswege stellen dann das Ausgangsmaterial für ein klassisch iterativ-inkrementelles Arbeiten im Sinne Demings dar. 4.2.2 Ganzhirniges Arbeiten Nachdem ich Ihnen die eher prozessuale Seite systemischen Denkens nahe gebracht habe, möchte ich mich nun der Performance Ihres eigenen Denkapparates zu wenden und diese hiermit in Bezug setzen. Das menschliche Großhirn besteht aus zwei symmetrischen Hälften mit unterschiedlichen Funktionen. Bereits der griechische Arzt Hippokrates stellte an Verwundeten aus den Perserkriegen fest, dass die Schädigungen bestimmter Hirnareale mit dem Verlust spezifischer kognitiver Leistungen


einher gehen. Im Laufe der Zeit wurde immer klarer, dass die beiden Hemisphären (= Hälften) unseres Großhirns zwar äußerlich symmetrisch angelegt sind, sich jedoch funktional unterscheiden. So ist die linke Gehirnhälfte Sitz des Sprachzentrums, denkt in Sprache und Begriffen und ist dabei logisch und analytisch. Menschen mit einer Dominanz dieser Hemisphäre lösen ihre Probleme daher logisch, analytisch, Schritt für Schritt und bevorzugen Zahlen sowie Fakten. Das Rohmaterial der Gedanken, die aufblitzenden Ideen, die Bilder und auch alle Sinneseindrücke bearbeitet hingegen die rechte Gehirnhälfte. Diese denkt unmittelbar in Bildern, verarbeitet Informationen, intuitiv und nutzt räumliche, farbige wie auch dynamische Modelle. Rechtshirnige Menschentypen suchen oft gestaltgebende Tätigkeiten. Sie denken an vieles gleichzeitig und beginnen mehrere Tätigkeiten auf einmal. Der Rechtshirn-Typ löst seine Probleme intuitiv, mit Gefühl für „Ganzheit“. Diese Kenntnisse gehen auf den Nobelpreisträger Roger Sperry und seiner Hemisphärentheorie zurück. In den 60er Jahren durchtrennte Sperry bei schwerstkranken Epilepsiepatienten das Corpus Callosum, den Verbindungsstrang zwischen den Gehirnhälften. Hierdurch wurde die Epilepsieerkrankung der Patienten gelindert, es traten jedoch spezifische Defizite bei der Denkfähigkeit auf, die Sperry näher untersuchte. Trägt man einige der typischen Eigenschaften der jeweiligen Gehirnhälften gegeneinander auf, so ergibt sich für die meisten Menschen die folgende Aufteilung: Linkshirnig digital sprechen und schreiben analytisch analysiert mathematisch zeitlich orientiert die Zeit Objektebene logisch merkt sich Namen linear, detailliert kontrolliert analytisch spricht das Wort bewusstes Verarbeiten

Rechtshirnig analog klangliches Musikempfinden holistisch spekuliert symbolisch räumlich orientiert der Raum Metaebene figurativ merkt sich Gesichter intuitiv, kreativ emotional träumerisch sieht das Bild unbewusstes Verarbeiten


Beide Gehirnhälften haben zwar ihre Schwerpunkte, arbeiten aber im Parallelbetrieb zusammen. Das Gehirn selbst arbeitet dann am effizientesten, wenn möglichst viele funktionale Bereiche beteiligt sind. Dies wird übrigens durch Studien an Schülern belegt. Diejenigen, die in solch ganzheitlicher Weise arbeiteten, waren entsprechend dieser Studie überdurchschnittlich gut in Mathematik. Dennoch setzen viele Menschen diese Fähigkeit kaum oder garnicht ein. Sie denken und erinnern „einseitig“, das heißt rechts- oder linkshirnig. Zwar können wir den internen Betrieb des Gehirns nicht beeinflussen, aber es lassen sich sehr wohl Techniken und Arbeitsmethodiken erlernen, die diese ausgewogene Nutzung des Gehirns unterstützen. Es scheint übrigens so zu sein, als sei dies ein Gegenwartsproblem des modernen Menschen infolge der zunehmenden Spezialisierung. Man kann nachweisen, dass in der Antike die Welt ganzheitlich betrachtet wurde. Gelehrte des Altertums vertraten und beherrschten häufig Natur- und Geisteswissenschaften wie z. B. Mathematik oder Medizin und Philosophie gleichzeitig. Dies ist in der heutigen Zeit aufgrund des ungeheuren Fachwissens so sicherlich nicht mehr möglich, weshalb wir je nach Neigungen und Aufgaben stärker die rechte oder die linke Gehirnhälfte nutzen. Andererseits beweisen große Multitalente oder Genies, wie etwa Leonardo da Vinci, Goethe oder Einstein, dass ganzhirniges Denken nicht nur in der Antike möglich war. Auch wenn Sie und ich nicht dieses Maß an Begabung mitbringen sollten, so lassen sich ganzheitliches Denken und Lernen gezielt als Fähigkeiten entwickeln und nutzen, was eine Effizienzsteigerung der eigenen Arbeitsweise zur Folge hat. Behält man das ganze System im Auge und betrachtet es ganzheitlich, so lassen sich viel umfassendere Implikationen ableiten und daraus systemweite Entscheidungen treffen. Sehen Sie nur Teilaspekte, so kann Ihnen schlimmstenfalls etwas passieren, wie es im nachfolgenden Beispiel geschildert wird. Mit zunehmender Komplexität von Systemen und Prozessen ist ganzheitliches Denken und Handeln sowohl auf technischer Seite wie auch managementseitig dringend notwendig. Erfolgreiche Manager bewältigen diese Herausforderung, indem sie ganzheitlich vernetztes Denken mit analytischem Vorgehen kombinieren. Sie behalten in komplexen Situationen den Überblick und durchschauen vernetzte Zusammenhänge. Sie schätzen Chancen und Risiken ab und planen Maßnahmen zielbezogen und strategisch. Verborgene, aber potentiell gefährliche Entwicklungen werden frühzeitig erkannt. Hoch komplexe Sachverhalte werden auch im Team effektiv und strukturiert bearbeitet. Diese Führungspersönlichkeiten wenden somit Denkweisen an, mit denen sie der komplexen Realität erstaunlich gut begegnen können. Auf diese Weise vermeiden sie die typischen Fehler, die sonst beim Umgang mit komplexen und vernetzten Systemen auftreten können.


Softwarebau kann, gerade was die fatalen Konsequenzen aus unsachgemäßem Umgang mit Komplexität und Dynamik anbelangt, sehr viel von Katastrophen, die ausschließlich auf einer Kette falscher Entscheidungen und Missachtung der vorgestellten Prinzipien beruhen, lernen. – Die Fehlerkette, die dabei im Kontext einer Softwareentwicklung abläuft, wird vermutlich nicht, wie im nachfolgenden Beispiel, eine riesige Strahlungswolke freisetzen oder entsprechende Umweltschäden anrichten, kann aber durchaus Millionenbeträge kosten, wenn man z. B. an die verlorene Ariane-Rakete als Folge eines Softwarebugs denkt. – Die Chance, dass durch eine Verkettung von Umständen aufgrund von Ignoranz, reaktivem Denken und Unkenntnis gewaltige wirtschaftliche Schäden entstehen können, ist eindeutig.

Der Tschernobyl-Faktor Für Tschernobyl ist durch Studien belegt worden, dass die Katastrophe zu 100% auf psychologische Faktoren zurückgeführt werden kann (Dörner 2006). Da es in diesem Buch um Software geht, möchte ich mich nur knapp auf die dort erarbeiteten Grundelemente beziehen und nicht eine bekannte Historie neu nachzeichnen16. In Essenz lassen sich die psychologischen Ursachen wie folgt zusammenfassen: Durch Überdosierung von Maßnahmen, die unter hohem Zeitdruck erfolgen mussten, sowie durch die Unfähigkeit, Neben- und Fernwirkungen des Gesamtverhaltens und Systems im notwendigen Maß abschätzen zu können, sowie durch die Unterbewertung von exponentiellen Abläufen wurde diese Katastrophe in Gang gesetzt. All dies sind Faktoren, die – wie gezeigt wurde – auf den mangelnden Einsatz ganzheitlichen Denkens hinweisen. Hinzu kamen in Tschernobyl noch zwei weitere nicht zu unterschätzende Grundaspekte: Die Kraftwerksmannschaft war gerade kurz vorher für ihre hohe Zeit „am Netz“ ausgezeichnet worden. Sie sah sich also als eine Truppe sehr erfahrener Reaktorfahrer an, die ihren Reaktor mehr aus Intuition statt ganzheitlich analytisch steuerte. Diese Gruppe hatte „gelernt“, Grundregeln zu missachten oder elementare Regeln der Zweckmäßigkeit halber zu umgehen. Dabei war der Lerneffekt dadurch entstanden, dass durch Missachtung von Regeln zeitsparende Abkürzungen erreicht wurden und zunächst keine sichtbaren Nachteile durch diese Unterlassungen auftraten. Insgesamt fand hier ein Gruppendenken statt, bei der ein eingeschworener Kreis an Entscheidungsträgern (hier die Reaktorfahrer) die Sicherheitsempfehlungen und Ratschläge wegrationalisierte und aus dieser rollenbedingten Selbstüberheblichkeit in die Katastrophe hineinraste. 16

Die Details über den Hergang in Tschernobyl in Hinblick auf die verhängnisvolle Verkettung von Fehlentscheidungen wird in dem Buch von D. Dörner „Die Logik des Misslingens“, (Dörner 2006, S. 47–57) hervorragend beschrieben.


Solche „Schnell-schnell“-Effekte sind übrigens in der Softwareentwicklung nichts Unbekanntes. Quick-and-Dirty-Lösungen oder zu frühe Umsetzung eines nur unvollständig verstandenen Entwicklungsauftrags arbeiten dabei nach exakt derselben Dynamik!

Schlankes, aber komplexes Denken Komplexes Denken tut not – und das nicht nur in Kernkraftwerken! Der komplexe Denker hat sich eine ganze Reihe von Denktechniken erarbeitet und ist in der Lage, diese in den entsprechenden Situationen einzusetzen. Ihm ist es gegeben, in innovative Ansätze einzusteigen, dabei aber durchaus Dinge auch kritisch zu hinterfragen. Neue Informationen werden rasch mit bereits erworbenen Aspekten in Bezug gesetzt und ganzheitlich zugeordnet. Für den ganzheitlich Denkenden ist es wichtig, neue Gedankengänge zu bewerten und diese ggf. in ein größeres Ganzes einzubringen. Die Tatsache, dass sich bestimmte Aspekte in der Vergangenheit bewährt haben, verführen ihn nicht dazu, alte Lösungen blind zu iterieren, da er sich immer wieder neben sich selbst stellt, um die eigenen Denkansätze kritisch zu hinterfragen und hieraus eigene Schlüsse zu ziehen. Eine Spielart aus dieser Vorgehensweise ist das „Lean Thinking“. Das Konzept des schlanken Denkens stammt aus der japanischen Managementpraxis nach dem Ende des Zweiten Weltkriegs. Insbesondere Taiichi Ohno (1912–1990), damals der strategische Kopf von Toyota, wird mit dieser industriellen Produktionsweise in Verbindung gebracht. Durch die berühmte MIT-Studie „The Machine That Changed The World“ (Womack, Jones et al. 1991) wird der revolutionäre Ansatz dieser Methode erstmals einer breiten Öffentlichkeit vorgestellt. „Lean Thinking“ wird dabei als dritte Phase eines unumkehrbaren Prozesses verstanden, der mit der handwerklichen Produktion begann, danach zur großvolumigen und standardisierten Massenproduktion führte, um schließlich in variable und kleinvolumige Serien überzugehen. Hierdurch ist es möglich, den oft unberechenbaren Marktschwankungen bzw. differenzierteren Kundenansprüchen besser und schneller gerecht zu werden. Im Detail werde ich auf die Lean-Ansätze in Kap. 5.3 (S. 142 ff.) eingehen und diese mit der Softwareproduktion in Bezug setzen.

4.3 Emergente Meme Software ist eine Kombination aus hochstrukturierten, in sich verschachtelten Kausalmodulen, die als formale Befehlsketten und in Verbindung mit Daten auf geeigneten Speichermedien abgelegt wurden, um von dort aus

4.3 Emergente Meme 119

für die Steuerung ganz spezieller Prozessoren herangezogen zu werden. Dabei sind diese Entitäten nicht mehr gedanklicher Natur, da diese ständig fluktuieren können, aber auch nicht stofflicher Natur. Vielmehr lässt sich Software als das formalsprachlich abgelegte Kondensat iterativ gewonnener und verdichteter logischer Gedanken interpretieren, das eigenen Gesetzmäßigkeiten folgt. In einem Artikel von Nicolas El Baze (El Baze 2005) beschreibt dieser, wie die Entwicklung der Informationstechnologie seit über 40 Jahren durch das Moore’sche Gesetz geprägt worden ist. Zur Erinnerung: Im Jahr 1965 sagte Gordon Moore, der Mitbegründer von Intel, voraus, dass sich die Anzahl der Schaltelemente auf einem Chip je Quadrat-Inch alle zwei Jahre verdoppeln werde und dass dieser Trend kontinuierlich sei. Bis heute stimmt seine Aussage und wird immer noch als offizielle Sicht von Intel kommuniziert. Zugegeben, das ist Hardware, aber innerhalb der Software gibt es vergleichbare Gesetzmäßigkeiten. Konkret denke ich an Nathans Gesetz aus dem Jahr 1997. Der CTO der Firma Microsoft Nathan P. Myhrvold sprach damals über die kommenden 50 Jahre Softwareentwicklung. In diesem Kontext schrieb er der Software dieselben Fähigkeiten wie ein Gas zu: Es füllt stets den gesamten zur Verfügung gestellten Raum aus, und zwar so lange, bis das Moore’sche Gesetz zum begrenzten Faktor wird. In Erweiterung hierzu wird immer wieder auch der menschliche Intellekt als begrenzender Faktor gesehen. In Anlehnung an die Gesetze der Thermodynamik möchte ich diese Eigenschaft zum Ausgangspunkt für einige Hauptsätze der IT-Entwicklung machen. Dazu ist es notwendig vorher noch das Emergenzprinzip einzuführen und zu erläutern. 4.3.1 Software-Emergenz Emergenz bezeichnet in Philosophie und Psychologie das Phänomen, dass sich bestimmte Eigenschaften eines Ganzen nicht aus seinen Teilen erklären lassen. Dies kommt auch durch den verbreiteten Spruch „Das Ganze ist mehr als die Summe seiner Teile“ zum Ausdruck. Dabei ist Emergenz eine wichtige Eigenschaft von komplexen bzw. nichtlinearen Systemen. Diese Systeme können Eigenschaften entwickeln, die sich aus der Summe ihrer Einzelkomponenten nicht erklären lassen. Lassen Sie mich dazu den Begriff der „Emergenz“ umreißen: Hierunter versteht man das Entstehen neuer Strukturen aus dem Zusammenwirken von Elementen in einem komplexen System. Als emergent werden Eigenschaften bezeichnet, die erst im Verbund vieler Einzelteile auftreten. Um diese


Eigenschaft zu bewältigen, betritt man einen Bereich, bei dem Indeterminismus17 und Nicht-Linearität18 zu ständigen Wegbegleitern werden. Emergenz ist ein Synonym für ‘Springen’, wenn damit gemeint ist, dass ein Vorgang nicht kontinuierlich, sondern eben ‘sprunghaft’ verläuft. Derartige Prozesse lassen sich weder voraussagen noch ableiten. So verhält sich z. B. die Thermodynamik emergent. Nimmt man hierbei die Luft als Summe vieler Einzelmoleküle, bei denen jedes einzelne den Stoßgesetzen folgt, so erklären diese Gesetze keineswegs die aerodynamischen Gesetzmäßigkeiten. Hierfür bedarf es sehr vieler Luftmoleküle als Voraussetzung für das Zustandekommen dieser neuen Gesetzmäßigkeiten. In diesem Sinne kann z. B. das Entwicklungsteam einer Software als emergentes Team verstanden werden. Jede einzelne Person folgt bestimmten Regeln und Maximen. Kommt es zur Zusammenarbeit, bei der die Einzelnen bestimmte Rollen wahrnehmen, so treten auch hier Emergenzen auf: Das Team entwickelt nach ihm eigenen Gesetzen. Wird in eine bestehende Applikation ein neues Subsystem integriert, also mit den anderen Systemelementen durch Wirkbeziehungen verknüpft, kann das System neue, emergente Eigenschaften aufweisen, die nicht vorhersehbar waren. – Gründe sind hierfür: x Das System ist bereits so komplex, dass es ohne Reduktion nicht untersuchbar oder simulierbar ist. x Es entstehen zwischen den Systemelementen neue Verbindungen, Wirkbeziehungen und Prozesse, die nicht vorgeplant waren. x Die Kopplungen oder Wirkbeziehungen zwischen allen Elementen werden durch die Integration des neuen Elementes verändert. Sicherlich kennen Sie dieses Phänomen: Sie haben eine große Software bauen lassen, sagen wir in der Programmiersprache Java, und stellen fest, je komplexer die Software wird, desto langsamer läuft das Ganze. Unter Umständen wird Ihre Software am Ende so langsam sein, dass Sie nicht einmal mehr die geforderten Performance-Kriterien erfüllt, obschon alles andere genial geplant und gebaut wurde. – Übertragen auf den Begriff der Emergenz bedeutet dies: Java ist an sich eine Programmiersprache, in der einzelne Softwareobjekte schnell von einem Prozessor abgearbeitet werden. Als 17

18

In deterministischen Systemen sind alle kommenden Ereignisse aufgrund feststehender Gesetzmäßigkeiten vollständig bestimmbar. Der Apfel, der vom Baum fällt und hierbei dem Gesetz der Schwerkraft folgt sei hier als Beispiel genannt. Im Gegensatz dazu stehen indeterministische Systeme, bei denen – z. B. durch Zufälle oder Verkettung von Umständen – vieles wegen mangelnder Gesetzmäßigkeiten nicht vorhersagbar ist. – Dies entspricht dem Projektalltag in Softwareprojekten. Lineare Systeme erlauben diskrete Schritte, die nacheinander abgearbeitet werden können. Sie sind somit die Voraussetzung für echtes ingenieurmäßiges Planen und Arbeiten.


emergente Eigenschaft kann jedoch ein deutlicher Performanceverlust bei sehr großen Objektstrukturen auftreten. Dieser Effekt mag in der Praxis immer wieder so auftreten und weist auf einen oft unberücksichtigten Zusammenhang mit der inhärenten Komplexität und Größe der entstandenen Software hin. – Anders als vor ca. einer Dekade, als das Problem in begrenzter Hardware zu suchen war und hierdurch die bereits betrachtete „Softwarekrise“ (vgl. S. 64 ff.) ins Dasein gerufen wurde, begegnen wir hier einer Krise ganz anderer Art. – Moderne Programmiersprachen, Konstruktionswerkzeuge und Vorgehensweisen implizieren leicht, dass man diese Softwareobjekte in nahezu beliebiger Größe und beliebiger Schachtelungstiefe anlegen kann – was prinzipiell richtig ist. – Allerdings bezahlen Sie für diese Vereinfachung auf Programmseite einen mehrfachen Preis: Der erste besteht darin, dass solche Programme, die über viele Klassen verschachtelt sind, fast einem Krebsgeschwür ähnlich Raum (also Speicher) für sich in Anspruch nehmen – dieses Problem ist im Wesentlichen gelöst. Anders sieht es aber aus, wenn Sie sich die sogenannten „Stack-Operationen“ anschauen. An jeder Objektgrenze werden die Daten des Prozessors ausgelagert, um die Daten der neuen Klasse oder des neuen Objektes zu übernehmen. Bei Rückkehr aus diesem Objekt wird diese Information wieder zurückgeholt. – Je größer und tiefer verschachtelt solche Objektstrukturen werden, umso mehr Zeit verbringt der Prozessor damit nichts weiter zu tun, als diese Informationen zu laden und zu entladen, zu laden und zu entladen. 4.3.2 Hauptsätze der Softwareentwicklung In gewisser Weise hat Software Engineering fast thermodynamische Eigenschaften, die unabhängig vom Projekt sich entsprechend den Naturgesetzen immer wieder aufs Neue bestätigen. Es entsteht leicht der Eindruck, dass dieses Fluidum aus Bits und Bytes ähnlichen Gesetzmäßigkeiten folgt wie Gas. Nicht nur dass immer größer werdende Applikationen gasförmigen Charakter haben, indem sie sich einem Gas ähnlich bis an technische und andere Grenzen ausdehnen. Gleiches gilt auch für Softwareprojekte an sich: Egal wie viel Zeit und Ressourcen Sie für ein Projekt ansetzen, Sie können davon ausgehen, dass diese restlos aufgebraucht werden. – Auch Gas füllt umgehend den zur Verfügung gestellten Raum vollständig aus! Somit liegt es nahe, aus diesem Pendent einige Erfahrungstatsachen abzuleiten.

1. Hauptsatz der IT (Energieerhaltung) Im ersten Hauptsatz der Thermodynamik geht es um Energieerhaltung: Jedes System besitzt eine innere Energie. Diese kann innerhalb des Systems


in unterschiedlichen Formen vorliegen oder überführt werden. Die Gesamtsumme bleibt jedoch unverändert. Verschiedene Energieformen können sich demnach ineinander umwandeln, aber Energie kann weder aus dem Nichts erzeugt werden noch vernichtet werden. Die Energie der Software hat ihre Entsprechung in der Komplexität. Dabei kann die Komplexität niemals niedriger werden als diejenige des Problems, anders als in der Physik hat sie jedoch die Tendenz, nahezu irreversibel zuzunehmen. Dieses Gesetz lässt eine Implikation zu. Segmentiert man das Gesamtproblem geschickt und sorgt für handhabbare Verbindungsstücke, so lässt sich ein großes Problem in Teilprobleme zerlegen, ohne dass hierdurch die Komplexität zunimmt. Das Geheimhaltungsprinzip von Parnas bringt dies am klarsten zum Ausdruck.

2. Hauptsatz der IT (Entropie) Entropie beschreibt die „Unordnung“ eines Systems, wobei die Gesetze der Thermodynamik klar ausdrücken, dass jedes System von sich aus den Zustand größtmöglicher Unordnung anstrebt. Am Ende herrscht somit größtmögliche Unordnung! Dies ist die Schlussfolgerung aus dem 2. Hauptsatz der Thermodynamik über die zunehmende Entropie: Die Entropie eines Systems wächst über die Zeit, es sei denn, es wird dauerhaft Energie (Arbeit) investiert, um der Entropie entgegenzuwirken. Auf die Praxis übertragen heißt dies: Selbst wenn Ihre Software zu Beginn ingenieurmäßig sauber geplant wurde, unterliegt sie dennoch Zerfallsprozessen, die darin bestehen, dass erkannte Fehler oder funktionale Defizite der Software nachträglich in das Konstrukt eingebracht werden und graduell die ursprünglich aufgebauten Strukturen aufweichen.

3. Hauptsatz der IT (absoluter Nullpunkt) In der Thermodynamik wurde dieser Hauptsatz von Walther Nernst im Jahr 1906 vorgeschlagen und ist auch als Nernst-Theorem bekannt geworden. In seinem Theorem wird ausgedrückt, dass ein System nicht bis zum absoluten Nullpunkt abkühlen kann. Auch dieses Gesetz findet in der IT sein Gegenüber. Als Erfahrungswert gilt: Ein dauerhafter Null-Fehler-Zustand von Software kann angenähert, aber nicht ohne dauerhafte Zusatzaufwände gehalten werden.

4. Hauptsatz der IT (Gleichheit) In der Thermodynamik beschreibt der 4. Hauptsatz Folgendes: Wenn ein System A sich mit einem System B und B sich mit einem System C im thermischen Gleichgewicht befindet, so befindet sich auch A mit C im thermischen Gleichgewicht.


Übertragen auf Software bedeutet dies: Jede Software, die auf ein gemeinsames komplexes Modul zurückgreift, wird ebenfalls komplex werden.

5. Hauptsatz der IT (Verdrängung/Wachstum) Diesem Gesetz steht kein thermodynamisches Pedant gegenüber, dennoch zählt es aus meiner Sicht zu den Grundgesetzen. Dieser „Hauptsatz“ steht in enger Beziehung zu dem vorangegangenen und besagt: Der jeweils komplizierteste Teil in einem Softwaresystem wird sich krebsartig ausbreiten und alle anderen Bestandteile der Anwendung in Mitleidenschaft ziehen. 4.3.3 Geistesblitze Wenn der Wind weht, löscht er die Kerze aus und facht das Feuer an. (arab. Sprichwort) Ende 1905 startete in Kitty Hawk das erste mit eigenem Antrieb versehene Flugzeug. Bevor Fliegen jedoch für viele Menschen möglich wurde, vergingen weitere 30 Jahre. Ehe Telefonieren aus Flugzeugen für alle Flugreisenden angeboten wurde, vergingen noch einmal über 50 Jahre. – Mit dem Luftsprung der Gebrüder Wright wurde eine neue Idee Wirklichkeit, ein neues „Mem“ sah das Licht der Welt. Bis dahin hat die Vorstellung vom Fliegen lange in vielen Köpfen und Fantasien von Menschen gelebt, war jedoch noch nicht Realität geworden. Der Begriff „Mem“ wurde 1976 von dem Oxford-Zoologen Richard Dawkins geprägt. Er wird vom lateinischen memoria (Erinnerung) abgeleitet. Ein Mem ist folglich etwas, das erinnert wird. Um es einfach zu machen: Man kann Meme in gewisser Weise als materialisierte Idee betrachten, die z. B. durch einen Laborversuch, 100 m Fliegen oder ein „Hello World“-Programm irgendwann das Licht der Welt erblicken. Diese Idee repliziert sich z. B. durch Sprache, Medien oder Internet und wird andere dazu anregen, auf ihm aufzubauen. So wird aus einer solchen Grundsatzerfindung, die gekoppelt ist mit einem Stück Genius ihres Erschaffers, eine Innovation, wenn sie sich als zuverlässig erweist und mit vertretbaren Kosten repliziert werden kann. Es wird also ein neues „Mem“ freigesetzt (Wegener 2001), ein neuer Bausteine des Wissens und der Erkenntnis, mit dessen Hilfe jetzt noch nicht realisierbare Ziele (auch im Softwarebau) verwirklicht werden können. Wandert diese Idee vom Stadium der Erfindung auf die Ebene der Innovation, so kommen meistens verschiedene zu diesem Zeitpunkt verfügbare Komponententechnologien zusammen, die ihrerseits wieder auf bereits vorhandenen Memen aufbauen und aus denen eine neue Technologie


zusammengesetzt wird. Hierbei müssen die richtigen Komponententechnologien zueinander passen: Ein PC im heutigen Sinne wurde erst möglich, nachdem es die Technologie der Winchesterplatten, Floppydrives, Mikrochips und kostengünstigen Leiterplattenherstellung gab. Wäre eine dieser Teiltechnologien nicht verfügbar gewesen, so hätte ein solcher Rechner nicht entstehen können. – Sollte eine solche Innovation dann auch noch einen starken Einfluss aufweisen, wie etwa bei einem Flugzeug oder dem Computer, so spricht man von einer Basisinnovation, aus welcher sich typischerweise eine eigene Industrie entwickelt oder die vorhandene Industriestruktur verändert wird. Ideen, die Wirklichkeit geworden sind, werden so zur Ausgangsbasis für wiederum neue Ideen. Mit Hilfe der heute gegebenen Kommunikationskanäle wird die Replikation dieser Meme, also ihre Weiterverbreitung, immer schneller und einfacher. Jeder kann seine Gedanken ins Internet einbringen und Suchmaschinen sorgen dafür, dass sie nach kurzer Zeit überall im Netz gefunden werden können. Dabei folgen diese Quantensprünge menschlichen Geistes nicht unbedingt den gleichen Regeln wie die Gesetze der Komplexität. Um noch einmal einige derjenigen Meme, die im Rahmen dieses Buches erwähnt wurden, zusammenzutragen: Wenn Sie zu Kap. 3.5 (S. 59 ff.) zurückgehen, so war dort die Rede von Betty Holberton, der Erfinderin der ersten Programmiersprache. Andere hatten auch diese Idee, ihr gelang es jedoch – ähnlich den Brüdern Wright beim Fliegen – als erste diese Idee bleibend zu realisieren. Ihre Überlegungen bildeten die Ausgangsbasis für andere. Aufgrund ihrer Arbeiten entstand Raum für andere Meme, etwas die Trennung von Hard- und Software, die Erfindung von Unterprogrammen oder die objektorientierte Programmierung bis hin zum grafischen Designen von Programmen mit Hilfe von UML. – Im Sinne dieser Meme wird moderne IT Entwicklung in ihren Planungs- und Umsetzungsarbeiten stets einen Blick auf die Meme der IT werfen müssen, um so zukunftsweisende Trends (nicht nur auf rein technologischer Seite) rechtzeitig erkennen und nutzen zu können.

4.4 Und sie lebt doch! Man soll keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug. (Jean-Paul Sartre) In Abb. 4.5 ist der typische Lebenszyklus einer Applikation aus kommerzieller Sicht wiedergegeben. Es stellt sich die kaufmännisch wichtigste Frage: Wie groß werden die Gesamtgewinne während des gesamten Softwarelebens sein, falls ich diese Software baue.

4.4 Und sie lebt doch! 125

Abb. 4.5. Kosten und Gewinne in einem Software-Lebenszyklus

Um das Leben darüber hinaus nicht unnötig zu verkomplizieren, betrachte ich an dieser Stelle ausschließlich technisch bedingte Faktoren. Außer Acht lasse ich hier den Vertrieb und die Wettbewerbssituation, die natürlich einen ganz erheblichen Einfluss auf die verkaufte Stückzahl haben. Worum es hier geht, sind all diejenigen Aspekte, die mit der initialen Erstellung, der Weiterentwicklung und der Aufrechterhaltung des Betriebs zu tun haben. Hierzu ist es sinnvoll, den Lebenszyklus einer Software in vier Phasen zu unterteilen (vgl. Abb. 4.5). Jede Software durchläuft diese Phasen, wenn auch in unterschiedlicher Ausprägung.

Infantile Phase In dieser ersten Phase wird die Software initial gebaut und „lernt laufen“. All das, was über die schrittweise Transformation eines Problems in eine digitale Lösung besprochen wurde, gilt für diesen Bereich. Die Dauer dieser Phase ist normalerweise identisch mit der Länge des zugrunde liegenden Projektes zum initialen Bau dieser Applikation. Diese Phase endet mit der ersten stabilen Version, die offiziell (nicht Beta-mäßig!) an einen Kunden geht!


Juvenile Phase Die Erfahrungen zeigen, dass eine solche Erstversion beim Kunden noch eine ganze Menge Kinderkrankheiten in sich birgt und demzufolge keineswegs fertig ist. Aufgrund der ersten Praxiserfahrungen werden Fehler und nachbesserungswürdige Funktionen ersichtlich. Diese sind durch den Hersteller zu beheben, was für ihn in aller Regel noch einmal erhebliche Aufwände zur Folge hat. Besonders die politische Komponente, wonach man sich vor dem oder den ersten Kunden keine Blöße geben möchte, wirkt hier sehr stark mit ein. Diese Pflegeljahre der Software kommen zum Ende, sobald die Fehlermeldungen stark rückläufig sind und das Produkt an Reife und Stabilität gewonnen hat. Wirtschaftlich gesehen ist diese Phase nicht im Gewinnbereich anzusiedeln, sondern bindet weiteres Kapital.

Aduleszente Phase Sobald die Fehlerrate sich nach unten bewegt und die tatsächlichen Gewinne die Ausgaben für Fehlerbehebung und andere Nachbesserungen überschreitet, tritt langsam die aduleszente Phase ein. Die Software ist im Wesentlichen ausgereift, sie läuft stabil, alle Requirements sind realisiert und die Fehlermeldungen sind stark rückläufig. Dieses ist nun die Phase, in der das Produkt die eigentlichen Gewinne einfahren sollte. (Es sei denn, es handelt sich um ein Unikat!) Diese Phase zeichnet sich auch dadurch aus, dass Änderungen bzw. Ergänzungen – so denn zu Anfang sauber gearbeitet wurde – mit geringem Aufwand in die Software integriert werden können. Im Laufe der Zeit werden jedoch die Aufwände für Änderungen oder Ergänzungen in der Software graduell zunehmen, was mit dem Alterungsprozess der Software gleichbedeutend ist.

Vergreisungsphase Nachdem sich die Software für einen gewissen Zeitraum gut verkauft hat, finden sich meist Wettbewerber, die mit moderneren Verfahren oder breiterer Funktionalität um die Gunst der Kunden ringen. Sie sorgen dafür, dass die von Ihnen belegte Marktnische enger wird. Zur gleichen Zeit altern die Komponenten von Drittanbietern, was zur Folge hat, dass sie entweder dauerhaft auf immer älteren Teilkomponenten sitzen oder aber mehr und mehr Geld investieren müssen, um aktuelle Versionen in Ihre Software zu integrieren. Wie immer Sie sich hier verhalten, eines ist klar, die Gewinne korrigieren sich deutlich nach unten und der Ruf aus den eigenen Reihen, endlich ein vernünftiges Reengineering zu machen, statt nur an Symptomen zu flicken, wird immer lauter. Insgesamt: Die Phase, in der Sie hohe Gewinne abschöpfen konnten, ist vorbei, es sei denn Sie investieren.

4.4 Und sie lebt doch! 127

Frühvergreisung Wie schnell diese Vergreisung stattfindet, haben Sie übrigens in erheblichem Maße selbst in der Hand. – Wie gesagt, ich lasse die kaufmännische Sicht hier außer Betracht, mit dem Wissen, dass es hier eine ganze Reihe Faktoren gibt, die sehr kurzfristig alle eigenen Planungen zu Makulatur werden lassen. Die Geschwindigkeit des technischen Vergreisungsprozesses haben die Entwickler der betroffenen Software aufgrund mangelnder oder weitsichtiger Planung in erheblichem Maße dieser bereits in die Wiege gelegt. Haben Sie damals eine technische Planung durchgeführt, die nur bis ans Ende des Projektes gedacht hat, so werden Bugfixing, Nachbesserungen und die Ergänzung neuer Funktionalitäten recht schnell dafür sorgen, dass die Software immer verwinkelter und komplizierter wird und dementsprechend die Aufwände für Wartung und Änderung nach oben gehen. Haben Sie andererseits in Ihrer Planung LebenszyklusAspekte betrachtet und integriert, so haben Sie auch über die eigentliche Projektphase hinaus dafür gesorgt, dass der Zuwachs an Komplexität möglichst langsam geschieht.

Traum und Wirklichkeit In Hinblick auf die erhoffte Wirtschaftlichkeit des Produktes ergeben sich hieraus folgende Bemerkungen (vgl. Abb. 4.5): Zwar setzt die (idealisierte) Einnahmenphase recht bald nach Abschluss des Softwareprojektes ein, jedoch ist die tatsächliche Gewinnphase oftmals sehr viel kleiner als auf den ersten Blick erwartet. Wirtschaftlichkeitsrechnungen gehen meistens davon aus, dass die wesentlichen Kosten bis zum Ende der infantilen Phase entstanden sind, und setzen danach nur noch relativ geringfügige Beträge für Bugfixing und Produktpflege an. Ich nenne diese Vorstellung „Dreamline“, da sie aus Wünschen lebt, nicht aber von der Wirklichkeit getragen wird. Die Wirklichkeit sieht anders aus! Gerade dann, wenn „klassisch“ gearbeitet wird, entstehen nach der Produktentwicklung noch einmal Kosten in der juventilen Phase, die den Herstellungskosten durchaus sehr nahe kommen können. Das Ausreifen der Applikation bindet dabei in vielen Fällen erheblich mehr Ressourcen als geplant und verringert damit die tatsächlichen Gesamtgewinne deutlich. Gleiches gilt auch für alternde Systeme. Durch die oben beschriebenen Faktoren fließen in dieser Phase meist sehr viel früher und zunehmend stärker Ressourcen ab. Vorausschauende und ganzheitliche Planung beeinflusst hier ganz erheblich, wie viele Mittel tatsächlich verloren gehen. Die in Abb. 4.5(A) und (B) ausgedrückten Zeitspannen stehen in direkter Relation zu dem, was ganz zu Projektanfang an Vorgehensweisen und Lösungen festgelegt wurde. Somit ist ganzheitliches Vorgehen, das die bis hierhin beschriebenen


Faktoren einbezieht, ein Schlüssel, um zu einer deutlich besseren Rendite mit einer speziellen Applikation zu gelangen.

Literatur Blackmore, S. (2000). The Meme Machine. New York, Oxford Press. Lasko, W. W. (2001). Wie aus Ideen Bilder werden. Wiesbaden, Dr. Th. Gabler Verlag. Meyer-Grashorn, A. (2004). Spinnen ist Pflicht. Augsburg, mvg Verlag.

5 Ganzheitlicher Softwarebau

5.1 „Coole“ Software Was ist das Ziel Ihrer Organisation? Ich vermute: Geld zu verdienen und in Ihrem Marktsegment mit Ihren Applikationen eine führende Position einzunehmen. Wenn Sie andere als diese subtilen Gründe haben, so können Sie diesen Abschnitt gerne überschlagen! Wie erreichen Sie dieses Ziel? Mit guter Software! Wie aber lässt sich gute Software allgemein gültig definieren? Anhand von Abb. 5.1 werde ich dieser Frage nachgehen, schränke sie aber bewusst auf solche Applikationen ein, die in direkter Interaktion mit dem Anwender über ein grafisches Benutzerinterface stehen. – Wie ist es Ihnen ergangen, als Sie das letzte Mal neu georderte Software auf Ihrem Rechner installierten? Sie

Abb. 5.1. Was gute Software ausmacht

130 5 Ganzheitlicher Softwarebau

hatten ein Programm für einen ganz speziellen Zweck erworben in der Erwartung, dass diese Applikation Ihnen das Leben an dieser konkreten Stelle erleichtern möge. In diesem Beispiel erfüllt das gekaufte Programm die funktionalen Erwartungen in vollem Umfang, allerdings hat es keine besonders galante Benutzerschnittstelle, bzw. zeichnet es sich durch wiederholte Programmabstürze und geringe Performance aus. Handelt es sich Ihrer Wahrnehmung nach in solch einem Fall um „gute“ Software? Ich meine: Nein! An dieser kleinen Überlegung wird deutlich, dass wir unausgesprochene Erwartungen an eine Anwendung haben. In einer Zeit, in der TurnkeyProjekte einen immer breiteren Raum einnehmen, gibt es Dinge, die man schlichtweg von einer vernünftigen Software erwartet. Wir möchten ein „Rundum-Sorglos-Paket“ erwerben. Dabei gehen wir als Anwender davon aus, dass der Hersteller ganzheitlich das entsprechende Problem gelöst hat. Wir erwarten von ihm, dass er über viele grundlegende Eigenschaften der kommenden Anwendung selbstverständlich nachgedacht und diese bei der Umsetzung berücksichtigt hat, ohne dass er explizite Vorgaben hierzu erhalten hätte. Bestenfalls verbinden wir dessen Professionalität damit, dass vielmehr er uns z. B. fragt: „Bedarf es eines Sicherheitskonzepts, gibt es einzuhaltende Performancekriterien oder muss die Software im Synchronbetrieb arbeiten können?“ Die Blase rechts in Abb. 5.1(A) enthält einige derjenigen Punkte, die von einer modernen Software im Sinne nichtfunktionaler Anforderungen erwartet werden. Sind diese Punkte in nicht ausreichendem Maße realisiert worden, so ist der Kunde mit der Qualität des Produktes unzufrieden! Sind diese Punkte andererseits vorhanden, so wird der Hersteller keineswegs mit Ovationen bedacht werden, vielmehr denkt sich der Kunde, falls er es überhaupt wahrnimmt: „Das ist doch selbstverständlich.“ – Aus Sicht des Herstellers ergibt sich daraus eine ganz simple Logik: Sind die Punkte aus Abb. 5.1(A) zu wenig berücksichtigt worden, so hat er einen unzufriedenen Kunden, wurden die Punkte jedoch ausreichend umgesetzt, so hat er keineswegs eine Applikation geliefert, die deshalb beim Kunden hervorsticht. Um dem Anwender wenigstens etwas Begeisterung zu entlocken, sind andere Dinge notwendig. Anhand von Abb. 5.1(B) wird verdeutlicht, dass die Kundenbegeisterung sehr viel mit der Interaktion zwischen Mensch und Maschine, den Funktionen, dem Workflow und der Optik zu tun hat. Diese Interaktionsfähigkeit wird gespeist vom individuellen Nutzwert und dem Bedienungskomfort der Applikation. Sie trägt am Ende erheblich dazu bei, dass der Kunde das Produkt als „gut“ empfinden kann. Wichtig sind hierbei drei Eigenschaften, die der Anwender sehr subjektiv wahrnimmt und die ihrerseits die Grundlagen für die Wahrnehmung von Nutzen und Komfort bilden. Es handelt sich dabei um die folgenden Aspekte:

5.1 „Coole“ Software 131

Aufgabenstellung: Wie und in welchem Umfang können die Aufgaben in diesem Tätigkeitsfeld mit Hilfe dieser Applikation gelöst werden und in welchem Maß deckt die Anwendung die anfallenden Tätigkeiten ab? Interaktion: Wie gut gestaltet sich die Zusammenarbeit mit anderen Prozessen, anderen Aufgabenbereichen und anderen Personen? (Fragen, die Sie leicht in vielen modernen Windows-Applikationen wiederfinden, wenn Sie an die wechselseitige Einbettung von Programmen denken, die Nutzung der Crosskonvertierung unterschiedlicher Datenformate oder den direkten Versand von E-Mails aus Applikationen heraus.) Arbeitsumfeld: Wie gut ist dieses virtuelle Arbeitsumfeld gestaltet? Hier geht es um das „Look & Feel“ der Anwendung. Es geht um die implementierten Arbeitsabläufe, die Intuitivität und die Einhaltung von Standards bei der Benutzerführung. Ebenso spielen die optische Übersichtlichkeit, das Vorhandensein von intelligenten Wizards oder gut gestaltete Hilfen eine wichtige Rolle.

Subjektive Wahrnehmungen Die Wahrnehmung dieser Fähigkeiten einer Applikation hängen sehr stark von subjektiven, nicht rationalen Kriterien ab. Positive oder negative Gefühle, die Freude am Umgang mit diesem Produkt, die Art der gemachten Erfahrungen und die Lust am Spielen gelten im Bereich der Informationsarchitektur als wichtige Elemente zur individuellen Gesamtbewertung. Langer Rede kurzer Sinn: Damit eine Anwendung als „gut“ wahrgenommen werden kann, müssen Funktionsumfang und Interaktionsschnittstellen sehr gründlich durchdacht und ausgefeilt worden sein. (Was leider im Softwarebau keineswegs selbstverständlich ist!) Gemeinsam wirken die beschriebenen Faktoren der Zufriedenheit bzw. Unzufriedenheit auf die Wahrnehmung des Kunden (vgl. Abb. 5.1(C)). Solange die nicht erfüllten Selbstverständlichkeiten überwiegen, wird dieser sich vorwiegend negativ über das Produkt äußern und nicht zufrieden mit der Software sein. Erst wenn – wie in der Kurve gezeigt – die Positiva in einem für den Anwender individuellen Maß überwiegen, kommt beim Kunden Zufriedenheit auf. Dieses Zusammenspiel der Kräfte ist übrigens für die Planung neuer Softwareprodukte oder beim Bau von Nachfolgeprodukten von großer Bedeutung. Projekte, deren Fokus mit besten Absichten auf die Themen fokussieren, die im unteren Bereich liegen, werden diese Anstrengungen nur sehr begrenzt von den Kunden gewürdigt bekommen. Demgegenüber wird alles, was zusätzlich im oberen Bereich der Grafik zu finden ist, vom Kunden wahrgenommen und im beschriebenen Sinne bewertet werden.


Um solche Software entstehen lassen zu können, sind in der Introspektive der Produktion mehrere Faktoren in einem ausbalancierten Verhältnis zu halten. Die Nutzbarkeit einer in Planung befindlichen Applikation wird erheblich durch das Wechselspiel der in Abb. 5.2 wiedergegebenen Größen beeinflusst. Je ausgewogener diese Faktoren gegeneinander ausbalanciert sind, umso wahrscheinlicher ist die Chance, eine „gute“ Software zu entwickeln. Dies drückt sich sowohl durch eine ausgewogene technische Lösung aus, mit deren Hilfe der bereits bekannte Komplexitätsanstieg gering gehalten werden kann und aus dem heraus ad hoc viele der nichtfunktionalen Anforderungen entsprechende Berücksichtigung finden. Zum anderen wird aber auch mit Hilfe dieser Ausgewogenheit erreicht, dass projekttechnisch Notwendiges mit IT-technisch Sinnvollem gekoppelt wird und dieses wiederum ausreichenden fachlichen Bezug zur Wirklichkeit hat. Im Einzelnen gilt dabei für die vier Achsen von Abb. 5.2:

Abb. 5.2. Balance zwischen Projektsituation und Nutzbarkeit

Domainwissen. Nur wenn das fachliche Wissen über inhaltliche Zusammenhänge und Abhängigkeiten gegeben ist, werden Applikationen entstehen können, die als gut empfunden werden. Ein Beispiel: Welches Programm zur Ermittlung Ihrer Einkommenssteuer finden Sie besser: Eines, das Ihnen ganz präzise und steuertechnisch korrekt all die einzelnen Schritte und Zwischenergebnisse auf dem Weg zum Ziel vermittelt, oder

5.1 „Coole“ Software 133

ein Programm, das Ihnen diese Rechnung zwar nicht anzeigt, jedoch die legalen Tipps und Tricks konkret während der Bearbeitung an dafür sinnvollen Stellen vorschlägt? Ein hohes Maß an Spezialkenntnis ist für die Ausstattung eines solchen Programms notwendig! IT-Technologie. Um am Beispiel mit dem Einkommenssteuerprogramm zu bleiben: Das oben genannte Wissen kann selbstverständlich händisch in eine gigantische Softwarekonstruktion integriert werden. Dies wird jedoch die Komplexität des Produktes erheblich steigern, somit wird die Implementierungsdauer, die Fehlerrate und die interne Unübersichtlichkeit deutlich zunehmen, drei Dinge also, denen im Rahmen dieses Buches der Kampf angesagt worden ist. Des Weiteren bedeutet alte Technologie oft auch altes „Look & Feel“: Eine noch so gute Software, die mit Technologien längst vergangener Versionen von z. B. „Windows“ neu entsteht, wird fast immer als alt oder sogar veraltet wahrgenommen werden. Der Brückenschlag zwischen Problemstellung und Lösungsraum wird durch die Entwicklungsmannschaft und ihre Arbeitsweisen vollzogen. Somit sind die beiden Größen, nämlich Projekt- & Teammanagement sowie Prozesse & Werkzeuge, zwei sehr wichtige Säulen bei der Realisierung der Lösung. Auf den ersten der beiden Punkte gehe ich hier nicht weiter ein, da weite Bereiche dieses Buches sich hiermit befassen. Auch über die unterschiedlichen Prozessmodelle wurde bereits gesprochen. Werden diese nicht durch geeignete Werkzeuge für die Entwicklung bzw. Interprozesskommunikation ergänzt, so ist die Effizienz während der Softwareproduktion nicht ausreichend sichergestellt. Prozessautomatisierung findet nicht im notwendigen Maße statt!

Alles im Zeichen der Qualität Es ist wichtig, dass diese vier Größen in ausgewogenem Verhältnis zueinander stehen und damit die Grundlage für Kundenzufriedenheit nach außen und ganzheitliches Qualitätsmanagement nach innen gewährleisten. Der eigene Unternehmenserfolg wird durch optimale Erfüllung der Kundenwünsche verbessert. Dabei stehen die oben beschriebenen „guten“ Produkte im Mittelpunkt, wobei nicht die Lieferung von Überqualität gefragt ist, da diese vom Anwender nicht gewürdigt wird. Mit diesen Voraussetzungen ist es nur noch ein ganz kleiner Schritt zum TQM, dem „Total Quality Management“. Hier soll die Qualität der Ergebnisse automatisch durch die Qualität der Prozesse und Strukturen garantiert werden. Dabei betrachtet TQM die Qualität im gesamten Unternehmen – arbeitet also ganzheitlich. Unter Qualität wird in diesem Zusammenhang die subjektiv wahrgenommene Güte des Produktes im Vergleich zum Wettbewerb verstanden, also genau das, wovon in Abb. 5.1 die Rede war.


Um Total Quality Management umsetzen zu können, bedarf es gewisser Rahmenkriterien. Diese sind im organisatorischen Bereich die Definition und Kontrolle von Prozessen und Prozessqualitäten. Dabei ist es wichtig, dass die Entscheidungen dezentralisiert werden, um so eine Reintegration von Arbeit zu unterstützen und Teamwork anzustoßen. – Personell geht es um die Entwicklung von Instrumenten zur Mitarbeitermotivation. Hierbei soll die Qualifikation der Mitarbeiter gesteigert und deren kundenorientierte Art zu denken verbessert werden. Die Mitarbeiter sollen dabei ein höheres Maß an Gesamtverständnis erhalten. – Technisch gesehen sollen verbesserte Technologien eingesetzt werden, wobei vor allem verbesserte Informationssysteme für das Qualitätsmanagement genutzt werden sollen. TQM setzt dabei auf die folgenden drei Qualitätsprinzipien: Prozessorientierung. Ihr Ziel ist es, dass keine Fehler auftreten, um somit Folgekosten zu vermeiden. Als Mittel wird hierbei "Continuous Improvement“ und präventives Verhalten eingesetzt, also vermeiden statt prüfen. Kundenorientierung. Sie hat das Ziel der Kundenzufriedenheit. Kundenorientierung soll auf allen Wertschöpfungsstufen stattfinden, es soll also ein Qualitätsbewusstsein geschaffen werden, bei dem jeder verantwortlich ist für die weitergegebe Qualität. Managementverhalten. Die Philosophie der Fehlervermeidung statt der Fehlersanierung soll umgesetzt werden. Dabei geht es um die Motivation der Mitarbeiter. Als Mittel dient vorleben und die Vermittlung dieser Philosophie im Top-down-Approach. Es sollen dabei Rahmenbedingungen und Mitarbeiterintegration durch Weitergabe von Informationen geschaffen werden. Nun ist ganzheitlicher Softwarebau keineswegs mit Hilfe von TQM vollständig zu realisieren, dennoch ist es ein sehr wichtiger Baustein aus Sicht des Qualitätsmanagements.

5.2 Holismus pur Ein Reporter befragte Bill Gates nach seinem Erfolgsgeheimnis. Hierauf antwortete der Microsoftgründer wie folgt: „Ich konzentriere mich auf das Wesentliche.“ Vorweg: Wenn ich im Weiteren den Begriff holistisch verwende, so tue ich dies nicht, um der Zugehörigkeit zu aktuellen Trends zu huldigen. Der Begriff Holismus steht für Ganzheitlichkeit, sorgt aber teilweise noch im-

5.2 Holismus pur 135

mer für Verwirrung. Ganzheitliches Denken ist dabei uralt: In früheren Epochen musste man ganzheitlich denken, um überleben zu können. Im Laufe der Zeit brachte der Fortschritt viele Erleichterungen und man glaubte, auf ganzheitliches Denken und Handeln verzichten zu können. Bereits in der zweiten Hälfte des 20. Jahrhunderts verbanden sich im wissenschaftlichen Bereich mit den holistischen, also ganzheitlichen Ansätzen solche Aspekte, wie sie im Kontext dieses Buches teilweise vorgestellt wurden. Hierzu gehören Chaos und Komplexität, systemisches Denken und Emergenz, aber auch die Betrachtung der Wechselwirkungen zwischen den einzelnen Elementen. Wie bereits diskutiert, führt ein reduktionistischer Ansatz (z. B. nur die Beschreibung der Einzelelemente) zu Problemen, Missinterpretationen und unvollständigen Lösungen. Um dies schrittweise zu reduzieren, bedarf es eines ganzheitlichen Umgangs mit dieser Thematik auch im Softwarebau. Dies erfordert eine komplexe, multilinear vernetzte, hoch assoziative Denkweise, bei der nicht nur das Projekt, sondern gleichermaßen der gesamte Kontext wie auch die beteiligten Menschen in ihren Wirkzusammenhängen berücksichtigt werden. Wenn Sie im Sommer draußen sitzen und zusehen, wie sich recht rasch der Himmel verdunkelt und sich große Wolkentürme bilden, so ist Ihnen klar, dass es bald regnen dürfte. Dies wissen Sie, obwohl es zwischen dem Dunkelwerden und dem erwarteten Regen zunächst keinen direkten Bezug gibt. Es ist vielmehr Ihr Wissen, das tiefere Zusammenhänge kennt und Ihnen diese Schlussfolgerung erlaubt. 5.2.1 Systemische Wissenserzeugung Software zu entwickeln heißt zunächst ganzheitlich Wissen aufzubauen. Es werden spezielle Kenntnisse über die individuellen Anforderungen, die einzusetzenden Techniken sowie die effizientesten Wege, diese zu implementieren, benötigt. Erst wenn diese Dinge zusammenfinden, ist mit einer „guten“ Zielapplikation zu rechnen. Je besser der Prozess der Wissensgenerierung im Sinne der bereits beschriebenen Transformationen stattfindet, desto effizienter wird sich der Herstellungsprozess der Software und desto besser die Applikation an sich gestalten. In Untersuchungen von Nonaka und Takeuchi wird ein Ansatz beschrieben, wie diese Wissensbeschaffung gezielt und systematisch erfolgen kann. Hierzu zunächst eine Randbemerkung: Im Rahmen ihrer Untersuchungen konnten die beiden Forscher einen interessanten kulturellen Zusammenhang aufdecken. Sie konnten zeigen, dass der kulturelle Hintergrund einen erheblichen Einfluss auf die jeweilige Art zu lernen hat. Entsprechend ihren Arbeiten (Nonaka and Takeuchi 1995) ergab sich die folgende Ausgangssi-


tuation: Bei innovativen Produktentwicklungen galten Intuition, Kreativität und hoher zwischenmenschlicher Austausch als die Stärken japanischer Unternehmen. Demgegenüber betonten westliche Unternehmen, dass ihre Stärken in der Vielseitigkeit der Individuen, deren analytischen Fähigkeiten sowie der Speicherung vorhandener Wissensbestände in Datenbanken, Dokumentationen und Handbüchern lägen. Übertragen auf aktuelle Projekte ist immer wieder zu beobachten, dass Projektmitarbeiter in einem mitteleuropäischen Kontext vielfach nervös werden, wenn Begriffe wie Kreativität oder gar Intuition in frühen Projektphasen eingebracht werden. Man möchte Prozesse definieren, sich um die Speicherung von Daten kümmern oder sehr früh damit beginnen, Spezifikationen festzulegen. Insgesamt entsteht der Eindruck, dass entsprechend Kap. 4.2 (S. 107 ff.) zwei Kulturkreise jeweils einen Aspekt des systemischen Denkens im Fokus haben. Die beiden japanischen Forscher haben, vergleichbar den zuvor präsentierten Ansätzen, die kulturell jeweils starken Aspekte in einem „FünfPhasen-Modell der Wissensgenerierung“ zusammengeführt. Indem sie beide Vorgehensweisen verknüpften, lieferten sie einen weiteren wertvollen Schlüssel zur Ganzheitlichkeit auch im Softwarebau. Sie identifizierten bei ihren Analysen vier unterschiedliche Wissensformen (vgl. Abb. 5.3):

Abb. 5.3. Fünf-Phasen-Modell der Wissensbildung


x Sozialisation durch Austausch von implizitem Wissen in einer Gruppe oder einem Team x Externalisierung durch Schaffung von gemeinsamen Konzepten oder mentalen Modellen x Kombination durch Verknüpfung und Erweiterung des explizieten Wissens mit vorhandenen Wissensbeständen x Internalisierung durch Wissenstransfer auf neue Kontexte Aufbauend auf ihrem Fünf-Phasen-Modell lässt sich das Ganze am Beispiel der Anforderungserfassung wie folgt übertragen: Implizites Wissen austauschen. Implizites Wissen wird durch eigene Erfahrungen erworben und kann meistens nicht durch Worte ausgedrückt werden. Diese Erfahrung und der anschließende Austausch impliziten Wissens zwischen mehreren Personen verschiedener Fachdisziplinen, Perspektiven und Motivationen ist eine entscheidende Voraussetzung für eine breit angelegte Wissensschaffung. In ihren Arbeiten beschreiben die Autoren, dass ein Entwicklungsteam der japanischen Firma Matsushita einen Brotbackautomaten entwerfen sollte. Dazu wurde das gesamte Team zu einem der besten Brotbäcker der Stadt geschickt, um selbst Brotteig zu kneten. Anschließend versuchten die Teilnehmenden, den Vorgang des Teigknetens zu beschreiben. – Auch wenn Software-Engineering keine Brotbackautomaten als Endergebnis liefern soll, so ist diese Vorgehensweise in Ergänzung zu den klassischen Stakeholder-Interviews und anderen Methoden der Problemerfassung ungemein wichtig. Nur wenn das Entwicklungsteam am eigenen Leib erfahren hat, für welchen Kontext eine Lösung erstellt werden soll, wird es ein ganzheitliches Bild der Ausgangssituation haben. – Auch wenn es nicht in erster Linie klassisch europäischem Ingenieurdenken entspricht: In dieser Phase geht es nicht um die frühe Erarbeitung erster Lösungen, sondern um das Wahrnehmen des Kontextes. Hierzu sind Kreativität und Spontanität gefragt, jedoch noch keine digitalen Zeichenbretter! Die Studien belegen, was bereits etwas abstrakter umrissen wurde: In dieser Phase ist es notwendig, möglichst viele und auch abwegige Ideen und Gedanken zu produzieren. Jede Kritik oder Einschränkung zerstört die Produktivität dieser Phase und behindert den Prozess der Hypothesenbildung. Konzepte schaffen (Externalisierung). In dieser Phase werden durch Diskussionen und gemeinsame Reflexionen aus dem bis dahin noch recht unstrukturierten Wissen Konzepte abgeleitet. Es werden abstrahierte Wirkzusammenhänge formuliert, die nun in direktem Bezug zur selbst gemachten Erfahrung stehen. Hierzu müssen die Beteiligten ihr Alltagsund Vorwissen in Frage stellen, Prämissen überdenken und ggf. revidieren.


Offene Teamarbeit ist somit ein sehr wichtiger Schlüssel, um die zu Anfang dieses Prozesses formulierten Perspektiven und Betrachtungsweisen zusammenzuführen und in einem gemeinsamen mentalen Modell zu integrieren. In Anlehnung an Abb. 4.3 (S. 113)und Abb. 4.4 (S. 114) geschieht dies praktisch mit Hilfe eines interativ durchlaufenen Prozesses, bei dem schrittweise die aufgestellten Konzepte gegen die erworbenen Erfahrungen bzw. aufgedeckten Abhängigkeiten überprüft und ausdiskutiert werden. Konzepte erklären. Als Nächstes geht es darum, die auf Flipcharts, Wandtafeln oder in den Köpfen der Mitarbeiter hinterlegten Konzepte und mentalen Modelle so zu beschreiben, dass diese Erfahrungen, die den Konzepten und Modellen zugrunde liegen, von anderen Personen, die diese Erfahrungen nicht gemacht haben, nachvollzogen und auf deren Sicht der Wirklichkeit projeziert werden können. Hier setzt der Prozess der Formulierung und Systematisierung ein! Vision-Dokumente, die explizite Beschreibung von Anforderungsdetails, sind klassische Resultate dieser Phase. Sie sollten jedoch nicht vom „grünen Tisch“ her entwickelt werden, sondern sich aus den vorgelagerten Phasen ergeben. Archetyp/Prototyp/Operationsmodell bilden. Endlich ist der Zeitpunkt erreicht, auf den gerade im Kontext der IT-Entwicklung so mancher Softwareentwickler und auch Manager seit längerem nervös gewartet hatte. Die Rede ist davon, die gemeinsam erarbeiteten und mit theoretischen Überlegungen abgeglichenen Konzepte (z. B. auch die nichtfunktionalen Anforderungen) für eine Anwendung handhabbar und überprüfbar zu machen. Hierdurch ergibt sich zusätzlich die Möglichkeit, unterschiedliche Begriffswelten in Deckung zu bringen. Auf diese Weise gelingen wenigstens zwei Dinge: Es wird sichergestellt, dass Erfahrung bzw. Wissen an z. B. das Entwicklungsteam transferiert wurde und dass man ein gemeinsames begriffliches Verständnis aufgebaut hat: Verwendet man gleichlautende Begriffe, so drücken sie für alle Beteiligten tatsächlich auch dasselbe aus. Wissen übertragen (Transfer). In der letzten Phase geht es darum, das erarbeitete Konzept und Modell in andere Kontexte zu übertragen. Bezogen auf das Anforderungsmanagement beim Softwarebau bedeutet dies zum einen, dass ähnliche Abläufe oder Zusammenhänge sehr viel schneller an Transparenz gewinnen und evtl. inhaltlich sogar auf eine gemeinsame Metamodellebene bezogen werden können. Zum anderen ist dies aber auch für den internen Folgeprozess, nämlich die Vermittlung des gewonnenen Wissens an die nachfolgenden Instanzen, etwa die IT-Architektur, höchst bedeutsam, da diese hierdurch bereits kumuliertes und reflektiertes Wissen statt langer Listen halb verstandener Anforderungen erhält.


5.2.2 Das Matruschka-Prinzip Nach diesem Abstecher in die Wissenserzeugung heißt es nun, im ganzheitlichen Sinne auf das Projekt an sich zu schauen. Abbildung 5.4(A) (S. 141) beschreibt hierbei die wechselseitigen Abhängigkeiten. In diesem Zwei-Sichten-Modell werde ich zunächst ein Schalenkonzept, das ähnlich wie die russischen Matruschka-Puppen funktioniert, vorschlagen und präsentieren. Um es vorweg zu nehmen: Es geht hierbei nicht um ein verkapptes Wasserfallmodell! Was in diesem Kontext jedoch wichtig ist, hat mit der Blickrichtung und Einflussnahme zu tun; kurz gesprochen: Wer prägt wem in besonderem Maße seine persönliche Note auf? Bei diesem Ansatz steht der eigentliche Projektauftrag im Zentrum. Als Auftraggeber kommt dem oder den Projektsponsoren eine wichtige Rolle zu, da sie durch entsprechende Einflussnahme auf das Projekt, etwa durch Verträge oder Steeringboards, den generellen Kurs festlegen. Was immer im Projekt getan wird: Es muss in direkten Sachzusammenhang zu dieser Beauftragung gebracht werden können und muss diese fördern. Bereits die nächste Schale beschreibt den Projektmanager. Dieser hat in einem Projektvertrag die Verantwortung dafür übernommen, den Auftrag in einem definierten Rahmen erfolgreich zu realisieren. Um dies möglich zu machen, muss er mit seiner Persönlichkeit sowie seinem fachlichen und methodischen Wissen das Projekt lenken. Ihm obliegt es (in unternehmensspezifischen Grenzen), die grundlegenden Arbeitsmethoden festzulegen, Mitarbeiter auf dieses Projekt „einzuschwören“ und mit deren Hilfe schrittweise Ergebnisse den Projektsponsoren vorzulegen. Hierbei spielen sein eigenes Grundwertesystem, seine Persönlichkeit sowie die eigenen Erfahrungen wichtige Rollen. Aus ihnen leitet sich der eigene Führungsstil, die entstehenden Teamstrukturen sowie die notwendigen Teambildungsprozesse maßgeblich ab und geben dem gesamten Team eine individuelle Prägung. Es ist sein Job, so zu arbeiten, dass die Mitarbeiter möglichst effizient (im ganzheitlichen Sinne) und interaktiv ihre Arbeiten erledigen können. Um dies möglich zu machen, ist er es, der eine projektspezifische Balance zwischen den eingesetzten Arbeitsmethoden entsprechend seiner persönlichen Paradigmen17 herstellen muss. Wie viel an Agilität oder streng prozessgetriebenem Vorgehen in einem Projekt eingebracht werden kann, muss er festlegen und überwachen. In gleicher Weise muss er in Abhängigkeit zum Fortschritt des Projekts darüber wachen, dass Kreativität, Dynamik, systematisches Denken und innovatives Handeln im jeweils notwendigen Maße Raum gegeben wird. Besonders effektiv für die Teamentwicklung ist überdies, wenn diese Person in gewissem Umfang als Teamcoach operiert. Somit 17

Echtes Changemanagement in einer Organisation wird daher genau diese Rolle im Auge haben und dort mit Veränderungen beginnen.


liegt ein ganz zentrales Augenmerk des Projektmanagers auf dem Team, seiner internen Zusammenarbeit und den erbrachten Fortschritten. Das Team repräsentiert in diesem Modell die nächste Schale. Es ist seine Aufgabe, das vom Projektmanager in große Brocken zerlegte Gesamtprojekt schrittweise und gemäß den jeweils zugeteilten Rollen zu realisieren. Dabei wird die Qualität dieser Teamarbeit in hohem Maße von den Führungs- und Coachingfähigkeiten des Projektmanagers geprägt werden. Als fachliche Berater des Projektmanagers spielen die einzelnen Teammitglieder eine wichtige Rolle bei der Festlegung des eigentlichen Projektkurses. Ansonsten liegt jedoch der Fokus des Teams auf den Resultaten. In enger interdisziplinärer Zusammenarbeit gilt es hier, den Blick stetig auf die nächste „Schale“ des Modells zu richten. Die Suche nach guten, zukunftssicheren, weitsichtigen und im Kundensinne stabilen Lösungen ist hier die wichtigste Blickrichtung dieser Mitarbeiter. Die äußerste Schale ist der Lösung vorbehalten. Hierbei beinhaltet Lösung in diesem Kontext keineswegs nur die Applikationen und Dokumentation, sondern sie bezieht sich auch darauf, wie der Anwender die Realisierung wahrnimmt und empfindet. Fachliche Interaktion, frühe Prototypen, sowie regelmäßiger inhaltlicher Austausch mit den Nutzern nehmen somit einen wichtigen Raum ein. Nur indem dieser Austausch zeitnah und regelmäßig stattfindet, ist es möglich, die tatsächlichen Bedürfnisse schrittweise kennen zu lernen und zu berücksichtigen. Wenn Sie sich an die agilen Prozessmodelle zurückerinnern, so wurde dort dieser Art von Zusammenarbeit viel Raum gegeben. Ohne Berücksichtigung der anderen „Schalen“ ist jedoch die Chance sehr groß, dass instabile Projektsituationen entstehen. Dies kann z. B. dadurch geschehen, dass der Rahmen der ursprünglichen Beauftragung oder die Projektfinanzierung durch zu viele gute Wünsche des Nutzers rasch gesprengt werden. Mit der zweiten Sicht in Abb. 5.4(B) soll verdeutlicht werden, dass das gesamte Projekt in systemischer Weise miteinander vernetzt ist und die wechselseitigen Abhängigkeiten aktiv optimiert werden müssen. Wenn das Team nicht im Sinne von Kap. 5.2.1 den Kontext der Beauftragung kennt oder sich der Projektmanager nicht ausreichend mit der Realisierung identifiziert, so liegen erhebliche Problemzonen vor. Wenn das Anforderungsmanagement, die IT-Architektur oder das Projektmanagement dem Kunden gegenüber nicht auch als kompetente fachliche Berater begegnen, sondern als „Ja-Sager“ und reine Implementierer, so laufen Dinge gründlich falsch. Gleiches gilt auch, wenn der Projektauftraggeber, der vielfach nicht identisch mit dem Anwender ist, und die Nutzer sich nicht ausreichend intern abgestimmt haben und infolgedessen unterschiedliche Projektziele verfolgen. Kommunikation und Abstimmung werden daher in unterschiedlichem Maß zwischen allen vier Bereichen notwendig sein, um so gemeinsam eine optimale Lösung herbeizuführen. Das Ziel besteht darin – ähnlich wie beim


Abb. 5.4. Schalenmodell im ganzheitlichen Softwarebau

Golfen – das Projekt und dessen Resultate genau in das Loch im Zentrum von Abb. 5.4(B) zu bringen. Wird dies erreicht, so tritt eine Win-Win-Situation für das gesamte Projekt ein (Fuller 2000). Gerade den drei oben genannten Projektrollen (Projektmanagement, Anforderungsmanagement und IT-Architektur) fällt es dabei zu, diesen Optimierungsprozess aus der jeweiligen Rollensicht heraus zu moderieren und zu steuern. Ein Beispiel: Wenn das Anforderungsmanagement seine Rolle ernst nimmt, so wird es den Anwender zunächst fachlich beraten und dann so intensiv mit diesem zusammenarbeiten, bis ein wirklich „rundes“ Anforderungsprofil entstanden ist und nicht länger die berühmte Wunschliste existiert. Dieses Auftreten als Consultant ist in vergleichbarer Weise durch die beiden anderen Rollen zu leisten. Plakativ gesprochen: Um diese Zusammenarbeit zwischen Lieferanten und Kunden möglich zu machen, muss jeder der drei Rolleninhaber zum einen die rollenspezifischen Qualifikationen mitbringen, aber auch Beraterqualitäten nahe den psychotherapeutischen Fähigkeiten erworben haben. Warum? Weil nur dann das oben beschriebene „Golfloch“ hinreichend schnell erreicht werden kann, wenn der Kunde als Teil des Prozesses entsprechend geführt wurde. Ist dieser Kräfteausgleich zwischen den Parteien hergestellt und wurde das Projekt im Sinne von Abb. 5.4(A) „gefahren“ sowie die Applikation


im Sinne „guter“ Software realisiert, so ist davon auszugehen, dass dieses Projekt samt seiner Lösung vom Kunden als mustergültig erlebt wird. Es ist von einer hohen Kundenzufriedenheit sowohl über den kompetenten Projektablauf wie auch über das Endprodukt auszugehen. Die eigene Organsiation profitiert hiervon in mehrfacher Weise. Zum einen werden durch einen solchen Interessenausgleich vielfach Aufwände und Gewinne ins richtige Verhältnis zueinander gesetzt. Zum anderen hat der Lieferant Qualität geliefert und Vertrauen beim Kunden aufgebaut, was für zukünftige Beauftragungen ein ungemein wichtiges Kapital darstellt. Erst wenn der Projektrahmen um den Bau einer spezifischen Software als ein jeweils wieder neu zu optimierendes System verstanden wird und die Schlüsselrollen durch ganzheitlich arbeitende Persönlichkeiten mit der Fähigkeit zur Beratung und zum sauberen ingenieurmäßigen Arbeiten besetzt worden sind, werden Dinge tatsächlich effizienter. Nicht länger stehen dann statische Prozesse oder unreflektierte bzw. vorschnelle Ergebnisse im Mittelpunkt, sondern es findet eine fortschreitende Optimierung des Gesamtsystems statt. Mag sein, dass sie diese Sicht für unnötig oder utopisch halten. Ich gebe jedoch zu bedenken, dass die Automobilbranche an einem vergleichbaren Scheideweg stand. Dort hat man sehr erfolgreich branchenspezifische Wege gesucht und gefunden, um durch ganzheitliches Vorgehen zu wirtschaftlichen Erfolgen zu gelangen. Die Rede ist von der „Lean Production“, um die es im Weiteren gehen wird.

5.3 Schlanke Produktion In der Automobilindustrie gab es in den frühen 70er Jahren einen Paradigmenwechsel. Dieser wurde vom MIT weltweit aufs gründlichste untersucht und ausgewertet (Womack, Jones et al. 1991). Dieser Paradigmenwechsel wurde notwendig aufgrund des zunehmenden Wettbewerbsdrucks und den bis dahin üblichen starren Vorgehensweisen. Das Bild der Automobilfertigung sah damals sehr düster aus: Um effektiv produzieren zu können, mussten riesige Spezialmaschinen große Mengen an Einzelteilen produzieren, die danach von Fließbandarbeitern im Akkord verbaut wurden. Firmen wie etwa Toyota waren kurz vor dem wirtschaftlichen Ruin, als ein Mann namens Taiichi Ohno dort das Ruder der Produktion übernahm. Aufgrund der desaströsen Situation bei Toyota postulierte er eine neue Vorgehensweise, die auf drei Grundaussagen fußt: x Baue nur noch das, was tatsächlich gebraucht wird. x Beseitige alles, was dem Produkt keine Wertsteigerung gibt. x Bekämpfe alles, was schief läuft.

5.3 Schlanke Produktion 143

Aufgrund dieser Leitsätze und zusätzlicher Evaluationen musste man sich zunächst eingestehen, dass man immer nur bis an die eigenen Fabriktore gedacht, keineswegs aber das gesamte System „Automobilbau“ mit seinen weltweiten Zulieferern, Servicenetzen etc. im Auge gehabt hatte. Bei der hieraus entwickelten Lean Production geht es darum, alle Prozesse auf Wertschöpfung hin zu fokussieren und "Verschwendung zu vermeiden". Dazu wurden und werden in den verschiedenen Schwerpunktbereichen Optimierungen vorgenommen. So wurde im Produktionsbereich den Arbeitern ein Maximum an Verantwortung übertragen, es wurden Mechanismen installiert, um Fehler aufzudecken. Entwicklung und Fertigung wurden parallelisiert, die Automatisierungsrate mit Hilfe möglichst flexibler Maschinen wurde stark verbessert, sodass diese Produktion eine große Produktvielfalt liefern kann. Auch die Zulieferer sind in diese Prozesse einbezogen. Ihre Komponenten sind einer kontinuierlichen Produktverbesserung unterzogen – Kooperationen werden dabei unterstützt. Statt eines Preismarktes regeln langfristige Vereinbarungen die Zusammenarbeit. Hierbei besteht das Ziel darin, einen sinnvollen Rahmen für Kostenanalyse, Preisfestsetzung und Gewinnteilung für alle Beteiligten zu erreichen, also eine echte Win-Win-Situation herbeizuführen. In diesem Produktionsmodell ist dabei das wichtigste japanische Stichwort „muda“, was sich am besten mit Müll, Abfall, Ausschuss oder Verschwendung übersetzen lässt. Jede Aktivität, die Ressourcen verbraucht, ohne im Gegenzug einen Wert zu schaffen, ist per definitionem „muda“. Taichii Ohno, der erklärte Gegner aller und jeder Form von „muda“, hat hierbei für seine Sparte sieben Quellen spezifiziert, die Müll verursachen: x Überproduktion, die der tatsächlichen Nachfrage vorauseilt. x Daraus resultierende große Lagerbestände, die über das notwendige Minimum weit hinausgehen. x Untätigkeit und Warten, weil der nächste konkrete Schritt in der Produktion nicht durchgeführt werden kann. Etwa wegen Terminschwierigkeiten mit Zulieferern oder weil der eigene Produktionsprozess wegen zu langer Umrüstungszeiten oder dogmatischer Kapazitätsauslastung teurer und unflexibler Maschinen ins Stocken gerät. x Unnötiger Transport von Material aufgrund geographisch zerstreuter Produktionsanlagen. x Eine übermäßige Bearbeitung von Teilen, verursacht durch schlechtes Werkzeug oder Design. x Unnötige Bewegungen von Mitarbeitern, die Teile, Werkzeuge oder auch Rat und Hilfe suchen. x Mangelhafte Teile, die eine Nachbearbeitung nach Ende des tatsächlichen Produktionsprozesses erfordern.


Toyota, das belegen die aktuellen Wirtschaftszahlen, ist dank dieser schlanken Methoden weltweit zum gewinnträchtigsten Automobilkonzern aufgestiegen. Mehr und mehr Industriezweige – darunter auch die Luftund Raumfahrtindustrie – blicken auf „lean“ und wagen den Umstieg. Auch in der gesamten IT-Branche fangen erste Gehversuche mit diesem schlanken Produktionskonzept an. Von Erfolgsfirmen der Branche wie dem Hardwarelieferant „Dell“ oder dem Internetauktionshaus „Ebay“ ist bekannt, dass dort „lean“ gearbeitet wird. Auch beim Softwarebau lernt man „lean“ zu berücksichtigen und es teilweise mit agilen Vorgehensweisen zu verbinden (Poppendieck 2003).

Lean-Produktionsmodell in der Software Um die Übernahme von „lean“ in den Softwarebau zu ermöglichen, muss zunächst der für die Automobilindustrie spezifische Ansatz adaptiert werden. Ausgehend von dem klassischen Ansatz ist dies in Abb. 5.5 geschehen. Die Grafik verdeutlicht, dass im Mittelpunkt des Geschehens Planung und Bau der Software stehen, also dort das geschieht, wovon bisher die Rede war. Im Sinne eines Gesamtsystems muss diese Produktion jedoch eingebettet werden in vier unterschiedliche produktionsbeeinflussende

Abb. 5.5. Lean Production im IT-Kontext


Aspekte. Eine genauere Betrachtung der einzelnen Bereiche liefert dabei Folgendes: Planen und bauen. Ich fange bewusst in der Mitte an, obwohl diese Selbstverständlichkeiten enthält: Die gute Nachricht: Wenn Sie in das „Lean“Gedankengut einsteigen, dürfen Sie Ihre Prozesse und Verfahren zunächst behalten. – Ich sage bewusst „zunächst“, da richtig eingesetzte „Lean Production“ im Verlauf der Zeit diese genauso auf den Prüfstand stellen wird wie alles andere auch. Sollten Ihre lieb gewonnenen Vorgehensweisen sich dann als uneffizient herausstellen, so gilt es, diese genauso auszuwechseln wie einen abgefahrenen Autoreifen. Ansonsten sind hier Ihr Prozessmodell, systemisches Anforderungsmanagement (vgl. hierzu S. 89 ff.), Vereinfachungen und hohe Automatisierungquote einzuordnen. Ein klärendes Wort zu den Vereinfachungen: Hier geht es darum, mit Hilfe iterativer Vorgehensweisen Methoden, Prozesse und technische Umsetzungen schrittweise immer mehr zu vereinfachen. Planen und bauen hängt hierbei intern von mehreren für den modernen Softwarebau spezifischen Größen ab: x Prozessmanagement: Es handelt sich hierbei um unternehmens- und projektspezifische methodische Ansätze und Vorgehensweisen, wie sie z. B. dem SWEBOK18 oder PMBOK19 zu entnehmen sind. x Wissensmanagement: Hierbei geht es um die organisationsweite Klärung, wie mit dem hausinternen Wissen zu verfahren ist, wie es verwaltet und genutzt werden kann. x Qualitätsmanagement: Softwarebau ist branchenspezifisch. Hervorragende Software ohne Beachtung der einschlägigen Qualitätsbestimmungen liefert nicht immer gute Resultate, da möglicherweise notwendige Zertifizierungen, wie sie z. B. in der Medizin oder der Luftfahrt vorgeschrieben sind, nicht hinreichend berücksichtigt wurden. x Nutzungsmanagement: Softwarebau ist personalintensiv und teuer. Gezielte organisationsspezifische Vorgehensweisen zur Mehrfachnutzung von Programmen, Codeteilen, Wissen etc. wird Einfluss auf die Art und Weise der zu bauenden Software haben. Wer nur Datenbanken programmiert, wird dies mit Hilfe spezieller Prozesse und Werkzeuge optimal machen können, wird aber in anderen Situationen recht suboptimal arbeiten.

18

19

SWEBOK steht für „Software Engineering Body of Knowledge“ und ist eine Dokumentation der IEEE Computer Society und Association for Computing Machinery über den Stand des Software-Engineering. PMBOK steht für „Project Management Body of Knowledge“ und ist eine Dokumentation der IEEE Computer Society und Association for Computing Machinery über den Stand des Projektmanagements.


Im äußeren Bereich finden sich gegen den Urzeigersinn betrachtet die folgenden vier Schwerpunkte: Produktlinienorientiertes Portfolio. Um als Hersteller effektiv Software produzieren zu können, bedarf es eines recht genau definierten Segments. Es ist zwar lobenswert als Vollsortimenter für Softwarebau aufzutreten, jedoch ist dies ein teures Unterfangen. Aus diesem Grunde spielen Produktlinien eine immer größere Rolle. Betrachten Sie z. B. die Firma Airbus, so hat diese in den vergangenen Jahren ganz erhebliche Marktzuwächse erreicht, weil sie ihr Marktsegment (kleine, mittlere und große Flugzeuge für kurze, mittlere und lange Strecken) genau ausgewertet hat und mit Hilfe einer Art Legokasten-Systems (Sie erinnern sich?) unterschiedliche Flugzeuge mit für die Anwender (= Piloten) ähnlichen Eigenschaften baut. Anders als beim Wettbewerb kann auf diese Weise ein Pilot in kurzer Zeit von einem kleinen Airbusmodell auf größere Modelle umgeschult werden, wobei ihm sehr vieles im neuen Modell vertraut ist. Ähnliche Effekte gelten für die Produktion oder auch die Instandhaltung. Übertragen auf den Softwarebau geht es darum, die Gemeinsamkeiten und Unterschiedlichkeiten („Commonalities“ und „Variabilities“) einer Produktfamilie zu ermitteln und gezielt die Plattformkonformitäten für effektive Planung, Bau und Testen zu nutzen. Vorsicht: Die Rede ist nicht davon, dass Sie Ihre Entwickler anweisen, vorhandene Softwareobjekte möglichst oft wiederzuverwenden oder lange Konfigurationsskripten zu schreiben. Worum es zunächst geht, ist eine profunde Marktbetrachtung, aus der sich kurzfristige bis langfristige Ziele zum Bau von Software ableiten lassen. Qualifizierte Mitarbeiter. Da über dieses Thema noch weiter gesprochen werden wird, verweise ich hier auf die kommenden Kapitel. Den Kundenbedürfnissen dienen. Da von der Befriedigung der Kundenbedürfnisse bereits die Rede war, möchte ich hier aus dem weiten Themenfeld einen Aspekt noch einmal klar hervorheben. Befriedigung von Kundenbedürfnissen heißt in den wenigsten Fällen, dass genau die vom Kunden gewünschten Anforderungen unreflektiert in eine wie auch immer geartete Anwendung überführt werden. Vielmehr bedeutet es, zunächst den Kunden kompetent und ganzheitlich zu beraten und erst dann Software zu erstellen. Nur so kann erreicht werden, dass die künftige Applikation inhaltliche Themen sehr viel vollständiger abdeckt, was dem Kunden, wie auch dem Lieferanten, erhebliche Folgekosten sparen kann. – Auch während des Lebenszyklus eines Produktes haben Kunden eine ganze Menge Bedürfnisse, die ein Softwarelieferant befriedigen sollte (Helpdesk, Updates, Fernwartung etc.).


Ausschuss vermeiden. Wie lässt sich nun aber „muda“ auf die Softwareproduktion übertragen? Es ist gut möglich, dass Sie mich an dieser Stelle mit großen Augen anschauen und sich fragen, was man denn an Ausschuss in einem Softwareprojekt erzeugen kann. Die hohen Papierberge in den zumeist „papierlosen“ Büros sind vermutlich nicht damit gemeint! – Richtig, aber was ist z. B. mit der unnötig eingesetzten Zeit, die aufgewandt wurde, weil ein Entwicklungsingenieur einen Usecase über 100 oder mehr Seiten beschreibt, statt methodisch gelernt zu haben, dass der gleiche Usecase, wenn er denn nur z. B. 20 Seiten lang geworden wäre, ihm sehr viel Zeit gespart hätte und zugleich ein vermutlich besseres Umsetzungsergebnis geliefert hätte. (Unter dem allgemein üblichen Projektdruck wird man bei Lesen von 100 Seiten deutlich mehr überlesen – und damit Fehler machen – als bei der geringeren Seitenanzahl.) Ein weiterer Punkt: Wie effektiv oder ineffektiv sind Ihre Meetings? Wie viele Stunden Zeit werden vergeudet, weil die Projektbeteiligten sich verzetteln, mit unendlicher Detailliebe, – jedoch viel zu aufwändige Präsentationen vorbereiten oder vor lauter Grundsatzdiskussionen zu keinen Ergebnissen kommen. – Zuletzt noch ein drittes Beispiel: Wie viel Zeit verbringen wichtige Projektmitarbeiter damit, immer und immer wieder aufs Neue händisch Skripten ablaufen zu lassen bzw. völlig überzogene Formblätter auszufüllen, nur weil es niemand fertig gebracht hat, hier den Computer in seiner ureigensten Eigenschaft, nämlich als Automaten, für u. a. auch solche Dinge mit einzusetzen? 5.3.1 Automaten für alles Auch wenn mir vielleicht Experten widersprechen: Es gibt eine menschliche Wesensart, ohne die die Innovation auf Dauer nicht rund läuft – die Faulheit, oder etwas vornehmer, der Hang zur Rationalisierung. (Ron Sommer, ehem. Vorstandsvorsitzender Deutsche Telekom AG)

Aufbruch zu neuen Ufern – die Zukunft? Im Dezember 2002 saßen im Silicon World Internet Center die Auguren des Informationszeitalters zusammen, um herauszufinden, was wohl bis 2007 die großen Themen am Horizont seien (n.n. 2002). Hierbei hatte fast die Hälfte aller vorgeschlagenen Themen die Optimierung des Softwarebaus sowie die Beherrschung der zugrunde liegenden Komplexität zum Inhalt! Die Rede war dort von Produktionsautomatisierung im Softwarebau und -betrieb, also Themen im Bereich selbstkonfigurierender, selbstoptimierender, selbstheilender und selbstschützender Software. Des Weiteren stand die Beherrschung der Komplexität im Mittelpunkt. Hiermit in Bezug stand als


weiterer Themenkandidat die Berücksichtigung ganzer Firmeninfrastrukturen in sogenannten „Enterprise Architectures“ – und zuletzt: die Entwicklung von technischen Systemen, mit denen man sehr schnell Software entwickeln kann, dem sogenannten „Rapid Application Development“. Schon lange gibt es Industrieforderungen – gerade aus dem Bereich des „Rapid Manufacturing“, also der schnellen Produktion neuer Güter –, sehr viel mehr in die ganzheitliche Art und Weise des Denkens einzusteigen. Lineares, analytisches Denken hatte hierbei einen hohen Wert, reicht aber bei weitem nicht mehr aus, um die Kundenerwartung nach schnellen „Rundum-sorglos-Paketen“ zu realisieren.

Von der Emergenz der Automaten Kennen Sie das Prinzip Ihres Kleinhirns? Nun, hier macht uns die Natur etwas vor, das uns Menschen überhaupt erst in großem Maße die Freiräume schafft, um zu denken und in die abstrakten Sphären menschlicher Kommunikation einzutreten. Wenn Sie sich an Ihre Zeit als ABC-Schütze zurückbesinnen, so war dies ein Zeitraum, in dem Sie vermutlich sehr mühsam und vor allem hochkonzentriert Schwungübungen zum Schreibenlernen absolvierten, eine Zeit, in der Sie mühsam buchstabenweise Worte zusammensetzen mussten, und eine Zeit in der Sie – wenn Sie damit beschäftigt waren – wenig Raum für andere Themen hatten. – Warum ist das heute zumeist anders? – Nun, die Antwort ist simpel. In dieser Lernphase wurde z. B. die Motorik Ihrer Handschrift „programmiert“. Zu Anfang ist dies ein Prozess, der durch Ihr Bewusstsein aktiv gesteuert werden muss. Haben sich diese Muster jedoch erst einmal eingeprägt, so werden sie im Kleinhirn – quasi als Automatenprogramme – hinterlegt. Das bedeutet: Damit das Gehirn Raum bekommt, die Komplexitäten der Umwelt zu beherrschen, verwandelt es stereotyp wiederkehrende Handlungsabläufe in festkodierte, unbewusst kontrollierte Ablaufmuster. Sind diese „programmiert“, so reicht ein entsprechender Gehirnimpuls, um das Ganze in Gang zu setzen und zu kontrollieren, während Ihr Bewusstsein anderen Aufgaben zur Verfügung steht. Noch einen weiteren Aspekt gehirngerechten Arbeitens möchte ich an dieser Stelle einbringen: Wo liegen eigentlich die Stärken und wo die Schwächen ihres Gehirns? – Lassen Sie mich das Ganze noch einmal ein wenig anders formulieren: Was erwarten Sie, wenn z. B. 10 PKW ausschließlich in Handarbeit hergestellt werden, und was erwarten Sie, wenn dies durch eine automatisierte Fertigungsstraße geschieht? – Im ersten Fall werden Sie solide Lösungen haben, die aber leichte Abweichungen, möglicherweise auch Fehler aufweisen. (Ausnahmen sind in diesem Beispiel sicherlich einige handgefertigte PKW Luxusmarken aus vorwiegend


englischer Produktion.) Im zweiten Fall erhalten Sie exakte Kopien voneinander – egal ob Fehler integriert sind oder nicht! Dies macht deutlich, dass wir eigentlich, selbst wenn wir sehr penibel veranlagt sind, nicht sonderlich gut dafür geeignet sind, Dinge in exakt gleichbleibender Qualität zu reproduzieren. Wer dies dennoch kann, wie z. B. Näherinnen in Ostasien oder Mitarbeiter im Luxusautomobilbau, der hat eine sehr hohe handwerkliche Kunst erlernt. Maschinen hingegen decken den Bereich präziser Reproduktion erheblich besser ab, weisen jedoch sehr begrenzte oder gar keine Flexibilität auf. In Bezug auf unsere Situation heißt dies aber, sich sehr früh zu fragen, wo wir als menschliche Wesen gut und effizient eingesetzt werden können und wo Automaten grundsätzlich besser sind als Menschen, selbst wenn jene Apparate heute noch nicht zur Verfügung stehen. Ein Stückweit steht die IT immer noch in der Mitte eines Prozesses, wie er vor über 200 Jahren bei den Webern in England oder Schlesien zu beobachten war. Bis dato hatte man Handwebmaschinen, danach Webautomaten. Die Leistung ging erheblich nach oben, nachdem diese sozial durchaus nicht einfache Umstellung stattgefunden hatte. Aus Webern wurden Industriemechaniker mit der Kenntnis zu weben! – Dieser Prozess, obschon Softwarebau letztendlich Automatenprogrammierung ist, kann und muss noch erheblich ausgebaut werden.

Starkes Automatisierungsdenken Nicht nur die Kodierung der eigentlichen Software sollte in starkem Maße durch eine hohe Automatisierung geprägt sein. Viele Arbeitsgänge – gerade auch in den Planungsphasen eines Projektes – verschlingen viel Zeit und Kraft der Mitarbeiter, die nebenbei bemerkt, in der Rolle des „Wiederholungstäters“ meist schlechter abschneiden als Maschinen. Aus diesem Grunde ist es sinnvoll und notwendig, schrittweise die Arbeitsteilung zwischen Menschen und Maschinen neu zu definieren: Innovative und kreative Tätigkeiten können durch Menschen am besten erledigt werden. Gleiches gilt für Prototypen und erste Modelle. Sobald sich jedoch Vorgehensmuster einspielen und zu Verfahren oder Prozessen sedimentieren, können Teile der sich wiederholenden Tätigkeiten auf Maschinen ausgelagert werden. Automationsmanagement, als eigene Disziplin verstanden, vergleichbar dem Qualitätsmanagement, stellt eine Möglichkeit dar, um gezielt diesen Transferprozess zu realisieren. Die zentrale Aufgabe dieser Disziplin besteht darin, rechtzeitig, systematisch und strategisch sinnvoll automatisierbare Prozesse, z. B. automatisiertes Testen oder automatisierte Projektüberwachung, herauszufiltern und diese schrittweise auf Automaten zu übertragen. Auf diese Weise wird sowohl die Qualität (etwa durch automatisiertes Testen) oder die Effizienz der eingesetzten Mitarbeiter deutlich gesteigert. Das Team wird darüber hinaus von Routinearbeiten entlastet


und kann sich im Sinne der oben beschriebenen Schlüsselfähigkeiten hochwertigeren Aufgaben zuwenden. Solche Paradigmenwechsel brauchen Zeit und binden Kapital. Oft ist gerade zu Beginn für das Linienmanagement wenig einsehbar, warum in solche Automatisierungsprojekte Ressourcen „vergeudet“ werden, statt sich mit der händischen Kodierung geplanter Software zu befassen. In diesem Sinne stellt eine solche Haltung des Managements den größten Risikofaktor dar. Verschiedene Untersuchungen belegen, dass mangelnde Unterstützung durch die Leitung, Reduktion oder Änderung der Inhalte, personelle Reduktion und Kürzung des Zeitbudgets ein hohes Potential haben, um diese Art von Projekten zu Fall zu bringen. Gemäß einer statistischen Erhebung von Earnest & Young sind 70% aller Changeprojekte nicht erfolgreich, wobei nur 20% dieser Projekte aufgrund schlecht formulierter Ziele scheiterten. Somit scheitern de facto etwas mehr als die Hälfte aller Änderungsprojekte durch menschliche Inkonsequenz oder Inkompetenz. – Auch wenn sich diese statistischen Zahlen keineswegs nur auf Manager und Automatisierungsprojekte beziehen, so belegt die Praxis genau dieses! Aus diesem Grunde hat sich ein aus dem „Kaizen“20 entliehenes Prinzip sehr bewährt. Es besteht darin, dass eine Umstellung in vielen kleinen Schritten geschehen kann und nicht am Anfang bereits ein großer Generalplan über die finalen Ergebnisse festgelegt werden muss. Vielmehr geht es darum, den oder die wichtigsten Bereiche für solche Umstellungen ausfindig zu machen. Dabei sollte die Paketgröße dieser Reformen mit Bedacht gewählt sein. Nach erfolgter Umstellung – selbst eines Teilschrittes – können die Nutzer diesen Fortschritt in ihre eigenen Arbeitsprozesse integrieren. Hat dies stattgefunden, so werden sich auf natürliche Weise neue Kandiaten für die nächste Verbesserungsrunde abzeichnen. Mit einer solchen Vorgehensweise werden zum einen konstante Quick Wins erzielt. Gleichzeitig wird durch diese inkrementelle Arbeitsweise erreicht, dass mit verhältnismäßig geringem Mitteleinsatz deutliche Verbesserungen im laufenden Betrieb erzielt werden können, ohne die eigene Produktion durch Großumstellungen zu gefährden. 5.3.2 Nachhaltigkeit Ein Ansatz, um Software über lange Zeit auf qualitativ hohem Niveau zu halten, besteht darin, regelmäßig und aktiv deren IT-Architektur, den Code sowie die Dokumente Revisionen zu unterziehen und dadurch aufzuräumen, wodurch die technischen Strukturen und Artefakte sehr viel länger in 20

Kaizen = japanisches Managementkonzept, das in engem Zusammenhang zur Lean Production steht.


einem guten Zustand gehalten werden können. Zwar gewinnt der Kunde hierdurch keine neue Funktionalität, auch entstehen dauerhaft Zusatzkosten, jedoch wird hierdurch erreicht, dass die Zunahme der Komplexität minimiert wird und es Fehlern erschwert wird, sich in ein immer unübersichtlicher werdendes System einzuschleichen. Beispiel: Stellen Sie sich z. B. Ihren PC vor. Als Sie das Gerät neu erwarben, war alles fest eingebaut, wohl dokumentiert und auf die anderen Komponenten abgestimmt. Im Laufe der Zeit haben Sie neue Hardwarekomponenten eingebaut, zusätzliche Lüfter oder Regelungen in die Maschine integriert. Mit jedem hinzugefügten Teil wächst die Chance, dass Fehler auftreten, vor allem dann, wenn sich das Innenleben immer mehr zu einem Kabelverhau entwickelt: Die Zeit, bis Ihnen wieder klar ist, welches Kabel wofür zuständig ist oder auch gar nicht mehr benötigt wird, steigt mit jedem Eingriff. Geben Sie ein solches Gerät aus der Hand, so wird der beauftragte Mechaniker, der zwar korrekt verkabelte Systeme kennt, nicht aber Ihre persönliche Logik, sich vermutlich die Haare raufen und in seiner eigenen Logik Dinge tun, die Sie als Fehler werten würden. Genau dies ist auch bei Software der Fall! Somit steht Refactoring für einen wohl definierten Prozess der Codeverbesserung (einschließlich der entsprechenden Dokumentation), nachdem das eigentliche Softwareentwicklungsprojekt längst abgeschlossen ist. Die Vorgehensweise hat hier durchaus Ähnlichkeiten mit dem Design einer neuen Software, jedoch wird im initialen Prozess Funktionalität nach bestimmten Regeln und Vorgaben hinzugefügt, während beim Refactoring ein Redesign und eine Optimierung des Codes ohne die Integration neuer Funktionalität stattfindet. Damit kehrt Refactoring die Entwicklung um, die Software normalerweise durchläuft: von einem (mehr oder weniger) guten Design über viele Iterationen von Fehlerkorrekturen, Erweiterungen und Wiederverwendungen hin zu einem schlecht strukturierten und kaum verständlichen Code – im Extremfall bis hin zu einem nicht mehr wartbaren Codegemenge. Dabei ist Refactoring eine relativ junge Software-Engineering-Disziplin, die ein methodisches Vorgehen bei der Bearbeitung von existierendem Programmcode definiert. Bearbeitung bedeutet in diesem Kontext nicht Fehlerkorrektur oder Erweiterung der Funktionalität. Vielmehr geht es darum, nach Möglichkeit kontinuierlich die Struktur (das Design) des Codes zu verbessern, ohne dabei das funktionale Verhalten der Anwendung zu verändern. Ziele sind somit, die Überschaubarkeit und Verständlichkeit des Codes zu erhöhen und die Wartbarkeit zu vereinfachen. Im weiteren Sinne gehören hierzu auch all diejenigen Änderungen an der Software, die notwendig sind, um die jeweils aktuellen Drittanbieterkomponenten zu nutzen. Nichts ist schlimmer als die Vernachlässigung dieser Drittanbieterelemente, die ab irgendeinem Zeitpunkt zunächst durch neuere Komponenten ausgetauscht werden und irgendwann auch nicht mehr vom Anbieter gewartet werden. Im Sinne der


Garantien, die Sie als Softwareproduzent Ihren Kunden gegenüber zu erbringen haben, kann dies, wenn nicht rechtzeitig bedacht, gerade in sicherheits- oder verfügbarkeitsrelevanten Bereichen sehr teuer werden! Wichtige Standardoperationen sind zum Beispiel die Umbenennung von Feldern und Methoden mit selbsterklärenden Namen sowie die Entfernung von Codeduplikaten, die durch Copy & Paste entstanden sind. Darüber hinaus beinhaltet Refactoring auch wesentlich komplexere Maßnahmen zur Codeverbesserung. Mittlerweile gibt es etwa hundert benannte Refactoring-Operationen (auch Refactoring-Patterns oder einfach Refactorings genannt), die ein Codefragment, ausgehend von einem definierten Anfangszustand, mittels einer Folge von wohl formulierten Transformationen in einen definierten Endzustand überführen. Trotzdem ist der Einsatz dieser Technik in vielen IT-Organisationen nicht unumstritten. Es herrscht vorwiegende Übereinstimmung, dass ein wohl strukturierter und verständlicher Quellcode den Einarbeitungsaufwand für einen neuen Softwareentwickler erheblich reduziert, Fehlersuche beschleunigt und Erweiterbarkeit vereinfacht. Über die gesamte Lebenszeit dieser Applikation betrachtet ist dies viel wert. Das Problem besteht in der Frage, wie viel Geld man für ein Refactoring-Projekt bereit ist auszugeben, um als unmittelbares Ergebnis die innere Qualität eines schon lauffähigen Systems zu verbessern? Auch das Argument „Never touch a running system“, also das Einbringen neuer Fehler in ein bereits stabil laufendes System, ist nicht von der Hand zu weisen. Zumindest für die initiale Bauphase einer Software ist diese Vorgehensweise sinnvoll und wird auch von verschiedenen agilen Projektmodellen propagiert. Sich andererseits dieser Grundsatzfrage nicht zu stellen und im Sinne der beschriebenen Drittanbieterproblematik die Augen zu verschließen ist grob leichtsinnig. Aus diesem Grunde erscheint es sinnvoll, in einer frühen Projektphase festzulegen, wie für die entstehende Software die Werthaltigkeit gesichert werden kann. Umdenken wird hier in vielen Softwarehäusern in ähnlicher Weise notwendig sein, wie die Erkenntnis, dass auch hervorragende Autos nicht 100.000 km ohne wenigstens einen Ölwechsel laufen sollten.

6 Arbeiten im Kollektiv

Wenn man weiß, was man tut, kann man tun, was man will! (Moshe Feldenkrais, Physiker) In den vergangenen Kapiteln war immer wieder von Menschen und ihrem intellektuellen Beitrag beim Softwarebau die Rede. Es ging um neue Wege des Denkens und Handelns. Ganzheitliches und stringentes Vorgehen, um den Produktionsprozess zu optimieren, spielten bisher eine zentrale Rolle. In diesem Kapitel wende ich mich gezielt dem Humankapital eines Projektes zu. Es geht um einige der menschlichen Grenzen, wie sie verlaufen und wo Grenzkorrekturen notwendig und sinnvoll sind. Diese Darstellung wird keineswegs vollständig sein, sondern erfolgt unter Gesichtspunkten der nachfolgenden Teamaspekte. Sind es nicht gerade die menschlichen Begrenztheiten aufgrund deren wir wegen ungenügender Kenntnis der Gesamtsituation bzw. vorschnelles oder unüberlegtes Handeln gut laufende Dinge destabilisieren, verzögern oder unnötigen Risiken aussetzen? Der Lebenszyklus einer Software wird dabei durch die beteiligten Personen und deren Sicht für das Ganze maßgeblich beeinflusst und geprägt. Dies ist nichts, was eine Maschine zu leisten im Stande wäre. Im Produktionsalltag werden Prozesse und Verfahren optimiert, um menschliches Versagen einzugrenzen. Mitarbeiter werden auf teure Lehrgänge geschickt, in welchen sie lernen, wie man Programmiersprachen nutzt, technische Diagramme korrekt erstellt oder Dateien versioniert. Was jedoch meistens offen bleibt, ist diejenige Seite eines Projektes, welche den „Faktor Mensch“ als zentrales Teil der Produktion ausreichend einbezieht. – Möglicherweise werden Sie mir jetzt widersprechen und mir entgegenhalten: „Ich erwarte von meinen Mitarbeitern Professionalität, demzufolge sind dies keine Themen für mich!“ – Darf ich Sie hier zurückfragen: Was bedeutet für Sie Professionalität? – Heißt dies, dass die beteiligten Mitarbeiter schnell und effektiv vereinbarte Prozesse leben? Was geschieht mit den Fehlern, wie sie in den letzten Kapiteln zusammengetragen wurden und die nahezu ausschließlich durch keinerlei Prozesse abgedeckt werden können? Welche Konsequenzen haben gemachte Fehler für den Einzelnen aufgrund seiner individuellen Persönlichkeitsstruktur?

154 6 Arbeiten im Kollektiv

6.1 Psychologie des Softwarebaus Wer etwas ändern will, sucht Wege. Wer nichts ändern will, sucht Gründe. (überliefert) Wollte man den Bau von Software auf eine Kurzformel bringen, so schlage ich Ihnen folgende Definition vor. Softwarebau ist nichts anderes, als dass der Genius des Menschen, also wesentliche Aspekte seiner Psyche, ein wohlgeordnetes logisches Netzwerk, eine Art Ontologie21, an voneinander abhängigen Ausführungsanweisungen für eine spezifische ITPlattform erstellt. Wie bereits in Kap. 1.2 angekündigt, geht es in diesem Werk immer wieder um „Psycho-Logische“ Aspekte beim Bau von Software. Dabei stehen die beiden Begriffsteile, nämlich die „Psyche“ und die „Logik“ im Softwarebau in einzigartiger Beziehung zueinander. Ganzheitlichkeit im Sinne dieses Buches darf sich daher keineswegs nur auf einen ganzheitlichen Denk- und Arbeitsstil beziehen, sondern muss ebenfalls den Menschen als integrales und integriertes Ganzes verstehen. Es geht darum, die Mitarbeiter zum Pars pro toto des Gesamtprozesses werden zu lassen. Dies verlangt die verstärkte Berücksichtigung dessen, was den einzelnen Mitarbeiter ausmacht und wie er sich demzufolge sieht oder wahrnimmt, was er einbringt oder auch blockiert. Psyche hat dabei mit der eigenen Befindlichkeit (Gefühle, (Selbst-)Wahrnehmung, Teamfähigkeit etc.) zu tun, drückt also dessen Persönlichkeit aus. Dies allein mit Rollen und Prozessen erledigen zu wollen löst viele Probleme nicht. Der individuelle Wesenskern, das lehren psychotherapeutische Ansätze, ist durch die eigene Biographie und das eigene Wertsystem in hohem Maße festgelegt („Ich bin ein Pedant und werde auch in meinen Grundzügen ein Pedant bleiben, selbst wenn ich Techniken erlerne, um diese Pedanterie einzugrenzen!“). Hier ist jeder Einzelne Individuum und muss mit seinen Stärken und Schwächen akzeptiert werden. Um diesen innersten Kern herum gibt es jedoch solche Bereiche, die sich mittel- und langfristig ändern lassen, wenn die betroffene Person bereit ist, hieran längerfristig zu arbeiten. Lippenbekenntnisse beim nächsten Mitarbeitergespräch zeigen dabei keine anhaltende Wirkung, da ohne die eigene Motivation und das eigene Engagement sich nichts Nachhaltiges ändern wird. („Ja, ich habe mich entschieden im nächsten Jahr Marathon zu laufen, deshalb habe 21

In diesem Sinne bedeutet Ontologie die hoch formale Beschreibung eines definierten Bereichs der Wirklichkeit, wobei die individuellen Wechselwirkungen Teil dieser Darstellung sind.

6.1 Psychologie des Softwarebaus 155

ich meine Lebensweise umgestellt und trainiere mehrfach in der Woche.“) Dinge müssen sich durch stete Einübung verinnerlichen, um Teil der neuen Haltung zu werden. Dies ist ein Bereich, der durch gute Führung der Mitarbeiter durchaus erreicht werden kann, bei dem jedoch Instant-Management-Maßnahmen oder moralische Zurechtweisungen verpuffen. Der letzte Bereich der Persönlichkeit ist dort zu finden, wo klassische Mitarbeiterführung ansetzt: Es werden Verhaltensnormen und Rollenerwartungen definiert und erwartet, dass Mitarbeiter diese „umsetzen“. Der englische Philosoph John Locke (1632–1704) definierte Logik als „Die Anatomie des Denkens“. Sie kann als Rückgrat der Computerwissenschaften verstanden werden und ist demzufolge das, was innerhalb der Informationswissenschaften in sehr großem Maße gebraucht wird, um die verlangten komplexen Softwarekonstrukte zu realisieren. Wenn von „Denken“ die Rede ist, so mag es sein, dass Sie die Skulptur „Der Denker“ von Rodin vor Augen haben. Diese Figur, die zurückgezogen, weitab von der Betriebsamkeit der Welt, über Dinge nachsinnt, entspricht nur noch selten der heutigen Wirklichkeit. Auch wenn früher Entwicklungslabors liebevoll als das „Reich der Dichter und Denker“ bezeichnet wurden, in denen sich die Mitarbeiter auf leisen Sohlen außerhalb der betrieblichen Hektik hin und her bewegten, so sieht die Welt in der Softwaresparte meist anders aus. Termindruck, Kampf gegen Fehler und Kundenforderungen halten die Mitarbeiter unter Dauerstress. Dabei bringt jeder Beteiligte sein Wissen und seine Fähigkeiten, aber auch seine persönlichen Einstellungen ein. Dabei ist es egal, ob der Einzelne als Person laut oder leise, mittelpunktsliebend oder zurückgezogen, launisch oder ausgeglichen ist. Die Person wird in ihrer Art auf das jeweilige Projekt einwirken und dort seine individuelle Note hinterlassen. – Nur wenn es gelingt, sowohl der individuellen Psyche wie auch der Logik bewusst adäquaten Raum zu geben, wird diese Ganzheitlichkeit positiven Einfluss auf die Produktionsergebnisse nehmen, indem Umsicht, Qualität oder Genialität der Beteiligten neue Horizonte erschließen. Es ist dabei eine bekannte Tatsache aus der Gehirnforschung, dass jeder Mensch im Wechselspiel dieser Kräfte im ganzheitlichen Sinne operiert: Haben Sie z. B. schlechte Laune bzw. Spannungen mit Kollegen, so wird dies vielfach Ihre logische Performance senken! – Wenn dem so ist, dann liegt es auf der Hand, dass neben prozessualen Kenntnissen über den Bau von Software ein systemischer, sprich ganzheitlicher Ansatz notwendig ist, der nicht nur das Produkt, die Prozesse und die verschiedenen „Rollen“ zur Realisierung dieses Produktes im Auge hat, sondern der aktiv die Stärken und Schwächen der beteiligten Menschen so integriert, dass diese im Rahmen ihrer Möglichkeiten und Fähigkeiten in ihrem individuellen Optimum agieren. Um dieses individuelle Optimum greifbarer zu machen, ist es sinnvoll, einen Blick auf diejenigen Einflussfaktoren zu werfen, die in besonderem


Abb. 6.1. Was an den Mitarbeitern zerrt und zehrt

Maße in und an den einzelnen Mitarbeitern wirken. Dabei geht es nicht um kurzfristige Schwankungen der eigenen Gefühlslage, sondern um solche Faktoren, die für einen Menschen prägend sind. Sie haben sich im Laufe eines Lebens individuell eingestellt und geben nun als Dauergäste dieser Person ein eigenes Gesicht. In Abb. 6.1 sind drei verschiedenartige Kräftedreiecke aufgetragen. Sie sind jeweils auf ihre spezifische Weise wirksam und beeinflussen das Verhalten des Einzelnen erheblich. Die Überlagerung und das Zusammenspiel dieser Kräfte, das sei vorab bemerkt, sind dabei zentrale Faktoren bei den in Kap. 6.3 beschriebenen Teamaspekten. Jeder Mitarbeiter – auch Sie selbst – wird in dem Kontext seiner Arbeit von diesen Kräften gezogen – vielfach auch gezerrt. Diese Kräfte beginnen im Innersten der Persönlichkeit mit dem, was den Menschen als Person im Sinne der Transaktionsanalyse von Eric Berne ausmacht. Bei der Transaktionsanalyse handelt es sich zunächst um ein therapeutisches Verfahren, das erfolgreich dazu eingesetzt wird, um das eigene Kommunikationsverhalten besser verstehen zu können. Das Modell an sich beruht auf drei verschiedenen, sogenannten „ICH-Zuständen“. Berne fand heraus, dass in der Kommunikation zwischen diesen verschiedenen Zuständen häufig gewechselt wird, was z. B. an Wortwahl, Tonfall und Inhalten wie auch Mimik, Gestik und Körpersprache zu erkennen ist. Die Transaktionsanalyse wird zunehmend mehr im Organisationsbereich eingesetzt und dient dort als Denk- und Handlungsmodell. Mit dieser Vorgehensweise ist es möglich, professionelles Handeln, Selbstverantwortlichkeit, Vereinbarungen und wechselseitiges Vertrauen des Einzelnen zu beschreiben, Teaminteraktionen aufzudecken bzw. einzelne Personen individuell weiterzuentwickeln. Mit dem klassischen transaktionsanalytischen Ansatz lassen sich die eigene Produktivität oder Lebensqualität, die Selbst- wie auch Fremdwahrnehmung erklären. Es ist möglich, das eigene Weltbild,


die verborgenen Wünsche, persönlichen Schwachstellen und Stärken als Grundgerüst des eigenen Handelns zu identifizieren und zu beeinflussen. Wenn auch dem eigenen bewussten Handeln oftmals verborgen, so sind es genau diese drei „ICH-Zustände“, die erheblich den Einzelnen in seinem Handeln beeinflussen. Hierbei wirken, je nach Reife der betroffenen Person, die folgenden imaginären ICHs auf die eigene Handlungsweisen ein: Eltern-ICH. Nach Berne trägt jeder in seinem Inneren seine Eltern mit sich herum. Dies äußert sich in der Kommunikation z. B. darin, dass der Gegenüber bevormundet wird oder man väterlich herablassend den Boss heraushängen lässt. Aus dieser Haltung wird dem anderen gesagt, wie er zu handeln habe oder dessen Verhalten gerügt. Gerade im betrieblichen Alltag mit seinen Hierarchien rutscht mancher Vorgesetzte leicht in dieses Eltern-ICH ab. Erwachsenen-ICH. Dieser ICH-Zustand ist reif und kann Situationen weitestgehend sachlich und objektiv wahrnehmen. Solange Kommunikation aus dem Erwachsenen-ICH-Zustand heraus geschieht, wird der Kollege als gleichwertig behandelt. Der Umgang ist respektvoll und sachlichkonstruktiv. Je mehr Mitglieder eines Teams aus diesem ICH-Zustand heraus handeln, umso mehr versachlicht sich die gemeinsame Arbeit und umso mehr wird sie von Dialogen und gegenseitiger Akzeptanz geprägt sein. Kinder-ICH. Vergleichbar dem Eltern-ICH reagiert hier der Einzelne kindisch. Uneinsichtigkeit oder Trotz, Unsicherheit oder Albernheit gehören zu diesen Charakteristika. Ebenso sind es nach Berne jedoch auch Phantasie, Neugier und Lerneifer die diesen Bereich umfassen. Kollegen, die immer wieder mit denselben Stereotypen ihre Witzchen reißen oder unerwartet emotional in Sachdiskussionen reagieren, handeln hier vielfach aus dem Kinder-ICH. Hierzu noch einige praktische Anmerkungen: 1. Der Vollständigkeit halber sei klargestellt das Kreativität nicht in diese „ICH-Zustände“ einsortiert werden kann, da auch Menschen sehr kreativ sein können, ohne dabei kindisch werden zu müssen. 2. Das erfolgreiche Überleben im Job erfordert Konfliktfähigkeit. Diese hat viel mit erfolgreicher Problembewältigung zu tun. Reife Mitarbeiter, also solche, die in zunehmendem Maße aus dem Erwachsenen-ICH heraus handeln, sind vielfach Menschen, die Probleme anpacken. Sie schieben diese nicht auf die lange Bank oder reden sie weg. Ohne als notorische Dickschädel auftreten zu müssen, stellen sie sich Konflikten und vertreten ihre Position.


3. Im Sinne dieser Wertung gehört das Feld der „Notlügen“ und Beschönigungen in diese Kategorie der ICH-Zustände. Um die eigene Haut zu retten, werden z. B. an Projektauftraggeber oder Kunden offensichtliche Unwahrheiten weitergegeben. Es ist letztendlich die unreife Vorgehensweise des Kinder-ICHs, das zwar Papas Lob oder Taschengeld (z. B. in Form eines Vertragsabschlusses) haben möchte, nicht aber dessen Schelte. Auch wenn diese kleinen und großen Unwahrheiten in der Geschäftswelt sehr verbreitet sind, so haben sie in Teams eine vehement zerstörerische Wirkung, da in effektiven Teams Vertrauen eine der wichtigsten Grundvoraussetzungen ist. Das zweite Einflussfeld in Abb. 6.1 (S. 156) setzt sich vorwiegend aus dem zusammen, weshalb Sie vermutlich den aktuellen Job bekommen haben. Ihr jetziger Arbeitgeber war der Ansicht, dass Ihr Wissen und Ihre Fähigkeiten dem am ehesten entsprachen, was er für die ausgeschriebene Position suchte. Auch wird er sich ein Bild Ihrer Persönlichkeit gemacht haben, um zu prüfen, ob hier die „Chemie“ stimmt. Ich nenne dieses Triagon das „Persönlichkeitsdreieck“, es findet sich teilweise auch unter dem Namen „holistisches Dreieck“, ist dort aber nicht eindeutig genug definiert. Wissen. In diesem Kontext bezieht sich Wissen ausschließlich auf das, was der Einzelne „im Kopf“ hat. Es geht nicht um ausgelagertes Wissen in Form von Kompendien, Datenbanken oder Knowledgebases. Dabei bezeichnet dieses individuelle Wissen die Gesamtheit aller organisierten Informationen mitsamt ihrer wechselseitigen, also ganzheitlichen Zusammenhänge. Von diesem Wissen ist vieles nicht ohne weiteres mit Worten beschreibbar, sondern muss vielfach mit Hilfe anderer Ausdrucksmittel beschrieben werden. (Ein Beispiel: Sie wissen, was eine Wendeltreppe ist, und wollen diese in einer anderen Sprache kommunizieren, ohne den genauen Fachbegriff zu verwenden. – Welche Mittel setzen Sie dafür ein?) Wenn Sie zurück an die Meme denken (S. 118 ff.), so wird deutlich, dass Wissen nichts Statisches ist, sondern eine eigene Dynamik aufweist. Es formt sich immer wieder neu, es aggregiert und wird ständig erweitert. Geschieht dies nicht mehr, so entspricht dies Krankheitsbildern im Sinne der Alzheimer Erkrankung. Fähigkeiten. Beschreibt Wissen die Zusammenhänge, so sind es die Fähigkeiten, die diesem Wissen Gestalt geben. Unter „Fähigkeiten“ ist all das zu verstehen, was Sie aktiv beherrschen und auch anwenden. Hierzu zählen auch die Metaskills, etwa Dinge systemisch anzugehen. – Es reicht nicht aus, diese nur zu kennen. Solange kein inneres Umlernen stattgefunden hat, werden Sie zwar über diese Dinge wissen, sie gehören jedoch nicht zu Ihrem Fähigkeitsrepertoir und kommen somit fast kaum zur Wirkung. Reine


Wissensvermittlung, die nicht darauf bedacht ist, Wissen in Fähigkeiten zu überführen, hat daher vielfach ihr Ziel verfehlt. Anders als Wissen unterliegen Fähigkeiten ganz anderen Gesetzen: Ihr Erlernen braucht Zeit und ist vielfach ein mühsames und stetes Üben. Werden Fähigkeiten nicht eingesetzt, so regredieren diese auch wieder. Einstellungen. Hierunter ist das persönliche Wertesystem zu verstehen. Was sind die Koordinaten, in denen Sie grundsätzlich operieren. Hier liegt fest, ob Sie vorwiegend aus Eigennutz handeln oder anderen Vortritt geben, ob Sie zwischen Mein und Dein unterscheiden können. – Einerseits werden Menschen, die länger mit Ihnen zusammen sind, Sie an diesen Einstellungen im Sinne einer Persönlichkeit messen, andererseits werden Sie diese Eigenschaften in nicht unerheblichem Maß in Ihre Umwelt replizieren. Insgesamt gilt hier, dass auch sie einem lebenslangen Entwicklungsprozess unterliegen. Alle drei Bereiche zusammengefasst, wirken in höchst individueller Weise durch jede einzelne Person und befähigen diese, anspruchsvolle Aufgaben in einem größeren Kontext zu erledigen. Auch hierzu möchte ich einige Implikationen für den Projektalltag ableiten: 1. Jeder dieser drei Punkte ist leicht verderbliche Ware. Besonders in der IT liegt die Halbwertzeit von Wissen deutlich unter 10 Jahren. Bisher angewandte Vorgehensweisen, wie z. B. Programme erstellt oder Projekte geführt werden, sind recht schnell veraltet und überholt. Es ist daher notwendig, ganzheitliches Lernen zum Teil der persönlichen Kultur zu machen, damit persönliches Wissen aktuell bleibt. 2. Gerade weil wir in einer „Wissensgesellschaft“ leben, liegt der Fokus auf dem Wissen an sich. Was jedoch leicht vergessen wird, ist die Tatsache, dass nur eine Wissensgesellschaft mit Werten und adaptiven Fähigkeiten in der Lage ist, rasch genug zu reagieren (vgl. hierzu „Lean Production“). 3. Aus der Erkenntnis, dass die produktive Effizienz in der Teamarbeit zu suchen ist, spielen persönliche Eigenschaften speziell im Softwarebau eine sehr wichtige Rolle. Diese Werte sind von enormer Bedeutung, da sie andernfalls den Einzelnen zum Teil einer grauen Masse aus JASagern oder hochgradigen Egoisten werden lassen, der nach außen hin systemkonform auftritt, aber der sich nach innen hin immer mehr abkapselt und gemeinschaftsunfähig wird. Dies jedoch sind Eigenschaften, die für kreative und dynamische Teams völlig ungeeignet sind! Das dritte Kräftedreieck in Abb. 6.1 betrifft das individuelle Beziehungsnetzwerk. Es sind die lauten und leisen Forderungen oder Wünsche, die tagtäglich auf den Einzelnen einwirken und auf die sich jeder als Folge


seines Lebens- und Arbeitskontextes einlässt. Dieses Triagon aus Geben und Nehmen, Einfordern und Anpassen spielt im beruflichen Kontext eine starke Rolle. In diesem Dreieck geht es dabei um Folgendes: Organsiation, Projekt & Prozesse. Die nackte Tatsache, dass man Geld zum Leben braucht, weshalb man einen Arbeitsvertrag unterschrieben hat, um im Gegenzug für eine Organisation nach vorgegebenen Arbeitsprozessen einen Job zu machen, ist die eine Variante. Die andere Variante kann lauten: Man bringt seine Fähigkeiten in eine Organsiation ein, die so strukturiert ist, dass sie die Mitarbeiter dazu motiviert, im Rahmen der eigenen Arbeit etwas Sinnvolles hervorzubringen, und ihm dafür soziale Anerkennung (Karriere) oder wirtschaftliche Anerkennung (angemessene Vergütung) anbietet. Während das erste Beispiel eher abstoßende Wirkung auf den Einzelnen erzielt, wird die zweite Variante eine ganz eigene Attraktivität – und damit Anziehungskraft – ausüben. Kollegen & Mitarbeiter (Rolle). Die zweite Kraft bezieht sich auf die Menschen im eigenen Arbeitskontext. Der Stress mit dem Chef, das Mobbing durch die Kollegen oder das tolle Team wirken hier auf ihre Weise und beeinflussen die Person in ihrer Einstellung, ihrem Arbeitswillen und ihrer Leistungsfähigkeit. Wie gerne man in den Kreis der Kollegen werktäglich zurückkehrt, ist hier ein gut wahrnehmbares Maß der Dinge. Privatbereich (Individuum). Die dritte Kraft, die ich in diesem Kontext bewusst an das Ende gestellt habe, betrifft den Privatbereich des Einzelnen. All das, was außerhalb vom Job stattfindet: die familiären Spannungen, bereichernde Hobbys, wachsende Schulden, harmonische Beziehungen in der eigenen Familie oder Unglücksfälle im eigenen Umfeld nehmen ganz erheblichen Einfluss auf die Einzelperson. Die Natur unterscheidet dabei nicht zwischen privat und beruflich, somit wird dieser Teil des Lebens, wenn auch vor den meisten Kollegen verborgen, in die Arbeit mit eingebracht. Sie verbessert oder verschlechtert die individuelle Arbeitsleistung ganz erheblich. Von den drei vorgestellten Kraftfeldern wirkt das zuletzt präsentierte am direktesten und schnellsten. Gerade für dieses Dreieck gilt in besonderer Weise, dass solche Menschen, die immer wieder neu und aktiv eine Balance dieser Einflussfaktoren herstellen, dauerhaft leistungsfähiger und gesünder bleiben als die Vergleichsgruppen. Zwar lässt sich nicht verhindern, dass kurzzeitige Ungleichgewichte auftreten und Mitarbeiter in ihren Leistungen beeinträchtigt werden, jedoch ist eine aktive Rückkehr zu dieser Balance notwendig. Personen, die hierauf keine ausreichende Rücksicht nehmen, sind mittelfristig dazu prädestiniert, sich in psychotherapeutischer Behandlung oder mit klassischen Stresserkrankungen wiederzufinden.


Es geht mir dabei nicht darum, ein „Heile-Welt“-Szenario zu propagieren, bei dem dieser Ausgleich zum Dreh- und Angelpunkt aller Aktivitäten wird. Worum es mir allerdings geht, ist klarzustellen, dass die einzelnen Mitarbeiter durch einen entsprechenden arbeitstechnischen und führungsmäßigen Rahmen die Chance haben müssen, regelmäßig in dieses Lot zu kommen, da sie nur so für die eigene Organisation maximale Leistung über lange Zeiträume erbringen können. Die weitsichtige und ganzheitliche Berücksichtigung dieses Wechselspiels systemischer Kräfte gestattet es, ein Arbeitsumfeld so zu gestalten, dass die einzelnen Mitarbeiter weitestgehend in ihrem Optimum arbeiten, ohne dabei zerrieben zu werden. Speziell für den Softwarebau ist dies von eminenter Bedeutung, da aufgrund der engen Zeitpläne und der hohen Kosten Effizienz die wichtigste Stellschraube ist, um „gute“ Resultate, im Sinne der Vorüberlegungen, in möglichst kurzer Zeit zu erhalten. Dies muss in einer Weise geschehen, dass die Mitarbeiter nicht aufgrund konstanter Überforderung oder strukturell bedingter Unzufriedenheit in starkem Maße fluktuieren oder als Einzelpersonen in den Burnout getrieben werden. 6.1.1 Grenzen der Arbeit Alle Dinge werden unter Druck schlimmer. (Murphys Law) Chronische Überforderung verlangt einen hohen Preis. Neueste Untersuchungen zeigen, welche enormen psychischen Belastungen auf Mitarbeiter in der Softwareindustrie wirken. In einer Studie des vom Bundesland Nordrhein-Westfalen betriebenen Forschungs- und Entwicklungsinstituts IAT wurde anhand von statistischen Untersuchungen belegt, dass Wissensarbeit im IT-Bereich viermal häufiger psychosomatische Störungen zur Folge hat, als sie unter deutschen Durchschnittsbeschäftigten üblich sind (Latniak und Gerlmaier 2006): Müdigkeit, Nervosität, Schlafstörungen oder Magenbeschwerden wurden hier weit häufiger angetroffen als in anderen Bereichen. Wo immer, so die Gelsenkirchner, länger als 8 Wochen Dauerstress in diesem Bereich überschritten werden, treten bereits Vorboten des Burnout auf, was bei ca. 40% der befragten Personen im Rahmen dieser Studie der Fall war! Mitarbeiter, die nicht ihre persönlichen Grenzen in der beruflichen Arbeit kennen, werden unweigerlich innerhalb kurzer Zeit von diesen Effekten in Mitleidenschaft gezogen. Dies hat zur Folge, dass die persönliche Leistungsfähigkeit, die Fähigkeit, komplexe Situationen effizient zu meistern, sowie kreatives Handeln deutlich nachlassen. In diesem Zusammenhang macht eine neue Krankheitsbezeichnung mit Namen „Hurry Sickness“ die Runde. Durch die ständige Forderung nach erhöhter Leistung des Einzelnen und unter Missachtung der eigenen


Ausbalanciertheit arbeiten vielfach IT-Mitarbeiter regelmäßig 60 und mehr Wochenstunden. Auf den ersten Blick mag das für ein Unternehmen sehr gut aussehen. Im Sinne des systemischen Dreiecks ist dies jedoch desaströs: Zum einen wird dieses innere Kräftegleichgewicht immer mehr aus dem Lot gebracht und speziell der private Bereich, der äußerst wichtig für die eigene Regenerierung ist, bleibt in aller Regel mehr und mehr auf der Strecke. Fatal sind auch die Folgen für die Organisation selbst: Die wachsende Zahl an Stunden im Büro wird zunehmend ineffizienter genutzt, zusätzlich sinkt die Qualität der Resultate. Überdies steigt das mittelfristige Erkrankungsrisiko, was für eine Organisation einen weiteren großen Nachteil darstellt, weil der Weggang oder Ausfall von Wissensträgern bzw. das Einarbeiten neuer Mitarbeiter sehr zeit- und kostenintensiv ist und die Gesamtproduktivität gerade in teamorientierten Organisationsstrukturen deutlich absenkt. Als eine Antwort auf diese Problematik setzen sich immer mehr nachhaltig denkende Unternehmen der Branche mit der „Time Life Balance“ auseinander. Dies wird unterstützt durch entsprechende Axiome innerhalb verschiedener agiler Prozessmodelle (vgl. Kap. 3.7.2, S. 75 ff.). Um die Leistungsfähigkeit der Mitarbeiter zu erhalten, werden diese, wenn irgend möglich, regelmäßig nach einem 8-Stundentag in die Freizeit entlassen. Dabei geht es nicht um die Unterstützung einer Mentalität, zu einer bestimmten Stunde die Computermaus fallen zu lassen. Hier hat sich vielmehr die Erkenntnis durchgesetzt, dass die investierten Mehrstunden zwar Kosten erzeugen, aber keine Produktivitätssteigerung mit sich bringen. – Arbeitstechnisch verlangt dies von der Organisation, dass ganzheitliche Optimierungen in die Wege geleitet werden, wie sie z. B. im Rahmen dieses Buches angesprochen werden. Stress, obwohl so verbreitet in der Branche, wird damit zum größten Feind, um die inhärente Komplexität großer Projekte effizient und konstruktiv lösen zu können. Dies ist physiologisch gesehen auch nicht weiter verwunderlich: Statt über den Problemen zu stehen, also diese zu beherrschen, befindet man sich auf einmal zwischen gewissen Umständen, Erwartungen und unter Zugzwängen. Statt frei agieren zu können und Lösungsvarianten mit ausreichender Ruhe und emotionalem Abstand betrachten zu können, muss im Eilverfahren reagiert und gehandelt werden. Die biologisch natürliche Reaktion des Körpers darauf wäre die Flucht. Die zivilisatorisch moderne Variante besteht darin, dass man versucht, sich dieser Probleme möglichst rasch zu entledigen. Als Folge des Stresses wird vorwiegend in kurzen und direkten Lösungen gedacht. Quick Wins werden gebraucht und Raum für die ganzheitliche Betrachtung der Probleme ist nicht mehr gegeben, da hierfür der Kopf nicht mehr frei ist. Infolgedessen können die systematischen Probleme hinter den sichtbaren Themen kaum noch wahrgenommen werden.


Hiermit soll nicht ausgedrückt werden, dass jegliche Art von Stress im projekttechnischen Sinne abträglich wäre. Eine Differenzierung zwischen den beiden bekannten Stressarten „Di-Stress“ und „Eu-Stress“ ist daher notwendig. Handelt es sich um dauerhaften Di-Stress, so ist damit zu rechnen, dass der Körper irgendwann zurückschlagen wird und diejenigen Effekte eintreten werden, die im Zusammenhang mit der IAT-Studie aufgeführt wurden. Die Situation wird als unangenehm, belastend und überfordernd wahrgenommen; infolgedessen übt sich der Betroffene in Vermeidungstaktiken. Wäre die Person an dieser Stelle absolut ehrlich, so würde sie vermehrt über schlaflose Nächte und Selbstzweifel berichten. Ganz anders der Eu-Stress: Hier wird die Aufgabe als Herausforderung wahrgenommen, der man sich stellt und für die man absolut alles mobilisiert. Man hält sich dabei für ausreichend kompetent, das Problem erfolgreich zu lösen, und nimmt die Aufgabe im Sinne einer sportlichen Herausforderung an. Dies ist die Atmosphäre, die für kreativ arbeitende Teams absolut notwendig und förderlich ist. Es ist der Zustand, in welchem ein hohes Maß an Ideen und gegenseitiger Inspiration komplizierte Zusammenhänge durchleuchten, systematisieren und transparent machen. Allerdings: Vorsicht ist an einer Stelle geboten! Nur ein sehr schmaler Grat trennt EuStress vom Di-Stress. Psychologische Untersuchungen belegen, dass oft nur ein Quäntchen Zuviel an Forderung ausreicht, um die Wippe umklappen zu lassen. Gerade den Teamleitern fällt daher meist die Aufgabe zu, das jeweilige Team bis an die Grenzen des Eu-Stresses zu führen, gleichzeitig jedoch zu verhindern, dass sie diesen Rubikon durchschreiten. Der Körper selbst arbeitet zyklisch im ständigen Wechsel zwischen Anspannung und Entspannung. Am Beispiel Wachheit und Müdigkeit kann jeder noch so logisch denkende Mensch dies an sich selbst wahrnehmen. Dabei lehrt die Psychologie, dass Störungen erst dann entstehen, wenn das Gleichgewicht zwischen beiden Größen aus dem Lot gerät. In solchen Situationen schaltet der Körper auf Kampfprogramm um: Die Pumpleistung des Herzens wird erhöht, ebenso wird der Blutdruck gesteigert, die Verdauungstätigkeiten reduziert und das Blut in die Muskeln geschickt. Hierdurch sinkt folgerichtig die Denkleistung!

Softwarebauer und Mönche Derzeit zieht langsam, fast unbemerkt eine neue Spezies in unsere Gesellschaft ein. Die Rede ist von den Slobbies. Hierbei handelt es sich keineswegs um Marsianer oder Lebewesen fremder Kulturen, sondern um Persönlichkeiten, die gelernt haben, dass eine enthektisierte Gangart sie nicht nur persönlich länger leistungsfähig hält, sondern es ihnen auch ermöglicht, qualitativ hochwertigere Arbeiten zu leisten, weil sie weniger Fehler machen. Hierbei steht der Begriff Slobby für „Slow but Better“. Vor dem


Hintergrund dessen, was Peter Senge (Senge 1994), einer der Vordenker im Bereich Unternehmensoptimierung, als „Gesetz“ propagiert hat, nämlich: „Schneller ist langsamer“, ist dieser hierzu invertiert formulierte Ansatz speziell im Zusammenhang mit dem Softwarebau auch aus wirtschaftlicher Sicht bedenkenswert. Er verlangt allerdings eine Lebenszyklus-bezogene Sichtweise. Übertragen auf den klassischen Projektalltag mag dies befremdlich klingen: Sollen die Softwareentwickler noch langsamer arbeiten, als sie es ohnehin schon tun? Nein, keineswegs – worum es geht, ist die „natürliche Geschwindigkeit“ der Entwickler (nicht eines faulen Entwicklers wohlgemerkt!) zu finden, aber das Umfeld, d. h. Werkzeuge, Methoden, Automatisierung etc., so zu optimieren, dass die Entwickler in ihrem Eigentempo nur dort in hohem Maße zeitlich gebraucht werden, wo ihre intellektuelle Leistung, ihre Kreativität oder ihr systemisches Denken zur Verringerung der Komplexität beiträgt. Im Sinne von Zeitökonomie führt überhastetes Arbeiten zu voreiligen Schlüssen und somit teuren Folgefehlern, die nur unter zusätzlichem Zeitoder Materialeinsatz wieder behoben werden können. Indem Projekt- und Eigenrhythmus der beteiligten Personen miteinander synchronisiert werden, ist hier eine klare Optimierung möglich. Besonders in der agilen Fachliteratur wird immer wieder auf die Bedeutung eines solchen Projektrhythmus hingewiesen. Hierunter ist zu verstehen, dass bei den iterativen Entwicklungsmodellen eine zeitliche Regelmäßigkeit der formalen Abläufe herbeigeführt wird, vergleichbar denen eines Wochenrhythmus. Wie lange im IT-technischen Sinne solch eine Iteration sein sollte, hängt von dem gewählten Prozessmodell (z. B. Extreme Programming 1 Woche, RUP 3–6 Wochen) sowie der Projektgröße ab. In diesem Sinne hat die Umstellung auf zyklisches Vorgehen auch für die Projektbeteiligten einen positiven Effekt: Hierdurch kann nicht nur bereits nach kurzer Zeit die geleistete Arbeit bewertet und ggf. korrigiert werden, sondern auch der Mensch, als zyklisch operierendes Wesen, kann in seinem eigenen Takt effizienter und stressärmer arbeiten. Dies lässt sich besonders gut beobachten, wirft man einen Blick auf die Mönchsbewegungen. Auch wenn für viele Zeitgenossen mönchisches Handeln keinen persönlichen Bezug mehr hat, so wurde und wird diese sehr zyklisch ausgerichtete Lebensweise dort erfolgreich seit hunderten von Jahren in hochstrukturierter Form praktiziert. – Keine Angst, ich will Sie an dieser Stelle nicht dazu ermutigen, Mönch zu werden oder einen IT-Orden zu gründen. Was ich allerdings möchte, ist, einen kurzen Blick auf einige interessante Aspekte dieser Gemeinschaften zu werfen. Alle vorgestellten Bereiche haben einen direkten Bezug zum Projektalltag. Es lassen sich, bei genauerer Betrachtung, eine ganze Menge Anregungen von diesen Formen religiös geprägten Zusammenlebens mitnehmen:


Leben im Rhythmus. Auch wenn für viele Menschen der Gegenwart der lateinische Satz „Ora et Labora“ bedeutungslos geworden ist, so prägt er dennoch in ganz besonderer Weise das Leben der einzelnen Mönche. Der regelmäßige Wechsel zwischen Konzentration und Kontemplation macht es immer wieder möglich, dass auch sehr anspruchsvolle Aufgaben, (z. B. Übersetzungsarbeiten, Abschreiben von Büchern im Mittelalter) zügig und in höchster Qualität erbracht werden bzw. wurden, da die nötigen Pausen durch Gebetszeiten oder andere Formen der inneren Einkehr regelmäßiger Bestandteil des Tagesablaufs sind. Leben in der Ganzheitlichkeit. Das gesamte klösterliche Leben ist von Ganzheitlichkeit geprägt. Durch den Wechsel zwischen Introspektive und Extrospektive wurden immer wieder auch ganz erhebliche akademische Leistungen im Sinne ganzheitlicher Betrachtungen und Forschungen durch Mitglieder dieser Gemeinschaften angestoßen und vielfach die Grundvoraussetzungen für unsere moderne Gesellschaft mitgeschaffen. Leben in Gemeinschaft. Durch das enge Zusammenleben im Sinne von 24/7-Gemeinschaften, vielfach auf dem begrenzten Raum klösterlicher Einrichtungen und der Verpflichtung, wirtschaftlich autonom zu arbeiten, haben gerade Klostergemeinschaften Teamarbeit im Sinne der Arbeitsteiligkeit bei gleichzeitiger Zusammenarbeit erfolgreich organisiert und vorgelebt. Leben in Unterordnung. Klöster sind keine basisdemokratische Einrichtung, sondern haben eine klare Organisationsstruktur mit eigenem Management und geteilten Verantwortlichkeiten (Abt, Celerar etc.). Gerade die Ordensregeln (Kirchner 2001), verstanden als Organisationshandbuch, legen großen Wert auf den Charakter und die Aufgaben dieser Leitungspersönlichkeiten. Insbesondere ganzheitliches Führen, aber auch die Weiterentwicklung der Mitmönche haben dabei einen besonderen Stellenwert. Die hier vor hunderten von Jahren definierten Standards entsprechen vielfach neuesten Erkenntnissen in der Managerausbildung. 6.1.2 Ganzheitlichkeit und Innovation Kreativität ist nichts anderes als die Fähigkeit, Dinge, die nichts miteinander zu tun haben, zu kombinieren. Dazu gehört die Fähigkeit, Dinge völlig unvoreingenommen zu betrachten und sich vom Korsett herkömmlicher Denkstrukturen zu lösen. (Ida Fleiß, ehem. Lufthansa Psychologin) Unsere Zeit ist geprägt von Spezialisten für jedes nur denkbare Thema. Gefragt ist vielfach die genaue Einhaltung definierter Prozesse. Manager


und IT-Verantwortliche denken dabei oftmals mit einem Tunnelblick, indem sie ihnen bekannte Dinge nehmen und sie auf Zukünftiges projizieren. Begründet wird dies damit, dass man keine erhöhten Risiken eingehen wolle. Hierdurch entstehen leicht Fehleinschätzungen, wie einige Beispiele aus der modernen Geschichte belegen: x Nachdem man die Eisenbahnen erfunden hatte, kommentierte Preußens König deren Weiterentwicklung wie folgt: „Mit Sicherheit wird sich niemand finden, der dafür Geld ausgibt, dass er binnen einer Stunde von Berlin nach Potsdam gelangt, wenn er die gleiche Strecke als Tagesreise auf dem Rücken eines Pferdes umsonst zurücklegen kann!“ x Über die dubiose Erfindung der Glühbirne durch einen gewissen Herrn Thomas A. Edinson bemerkte ein englischer Parlamentsausschuss, dass diese wohl zu nichts nütze sei und man ihr keine weitere Beachtung schenken solle. x Und selbst eben dieser Edinson äußerte sich ähnlich über eine andere seiner Erfindungen, nämlich den Phonographen. Sein Kommentar: Dieses Gerät werde wohl keinen kommerziellen Wert haben und all das Getue um drahtlose Übertragung werde sicherlich bald wieder abgeebbt sein. – Er irrte, wie wir wissen! Drei Ansichten prominenter Herkunft, Aussagen aber auch, die auf ein Problem verweisen, was zum limitierenden Faktor bei der innovativen Entwicklung von Software werden kann. Dort, wo dies stattfindet, so ein Artikel über Kreativität im „Harvard Manager 2/2003“, sind die entsprechenden Softwarehäuser im Branchenvergleich hervorragend platziert, wie die Studie am Beispiel von SAP belegt. Innovatives Denken und Handeln gehört daher speziell in der Softwarebranche zum absoluten Pflichtprogramm auf dem Weg zum Unternehmenserfolg. Um dies entsprechend umsetzen zu können, bedarf es des richtigen Umfeldes. Bezeichnend ist hierbei das folgende Zitat: Wenn Sie Arbeit zu einem Ort machen, an dem Menschen ermutigt werden, Sie selbst zu sein, Spaß zu haben und Risiken einzugehen, dann entfesseln und entsenden Sie deren Kreativität. (Mind Games in: Fast Company Jan./Feb. 2000, S. 168180) Somit ist mit dieser einzigartigen Mischung aus Anspannung und Konzentration, Sicherheit und Stimulation, Spaß und Risikobereitschaft die beste Voraussetzung für innovatives Wachstum gegeben. Es ist in diesem Zusammenhang zu beobachten, dass Mitarbeiter innovativer Firmen fast ausschließlich über sehr hohe Disziplin verfügen und in diesen Firmen sehr geringe Krankenstände vorhanden sind. Eine weitere Studie über Kreativität weisst daraufhin, dass die Innovativität einer Organisation direkt mit dem Maß an kreativem „Querdenken“ korrelliert (Meyer-Grashorn 2004).


Dieses Querdenken steht wiederum in engem Zusammenhang mit den individuellen Wahrnehmungskanälen und den spezifischen Intelligenzen der Beteiligten. Nach Gardner (Gardner 2000) differenzieren sich sieben unterschiedliche Formen der Intelligenz22, die in unterschiedlicher Kombination vorkommen können und die vielfach in den klassischen softwaretechnischen Bereichen nur ansatzweise genutzt werden, während diejenigen Sparten, die z. B. für den künstlerischen Bereich produzieren (z. B. Filmanimation, digitale Specialeffects etc.) dies sehr viel breiter nutzen. Allerdings: Kreativität braucht seine Zeit, wobei dieser Prozess durchaus als schwere Arbeit zu werten ist, bei dem kreative Gedanken reifen, überdacht, korrigiert und modifiziert werden müssen. All dies geschieht aus einer eigenen Dynamik heraus. Dabei werden mentale Frische und Kreativität von anderen Dingen des Lebens sowie der Vielseitigkeit andersgelagerter Interessen gespeist und inspiriert. – Es ist daher aus Organisationssicht notwendig, einen klaren, wenn auch flexiblen Rahmen zu schaffen und aufrechtzuerhalten, der dies unterstützt. Indem größere Wirkzusammenhänge eruiert werden und zugleich nach kreativen Lösungen gesucht wird, also neue Meme gebildet werden, entstehen Ansätze für schlanke und geniale Lösungen auch für den klassischen Softwarebau. Nach Siegmund Freud gleicht das menschliche Bewusstsein einem Eisberg. Unser direkter Wahrnehmungsbereich macht dabei 1020% aus, während der Rest unter Wasser verborgen liegt und dabei recht wenig über die logischen Teile unserer Ratio erreicht werden können. Demzufolge wird auch der größte Logiker, der nichts von „Gefühlsduselei“ hält, sich damit abfinden müssen, dass auch bei ihm nur 20% aus eben dieser Logik gespeist werden. Der Rest setzt sich aus Ängsten, Hoffnung, Sympathien, Unsicherheiten, Vertrauen, Erfahrungen, Erwartungen bzw. deren Gegenteile zusammen. Mit diesem Verweis auf Freud möchte ich verdeutlichen, dass selbst die größten Logiker und Rationalisten in ihren Entwicklungsteams letztlich nur einen Teil ihrer Fähigkeiten einsetzen, wenn sie ausschließlich klassisch an die Probleme herangehen. Um den für manche IT-Experten suspekten Bereich der Kreativität greifbarer zu machen, gibt es entsprechende methodische Hilfsmittel, um im Sinne von Risikobewertungen diese Kreativergebnisse sicherer und konkreter werden zu lassen. Wovon ich spreche, sind neben der Technik des systemischen Denkens vor allem auch ganzheitliche Bewertungsmöglichkeiten dessen, was hier entsteht. Konkret sind hier Methoden wie die der „sechs Hüte“ nach deBono (deBono 2000; deBono 2005) 22

Die sieben Intelligenztypen nach Gardner: Denken: verbal-linguistische Intelligenz, logisch-mathematische Intelligenz. Wahrnehmen: visuell-räumliche Intelligenz, körperliche und Bewegungsintelligenz, musikalisch-rhythmische Intelligenz. Kommunikation: interpersonale Intelligenz, intrapersonale Intelligenz.


anwendbar. Hier wird im Sinne der Ganzheitlichkeit die entsprechende Thematik aus sechs verschiedenen Blickrichtungen23 betrachtet und ausgewertet. Indem solche bihemisphärischen Arbeitsmethoden (Eiffert 2001) mehr Raum neben den klassischen Vorgehensmodellen erhalten, besteht die Möglichkeit, nicht nur sehr viel mehr des persönlichen Fähigkeitsspektrums im Kontext des Softwarebaus zu nutzen, sondern zugleich auch auf eine geringere Fehlerquote zu kommen. Dabei wird auf diese Weise sowohl der Logikteil des Gehirns als auch die intuitiv-optische Hälfte adäquat eingesetzt. Nicht umsonst propagieren verschiedene Prozessmodelle, wie z. B. der RUP, als eines ihrer sechs „Best Practices“ den Einsatz von grafischen Tools, um visuell zu modellieren. Diese Vorgehensweise ist eine von mehreren Ansätzen, um die beiden Hemisphären des Gehirns besser zu nutzen, die jedoch sowohl methodisch wie auch toolmäßig in Zukunft noch stark ausbaubar ist. In der Praxis sind gerade die frühen Phasen in Softwareprojekten oftmals in Bezug auf Kreativität hochgradig gefährdet, obwohl gerade hier innovatives Denken und Handeln erhebliche Kosten einsparen kann. Oft ist noch die antiquierte Erwartungshaltung zu finden, die darin besteht, dass gutes Software-Engineering durch raschen Beginn der Kodierung belegt wird. Ausreichend Zeit für Planen und Denken wird dort immer noch als Luxus empfunden.

6.2 Kybernetiker und Kutscher Qualität beginnt beim Menschen, nicht bei den Dingen. Wer hier einen Wandel herbeiführen will, muss zuallererst auf die innere Einstellung aller Mitarbeiter abzielen. (Philip B. Crosby, amerikan. Unternehmensberater) Kybernetik heißt Steuermannskunst – und genau darum geht es hier. Bekanntlich fällt dem Projektmanager die zentrale Rolle zu, das Projekt erfolgreich und rechtzeitig durch das gewünschte Ziel zu lenken. Um es vorwegzunehmen: Ein Projektmanager ist dabei nicht in erster Linie der Buchhalter oder Antreiber des Projektes. Versteht er seine eigene Rolle ganzheitlich, so ist er zwar die treibende Kraft, vor allem aber der Visionär und Motivator. Er 23

Bei den sechs Denkhüten nach deBono werden gezielt die folgenden Blickrichtungen eingenommen und aus dieser Sicht z. B. auf ein Projekt geschaut. Die Sichten sind: intuitiver Hut (Wie fühle ich mich bei dieser Sache?), informativer Hut (Welche Fakten liegen vor?), konstruktiver Hut (Wo liegen die Vorteile und Stärken?), reflektierender Hut (Wie kann das Ganze geplant und organisiert werden?), kreativer Hut (Wie kann Innovation und Wachstum eingebracht werden?) und zuletzt der Hut der Vorsicht (Wo sind Risiken und Gefahren?).

6.2 Kybernetiker und Kutscher 169

ist derjenige, nach dessen Vision Menschen sich formen und zu einem Team zusammenfügen lassen, um so gemeinsam die definierte Aufgabe zu lösen. In den Stellenanzeigen der FAZ, einer der bedeutenden Zeitungen für den Führungskräfte-Stellungsmarkt wurden am 30.07.94 vor allem folgende Eigenschaften für zukünftige leitende Mitarbeiter gesucht: Ganzheitliches Denken Belastbarkeit & Kampfgeist Flexibilität Verhandlungsgeschick Aufgeschlossenheit Durchsetzungsvermögen Kontaktfreudigkeit Zuverlässigkeit Integrationsfähigkeit Sympathisches Auftreten Pioniergeist

Zielgerichtete Kreativität Unternehmerisches Handeln Lust auf Verantwortung Eigeninitiative Persönlicher Einsatz Überzeugungskraft Vertrauenswürdigkeit Offener Führungsstil Kommunikationsfähigkeit Motivationsgabe Strategisches Denken

Diese Auflistung enthält sehr wichtige Fähigkeiten von Führungspersönlichkeiten. Was jedoch fehlte, sind Eigenschaften, wie die nachfolgend benannten: – – – – – – – – –

Bereitschaft zur permanenten Eigenkorrektur Mut zur Wahrheit Mut zu unpopulären Entscheidungen Klare ethische Position Menschen vor Gewinne zu stellen Ablehnung moralischer Kompromisse Enges Gewissen – aber weites Herz Globales Verantwortungsbewusstsein Authentische Lebensweise

Gerade diese fehlenden Eigenschaften aber sind es, die einer Führungspersönlichkeit Profil geben und diese befähigen, aus Einzelindividuen ein festgefügtes Team entstehen zu lassen, mit dem die gesetzten Ziele – vorausgesetzt sie sind realistisch – erreicht werden können. Weil in Unternehmen oftmals Zahlen das Entscheidende sind, wird der Mensch leicht zur Nebensache. Mitarbeiter degradieren zu Variablen, die man in BJ (= Beschäftigungsjahren) misst und dabei vergisst, dass diese, anders als bei Maschinen, keineswegs konstant die gleiche Leistung und Qualität erbringen, sondern in ihrer Leistungsfähigkeit sehr stark von anderen Faktoren beeinflusst werden. Hier setzt die wesentliche Aufgabe des Projektverantwortlichen oder Teamleiters ein. Zwar muss auch er am Ende


Zahlen und Ergebnisse liefern, jedoch besteht seine vordringlichste Aufgabe darin, die eigenen Mitarbeiter zu führen, zu motivieren und zu entwickeln. Somit muss er aus einer Sandwich-Position heraus in zwei Richtungen mit unterschiedlichen Methoden arbeiten und in keiner Weise im Sinne eines Funktionärs handeln. In diesem Zusammenhang ist eine neuere Umfrage unter Softwarehäusern durch die Universität Hamburg bezeichnend. In ihr sollte die Wichtigkeit einzelner Fähigkeiten für zukünftige Mitarbeiter im Projektmanagement ermittelt werden. Dabei ergab sich die folgende Rangfolge: x Persönliche Softskills (46%) x IT-Standardanwendungen (44%) x Soziale Softskills (32%) x Produktschulungen (29%) x Kaufmännische Fachkompetenzen (28%) x Gewerblich technische Fachkompetenzen (25%) x Fremdsprachen (21%) Diese Aufstellung verdeutlicht die überaus hohe Bedeutung von persönlichen Softskills und sozialen Fähigkeiten, um dieser komplexen Aufgabe gerecht zu werden. Es wurde bereits an anderer Stelle darüber gesprochen, dass gerade die Entwicklerteams durch ihren Einsatz, ihre Art zu denken und somit ihre Vorgehensweisen massiv über die entstehenden Kosten oder Gewinne der jeweils nächsten Dekade entscheiden (Grün 2003). Organisationen, wie z. B. die Internetfirma „Google“, haben für sich verstanden, dass eine hohe Investition in die Mitarbeiter einen entscheidenden Teil zum Unternehmenserfolg beiträgt. Auch unterstreicht der Blick in die derzeit aktuelle Managementliteratur (Schütz 2005) dies ganz klar: Hier wird Kooperation immer mehr zur Königsdisziplin erklärt – und zwar in allen für das Unternehmen relevanten Aspekten. – Statt starrer pyramidaler Strukturen, die in hohem Maße undurchlässig sind und eine ausgesprochen hierarchische Oben-unten-Struktur entstehen lassen, finden sich in modernen Organisationen immer mehr kooperative Varianten. Es kann nicht darum gehen, dass härter geschoben wird oder man versucht, noch mehr aus den Mitarbeitern herauszuquetschen. 6.2.1 Führung mit Stil Nie wissen wir genau, ob etwas besser wird, wenn wir es verändern. Wir wissen aber sehr wohl, dass wir verändern müssen, wenn wir verbessern wollen. (Joseph Schmidt, Management-Trainer) Denkarbeit braucht Zeit und Freiräume. Peitsche und Zügel sind daher keine Methoden, um Kopfarbeit in Schwung zu bringen. Stattdessen bieten


sich Formen an, bei denen die dauerhafte Bearbeitung von Aufgaben durch das Team stattfinden. Die Mitglieder bestimmen mehr oder weniger eigenständig über ihre Arbeitsplanung, -verteilung, -erledigung und -kontrolle. Meist sind nur das Was (Produkte/Produktteile), das Wieviel und/oder das Bis-wann von außen vorgegeben. Planende, steuernde und kontrollierende Tätigkeiten sind in die Gruppenaufgaben integriert. Dieses Konzept steht im diametralen Gegensatz zum tayloristisch-hierarchischen Ansatz, dessen Charakteristika die Verhaltenssteuerung durch Anweisung, autoritäte Führung, exakte Arbeitsteilung und -zuweisung, geringe Handlungs- und Entscheidungsspielräume, enge Kontrollen, das Vorherrschen technischer Rationalisierung und die Betonung des Menschen als Kostenfaktor sind. Somit spielt der Führungsstil eine ganz zentrale Rolle dabei, wie effizient ein Team arbeitet. Besonders in Hinblick auf die Tatsache, dass hier ein hohes Maß an persönlicher Veränderungsbereitschaft vorherrschen muss, um auf diese Weise Raum für die Entwicklung neuer Lösungswege zu geben. Es spielt dabei keine unwichtige Rolle, ob sich die Projektleiter durch ihr eigenes Handeln eine veränderungsresistente Gruppe an Mitarbeitern herangezogen haben oder ob ein Klima, das Veränderungen unterstützt, vorhanden ist. Praktisch gesprochen gibt es verschiedene Merkmale, an denen erkennbar ist, ob und wie stark die Führung eines Teams und somit das Team selber Raum für Änderungen ermöglicht. Dabei werden keine Imperatoren, sondern Inspiratoren gesucht, denen es gelingt, Kooperation zur Königsdisziplin auszubauen. Taylorismus ist daher nichts für Wissensarbeit (DeMarco 2001), unter die Fähigkeiten wie Erfindungsgabe, Abstraktionsvermögen, Artikulationsfähigkeit und geschicktes Management vieler Beziehungen gehören. Der Führungsstil hat einen erheblichen Einfluss auf die Qualität und Quantität der hier zu leistenden Arbeiten. Wie effizient oder ineffizient das Team im Sinne einer lernenden Organisation (Senge 1994) zum dynamischen Handeln angeleitet wird, steht in direktem Zusammenhang zum Führungsstil. Wo dabei die eigene Mannschaft steht, lässt sich an den nachfolgend aufgeführten Punkten ermitteln: Persönliche Ansichten. Wenn Sie in Ihrem Team eine Atmosphäre haben, bei der die Einzelnen vor allem an ihren persönlichen Ansichten festhalten bzw. diese verteidigen, offenkundige Tabuthemen vorhanden sind oder Ansichten als grundweg inakzeptabel gelten, so scheint das Team „angepasst“ zu sein. Bereitschaft für Veränderung ist nur begrenzt vorhanden. Um Offenheit für Veränderungen in diesem Bereich den Weg zu bahnen, ist es notwendig, Mitarbeiter so zu führen, dass freie Diskussionen, tabufreie Offenheit und ehrliche Meinungsunterschiede möglich werden, die jedoch immer wieder aktiv in eine Einheit zurückgeführt werden müssen.


Entscheidungen treffen. Ist der Leiter autokratisch, restriktiv oder begrenzend, so besteht eine große Wahrscheinlichkeit, dass die Geführten angepasst leben. Offenheit für Veränderungen braucht eine Atmosphäre der Ermutigung und der Teamorientiertheit. Nur durch die Umstellung des eigenen Führungsstils, also der Bereitschaft des Leiters, die eigenen Paradigmen kritisch zu hinterfragen und diese dann aktiv zu verändern, wird hier ein Veränderungsprozess möglich werden. Rollendynamik. Wie sind die einzelnen Mitarbeiter im Team? Sind sie Stereotype oder veränderungsresistent? Oder sind sie offen dafür, relativ flexibel andere Rollen zu übernehmen, offen zu sein für neue Umstände, aber auch offen genug, um ihre Empfindungen auszudrücken? Sowohl die Bereitschaft, andere Rollen zu übernehmen, wie auch die Bereitschaft, die eigenen Gefühle auszudrücken, sind zwei wichtige Indikatoren dafür, wie weit sich die einzelnen Mitarbeiter in persönlichen Fluchtburgen verschanzt haben. Im Sinne der zu Beginn des Buches beschriebenen Notwendigkeit der barrierearmen Kommunikation sind dicke persönliche Mauern klar kontraproduktiv. Potentialentwicklung. Der Ton macht die Musik und die eigene Wortwahl offenbart, wie indoktrinierend der aktuelle Führungsstil ist. Wenn der Leiter definiert, was „richtig“ oder „falsch“ ist, wenn Ausdrücke wie „man sollte“, „man müsste“ bzw. man „müsste nicht“ regelmäßiger Bestandteil seines Wortgebrauches sind, so ist klar, wer das Wissensmonopol hat: Den Mitarbeitern wird durch diesen Führungsstil vorgegeben, was sie zu denken oder zu glauben haben. Gibt es da noch irgendeinen Grund, kreativ tätig zu werden? Nur wenn hier der Leiter die eigene Position ändert und diesen autokratischen Stil aufgibt, werden die vorhandenen Potentiale freigelegt werden können. Indem die Mitarbeiter aktiv darin unterstützt werden, selbst Verantwortung zu übernehmen und infolgedessen auch Fehler machen, können Dinge anders werden. Nur wenn Führung an dieser Stelle bedeutet, denjenigen zu beraten, wie entstandene Fehler wieder korrigiert werden können, wird ein Klima der Veränderung entstehen. Meinungsfreiheit. Gerade Projektleiter sollten die teaminterne Leitfigur sein. Ist dabei der Führungsstil durch verordnete Disziplin und Bestrafung von Fehlern geprägt oder wird das Team als persönlicher Besitz betrachtet, bei dem korrektes Verhalten durch persönliche Zuwendung belohnt wird, so wird hier eine Gruppe von Ja-Sagern gezüchtet. Die Entwicklung eines auf gegenseitigem Respekt aufbauenden Beziehungsnetzwerkes, bei dem Grenzen respektiert und somit andere Ansichten akzeptiert werden, wird kaum stattfinden. Die Folge ist, dass auf diese Weise eine sternförmige Beziehungssymmetrie auf den Leiter hin entsteht, statt zu einer möglichst


gleichmäßigen Vernetzung zu gelangen. Hierdurch bedingt werden Teammitglieder immer wieder Dinge tun, ohne das ganze Team zu informieren, da die Blickrichtung vor allem auf den Leiter gerichtet ist. Zusammenfassend lässt sich feststellen: Ist der Führungsstil des Leiters eher kasernenhofmäßig, also geprägt durch autoritäres Auftreten, Insensibilität und Beziehungsdistanz, so werden sich die Mitarbeiter in persönliche Nischen zurückziehen und in hohem Maße angepasst handeln. Dies wird unterstützt, wenn Angespanntheit, negatives Reden, Schuldzuweisung oder starke Fraktionsbildung in der Organisation vorherrschen. Menschen werden sich dieser anpassen, wenn strenge Regeln vorgegeben sind und deren Einhaltung auch kontrolliert wird, wenn Fehler zu Bestrafungen führen und der Schein wichtiger ist als das Sein. – Ein Klima der Veränderung verlangt hingegen einen Umgang, bei dem Lösungen im Mittelpunkt sind und bei der die Persönlichkeit des Einzelnen an erster Stelle steht. Um Veränderungsprozesse zu bewirken, sind Entspanntheit, Sicherheit, Vertrautheit, Spontanität und Fürsorge Grundvoraussetzungen. Ist der Führungsstil in diesem Sinne unterstützend und von Respekt geprägt, so werden die Mitarbeiter wachsen können, werden für Veränderungen offen sein und neue Aufgaben als persönliche Herausforderungen annehmen. 6.2.2 Gallionsfigur werden Ein gescheiter Mann muss so gescheit sein, Leute einzustellen, die viel gescheiter sind als er. (John F. Kennedy) Betrachtet man die Projektwelt, auch außerhalb der IT, so lässt sich feststellen, dass es sehr erfolgreiche Produkte gibt, die das Geheimnis um die richtige Führung zu ihren Gunsten gelüftet haben (Bennis und Biederman 1998): Warum waren wohl Walt Disneys Leute (trotz schlechter Bezahlung), die Mitarbeiter des Manhattan-Projektes (trotz aller moralischen Bedenken) oder die Entwickler des frühen Eclipse-Computers (trotz schleppender Markteinführung) so erfolgreich? – Letztendlich verdanken diese Teams ihren Erfolg in erster Linie exzellenten Führungspersönlichkeiten, die es verstanden, die Mitarbeiter zu motivieren und diese mit Klarheit aber auch Weitsicht in jeweils ganz spezieller Weise zusammenzufügen. Ehe ich auf einige Grundfertigkeiten solcher Führungspersönlichkeiten eingehe, werde ich den Begriff des Führens gegen einige ähnlich lautende Mythen nach J. Maxwell (Maxwell 2002) abgrenzen. Diese Vorstellungen mögen anderswo ihre Berechtigung haben, wo sie jedoch völlig deplatziert sind, das ist in Software produzierenden Teams:


Management-Mythos. Vielfach ist man der Ansicht, dass Führen und Managen ein und dasselbe seien. Dies ist nicht der Fall, da Management mit Instandhaltung und Systemen zu tun hat, also Organisationsstrukturen betrifft. Führen hingegen bedeutet, dass man andere aktiv beeinflusst und sie dazu bewegt, Teilhaber an der eigenen Vision zu werden. Unternehmer-Mythos. Durchaus sehr erfolgreiche Personen mit Ideen und Charisma sind nicht notwendigerweise im hier verstandenen Sinne Führungspersönlichkeiten, solange ihr Hauptaugenmerk auf „Business Opportunities“, also Gelegenheiten zum geschäftlichen Loslegen, ausgerichtet ist. Wissens-Mythos. Auch hohes Wissen und Intelligenz machen noch keine Führungspersönlichkeit aus. Selbst wenn Menschen dazu neigen, Führerschaft mit Macht in Verbindung zu bringen, so ist diese Kombination ein Trugschluss. Wissen mag Macht sein, aber es ist kein Maßstab für Führerschaft. Pionier-Mythos. Pioniere mögen bemerkenswerte Charaktereigenschaften besitzen und eine hohe Leidensbereitschaft mitbringen, um ihre jeweilige Pioniertat erreichen zu können. Dieser Pioniergeist reicht jedoch als Führungsqualität nicht aus, solange es keine Menschen gibt, die sich aktiv diese Vision zu Eigen machen und dieser Führung bewusst folgen. Positions-Mythos. Auch die Tatsache, eine Leitungsfunktion innezuhaben, macht noch keine Führungspersönlichkeit aus. Nicht der Titel, die erworbenen Qualifikationen oder die verliehene Position machen jemanden zum Führer, sondern die Art und Weise, wie er diese Verantwortung lebt. Jeder, der führt, geht von einem bestimmten Menschenbild aus. Dieses prägt dabei das eigene Bild derjenigen Personen, die man führt, und offenbart zugleich die eigene Weltsicht. In diesem Sinne muss gute Führung ein Paradoxon auflösen: Der gesellschaftliche Trend hat sich sehr stark in Richtung Individualismus und Egoismus entwickelt und wird von vielen Mitarbeitern entsprechend ausgelebt. Der notwendige Trend, um mittels effizient zusammenarbeitender Teams erfolgreich das Komplexitätsproblem im Softwarebau zu lösen, ist jedoch genau gegenläufig. Hier müssen in nicht unerheblichem Maße die Hürden des Individualismus überwunden werden, um so Kommunikationshindernisse und Team-Inhomogenitäten beiseite zu schaffen. Neue psychologische Arbeiten zeigen jedoch noch einmal einen klaren Trend in den Bereich jenseits des Individualismus (Wheeler 2006) und kündigen damit eine langsame Kehrtwendung in diesem Punkt an. Im Vorgriff auf die später hierzu vorgetragenen Aspekte halte ich daher die nachfolgenden Grundanforderungen an einen Leiter für


absolut notwendig. Sie sind anspruchsvoll, aber liefern die notwendigen Voraussetzungen, um die geforderten Lösungen schrittweise zu erreichen. Visionär. Diejenigen Menschen, die für ein spezielles Projekt arbeiten, brauchen Leitbilder und eine Vision, auf die sie zuarbeiten. „Vision“ bezieht sich hierbei keineswegs nur auf ein gleichnamiges Dokument, in welchem die übergeordneten Ziele für alle nachlesbar hinterlegt sind. Es geht vielmehr darum, dass der Leiter gerade eines Softwareprojektes zum Visionär des kommenden Produktes werden muss. Gerade in den frühen Phasen eines solchen Projektes, in dem noch nicht die technische Planung oder quasihandwerkliche Fähigkeiten im Mittelpunkt stehen, ist es notwendig, dass sich eine, wenn auch nur schemenhafte Vision möglicher Endresultate manifestiert. Um sie herum können Mitarbeiter beginnen, sich mit der neuen Aufgabe zu identifizieren und dadurch die notwendigen Teamprozesse anzustoßen. Die Aufgabe des Leiters besteht darin, diese Vision zu prägen, im Idealfall selbst zur personfizierten Vision zu werden und auf diese Weise einen sehr wichtigen kommunikatorischen Beitrag in der Gesamtorganisation zu leisten. Besonders bei größeren Projekten mit einer Laufzeit über mehrere Jahre hinweg hat dieser Aspekt eine sehr prominente Bedeutung. Coach. Projektleiter sein, bedeutet gerade in größeren Projekten, Coach für das eigene Team zu sein. Da es zu den Aufgaben des Projektmanagers gehört, die Strukturen und Vorgehensweisen des jeweiligen Projektes zu definieren und zu etablieren, hängt es an ihm, dies auch so zu kommunizieren, dass andere es umsetzen können. Ist es möglich, auf diese Weise die Erfahrungen des Verantwortlichen auf die Mitarbeiter zu replizieren, so ist dies eine wichtige Ergänzung. Gerade im Sinne der Ganzheitlichkeit kommt dieser Rollensicht eine wichtige Aufgabe zu, da hierdurch einseitiges Denken als Folge von Spezialistentum mit einer übergreifenden Sichtweise, nämlich der des gesamten Projektes, verbunden werden kann. Durch aktives Anleiten der einzelnen Mitarbeiter ist es überdies sehr viel einfacherer, das notwendige persönliche Vertrauen aufzubauen und die Beteiligten so zu prägen, dass sie im Sinne der Gesamtvision eigenverantwortlich arbeiten. Hirte. Die qualifizierte Realisierung des Projektes hängt von der Entwicklungsmannschaft ab. Sie ist das wichtigste Kapital, das einem Projektmanager zur Verfügung steht, da hier die eigentlichen Leistungsträger und Umsetzer des Projektes sind. Nur wenn diese Truppe in einem guten Zustand gehalten wird, kann sie diese Ziele erreichen. In diesem Sinne bietet sich das Analogon von Hirte und Herde an. Hier ist es der Leiter, der die Mitarbeiter zielorientiert führt, für die interne Stabilität


der Gruppe sorgt, diese nach außen hin schützt und als Korrektiv wirkt (Leman und Pentak 2004)24. Netzwerker. Netzwerker sind im Stande, aus linearen Fäden Netze zu knüpfen, also ungewöhnliche Verbindungen herzustellen und diese zu einem komplexen Ganzen zu verbinden. So, wie Spinnen von einem Ausgangspunkt Fäden in alle Richtungen werfen und diese dann miteinander verknüpfen, betrachtet ein Netzwerker immer wieder das Ganze. Aus einer 360-Grad-Sicht wird immer wieder das Projekt, das Produkt, dessen Implikationen und der Kontext gedanklich bewertet. Dabei werden immer wieder neue Lösungen, die noch innovativer, ergonomischer und rationeller sind, gefunden. Ebenso kommen aber auch Risiken, negative Meinungsmache oder Abhängigkeiten zu Tage und können angegangen werden. Der Philosoph Peter Sloterdijk spricht davon, dass die Gesellschaft der Zukunft auf Vertrauen gegründet sein muss. Egal ob Sloterdijk in Bezug auf zukünftige Generationen Recht hat oder nicht. Für die aktuelle Generation von Entwicklungsteams gilt diese Aussage bereits heute! Neuere Untersuchungen belegen: Vertrauen rechnet sich! Haben Mitarbeiter und Führung wechselseitiges Vertrauen aufgebaut, so belegen diese Statistiken, dass hierdurch eine stabile Führungssituation entsteht, die zugleich auch schnellere Entscheidungen möglich macht. Der größte Feind des Vertrauens ist allerdings die Unehrlichkeit (Weiss 2000). Hierbei wird oftmals Ehrlichkeit und Direktheit miteinander verwechselt. Es geht an dieser Stelle nicht so sehr darum, Menschen auf den Kopf zuzusagen, was man von ihnen denkt, sondern es geht darum, wie Verantwortliche mit der Wahrheit an sich umgehen. Partizipieren Vorgesetzte an den kleinen und großen Versprechungen bzw. Lügen z. B. gegenüber Kunden und wird dies von Mitarbeitern wahrgenommen, so wird automatisch unterstellt, dass dies auch die Umgangsform mit den Teamangehörigen ist. Ebenso wird der eigene Verhaltenskodex ziemlich schnell zum Maßstab im Team werden (Rush 1992), weshalb es kontraproduktiv ist, hier Kompromisse einzugehen. Keiner arbeitet im Unternehmen allein, zwischenmenschliche Beziehungen bestimmen (fast) alles. Wenn man bei Unternehmenspleiten genauer hinsieht, so kann oftmals festgestellt werden, dass hinter der wirtschaftlichen Fehlleistung auch eklatante Fehlleistungen im zwischenmenschlichen 24

Leman verwendet die Analogie eines Schafhirten und arbeitet dabei die folgenden Schwerpunkte heraus: 1) Herstellung einer dynamischen Atmosphäre, 2) genaue Kenntnis über den Zustand der Mitarbeiter, 3) Stärken, Schwächen und aktuellen Zustand der Teammitglieder kennen, 4) dafür sorgen, dass sich die Mitarbeiter mit der eigenen Rolle und Vision identifizieren, 5) für die Sicherheit des Teams sorgen, 6) gezielte Führung und Korrektiv durch den Leiter, 7) Führen als Lebensstil und nicht als Technik.


Bereich zu verzeichnen waren: Erst wurde das Betriebsklima schlecht, dann die Zahlen und schließlich die Zukunftsaussichten. Umgekehrt kann eine gut harmonierende Belegschaft buchstäblich Berge versetzen. Ähnliches gilt auch für einzelne Teams. Das Einfühlungsvermögen ist daher die wichtigste Sozialkompetenz. Dabei ist Einfühlungsvermögen die Fähigkeit, sich in andere Menschen hineinzuversetzen und ihr Wollen, Denken und Fühlen zu verstehen. Wer nicht nachvollziehen kann, wie andere Menschen empfinden, der kann sie auch nicht führen oder motivieren. 6.2.3 Kutscher sein Das Management ist die schöpferischste aller Künste. Es ist die Kunst, Talente richtig einzusetzen. (Robert McNamara, 19611968 Präsident der Weltbank) Der Erfolg eines Leiters wird gemessen am Erfolg seiner Mitarbeiter. Wie für Spitzensportler so gilt auch für Entwicklungsteams, dass durch gezieltes Coaching die jeweiligen Fähigkeiten optimal entwickelt und eingesetzen werden können. Neben den bereits bekannten Faktoren ist es eine der wichtigsten Aufgaben eines reifen Projektmanagements, nicht nur Ziele zu erreichen, sondern mit der wertvollsten Ressource, dem Menschen, nachhaltig umzugehen. Im hier verstandenen Sinne bedeutet somit Führung eines Projektes zugleich auch Coach für das eigene Team zu sein und somit zum Berater, Konfliktmanager bzw. Mediator zu avancieren. Dies setzt menschliche Reife und Seniorität voraus, verlangt aber keine Allwissenheit, da ein Coach nicht zwangsläufig der beste Spieler sein muss, wohl aber sein Handwerkszeug zu beherrschen hat. Wer diese Rolle wahrnimmt, muss sich im ganzheitlichen Sinne die Frage gestellt haben, ob ihm der Umgang mit Menschen oder derjenige mit Methoden wichtiger ist. Ist Ersteres nicht der Fall, so mag der Einzelne immer noch gutes Projektmanagement im klassischen Sinne beweisen. Da Coaching begleitend und unterstützend wirkt, geht es darum, dem Einzelnen neue Wege und erweiternde Perspektiven in Bezug auf einen Lösungsraum aufzuweisen, um auf diese Weise einen bewussten Veränderungsprozess anzustoßen oder zu unterstützen. Der Zugang zur anderen Person ist dabei Grundvoraussetzung und steht somit im direkten Bezug zum bereits diskutierten Führungsstil (vgl. Kap. 6.2.1, S. 170 ff.). Da es hierbei nicht um eine einmalige Empfehlung geht, sondern um einen begleiteten Entwicklungsprozess, in welchem vereinbarte Aspekte betrachtet und bewertet werden, ist gerade der Beziehungsaspekt zwischen den beteiligten Personen von großer Bedeutung. Ähnlich zu den methodischen Ansätzen der Psychotherapie, die darin bestehen, erst das Vertrauen


zu einem Klienten aufzubauen und danach mit der Intervention zu beginnen, ist es auch hier. Auf diese Weise ist es möglich, auch tabuisierte Themen innerhalb der eigenen Entwicklungsmannschaft aus dem Wege zu räumen. Zwar kennt klassisches Linienmanagement die Rolle des Feedbackgebers z. B. durch Mitarbeitergespräche, aber hierdurch wird meistens keine echte Weiterentwicklung des Gegenübers angestoßen, sondern bestenfalls eine Konformitätsanpassung erreicht. – Es geht hierbei nicht um die Etablierung konformen Verhaltens. Stattdessen besteht das Ziel darin, unnötige Komplexitätszuwächse in der Weise zu verhindern, dass Barrieren zwischen den Mitarbeitern in definierten Bereichen gezielt abgesenkt werden und damit sowohl die individuelle Performance wie auch die Teamperformance optimiert werden. Die individuelle Freilegung vorhandener Fähigkeiten, die gezielte Unterstützung in Veränderungsprozessen sowie individuelle Angebote zur persönlichen Entfaltung können am besten durch solche Personen erbracht werden, die eine Vertrauens- und Führungsrolle im eigenen Kontext bereits genießen. Um eine solche Rolle leben zu können, ist nicht ein Diplom über Coaching notwendig, sondern die eigene Erfahrung im Umgang mit Menschen, die eigene Bereitschaft, sich selbst immer wieder in der Rolle des Coaches zu befinden, sowie die eigene Bereitschaft, sich selbst verändern zu lassen. Letztendlich ist es nicht in erster Linie der angewandte Methodenkoffer, sondern die eigene, hiermit verbundene Erfahrung, die den Coach authentisch werden lässt. Empfehlungen an andere werden dadurch authentisch und für den Gegenüber lebbar, wenn für diesen ersichtlich ist, dass der Coach den Rat, den er gibt, selbst lebt. Somit geht es hier um Nähe und nicht um die Rolle eines verkappten Psychoanalytikers, der distanziert und emotionslos den anderen durch Hinterfragen auf eigene Lösungswege bringen möchte. Coach sein heißt aber auch, im Kontext auftretende Konflikte wahrzunehmen und gegebenenfalls zu intervenieren. Ist das notwendige Vertrauensverhältnis gegeben, so werden sich Konflikte sehr viel nachhaltiger ausräumen lassen. Indem Coaching zum aktiven Bestandteil der Teamarbeit wird, gelingen zwei Dinge: Zum einen findet eine Form von Performance Management (Baguley 1999) statt, welches ohnehin schon eigenen Paradigmen folgt und vor allem darin besteht durch gezielte Mitarbeitermotivation, durch Weiterentwicklung und individuelle Unterstützung des Einzelnen dessen Aufgabenbereich so zu optimieren, dass Arbeit zwar anstrengend ist, jedoch Spaß macht. Zum anderen wird für die Mitarbeiter das Gefühl der Fremdbestimmung gesenkt oder sogar ganz abgebaut. Dies ist wichtig, da derjenige, der kontrollieren will, keine Mitarbeiter bekommt, mit denen effektiv Ziele erreicht werden können. Studien belegen, dass stark kontrollierte Mitarbeiter ihren Job machen – aber auch nicht mehr. Anders sieht dies jedoch mit

6.3 Artgerechte Haltung von Teams 179

Mitarbeitern aus, die um der Sache willen dabei sind. Hier ist ein viel höheres Maß an Einsatz und dementsprechend auch ein besseres Resultat sichtbar. Darüber hinaus gibt es einen direkten Sachzusammenhang zwischen Burnout und dem Maß an erlebter Fremdbestimmung. Aus der Schulmedizin ist dabei bekannt, dass die höchste Quote an Herzinfarkten bei solchen Gruppen zu finden ist, die Autonomieverluste und unzureichende Kontrolle über ihre eigene Lebenssituation erleben. Menschen hingegen, die das Empfinden haben, ihr Leben selbst in der Hand zu haben – so die Statistiken –, sind erheblich weniger krank! Somit ist das Gefühl, die eigenen Umstände – gerade auch im IT-Bereich – zu bestimmen, ein ganz erheblicher Faktor bezüglich der Effizienz und der geforderten Resultate. Es ist klar, dass diese Rolle nicht auf beliebig große Teams angewandt werden kann. Es zeigt sich, dass diese Vorgehensweise nur wirklich sinnvoll ist bei Gruppenstärken bis etwas mehr als 10 Personen. Dies ist übrigens eine Grenze, die auch für Teambildungs-Prozesse nicht unerheblich ist. Hiervon wird im nächsten Kapitel u. a. die Rede sein.

6.3 Artgerechte Haltung von Teams Den Wert eines Unternehmens machen nicht Gebäude und Maschinen und auch nicht seine Bankkonten aus. Wertvoll an einem Unternehmen sind nur die Menschen, die dafür arbeiten, und der Geist, in dem sie es tun. (Heinrich Nordhoff, ehem. Vorstandsvorsitzender von VW) Neuere Forschungen belegen, dass das Denken ein sozialer Prozess ist, der zum einen durch die Wechselwirkung zwischen Geist, Körper und Seele (Clark 1998; Gigerenzer 2000) stattfindet, zum anderen aber aus Gruppenbeziehungen gespeist wird. In der aktuellen IT-Literatur, wie z. B. den Büchern des IBM-Vordenkers Dueck (Dueck 2001; Dueck 2005) oder solchen von Rainwater (Rainwater 2003), findet dies entsprechenden Ausdruck. – Im Kontext der Kognitionswissenschaften, also im Umfeld von Psychologie, Philosophie, Neurophysiologie, Linguistik und Information – hier vor allem in der KI-Forschung –, bemüht man sich um Erkenntnisse der Denkprozesse. Diese sind es, die in mehrfacher Weise beim Bau von Software Eingang finden: Durch Auswertung komplexer Zusammenhänge in einem definierten Bereich unserer Wirklichkeit werden mit Hilfe kollektiver Denkprozesse komplexe Ablaufsteuerungen entwickelt (= Software), um so den Ursprungszusammenhängen ähnliche operative Abläufe (= z. B. Usecases) zu emulieren. Somit besteht das eigentliche Geheimnis effizienten Softwarebaus darin, dass erst Teamprozesse ein Sichtenmodell auf die in Software zu transformierende Wirklichkeit möglich machen. Nicht länger steht daher die primäre Frage im Mittelpunkt, ob Einzelindividuen die


richtigen Implementierungstechniken beherrschen. Stattdessen kommen mit zunehmender Größe und Komplexität des Projektes immer mehr solcher Aspekte in den Fokus, die mit dem Zusammenspiel der beteiligten Personen zu tun haben. In gewisser Weise müssen die beteiligten Personen als Gemeinschaft emergente Fähigkeiten entwickeln, Befähigungen also, die sie als Einzelindividuen nicht besitzen und die auch nicht dadurch sichtbar werden, dass man nebeneinanderher arbeitet. So betrachtet müssen die beteiligten Pesonen befähigt werden, als Teil eines kollektiven „Superhirns“ zusammenzuarbeiten. Gerade solche Prozessmodelle, die iteratives Vorgehen, Parallelisierung und Agilität postulieren, instrumentalisieren dies in rudimentärer Form. Ein Beispiel aus der Biologie verdeutlicht, worum es geht. Beobachtet man einen Termitenstaat, so lässt sich u. a. feststellen: x Es existiert ein Heer von spezialisierten Einzelindividuen, von denen jedes einen speziellen Platz hat. x Keines dieser Tiere hat den Bauplan dieser riesigen Termitenhügel mit ihren Hauptstraßen, komplizierten Belüftungssystemen, Verteidigungsstrategien oder Versorgungsmodellen als Blaupause bei Gründung eines solchen Termitenstaates mitgebracht. x Ein solcher Staat entsteht erst, wenn diese Tiere zusammenkommen und wie ein großer Organismus harmonisch zusammen operieren. x Es herrscht zwischen den Tieren keine Wettbewerbssituation, sondern Kollaboration. x Jedes Tier findet seine spezifischen Aufgaben und Rollen. x Durch die hohe Arbeitsteilung und gleichzeitig durch das barrierefreie kollektive Zusammenspiel entstehen solche gewaltigen Strukturen. Vergleichbare Prozesse müssen in die Teams der Softwareproduktion eingeführt werden. Dabei geht es nicht notwendigerweise um Edelkommunismus, Basisdemokratie oder akribische Prozessabarbeitung. Worum es in erster Linie geht, ist das barrierearme Zusammenspiel der beteiligten Einzelindividuen. Hierbei beziehe ich Barrierefreiheit auf die Interaktion zwischen den Beteiligten: Man hat gelernt zu kollaborieren, versteht die Sprache des anderen und arbeitet einander zu. Je besser dies gelingt, umso stärker werden emergente Effekte auftreten. – Oder andersherum formuliert: Eine Gruppe von Mitarbeitern, die ohne ein echtes Zusammenwachsen als Team versucht, kollektive Kooperation im beschriebenen Sinne zu praktizieren, wird dieses nicht sonderlich gut zustandebringen. Die Erkenntnis setzt sich immer mehr in der Branche durch, dass diesen Teameffekten eine eminent wichtige Rolle zukommt. Hierfür gibt es eine ganze Reihe Indikatoren innerhalb der Software Community: Collaborationrooms kommen in Mode, Teamsoftware wird zum Renner, teamorientierte Entwicklungsprozesse wie z. B. die agilen Vorgehensweisen haben Hochkonjunktur.


6.3.1 Humane Konglomerate Der Weg zur Vollkommenheit und zu jedem Fortschritt ist fortwährende Selbstkritik. (Kurt Schwitters, dt. Maler und Schriftsteller) Ob Menschen in Teams effektiv zusammenarbeiten oder nicht, entscheidet über den Erfolg und Misserfolg einer Organisation. Ausführliche Analysen erfolgreicher Organisationen belegen, dass Teamarbeit und Mitarbeitermotivation die Schlüsselfaktoren im täglichen Umgang miteinander darstellen. Das Zusammenfügen des jeweiligen Expertenwissens ist es, was die Lösung hervorbringt, dabei sind es nicht selten gerade ungünstige Teammechanismen, die genau dieses blockieren und verhindern. Damit wird deutlich: Um den gordischen Knoten von Komplexität und Dynamik im Softwarebau zu durchschlagen, kommen den Interaktionen zwischen den beteiligten Personen eine zentrale Rolle zu. Vor diesem Hintergrund ist zu klären, wie der optimale Umgang mit dem „Produktionsfaktor Mensch“ auszusehen hat und welche Ziele zu erreichen sind, damit dieser nicht verwildert und systembedingte Leistungseinbußen stattfinden. Hochleistungsarbeiter brauchen gewissermaßen eine „artgerechte Haltung“, damit sie dauerhaft die notwendige Performance erbringen oder sogar noch steigern können. Es gilt also zu klären, wie die Quadratur des Kreises gelingt und ein Konglomerat, bestehend aus Spezialisten, schrittweise, dafür aber dauerhaft zu einem eng aufeinander abgestimmten Team überführt werden kann. Aus der Fülle der hier existierenden Untersuchungen, Studien und Realisierungen möchte ich einige zentrale Aspekte aufgreifen (Katzenbach und Smith 2003): Ein Teil der Teamprozesse besteht darin, dass die Mitglieder beginnen, die gegenseitige Andersartigkeit in diesen Bereichen als eigene Ergänzung und Bereicherung wahrzunehmen, und dadurch zum einen die Stärken des anderen nutzen, dessen Schwächen jedoch durch eigenes Engagement abpuffern können. Hierbei sind es verschiedene Bereiche, in denen diese Ergänzungen notwendig sind: x Persönlichkeitstypen (z. B. Detailsichten / Gesamtsichten) x Arbeitsweise (z. B. sequentielles / paralleles Bearbeiten von Aufgaben) x Kollaborationsweise (z. B. gutes Arbeiten in Klausur / in der Gruppe) Auch ist in Grenzen ein gewisses Kräftemessen notwendig, wenn hierdurch die leistungsschwächeren Personen motiviert werden. Kommt es allerdings zu Formen des Wettbewerbs, bei dem der Beste öffentlich herausgehoben wird (wie z. B. in Bereichen des Multilevel Marketings üblich) oder werden Einzelne in besonderer Weise honoriert (z. B. durch Prämien), so kann dies sehr schnell auch gegenteilige Wirkung zeigen. Leicht können Missgunst oder Misstrauen entstehen, die ihrerseits Teamprozesse erheblich untergraben können! Dabei ist das gemeinschaftliche Arbeiten


nicht als erweiterte Lebensgemeinschaft oder kommunitäres Zusammenleben zu verstehen. Dennoch wirken hier ähnliche zwischenmenschliche Beziehungsmechanismen wie dort. Bedenkt man, wie viele Stunden Mitarbeiter intensivst während eines – z. B. einjährigen Projektes – zusammenarbeiten müssen. (Bei 200 angenommenen Arbeitstagen à 7,5 Arbeitsstunden sind dies 1500 Stunden!) Und fragt man sich, wie viele Jahre es wohl braucht, um dasselbe Maß an „Prime Time“ mit dem Ehe- oder Lebenspartner aktiv zu verbringen, so wird klar, worum es geht: Wie viele gute und kreative Phasen, aber auch kleine und große zwischenmenschliche Krisen werden in diesem Zeitraum durchlaufen? Man muss sich der Tatsache stellen, dass Teamzusammenarbeit kein beziehungsneutraler Raum ist. Die Arbeits- und Teamwelt ist keineswegs ein neutraler Raum ohne zwischenmenschliche Aspekte – sozusagen ein psychologischer „Cleanroom“, in dem ausschließlich Professionals hochsystematisch festgelegte Prozesse abarbeiten. – Weit gefehlt! – Auf einer der letzten XP-User-Konferenzen wurde die Frage nach dem am meisten gewünschten Teammitglied spontan von einem Teilnehmer wie folgt beantwortet: „Wir bräuchten einen Familientherapeuten.“ Damit Teams sich so entwickeln können, dass sie die erwartete Gemeinschaftsleistung erbringen können, bedarf es also eines entsprechenden Kontextes. 6.3.2 Grundlagen der Kollaboration Eine gute Vision erwächst aus der Balance zwischen Realitätssinn und Utopie. Visionen sind das gerade noch Machbare. (Hermann Simon, Harvard-Business School) Kernstück der Definition von Teams ist die Prämisse, dass diese und ihre jeweilige Leistung untrennbar miteinander verknüpft sind. Vorausgesetzt, das Team ist für ganz spezifische Resultate kollektiv verantwortlich und die Organisation verlangt diese Resultate auch tatsächlich ab, so sind wirklich engagierte Teams die produktivste Leistungseinheit, die dem Management zur Verfügung steht (Katzenbach und Smith 2003). Meridith Belbin hat in den 70er Jahren eine Methode zur optimalen Teamsteuerung entwickelt, die eine Basis für gewünschte Vorhersehbarkeit von Teamverhalten und Ergebnissen anbietet. Dabei kam Belbin zu folgenden Erkenntnissen: x Das Verhalten der Teammitglieder lässt sich acht verschiedenen Rollen zuordnen. x Das Verhalten ist einigermaßen konsequent. x Das Rollenverhalten im Team ist aufgrund von Testergebnissen vorhersehbar.


x Die Kombination von Teamrollen macht Teams schlagkräftiger. x Eine individuelle Teamrolle entspricht nicht notwendigerweise seiner funktionalen/organisatorischen Zuordnung. Tabelle 6.1. Aufteilung der Teamrollen nach Belbin tätigkeitsorientierte Rollen (action oriented) = erledigen

soziale Rollen (people oriented) = Kommunikation

intellektuelle Rollen (cerebral) = denken

Umsetzer

Koordinator/ Integrator

Neuerer/Erfinder

Macher

Wegbereiter/ Weichensteller

Beobachter

Perfektionist

Teamarbeiter/ Mitspieler

Spezialist

Die acht von Belbin identifizierten Teamrollen (vgl. Tab. 6.1) ergeben sich aus den Verhaltensmustern der Teammitglieder, die durch ihre Persönlichkeit und Charakterzüge bestimmt werden. Wird dafür Sorge getragen, dass Teams ausgewogen mit den verschiedenen Teamrollen besetzt sind, so bewirkt diese Kombination verschiedener Fähigkeiten eine optimale Ergänzung der einzelnen Teammitglieder. Jeder weiß, in welcher Situation er besonders zur Teamleistung beitragen und wann er auf die Stärken der anderen aufbauen kann. Dabei bilden die systemischen Beziehungen zwischen Personen, Funktionen und Situationen das dynamische Umfeld, aus dem heraus ein Team sich entwickeln muss. Belbin (Belbin 1996) beschreibt dabei die im Folgenden aufgeführten vier Phasen. Diese müssen keineswegs von außen angestoßen werden, sondern leiten sich aus der inhärenten Dynamik der Kooperation ab. Hilfreich ist jedoch, diesen Prozess von außen moderierend zu begleiten, da stark emotionale Faktoren hierbei auftreten können. Orientierungsphase. Diese initiale Phase ist gleichzusetzen mit der Entstehungsphase des Teams. Hier müssen die Mitglieder aufgrund bestimmter Erwartungen ihre eigene Rolle finden. In diesem Entwicklungsstadium findet das erste Kennenlernen der Teilnehmer statt. Noch bestehen keine Vertrauensverhältnisse, man übt sich in Zurückhaltung. Primäre Bezugspunkte sind die zu behandelnden Aufgabenstellungen und der Teamleiter. Konfrontationsphase. Gerade die zweite Phase ist von besonderer Bedeutung, da sich hier entscheidet, ob das Team weiter besteht oder aufgrund


unüberwindbarer Konflikte zerfällt. Es kommt zu Machtkämpfen, Meinungen und Gefühle werden offen ausgesprochen. Können diese Konflikte gelöst werden, so kommt es am Ende dieser Phase zur Definition der Aufgabenrollen; ein Grundkonsens hat sich gebildet. Die anderen Gruppenteilnehmer werden genau beobachtet, Vergleiche angestellt und Prozesse aufeinander zu beginnen. Kooperationsphase. Es entsteht ein Wir-Gefühl, Ideen und Gedanken werden offen ausgetauscht, dabei stellt sich ein freundschaftliches Klima des Vertrauens ein. Die Kooperation findet im ganzen Team statt, auch hat das Team eine solide Arbeitsplattform gefunden und baut diese weiter aus. Mehr und mehr wächst man zusammen, was den Kontakt zur Außenwelt verringert. Wachstumsphase. In dieser letzten Phase fließt die gesamte Teamenergie in die Aufgabenbewältigung. Aufgrund hoher Gruppenkohäsion sind nun auch Spitzenleistungen möglich. Teambuilding ist harte Arbeit und setzt voraus, dass im Sinne der vier Belbin’schen Phasen es tatsächlich zur Gruppenbildung kommt und somit die einzelnen Teamrollen besetzt werden können. In dem Maß, wie die gegenseitigen Vorbehalte überwunden wurden, wird sich im Laufe der Zeit das gegenseitige Geben und Nehmen einspielen. Gerade das Entdecken und anschließende Wertschätzen der sich einander ergänzenden Fähigkeiten spielt auf diesem Weg eine ganz zentrale Rolle. Im Rahmen dieser Rollenklärungen findet ein Sondieren der Fähigkeiten des jeweils anderen statt. Sehr unterschiedliche Themen werden dabei – oftmals unbewusst – adressiert. Hier einige Beispiele: x Wo bist Du Experte, wo bin ich es und wie können wir unser Spezialwissen für beide nutzbringend einsetzen? x Bist Du ein Perfektionist und ergänzt meinen visionären Stil oder sind wir beide detailverliebt und müssen lernen, uns hierin nicht zu verlieren. x Wie ist Deine Form mit mir umzugehen? x Wo sind Deine blinden Flecken, wo ich Dich ergänzen kann? x Wo sind Deine wunden Punkte, die ich umgehen sollte? Ohne eine gemeinsame Vision, gepaart mit effektiver Kommunikation und dem konstruktiven Umgang mit Kritik, ist dieses Ausloten nur sehr langsam möglich. Hier wiederum hat der Teamleiter im Sinne eines Coaches eine wichtige Aufgabe zu leisten. Die meisten echten Teams zeichnen sich durch Gruppen mit bis ca. 10 Personen aus. Dies ist übrigens eine Anzahl an Personen, die der Anzahl nach mit therapeutischen Gruppen verglichen werden kann. Bis zu dieser Größe, so ist die Erfahrung aus der


Kleingruppenarbeit, öffnen sich die einzelnen Mitglieder in hohem Maße voreinander und gehen „echt“ miteinander um. Wird diese Größe überschritten, so bedarf es bis ca. 15 Personen einer äußerst geschickten Leitung, um die notwendigen Prozesse der gegenseitigen Öffnung am Leben zu erhalten. In diesem Kontext ist ein weiterer Aspekt wichtig, der gerade auch bei Teambildungs-Prozessen von Bedeutung ist. Teams oder Gruppen brauchen Außengrenzen. Das heißt, dass Teams sich in bestimmten Aspekten gegenüber Nicht-Teammitgliedern abgrenzen müssen und werden. Dies kann in Form eines gemeinsamen Dress-Codes geschehen oder auch durch demonstrative sprachliche Ein- bzw. Ausgrenzung. Da es immer wieder vorkommt, dass Mitarbeiter in Softwareprojekten nach rein fachlichen Kriterien ausgewählt werden, ist es sinnvoll, die Konsequenzen unausgewogener Teams im Sinne der Teamrollen an mehreren Beispielen exemplarisch zu betrachten: Umsetzer-lastige Teams. Nach Belbin sind „Umsetzer“ konservativ, pflichtbewusst und praktisch veranlagt. Sie bilden die Seele des Projektes. Ihr Konservatismus verlangt auf der einen Seite einen eigenen festen Bezugsrahmen, z. B. indem eingefahrene Konditionen und Ansichten als gegeben angesehen werden. Gleichermaßen werden sie solche Bezugsrahmen in ihrem Umfeld weiter ausbauen. In der eigenen Organisation gelten sie als pragmatische Organisatoren und effiziente Arbeiter. Sie setzen mit hoher Selbstdisziplin Ideen um und sind dabei gut organisiert, jedoch kein Freund von Veränderungen. Befinden sich in einem Team dieser Persönlichkeiten in Überzahl, so werden die Ergebnisse durchschnittlich ausfallen, da wirklich innovative Ideen aufgrund der vorliegenden Unflexibilität ausscheiden. Innovatoren-lastige Teams. Kreative/Innovatoren bzw. Neuerer/Erfinder sind nach Belbin Menschen, die neue voranbringende Ideen, Strategien, und Ansätze liefern. Ihre Ideen bilden die Grundlage für neue Projekte, Problemlösungen bzw. Vorgehensweisen. Diese Persönlichkeiten sind individualistisch, dabei sehr intelligent, handeln vielfach unorthodox und sind meist ernste Menschen. Vielfach gelten sie auch als introvertiert. Ihre besonderen Stärken liegen in ihrer hohen Kreativität, wobei sie mit originellen Ideen aufwarten. Ebenso verfügen sie über großes strategisches Denkvermögen, vernachlässigen allerdings oftmals Details und übergehen immer wieder gegebene Anweisungen. Sind in einer Arbeitsgruppe zu viele Innovatoren, so führt dies dazu, dass Teams als solche nicht zusammenfinden, da jeder vor sich hinarbeitet. Die Konsequenz im Softwarebau ist mangelnde Abstimmung und somit ergeben sich erhöhte Reibungsverluste. Ebenso werden emergente Effekte aus einer Teamzusammenarbeit nur in sehr geringem Maße stattfinden.


Spezialisten-lastige Teams. In Anerkennung an die amerikanische Mondlandung wurde ein Phänomen bei so ausgerichteten Gruppen beobachtet, das als „Apollo-Syndrom“ in die Geschichte einging. Hochqualifizierte Expertenteams schnitten hierbei in Vergleichsbewertungen deutlich schlechter ab als weniger qualifizierte Teams. Im historischen Kontext hatte man bei freier Auswahl der Gruppenmitglieder ein Team aus lauter scharf analysierenden Persönlichkeiten zusammengestellt, um die zu bewältigende schwierige und komplexe Aufgabe zu lösen. Man war davon ausgegangen, dass ein Team aus lauter Spezialisten am besten in der Lage sein müsse, große Projekte zu realisieren. Nachdem genau dieses Team jedoch die schlechtesten Ergebnisse im Gesamtvergleich geliefert und man Versehen bzw. Fehlauswertungen ausgeschlossen hatte, untersuchte man dieses überraschende Resultat genauer. Die Untersuchungen brachten folgende Erkenntnis: Die Gruppe hatte intern viel Zeit durch destruktive bzw. nutzlose Diskussionen verloren, indem der eine den anderen zu überzeugen versuchte. Infolgedessen konnte das Team nur sehr schwerfällig zu Entscheidungen gelangen. Die starke eigene Position sowie die fehlende Teamsicht waren somit Hauptverursacher dieses Resultats.

6.4 Teampower Wer nur kann, was alle schon können … Und nur weiß, was alle schon wissen, kann auch nur tun, was bereits alle tun können. Wettbewerbserfolg setzt immer den Willen, die Kraft und Fähigkeit voraus, anderen mit eigenständigen Wissensfortschritten und Problemlösungen voranzugehen. (Prof. Hubert Markl, Präsident der Max-Planck-Gesellschaft) Der britische Zoologe Vero Wynne-Edwards stellte in den 60er Jahren zum ersten Mal eine Theorie auf, die unter dem Schlagwort „Gruppenselektion“ bekannt wurde. Sie besagt, dass eine Population, deren Angehörige sich als altruistisch, also selbstlos, erweisen, eine sehr viel größere Überlebenschance haben als eine Population, in der Eigennutz vor Gruppeninteressen steht. Genau diese Dynamik findet sich bei erfolgreichen Teams ebenfalls wieder. Ausgehend davon, dass man für ein gemeinsames Ziel kämpft und unter der Berücksichtigung der vorgestellten teamdynamischen Prozesse wird die Gruppe dazu von sich aus motiviert, gemeinsam die Ziellinie zu überschreiten. Neben der notwendig hohen Sachkompetenz tritt als starker Zusatzeffekt eine Form von Altruismus ein, bei dem man sich gegenseitig unter die Arme greift und hilft. Diese teaminterne Zusammenarbeit und gegenseitige Unterstützung hilft dabei, die internen Arbeitsstandards deutlich zu erhöhen, was im Kontext des Softwarebaus von zentraler Bedeutung ist und dazu beiträgt, den Komplexitätszuwachs bei der Lösung zu reduzieren.

6.4 Teampower 187

6.4.1 Hochleistungsteams Um als Team in solch einen Zustand zu gelangen, muss die Arbeitsgruppe aktiv durch einen Entwicklungsprozess geführt werden, der sich der Belbin’schen Sichtweise überlagert. Dort war die Rede von teambezogenen Persönlichkeitsprofilen und dem Prozess des Zusammenwachsens. Hier geht es um die Betrachtung von Leistungspotential und Effizienz solcher Teams. Wie den beiden Zeichnungen (nach Katzenbach) in Abb. 6.2 zu entnehmen ist, können entstandene Teams weiterentwickelt werden. Dabei ist dies kein linearer Wachstumsprozess! Echte Teams oder sogar Hochleistungsteams im Sinne von Abb. 6.2(A) entstehen nicht dadurch, dass man im Stil alter Managementlehre Mitarbeiter aus unterschiedlichen Gründen zusammensetzt und sie zum Team deklariert. Haben die Mitarbeiter vorher im Sinne von lose zusammenarbeitenden Sachbearbeitern ihre Arbeit gut erledigt, so werden sie in solch einem Pseudoteam wesentlich imperformanter tätig sein können. Der Grund liegt darin, dass jeder als Einzelkämpfer seinen Stil beibehält – jedoch unter erschwerten Bedingungen (z. B. Großraumbüro, andere Personen etc.). Das Hauptcharakteristikum solcher Pseudoteams ist die Tatsache, dass der kollektiven Leistung zu wenig oder kein Augenmerk

Abb. 6.2. Teams auf dem Weg zur Höchstleistung


geschenkt wird. Selbst die Tatsache, dass man in einem Raum sitzt, Mahlzeiten zusammen einnimmt oder miteinander redet, beseitigt dieses Problem nicht, da nahzu keine emergenten Effekte genutzt werden. Dabei ist es nicht ungewöhnlich, dass sich solch eine Gruppe von Menschen selbst als Team bezeichnen. Da allerdings kein Zielfindungsprozess stattgefunden hat, bei dem alle beteiligten Mitarbeiter gemeinsame und konkrete Ziele für ihr Team formuliert haben und diese auch mittragen, wurde der entscheidende Prozess nicht angestoßen. Dies ist übrigens eine große Problematik bei Prozessumstellungen innerhalb des Softwarebaus von Wasserfallmethodiken auf „agile“ bzw. „unified“ Verfahren. Hatte man bis dato in den unterschiedlichen Rollen im Sinne des Wasserfallmodells gearbeitet und dabei alle eingehenden Aufträge pünktlich erledigt und weitergeleitet, so ist auf einmal eine ganz andere Art der Interaktion gefragt. Plötzlich wird aktiver Dialog, gemeinsame Zielfindung und eigenaktives Handeln in den Mittelpunkt gestellt. Wurde diese mentale Umstellung nicht ausreichend in den Mitarbeitern verankert, so bleibt am Ende eine von oben verordnete Prozessumstellung mit sehr ineffizienter Arbeitsweise übrig. Im Sinne der Einzelkämpfer werden sich Mitarbeiter akribisch an die neuen Prozessabläufe klammern, jedoch die mentale Umstellung auf die andere Form der Zusammenarbeit nicht vollziehen. Erst wenn Gruppen gemeinsam versuchen, aus diesem Zustand herauszukommen, indem sie erste Stärken ihres gemeinsamen Handelns erkennen, wird wirkliche Teamarbeit möglich. Insbesondere zu Anfang braucht dies einiges an Zeit für die Selbstorganisation. Diese Zeit der Selbstfindung geht natürlich den eigentlichen Aufgaben verloren, weshalb Verantwortliche, die nicht weit genug denken, leicht in die Versuchung kommen können den alten, offenbar produktiveren Zustand wiederherzustellen. Damit verbauen sie sich jedoch die Chance, echte Teamarbeit oder sogar hochperformante Teams zu erhalten. Folgt man der Systematik von Katzenbach (Katzenbach und Smith 2003), so müssen auf der aufsteigenden Kurvenseite in Abb. 6.2(A) die nachfolgenden Stufen durchlaufen werden. Der Vollständigkeit halber beginne ich noch einmal beim Pseudoteam, als der ineffizientesten aller Formen der Zusammenarbeit. Pseudoteam. Als Team wird keine echte kollektive Leistung erbracht oder angestrebt. Jeder Einzelne versucht für sich eine gute Arbeit zu leisten, auch sieht man sich als Teil eines größeren Ganzen, jedoch erbringt man nicht wirklich gemeinsame Leistungen. Wie es die Kurve von Katzenbach belegt, trägt diese Gruppe für die Unternehmensleistung weniger bei als einer Gruppe lose zusammenarbeitender Spezialisten.

6.4 Teampower 189

Potentielles Team. Dieses steht erst am Anfang seiner Performancekarriere, dennoch ist es in der richtigen Richtung unterwegs. In den Mitarbeitern wächst die Erkenntnis, dass man nur gemeinsam stark ist, daher findet man in diesen Teams den Wunsch zur Zusammenarbeit, um hierdurch die Gesamtleistung zu steigern. Allerdings gibt es viel internen Klärungsbedarf in Hinblick auf den eigenen Existenzzweck sowie die Ziele und erwarteten Ergebnisse. Echte gemeinschaftliche Verantwortung existiert in diesem Sinne noch nicht. In diesen Teams im Rahmen des Softwarebaus ist dies vielfach daran zu erkennen, dass man über gemeinsame Prozesse, Kollaborationssoftware und andere Hilfsmittel diskutiert und deren Einführung anmahnt. (Diese Phase entspricht in etwa der Kooperationsphase bei Belbin.) Echtes Team. Ist eine solche Gruppe zu einem echten Team geworden, dann spielen Hilfsmittel zwar nach wie vor eine wichtige Rolle, sehr viel zentraler ist jedoch jetzt die Frage nach der gegenseitigen aktiven Unterstützung. Man erkennt und anerkennt hierbei die einander ergänzenden Fähigkeiten und fängt an, diese zu nutzen. Man macht gemeinsame Sache, zieht an einem Strang und hat ein gemeinsames Ziel vor Augen, für das sich alle mit ihren individuellen Fähigkeiten zum Wohle aller einsetzen. – (Diese Phase entspricht in etwa der Wachstumsphase bei Belbin.) Hochleistungsteam. Bei dem letzten Teamtyp – so die Untersuchungen von Katzenbach und die Erfahrungen aus der Praxis – kommen Teams dann in ihr Optimum, wenn die persönliche Komponente und das „Du“ im anderen wichtig geworden sind. Solche Hochleistungsteams übertreffen alle anderen Teamtypen bei weitem. Gemeinschaftlich übertrifft man die an den Einzelnen gestellten Erwartungen, wobei sehr hoher persönlicher Einsatz die einzelnen Mitglieder auszeichnet. Es tritt eine eigene Dynamik ein, die man als „Team Thinking“ bezeichnen könnte und von der im nächsten Kapitel noch ein wenig mehr die Rede sein wird. Das Hauptmerkmal dieser Teams besteht darin, dass neben den klassischen Teamfähigkeiten sich die einzelnen Mitglieder für einander einsetzen und dass besonders viel Wert auf die persönliche Entwicklung und den Erfolg der Mitstreiter gelegt wird. Als weiteres Merkmal zeigt sich für solche Teams – sofern sie nicht bewusst abgeschottet arbeiten –: Sie genießen eine hohe Anerkennung durch Mitarbeiter, die nicht zum Team gehören und erhalten entsprechende Unterstützung von dort. Gerade im Bereich der klassischen Softwareproduktion wird diese Stufe selten erlangt, stellt aber das ungenutzte Kapital vieler Organisationen dar. Wo diese Stufe erreicht wird, hat sie im Softwarebau eine erhebliche Wirkung, da all diejenigen Aspekte, die mit Kommunikation zu tun haben, weitestgehend gelöst sind. In Folge treten geringere Reibungsverluste


zwischen den einzelnen Fachdisziplinen auf, man sucht gemeinsam nach übergreifenden Lösungen und mobilisiert zusammen Kräfte, um Vereinbarungen einzuhalten. Vieles von dem, was in diesem Buch vorgestellt wurde, wird durch solche Teams erst in vollem Umfang möglich werden. Leider gibt es immer noch viele Unternehmen, die zu Verhinderern dieser Entwicklungsprozesse werden und die Teams, wo immer sie auch stehen mögen, in eine Mittelmäßigkeit zwingen. Eine der Ursachen hierfür ist das sogenannte Hollywood-Syndrom25: Hierbei leidet man unter dem überheblichen Glauben, dass Macht den Vortritt vor Talent habe – eine Krankheit, an der manche Linienorganisation der alten Schule leidet! Ganzheitlichkeit ist angesagt: Diese Hochleistungsteams entstehen nicht von alleine. Insbesondere die Persönlichkeit des Teamleiters, dessen fachliche Fähigkeiten, aber vor allem seine Gabe, auf die individuellen Bedürfnisse der Mitarbeiter emphatisch einzugehen, ohne dabei die kollektiven Bedürfnisse der Gruppe, wie auch den eigentlichen Auftrag, außer Acht zu lassen, sind entscheidend. Dabei ist es seine Aufgabe, die gemeinsame Vision zu prägen und hierin die Leitfigur zu sein. Dies ist umso wichtiger, als Hochleistungsteams eine Führung mit klaren Prinzipien und Richtungsvorgaben brauchen, um funktionieren zu können. Da es keine Schemata beim Umgang mit solchen Teams gibt, braucht der Leiter ein breites Spektrum an Erfahrung. Er muss sicherstellen, dass Ziele, Anliegen und Arbeitsmethodik gültig und sinnvoll bleiben. Da er den Puffer zwischen Team und Management bildet, ist es eine seiner Hauptaufgaben, hier konstant für Klärung zu sorgen und sicherzustellen, dass das Team nicht verunsichert wird. Ein letzter Punkt, wozu der Teamleiter in der Lage sein muss, besteht darin, die Fähigkeiten der einzelnen Mitarbeiter so freizusetzen, dass diese gezielt im Projekt genutzt werden können. Haben Teams eine solche Stufe erreicht, so entwickelt sich meist eine ganz spezifische Eigendynamik. Dies wurde gerade im Kontext genialer Teams (Bennis und Biederman 1998), also Gruppen, die nur aus den besten ihrer Klasse bestanden (z. B. „Manhattan-Projekt“26 Filmproduktion von Walt Disney, „Skunk Works“27), untersucht. Im Fall des ultrageheimen „Skunk-Works“-Projektes wurde dies dadurch unterstrichen, dass die Mitglieder eine Art Aufnahmeritus vollziehen mussten, in dessen Kontext sie auch zum Schweigen gegenüber dem Rest der Organisation verpflichtet 25

26

27

Das Hollywood-Syndrom drückt folgende Erwartungshaltung aus: Selbst wenn Du nur eine ganz kleine Rolle bekommen hast, so tue dankbar alles, was von Dir verlangt wird, egal wie langweilig und demütigend dies auch sein mag. Im Rahmen des „Manhattan-Projekts“ entstand die erste Atombombe, bei der die besten Wissenschaftler ihres Fachs in beeindruckender Teamarbeit gemeinsam diese moralisch umstrittene Waffe entwickelten. „Skunk Works“ nannte sich die Entwicklungsmannschaft des ersten hochgeheimen Tarnkappenbombers der US Airforce.

6.4 Teampower 191

wurden. Gerade mit dieser absoluten Geheimhaltung gegenüber NichtTeammitgliedern erreichte man dort, dass der Geist der Teammission noch einmal verstärkt wird. Das Wissen, zu einem kleinen informierten Kreis zu gehören, förderte in diesem Fall die Teammotivation. Eine besondere Variante dieser Hochleistungsteams ergibt sich, wenn – wie immer mehr üblich – an mehreren multinationalen Standorten gearbeitet wird. Statistiken belegen dabei eindeutig: Interkulturell arbeitende Teams zeichnen sich durch eine erhöhte Kreativität aus und sind hierin Teams aus nur einer Nation durchaus überlegen. Allerdings ist nachgewiesen, dass interkulturelle Teams ineffektiver arbeiten als Mitglieder aus nur einer Nationalität. Die Gründe hierfür liegen sehr häufig in den verborgenen Vorurteilen, den unterschiedlichen Arbeitsstilen und der unterschiedlichen nationalen Lebensgestaltung („Schaffe schaffe Häusle bauen“ in Süddeutschland, „Manjiana-Mentalität“ eher in südlich geprägten Ländern). Eine Studie von DaimlerChrysler aus dem Jahr 2004 zeigt dabei auf, dass sich die Schwierigkeiten verteilen: x Kommunikation (78%) x Unterschiedlicher Arbeitsstil (58%) x Andere Ziele und Motive (57%) x Art der Entscheidungsfindung (52%) Je besser es gelingt, die beschriebenen Mechanismen auch zwischen unterschiedlich geprägten Standorten zu etablieren, umso mehr inhaltlicher Gewinn wird hierdurch möglich. Es setzt jedoch voraus, dass sich gerade der Projektleiter aktiv mit den anderen Kulturen auseinander setzt, dadurch interkulturelle Kompetenz aufbaut und – soweit dies nicht durch eine andere Person erfolgt – zur kulturellen Brücke zwischen verschiedenen Welten wird. Hierdurch kann vermieden werden, dass durch die Missachtung kultureller Gepflogenheiten sich das Projekt entsprechend verzögert. Dies ist herausfordernd, jedoch ungemein bereichernd, da andere Sozialnormen oder Arbeitsmethodiken auch hier wieder in die Richtung der propagierten Ganzheitlichkeit führen. 6.4.2 Co-Intelligente Teams Was dem Schwarm nicht nützt, das nützt auch der einzelnen Biene nicht. (Marc Aurel (121–180), römischer Kaiser) Zum Abschluss dieser Sinneinheit möchte ich mit Ihnen einen Aspekt streifen, der bei echten Teams oder Hochleistungsteams eine interessante Implikation betrifft, die für die Überwindung der Komplexitätshürden im Softwarebau nicht unwichtig ist. Die Rede ist von der Gruppenintelligenz, also der kollektiven Intelligenz aller beteiligten Einzelintelligenzen.


Zunächst sind ein paar Grundlagen zu definieren. Dazu muss geklärt werden, was Intelligenz ist: Es handelt sich hierbei an erster Stelle um die Fähigkeit, mit der wir auf sich verändernde Umstände reagieren können. Als Nächstes ist die Frage zu beantworten, was den Unterschied zwischen individueller und kollektiver Intelligenz ausmacht. Folgt man den Ausführungen von Tom Atlee (Atlee 2003), so unterteilt er die individuelle Intelligenz in acht Bereiche: x x x x x

Wahrnehmung: Also sehen, hören, fühlen. Kommunikation: Sprechen, andere Formen der Kommunikation. Gedächtnis: Alle Formen des Wissens abrufen. Reflektion und Lernen: Wissen gezielt aufbauen und reflektierend nutzen. Probleme lösen: Komplexe Zusammenhänge analysieren, Rückschlüsse ziehen und Lösungen realisieren. x Kreativität und Vorstellungsvermögen: Sich Dinge in der eigenen Imagination entwickeln und sie visionär vor Augen haben. x Feedback und Review: Ergebnisse bewerten und einschätzen. Jedes intelligente Wesen verfügt über diese Fähigkeiten. Gleichzeitig versucht man, so weit als möglich diese Fähigkeiten auf künstliche Systeme abzubilden. (Was immer wieder eine der Grundthemen beim Softwarebau ist: Wie „intelligent“ kann die Software sein?) Wie bereits erwähnt, ist dies eines der Themen aus den Kognitionswissenschaften. Im Hinblick auf kollektive Intelligenz ist nun zu klären, was diese in Ergänzung zu den bereits genannten Eigenschaften hinzufügt. Für Atlee sind dies die beiden folgenden Bereiche, nämlich: x Kommunikation untereinander x Parallele Verarbeitung von Informationen In Ergänzung zu Atlee und zwecks Vermeidung voreiliger Schlüsse geht es hierbei nicht um die simple Gleichung: Weil mein Team parallel arbeitet und die Mitglieder miteinander E-Mails austauschen, deshalb haben wir bereits so etwas wie kollektive Intelligenz. Dies ist allerdings eine rudimentäre Form davon. – In Verbindung mit den Teamgedanken, also der Öffnung hin zu mehr und breiteren Kommunikationskanälen, bekommt dieser Punkt allerdings ein anderes Gesicht. Der Begriff der Co-Intelligenz (Atlee 2003; Atlee, Lynn et al. 2003) bezieht sich auf eine gemeinsam benutzte Intelligenz, die auf verschiedene Köpfe verteilt ist (vgl. Abb. 6.3). In diesem Sinne beschreibt es denjenigen Zustand des idealen Entwicklungsteams in seinen unterschiedlichen Rollen: Verschiedene agile Ansätze, etwa das Vieraugen-Prinzip oder gezielte Interaktionen zwischen den Rolleninhabern, nutzen diesen Effekt aus. Auch im Sinne der auf S. 52 beschriebenen intellektuellen Phasen beim Softwarebau und den hieraus resultierenden Schnittstellenproblemen – und damit Komplexitätszuwächsen bei der Er-

6.4 Teampower 193

Abb. 6.3. Gruppenintelligenz – Gehirne arbeiten zusammen

stellung softwaretechnischer Lösungen – ergibt sich eine Grundsatzantwort: Je störungsfreier der Austausch zwischen den Intelligenzen der Einzelpersonen stattfinden kann und je breiter die Kommunikationskanäle sind, umso effektiver ist deren Wirkung. Wie störungsfrei diese Kommunikationskanäle sind, steht in direktem Bezug zu denjenigen Mechanismen, wie sie den Hochleistungsteams entsprechen. Wenn immer Teams aus diesen Positionen heraus operieren, werden sie Resultate hervorbringen, die über die Summe der Einzelleistungen hinausgehen. Dabei ist Co-Intelligenz keine Methode! Es bewirkt jedoch folgendes: x Bessere und effektivere Zusammenarbeit. x Gezielter Einsatz der Unterschiedlichkeiten und persönlichen Einzigartigkeiten, um noch kreativer handeln zu können. x Sehr viel ganzheitlichere Einbringung als Persönlichkeit und damit die Option für ein größeres Leistungsspektrum. Dass dieser Bereich zukünftig auch im real existierenden Softwarebau stärker Einfluss gewinnen dürfte, lässt sich an zwei Dingen festmachen: 1. Die deutschen Kognitionspsychologen Dietrich Dörner (Bamberg) und Joachim Funke (Heidelberg) haben unter dem Schlagwort „Komplexes Problemlösen“ einen eigenen Forschungszweig begründet, in dem es um intelligente Kooperationen, vernetztes Denken und deren Netzwerker


geht. Alles Themen also, die darauf hinweisen, dass es hier in Zukunft Methoden geben dürfte, mit deren Hilfe der nicht abgeschöpfte kollektive Intellekt der Mitarbeiter im Softwarebau besser genutzt werden kann, um durch gemeinschaftliche Leistung dem Komplexitätsproblem zu begegnen. 2. Ein zweiter Bereich, der in diese Richtung deutet, ist das sogenannte wissende Feld nach Hellinger (Grochowiak und Castella 2002). Der Psychotherapeut ist durch seine „Familien- und Organisationsstellung“ bekannt geworden. Seine Annahme ist dabei – und die Praxis gibt ihm Recht –, dass ein Gruppe von Menschen zu einer definierten Thematik aus einer Einheit heraus gemeinsam etwas wahrnehmen und anschließend aus verschiedenen Sichten beschreiben können. Mit Hilfe der zugehörigen Techniken lassen sich z. B. Gruppenkonflikte bearbeiten. Ob und wie so etwas auf den Softwarebau zu übertragen ist oder ob sich hiermit nur kranke Softwareteams verarzten lassen, ist offen. Das Schlüsseziehen überlasse ich Ihnen.

Literatur Bartnik, D. (2001). Das müssen Sie über Management wissen. Frankfurt/Main, Campus Verlag. Beck-Bornholdt, H.-P. und H.-H. Dubben (2005). Der Hund, der Eier legt – Erkennen von Fehlinformation durch Querdenken. Hamburg, rororo. Boy, J. D., C. Dudek, S. Kuschel, (2003). Projektmanagement – Grundlagen, Methoden und Techniken. Offenbach, GABAL Verlag. Conrad, B., B. Jacob et al. (2003). Konflikt-Transformation, Konflikte werden gelöst – Unterschiede bleiben. Paderborn, Junfermann Verlag. DeMarco, T. (1997). Warum ist Software so teuer? Und andere Rätsel des Informationszeitalters. München, Wien, Hanser Verlag. Doppler, K. (2003). Der Changemanager. Frankfurt/Main, Campus Verlag. Eiffert, S. D. (2001). Eine Gehirnhälfte ist nicht genug. Landsberg/Lech, mvg-verlag moderne industrie. Ellis, J. T., René Tissen (2004). Die 7 Todsünden des Managements. Frankfurt, Wien, Redline Wirtschaft bei Ueberreuter. Finke, J. (1999). Beziehung und Intervention. Stuttgart, New York, Georg Thieme Verlag. Heigl, P. (2002). 30 Minuten für gute Retorik. Offenbach, GABAL Verlag. Holtbernd, T. (2003). Führungsfaktor Humor: Wie Sie und Ihr Unternehmen davon profitieren können. Frankfurt, Wien, Redline Wirtschaft bei Ueberreuter. Hüther, G. (2001). Bedienungsanleitung für ein menschliches Gehirn. Göttingen, Vandenhoek & Ruprecht. Jackson, A. (2001). Jetzt habe ich genug! Kreative Konfliktbewältigung. Zürich, Oesch.

Literatur 195 Johnson, S. (2000). Die Mäusestrategie für Manager. Kreuzlingen, München, Heinrich Hugendubel Verlag. Kaminski, E. (2004). 30 Minuten für mehr Erfolg durch Coaching. Offenbach, GABAL Verlag. Kasper, W. A. E. Günther (2003). Querdenken – Tools und Techniken für kreative Kicks. Kirchzarten bei Freiburg, VAK verlags GmbH. Kirchner, B. (2001). Benedikt für Manager, die geistigen Grundlagen des Führens. Wiesbaden, Dr. Th. Gabler Verlag. Koch, A. und S. Kühn (2000). Ausgepowert?: Hilfen bei Burnout, Stress, innerer Kündigung. Offenbach, GABAL Verlag. Kratz, H.-J. (2000). Kontrollieren – aber wie? Offenbach, GABAL Verlag. Leman, K. und B. Pentak (2004). Das Hirtenprinzip. Gütersloh, Gütersloher Verlagshaus GmbH. Logan, R. S. C. (2003). Das Coaching 1 u 1. Gießen, Brunnen Verlag. MacDonald, G. (1985). Ordering your private world. Crowborough, UK, Highland Books. Maxwell, J. C. (2002). Charakter und Charisma. Gießen, Brunnen Verlag. Maxwell, J. C. (2005). Die Entscheidungsformel – wie ethisches Handeln zum Erfolg führt. Gießen, Brunnen Verlag. Motamedi, S. (1999). Konfliktmanagement: vom Konfliktvermeider zum Konfliktmanager. Offenbach, GABAL Verlag. Pawlowski, K., H. Riebensahm, (2003). Konstruktiv Gespräche führen. Hamburg, Rowohlt Taschenburg Verlag. Peter, L. J., Raymond Hull (2001). Das Peter-Prinzip oder die Hierarchie der Unfähigen. Hamburg, Rowohlt Taschenbuch Verlag. Rabey, G. P. (2002). Basiswissen für Führungskräfte. Niedernhausen/Ts, Falken Verlag. Rainwater, J. H. (2003). Katzen hüten. Bonn, mitp-Verlag. Ratey, J. J. (2003). Das menschliche Gehirn: eine Gebrauchsanweisung. Düsseldorf, Zürich, Walter Verlag. Reddy, M. (1997). Mitarbeiter beraten. Weinheim, Basel, Beltz Verlag. Rush, M. (1992). Die Persönlichkeit des Managers. Asslar, Verlag Klaus Gerth. Sawizki, E. R. (2003). 30 Minuten für erfolgreiches NLP im Alltag. Offenbach, GABAL Verlag. Seewald, P. (2001). Die Schule der Mönche. Freiburg, Herder Verlag. Seewald, P. und S. Kosog (2004). Die Ruhe der Mönche. München, Zürich, Heyne Verlag. Seewald, P. und U. Hauser (2004). Die Spiritualität der Mönche. München, Zürich, Heyne Verlag. Seiwert, L. (2004). Mehr Zeit fürs Glück – Live-Balance. München, Deutscher Taschenbuch Verlag. Seiwert, L. J. (2003). 30 Minuten für deine Work-Life-Balance. Offenbach, GABAL Verlag. Stähle, M. (2003). Die vier Phasen für erfolgreiche Veränderungen. So steigen Sie auf. Konstanz, Aufsteiger Verlag. Wirth, B. P. (2003). 30 Minuten für bessere Menschenkenntnis. Offenbach, GABAL Verlag.

7 Showdown

Der Preis des Erfolges ist Hingabe, harte Arbeit und unablässiger Einsatz für das, was man erreichen will. (Frank Lloyd Wright, revolutionierte die europ. Architektur) Nachdem Sie sich bis auf diese Seite vorgearbeitet und von vielen Hintergründen und mancher Theorie gelesen haben, ist es jetzt an der Zeit, ganz praktisch zu werden. In diesem letzten Abschnitt werde ich ein zweites Mal mit Ihnen durch ein fiktives Projekt gehen. Es wird dieses Mal nüchtern ausfallen, ohne viel Prosa, aber dafür eine ganze Reihe konkreter Checklisten haben, mit denen Sie strukturiert arbeiten können. Da der Schwerpunkt dieses Buches auf ganzheitlichem Projektmanagement liegt, wird dies auch die Sicht der kommenden Seiten festlegen. Auf Detailaussagen zu anderen wichtigen Bereichen des Softwarebaus wird dabei bewusst verzichtet werden. Es liegt auch hier auf der Hand, dass die getroffenen Aussagen nicht auf jede Situation zu beziehen sind, somit auch nicht den Anspruch auf absolute Allgemeingültigkeit haben, sondern sich im Sinne von „Best Practices“ verstehen. Aus dem breiten Spektrum der Möglichkeiten wurde daher die Situation eines Neukunden und einem komplett neuen Projektauftrag herausgegriffen. Die wichtigsten Gedanken dieses Szenarios lassen sich jedoch mit wenig Aufwand auch auf Projekte mit Bestandskunden, auf Produktweiterentwicklung, hausinterne Projekte sowie Reengineering-Projekte übertragen.

7.1 Der Auftrag Gerade Softwareprojekte fallen selten aus heiterem Himmel. Vielfach kündigen sich Projekte schon im Vorfeld deutlich an. Auch wenn es noch keinen Vertrag mit dem Kunden bzw. Auftraggeber gibt, so sind – speziell bei größeren Projekten – gewisse Dinge wahrscheinlich. In Abhängigkeit von dieser Wahrscheinlichkeit, sozusagen projektvorbereitend, ist dies das Zeitfenster, in welchem einige sehr wichtige Vorarbeiten laufen müssen, ohne dass hierfür eine ganze Entwicklungsmannschaft abzustellen wäre. Um saubere Angebote abliefern zu können – es sei denn, dass es sich um strategische Angebote handelt –, ist es notwendig, sehr früh grundsätzliche

198 7 Showdown

Dinge mit dem Kunden zu klären, da sich hieraus die initiale Preisgestaltung wie auch weitere Folgeaufwände ergeben. Zu den hausinternen Aufgaben gehört an erster Stelle die Frage nach der Abstimmung mit der eigenen Produktstrategie28: Ist der potentiell neue Auftrag innerhalb des Definitionsbereiches, den die eigene Organisation als ihr Arbeitsfeld festgelegt hat? Ist es eine Randzone oder liegt es ganz außerhalb dieses Aufgabenfensters? Je nachdem was hier Ihr Ergebnis ist, werden Sie – zumindest nach innen hin – mit vermehrten Aufwänden rechnen müssen, weil Sie speziell im letzten Fall im Begriff sind, als Organisation Neuland zu betreten. Da es sehr starke wechselseitige Abhängigkeiten zwischen Produktstrategie, Anforderungen, IT-Basisarchitektur und anderen Kernbereichen der Softwareentwicklung gibt, entstehen durch eine nicht vorhandene oder schwammige Strategie interne zusätzliche Aufwände als Folge späterer Beseitigung von inhaltlichen Unstimmigkeiten oder Unklarheiten. Im Hinblick auf Abb. 7.1 (links oben) gilt dabei: Indem die Bereiche „allgemeine IT-Architektur“, „allgemeine Anforderung“ und „Produktstrategie“ eng aufeinander abgestimmt sind, optimieren sie sich im betrieblichen Alltag gegenseitig. Als Folge hieraus kommt vielfach eine Planung der zukünftigen Software zustande, deren Komplexität aufgrund dieser Wechselwirkungen deutlich reduziert werden konnte. Hierdurch werden sowohl bei der initialen Erstellung wie auch während des Lebenszyklus der Software erheblich Kosten eingespart. Dies gilt insbesondere dann, wenn diese drei Größen innerhalb der eigenen Organisation einer Art kontinuierlichem Refactoring-Prozess unterzogen bleiben und dieser ebenfalls Eingang in die real existierenden Softwareprodukte findet. Diese Vorgehensweise ist oftmals für das Management in erster Betrachtung nur bedingt nachvollziehbar, da die zusätzlichen Kosten für diese konstante Weiterpflege des beschriebenen Trios sowie die fortschreitende Aktualisierung bereits fertig gestellter Software zusätzliches Kapital bindet und man hier Gewinneinbußen zu sehen glaubt. Tatsächlich entstehen natürlich erhöhte Primärkosten, die jedoch durch deutlich geringere Aufwände im Lebenszyklus, etwa durch effizientere und somit günstigere Fehlerbehebung, Optimierung des funktionalen Umfangs o. Ä. auf mittlere und lange Sicht sehr wohl wieder wettgemacht werden. 28

Sollte es keine eigene Produktstrategie geben, so ist hier die dringende Empfehlung, eine solche zu entwickeln. Zielmärkte, Zielproduktspektrum, technische Zielplattformen sowie Fragen hauseigener Produktlinien sind hier nur einige der wichtigsten Schlagwörter, die es hinreichend präzise festzulegen gilt. Dabei sind die drei Zeithorizonte kurzfristig (ca. 1 Jahr), mittelfristig (ca. 3 Jahre) und langfristig festzulegen, wobei zeitnahe Strategie auch im technischen Sinne präzise sein muss, während mit zunehmendem zeitlichen Abstand die Aussagen eher einem Zielkorridor entsprechen und somit geringere Granularität aufweisen müssen. Bedingt durch die zeitliche Komponente ist die Strategie konstant nachzuführen.

7.1 Der Auftrag 199

Abb. 7.1. Kernbereiche im optimalen Softwarebau

In Abb. 7.1 (links unten) sind generelle hausinterne Vorgehensweisen und „Hilfsmittel“ aufgelistet. Je mehr es gelingt, diese Bereiche möglichst durchgängig in den unterschiedlichen Projekten der eigenen Organisation einzusetzen, umso effizienter wird sich die Softwareproduktion gestalten und umso einfacher wird es sein, Mitarbeiter zwischen Projekten zu verlagern. Vorgehensweisen (sowohl produktseitig wie auch projektseitig) im Sinne von hausinternen „Best Practices“ entwickeln sich damit als eigene Produktionskultur und gestatten effizientes und agiles Reagieren auf Marktbedürfnisse. Beiden Bereichen gemeinsam ist dabei das Wissensmanagement über die spezifische Domain. Je klarer die Produktstrategie des eigenen Hauses eine abgegrenzte Wissensdomain definiert und diese entsprechend gut mit Hilfe des Wissensmanagements (z. B. durch Ontologien) beschrieben bzw. dokumentiert wurde, umso schneller und umfassender lassen sich Anforderungen an ein neues Projekt im Sinne der Vollständigkeit abgleichen und ergänzen. Gerade hier ist der Pool zu suchen, in welchem das spezifische Domainwissen, wie es in Software transformiert werden soll oder wurde, hinterlegt ist. Je aktueller diese Wissensbasis gehalten wird, umso einfacher wird eine spätere Realisierung zusätzlicher oder ergänzender Funktionalitäten, aber auch die Implementierung gänzlich neuer Produkte in diesem Feld. Mit diesen Voraussetzungen haben Sie eine eindeutig definierte hausinterne Referenz, ob der mögliche Kundenauftrag Ihnen im kaufmännischen Sinne ausreichend gute Chancen auf ein Geschäft mit Erträgen liefern wird oder Ihnen mittelfristig Kosten entstehen werden, die diese Gewinnspanne voraussichtlich aufzehren werden.

200 7 Showdown

Im frühen Dialog mit dem Kunden sind hier weitere Dinge zu klären, die für die folgenden Projektschritte von großer Wichtigkeit sind: Es geht darum, mit dem Kunden eine gemeinsame Vorgehensweise festzulegen. Wie Sie sich erinnern werden, gibt es solche Prozessmodelle, die den Kunden als Teil des Projektes betrachten, ihn also in sehr hohem Maße im Projekt verfügbar sehen wollen, während andere Prozessmodelle dies nur für die Erfassung der Anforderungen verlangen. Wie sich Kunde und Lieferant in der geplanten Symbiose des Softwaredefinitionsprozesses stellen wollen, ist sehr früh in einer Art gemeinsamen „Kunden-Lieferanten“Strategie in Bezug auf den beabsichtigten Auftrag festzulegen. Hierin ist in groben Zügen neben den geplanten Inhalten und dem Umfang des beabsichtigten Projektes zu klären, was für die kommende Entwicklung und den folgenden Lebenszyklus der beabsichtigten Software als Ziele wichtig sind. Dabei kann eine solche Kunden-Lieferanten-Strategie durchaus als Teil eines LOI (= “Letter of Intent“) verstanden werden. Inhaltlich geht es darum, in welchem Maße, in welcher Form und wann Kundeninteraktion bei der Herstellung der kommenden Software grundsätzlich einzubringen ist. Es ist wichtig, dass sich der Kunde bereits sehr früh im Klaren darüber wird, was seine eigenen Grundaxiome in Bezug auf die kommende Software sein sollen. Diese Entscheidung legt letztendlich fest, ob der Lieferant eine eher dem Extreme Programming nahe Vorgehensweise wählen kann (= Entwicklungskontinuum, bei dem sich die Kundenwünsche schrittweise herausentwickeln) oder eine eher klassisch ingenieurmäßige Methodik (V-Modell, RUP o. Ä.), bei dem der Kunde je nach Prozessmodell nur bis zu bestimmten Punkten Anforderungen ändern oder ergänzen kann, wenn Preis und Fertigstellungstermin festliegen. Abgrenzungen zu ziehen ist in Softwareprojekten auf allen Ebenen von großer Wichtigkeit. Demzufolge muss diese frühe Phase im Umgang mit dem Kunden auch hiervon geprägt sein. Der potentielle Kunde muss wissen, wo projekttechnische Grenzen liegen und ab wo es inhaltlich für den Lieferanten uninteressant wird, dieses Projekt zu machen. Hintergrund hierzu ist: Mit einem, sagen wir „Quick & Dirty“-Projekt, das man nur deshalb an Land gezogen hat, weil volle Auftragsbücher intern gefordert wurden, entsteht in den meisten Fällen mehr Schaden als Nutzen: Mühsam erarbeitete hausinterne Arbeitsweisen oder Qualitätsstandards müssen durch solch einen Projektstil teilweise wieder außer Kraft gesetzt werden und das mühsam eingeführte gesamte Qualitätsniveau wird durch solch eine Politik durchlöchert werden. Mitarbeitern wird letztendlich wieder antrainiert, wie man unsauber arbeitet – und das wird auch auf andere Projekte abfärben. Selbst oder gerade in einer Zeit des harten Wettbewerbs wird letztendlich ein Mix aus Qualität und Preis den Kundenzuschlag erbringen und diesen auch halten!

7.2 Der Macher 201

7.2 Der Macher Inzwischen ist in Bezug auf den möglichen Neukunden oder das Neugeschäft ein Zeitpunkt erreicht worden, zu dem nahezu sicher ist, dass dieses Projekt zustande kommen wird. Ob ein LOI (= “Letter of Intent“) und/oder andere schriftliche Vereinbarungen zwischen Lieferanten und Kunden geschlossen wurden, wird abhängig von der jeweiligen Organisation sein und ist nicht weiter Thema an dieser Stelle. Es ist nun an der Zeit, dass in der eigenen Organisation Dinge vorbereitet werden. Die wichtigste Aufgabe, die spätestens jetzt erfolgen muss, besteht darin, festzulegen, wie viel Projektmanagement notwendig ist und wer der Projektmanager sein soll. Es ist unbedingt ratsam, dass diese Person von jetzt an bis zur Produktauslieferung an Bord des Projektes ist und quasi zur Seele desselben wird. Sobald der Projektmanager bestimmt worden ist, hat dieser umgehend seine erste Feuerprobe gegenüber dem eigenen Management zu bestehen: Vor allen weiteren projekttechnischen Details geht es hausintern zunächst einmal darum, das Zusammenspiel zwischen ihm und dem eigenen Management festzulegen und Spielregeln zu vereinbaren. Da das eigene Management mit seiner Sicht auf Kunden, Cashflow und Ergebnisse des Projektes schaut, muss der Projektmanager hier seine „Rechte“ klären, will er wenigstens einigermaßen vor unliebsamen Überraschungen aus den eigenen Reihen sicher sein. „Friendly Fire“29 durch die eigene Unternehmensführung, die unbedacht Zusagen macht oder „ex cathedra“ tiefgreifende Projektänderungen (z. B. erweiterter Projektinhalt, verkürzte Projektlaufzeit oder reduzierte Mitarbeiterstärke) fast schon im Nebensatz festlegt, ist einer der Hauptverursacher gescheiterter Projekte! Aus diesem Grunde sollte hier sehr früh eine verbindliche Abstimmung zwischen Projektsponsor (= dem Management) und Projektmanager erfolgen. Zu dieser konstituierenden Sitzung ist es sinnvoll, den Projektsponsoren einen „Projektanlaufplan“ vorzulegen. Aus diesem sollte klar hervorgehen, welche politischen Meilensteine bis zu welchem Zeitpunkt erreicht werden müssen, damit das Projekt pünktlich starten kann. Ebenso sollten hierin die Konsequenzen von Kursänderungen seitens des Managements sowie die sich hieraus ableitenden Risiken für das Projekt klar formuliert sein. Dieser Anlaufplan stellt gewisse Forderungen an das Management, um so einen termingerechten Start des kommenden Projektes zu ermöglichen. Insbesondere die rechtzeitige Freistellung von Mitarbeitern, die klare definierte Position des Projektmanagers, Vertragsunterzeichnungen mit dem Kunden sowie rechtzeitige Ausbildung oder grundsätzliche Bereitstellung 29

„Friendly Fire“ stammt aus dem Militärjargon und beschreibt den versehentlichen Beschuss der eigenen Soldaten.

202 7 Showdown

von Ausstattung sind hierbei zu nennen. Eine Anmerkung am Rande: Da auch das Management der eigenen Organisation manchmal zur Vergesslichkeit neigt, ist es unbedingt notwendig aus Sicht des Projektmanagers, hier generell auf Schriftlichkeit zu achten. Dies ist zwar keine Garantie dafür, dass das Management tatsächlich zu den eigenen Zusagen durchgängig steht, es schützt aber den Projektmanager vor unzutreffenden Vorwürfen. Gerade gegen Projektende, wenn sich die Wirkungen veränderter Rahmenbedingungen am stärksten zeigen und sich hierdurch Termine verzögern bzw. Aufwände nicht eingehalten werden können, wird dieser sonst sehr leicht zum alleinigen Sündenbock. Eine solche Anlaufplanung kann z. B. in Form eines „Projektvertrags“ zwischen dem Projektmanager und dem Gesamtmanagement erfolgen. (Ein solcher Projektvertrag ist nicht identisch mit einer „Project-Charter“, in welcher bereits konkrete Planungszahlen definiert werden!) Checkliste In welchem Maß hat der Projektmanager eigene Entscheidungsbefugnisse im Projekt? In welchem Maß können Personalentscheidungen eigenständig getroffen werden? In welchem Maß und in welcher Weise kann über das Projektbudget frei verfügt werden? Nach welchen Spielregeln soll im Falle von Dissenzen mit den Projektsponsoren verfahren werden? Welches sind die aus Managementsicht wichtigsten Ziele in Bezug auf den kommenden Auftrag? In welchem Maß sind Innovation in internen Prozessen und Verfahren politisch gewünscht? Gibt es mögliche organisationsinterne Tradeoff-Effekte, die Berücksichtigung finden sollen? Wie soll die Kommunikation zwischen Projektmanager und Organisation erfolgen und wie soll ein Projekt-Controlling durch das Gesamtmanagement aussehen?

Da gerade Neuprojekte, noch dazu bei neuen Kunden, ein hohes Maß an Aufmerksamkeit durch das eigene Management brauchen, ist es sinnvoll, die vorgestellte Liste um die generellen Hauptrisiken zu ergänzen. Die Verantwortlichen sollten vorher wissen, welche Konsequenzen ihr eigenes Handeln in Bezug auf das spezielle Projekt haben kann. Aus diesem Grunde sollten die nachfolgenden bereits jetzt bekannten Aspekte, die einen Projekterfolg im Sinne einer pünktlichen Lieferung gefährden können, hier klar formuliert und hinterlegt sein. Dabei ist an dieser Stelle verbindlich zu

7.2 Der Macher 203

klären, wie man mit dem Projekt an sich umgehen wird, falls die folgenden Punkte dennoch notwendig werden sollten bzw. eintreten. Checkliste Verkürzung des Zeitplans Verkürzung der Ressourcen Elementare inhaltliche Änderungen Strategische Neuausrichtungen Management zeigt keine durchgängige aktive Unterstützung des Projektes (das „zu viele andere Baustellen“-Phänomen) Verzögerte oder späte Entscheidungen Geänderte interne Strategie Interne Umstellungen auf andere Methoden, Verfahren, Werkzeuge

Da Offshoring derzeit in aller Munde ist, sollte ebenfalls spätestens an dieser Stelle verbindlich festgelegt werden, ob und in welchem Maße Arbeiten ausgelagert werden sollen, können oder müssen. Wird dies positiv entschieden, so erwarten den Projektmanager hier per sofort eine ganze Reihe neuer Aufgaben. Er muss mit dem oder den Sublieferanten auf der inhaltlichen Seite ähnlich verfahren wie mit dem eigenen Management. Dazu bietet es sich an, drei gestaffelte Vertragswerke mit dem Lieferanten zu betrachten: 1. Der übliche Mantelvertrag zwischen den beiden Firmen, in dem man grundsätzlich klärt, wie man miteinander arbeiten möchte, welche Modalitäten, Rechte und Pflichten als Basis der Zusammenarbeit gelten sollen. – Dieser Vertrag bezieht sich auf alle Interaktionen zwischen den beiden Organisationen. 2. Sehr früh in einem neu anlaufenden Projekt empfiehlt sich ein konkreter Projektvertrag, in dem das betroffene Projekt definiert wird, aus denen die Inhalte, die Arbeitsteilung, die Schnittstellen, Kontroll- und Überwachungsmechanismen sowie verbindliche Voraussetzungen an Arbeitsmitteln, Methoden und Ausbildungsständen des Teams beim Offshore-Partner hervorgehen. – Bleibt eine solche frühe Absprache außer Acht, so können gerade die kulturell bedingten Unterschiede eine ganz individuelle, meist unangenehme Eigendynamik entwickeln. 3. Als Drittes empfiehlt sich ein „Supplier-Management-Plan“. In diesem werden zu einem etwas späteren Zeitpunkt alle für das Projekt selbst notwendigen Planungsdetails konkret festgehalten (vgl. Checkliste). Dieses Dokument ist das eigentliche Arbeitspapier innerhalb des Projektes und bildet die Grundlage für konkrete Zusammenarbeit im Projekt. Es ist dazu bestimmt, dass jeder genau weiß, was er in welcher Form bis wann und mit welcher Granulierung bzw. Qualität einzubringen hat.

204 7 Showdown

Nachfolgend habe ich Ihnen zunächst Eckpunkte für einen Projektvertrag mit einem Offshore-Zulieferer zusammengestellt. Leicht modifiziert eignen sie sich auch für einen Binnenlieferanten. Hier also die Checkliste: Checkliste Wie vertraut ist der Projektmanager mit den Spezifika30 der anderen Kultur? Was ist der geplante Auftragsrahmen? Was sind die Kommunikationskanäle? Wie gestaltet sich die praktische Zusammenarbeit zwischen dem heimischen Team und dem/den Offshore-Teams31? Wie werden Probleme eskaliert und in welcher Form wird der Fortschritt überwacht? In welchem Maß wird der Projektmanager vor Ort sein? In welcher Weise und in welchen Bereichen werden Vor-Ort-Audits32 beim Lieferanten durch den Kunden vorgenommen? Wie wird die fachliche Überwachung/Kontrolle durch den Kunden ermöglicht? Wie kann der Lieferant nachweisen, dass seine Mitarbeiter tatsächlich die notwendigen Ausbildungsstände haben, tatsächlich die festgelegten Prozessmodelle gelebt werden können und tatsächlich die geforderten Tools nicht nur auf dem Papier zu finden sind? 30

31

32

Hierzu einige Beispiele: In Südostasien ist immer noch das Hierachieprinzip sehr ausgeprägt. Derjenige mit dem höheren Titel hat hier das Sagen. – Das Zeitverständnis weicht in vielen Kulturen, selbst im europäischen Umfeld, von dem deutschen ab. „Pünktliche“ oder „vollständige“ Lieferung wird hierbei kulturell bedingt an vielen Orten großzügiger definiert als in einem rein deutschen Kontext. – Proaktives und rechtzeitiges Informieren über auftretende Probleme oder Verzögerungen ist keineswegs selbstverständlich und findet immer wieder trotz aktiven Einforderns nicht statt. – Auch hier ist in vielen Fällen von einer starken kulturellen Komponente auszugehen. Die Aussage: „Wir tauschen per E-Mail oder Webkonferenz aus und benutzen bestimmte Dokumenttypen“ ist hierbei erheblich zu wenig, da der Vorteil multinationaler Teams hierdurch in keiner Weise genutzt wird. Zwei Anmerkungen hierzu: 1. Multinationale Teams, wenn sie denn als Team zusammenarbeiten, sind erheblich kreativer als mononationale Teams – der Kommunikationsaufwand ist jedoch aufgrund der unterschiedlichen Nationalitäten per se schon höher! 2. Hiermit stehen in enger Verbindung Praxiserfahrungen, wonach die tatsächliche Kostenreduktion durch partielles Offshoring in sehr vielen Fällen unter 10% liegt. Über den Projektverlauf gestaffelte und inhaltlich angepasste „360°-Audits“ während des gesamten Projektverlaufs sind hier ein außerordentlich effizientes Mittel. Hierbei werden zunächst Arbeitsmittel und Ausbildungsstände, später Kommunikationskanäle und Qualität der Prozessdokumentation, danach inhaltlich-fachliche Leistungen und zuletzt produkt- und qualitätsspezifische Aspekte auditiert.

7.2 Der Macher 205

In Bezug auf den „Supplier-Management-Plan“ gibt es auch hier eine Übersicht über die wichtigsten Punkte in diesem Kontext. (Projektspezifisch wird sich hier ein gewisser Variantenreichtum ergeben.) Checkliste Erwartete Dienstleistungen: Was für Aufgaben sind von wem und bis wann konkret zu erbringen? Erwartete Zusammenarbeit: Wie viel Eigeninitiative wird erwartet und in welcher Form soll hier der Auftraggeber in diese Ergebnisse einbezogen werden? Erwartete Meilensteine: Welches sind inhaltlich die Hauptmeilensteine und bis wann sind diese zu realisieren? Erwartete Orte der Leistungserbringung33: Welche Sachen sollen wo erarbeitet werden? Projektmanagement: Wie soll die Zusammenarbeit zwischen dem Gesamtprojektleiter und dem Offshore-Teilprojektleiter konkret aussehen? – Wann wird berichtet oder eskaliert, wer tritt mit wem zu welchem Zeitpunkt in Verbindung? Artefakte: Welche Dokumente oder Codes sollen in welcher Form bis wann an wen übergeben werden? – Wer gilt für welches Artefakt als „Owner“, hat also die primäre Befugnis, Dinge zu ändern? Qualität und Testen: Welche qualitätssichernden Maßnahmen sollen für welche Teilaspekte wie erbracht werden? Arbeitsumgebung: Welche konkreten Werkzeuge sollen in welchen Versionen und Formaten wie zum Einsatz gelangen? Welche Prozesse sollen dabei angewandt werden?

Damit der Projektmanager die notwendigen Vorbereitungsarbeiten für den Projektanlauf erbringen kann, empfiehlt es sich ebenfalls, an dieser Stelle zu klären, in welchem Maße in die zu implementierenden Arbeitsprozesse des Kunden Einblick genommen werden kann. Soweit politisch möglich, ist es durchaus sinnvoll, wenn der Projektmanager gerade bei Neukunden oder größeren Neuprojekten einige Tage lang vor Ort beim Kunden „mitarbeitet“, um so aus eigener Anschauung zu erfahren, wie der Kunde arbeitet, was er implementiert haben möchte und welches der Kontext hierzu ist. 33

Dieser Punkt hat insofern eine hohe Relevanz, als es sich in Neubauprojekten als sehr effektiv erwiesen hat, wenn ein oder zwei führende Projektmitarbeiter des Offshore-Partners in den frühen Planungsphasen vor Ort mitarbeiten. Auf diese Weise „inhalieren“ sie den Geist des Projektes und können später sehr viel einfacher im Sinne des Projektes dieses zuhause steuern.

206 7 Showdown

Sobald der Projektmanager feststeht, gilt für diesen eine völlig eigene Dynamik im Sinne der Ganzheitlichkeit. Zunächst geht es darum, dass er absolut zielorientiert arbeitet und sich letztlich bei jedem Schritt fragt, ob ihn sein aktuelles Handeln der eigentlichen Ziellinie näher bringt. Diese Hauptziele lauten: das übertragene Projekt in hoher Qualität, kosteneffizient und pünktlich an den Kunden zu übergeben. Infolgedessen wird er ab Tag eins damit beginnen müssen, über die letzte Meile seines Projektes nachzudenken und sich zu fragen, wie latente Risiken, die bereits jetzt bekannt sind, abgefangen werden können. (Dazu gehört u. a. die zuletzt beschriebene Abstimmung mit dem Management.) Zielorientiertes Handeln muss sich dabei auch in allen Projektdokumenten ausdrücken – egal nach welchem Vorgehensmodell das Projekt umgesetzt wird. Hieraus leiten sich die folgenden Vorgehensparadigmen für den Projektmanager ab. Diese Punkte sollten sinnvollerweise durch den gesamten weiteren Verlauf des Entwicklungsprojektes immer wieder Beachtung finden, da sie den Arbeitsstil des Projektmanagers betreffen. Checkliste Frühes, proaktives Handeln. Ein Projekt so planen, dass Sie stets das Ende des Projektes vor Augen haben. Wissen, was die wirklich dringlichen Dinge sind (z. B. Risiken) und genau diese auch wirklich mit höchster Priorität angehen! Probleme lösen sich nicht durch Aussitzen, sondern durch Win-WinSituationen. Nicht Perfektionismus, sondern mit Besserwerden beginnen. IT-Projekte serviceorientiert führen, d. h. zuerst auf die Bedürfnisse des anderen eingehen. Konstante Suche nach Synergien. Planen Sie im Sinne des Win-Win regelmäßige, messbare Zwischenergebnisse ein. Konstante Suche nach den größten Schwachstellen im Projekt und deren aktive Bekämpfung. Mit Weitsicht arbeiten im Sinne von „die Unachtsamkeiten von heute sind die Probleme von morgen“. Suche nach potentiellen Problemzonen – gerade auch an der Peripherie des Projektes. Nicht nur technisch denken, sondern das (zukünftige) Team mit seinen Stärken und Schwächen im Auge haben.

7.3 Projektvorlauf 207

Im Sinne von Meilensteinen kann diese Phase als abgeschlossen betrachtet werden, wenn Projektmanager und Gesamtmanagement in der beschriebenen Form zu einer (schriftlichen) Übereinkunft gelangt sind. Erst wenn diese vorliegt, sollte konsequenterweise mit der nächsten Phase, nämlich dem Projektvorlauf, begonnen werden. Es ist dabei äußerst sinnvoll, darauf zu achten, dass immer erst eine solche Projektphase beendet wurde, ehe eine neue beginnt. Die Praxis zeigt immer wieder, dass andernfalls bestimmte Voraussetzungen für den nächsten Schritt im Nachhinein nur noch unvollständig oder gar nicht mehr eingefordert werden können.

7.3 Projektvorlauf Ziel dieser Phase ist es, den Rahmen des Projektes zu definieren sowie die Risiken des eigenen Vorgehens zu bewerten. Als Eigner des Projektes fällt diese Aufgabe vorwiegend dem Projektmanager zu. Allerdings ist es sinnvoll, sich den Rat derjenigen einzuholen, die voraussichtlich die Schlüsselpositionen im Projekt besetzen werden. Die Ergebnisse dieser Phase sollten in eine Project-Charter münden. Diese beinhaltet den Projektrahmen, die allgemeinen Vorgehensweisen, den notwendigen Personal- und Mittelbedarf sowie Projektspezifika. Genau dann, wenn zwischen Management und Projektmanager dieser Projektrahmen im Sinne einer Projektdefinition unterzeichnet wurde, kann diese Phase als abgeschlossen betrachtet werden. Von nun an ist die Projektverantwortung mit all ihren Risiken an den Projektmanager übergegangen und er muss zusehen, wie er sein Ziel erreicht! Neben den inhaltlichen Belangen haben an dieser Stelle zwei voneinander abhängige Themen für das Projekt und seinen Eigner eine zentrale Bedeutung und bedürfen der vorrangigen Klärung. Die Rede ist zum einen von den zu beteiligenden Mitarbeitern (sowie deren Anzahl) und zum anderen von der methodischen Vorgehensweise, also dem zu verwendenden Prozessmodell an sich. Die nachfolgenden Checklisten liefern einige Entscheidungskriterien bzw. Aspekte, die jetzt in Vorbereitung für die kommenden Arbeitsschritte zu klären sind. Dabei bezieht sich die erste Auflistung auf das Projekt selbst und auf den Zustand der eigenen Organisation:

208 7 Showdown

Checkliste Welche Erfahrungen liegen im Team vor? Welche Rahmenbedingungen müssen erfüllt werden? Auf welchem CMM-Level befindet sich Ihrer Meinung nach die eigene Organisation34? Wurden Projektdauer, Mitarbeiterstärke oder finanzieller Rahmen für das Projekt durch die Projektsponsoren bereits vorgegeben oder ist dies noch zu ermitteln? Wo liegt die Erwartung des Kunden in Bezug auf zertifizierte Qualität35? Was ist bereits jetzt an Besonderheiten36 über das kommende Projekt bekannt? Wie lässt sich das kommende Projekt im Kontext der Projekterfahrungen Ihrer Organisation klassifizieren37 (klein – groß; einfach – komplex; Standardtechnologien – Sondertechnologien)?

Aufgrund dieser Eckdaten gilt es nun, die notwendigen Mitarbeiter zu rekrutieren, soweit diese nicht bereits durch ein vorhandenes Projektteam 34

35

36

37

Je niedriger Sie den CMM-Level Ihrer Organisation einstufen, desto mehr Zusatzaufwände müssen Sie für Mitarbeiterqualifikation, Worst-Case-Vermeidung und Nachbesserungen jenseits des Projektendes vorhalten. Das Projekt an sich mag zunächst bei geringem CMM-Level sehr schlank erscheinen, jedoch ist in solchen Fällen dieser Schein meist sehr trügerisch! Die letzte Meile des Projektes wird hierbei nicht selten zum Kampf gegen Windmühlen, da Fehler und Probleme erheblich schneller neu aufbrechen, als offene Baustellen geschlossen werden. An dieser Stelle geht es darum, ob der Kunde nur „gute Software“ wünscht, die im Sinne der Nutzbarkeit ihre Ziele erfüllt, oder ob es Rahmenbedingungen gibt, die konkrete Anforderungen an den Entwicklungsprozess stellen. Handelt es sich um sicherheitsrelevante Software (etwa in der Medizin oder der Aeronautik) oder wird die Software durch einen öffentlichen Auftraggeber angefordert, so sind hier klare Vorgaben an den Entwicklungsprozess die Regel. Diese sind verbindlich anzuwenden. Unter Besonderheiten sind all solche Punkte zu verstehen, die bereits jetzt – also vor der eigentlichen Erhebung der Anforderungen – bekannt sind. Hierzu zählen Themen wie die enge Verflechtung mit anderen Anwendungen, unübliche technische Plattformen oder Programmierumgebungen, spezielle Forderungen an Qualität oder Arbeitsmethodiken. – Kurz: all das, was von Ihrem Standardrepertoir abweicht und Sonderaufwände bzw. Zusatzrisiken nach sich ziehen kann. Aufgrund der bis hierhin gesammelten Informationen ist es sehr wichtig, eine erste kontextuelle Projektklassifizierung vorzunehmen. Hierdurch wird ersichtlich, ob die zuvor ermittelten projektspezifischen Risiken sich noch einmal erhöhen, da z.B. die eigene Organisation in den letzten Jahren kein vergleichbar großes Projekt bearbeitet hat oder die geforderte Technologie bisher nicht im geforderten Maße angewendet hat.


vorgegeben sind. Dabei spielen nicht nur Fachkenntnisse eine wichtige Rolle, sondern es ist darauf zu achten, dass im Sinne der Ganzheitlichkeit und zukünftiger Teamperformance die nachfolgenden Punkte, wenn Sie Ihre Mannschaft als Ganzes im Blick haben, berücksichtigt werden: Checkliste Wie hoch ist das Maß an Erfahrenheit38 in der Gesamtorganisation wie auch bei den vorgesehenen Teammitgliedern? Sind die Fähigkeiten des geplanten Teams im Sinne der Belbin’schen Betrachtung einigermaßen gleichverteilt? Können Sie im Blick auf das Projekt fachlich alle Aspekte abdecken oder stoßen Sie auf Lücken? – Falls ja: Wie wollen Sie diese schließen? Sind Ihnen offene oder versteckte Konflikte zwischen zukünftigen Teammitgliedern bekannt und was werden Sie tun, um diese vor Projektanlauf zu entschärfen? Wie hoch ist die Bereitschaft der Einzelnen sich auf Neues aktiv einzulassen und ggf. lieb gewonnene Fahrwasser zu verlassen?

Spätestens jetzt ist es an der Zeit, sich für eine Entwicklungsmethode zu entscheiden und sich seitens des Projektmanagements festzulegen, in welchem Umfang bzw. in welcher Vollständigkeit dieser Prozess zur Anwendung kommen soll und welche Konsequenzen dies nach sich ziehen kann. Da kein Projekt wie das andere ist, muss bei dieser Grundsatzentscheidung das oberste Ziel darin bestehen, die Gesamtkomplexität von Aufgabe, Lösungsweg und Ergebnis so gering als irgend möglich zu halten. Andersherum gesprochen, zusätzliche Komplexität sollte am Punkt ihres Entstehens bekämpft werden. Dies hat zur Folge, dass sehr konkret über das für diesen speziellen Fall geeignetste Prozessmodell im Kontext der gesetzten Aufgaben und organisationsinternen Rahmenbedingungen entschieden werden muss! Auch wenn viele Organisationen sich dauerhaft auf ein Modell festgelegt haben, so sollte auch hier die dann allerdings eingeschränkte Frage nach dem für diesen Anwendungsfall effizientesten Projektmodell gestellt werden. (Falls Sie z. B. nach einem Unified Process arbeiten, so können Sie durchaus kleine Projekte mit verdichteter Rollenzahl bzw. stark zusammengefassten Dokumenten erfolgreich durchführen.) Tun Sie dies nicht in diesem sehr frühen Stadium des Projektes, so handeln Sie sich im Sinne der Komplexität zusätzliche „Freiheitsgrade“ ein, die das (Projekt-)Leben 38

Als Erfahrenheit ist hier nicht nur die Zahl der Berufsjahre zu werten und die Auflistung von Entwicklungswerkzeugen, technischen Vorgehensmodellen oder Programmiersprachen. Diese Dinge sind wichtig! Entscheidend ist hier ein Gesamteindruck der Person im Sinne der Ganzheitlichkeit!

210 7 Showdown

später unnötig verkomplizieren werden. Bei der Auswahl des geeigneten Prozessmodells sollten Sie sich verschiedene Fragen im Vorfeld gestellt haben, da sie hiermit klären können, welche Vorgehensweise Sie überhaupt sinnvoll leisten können: Checkliste Wie erfahren ist der Projektmanager selbst? (Agile Prozesse brauchen erfahrenere Projektleiter als nicht agile Prozesse.) Wie hatten Sie den CMM-Level für das eigene Haus definiert? (Ist der CMM-Level niedrig, so kann man keine Wunder vom kommenden Projekt erwarten!) In welchen Prozessmodellen haben die Projektmitarbeiter Erfahrungen? Welche Prozessmodelle sind mit der vorhandenen Infrastruktur überhaupt leistbar? Wie stark will der Kunde im Projekt beteiligt sein? Wünscht der Kunde ein abgeschlossenes Projekt oder eines, das anschließend fortgeschrieben wird? Gibt es einschränkende Faktoren im Sinne von geforderten Zertifizierungen oder vorgeschriebenen Arbeitsmodellen? Gibt es weitere Abhängigkeiten dieses Projektes – z. B. zu anderen internen Projekten, die Einfluss auf die Prozessentscheidung haben könnten? Welches sind Ihrer Meinung nach die Schlüsselrollen dieses Projektes? Können Sie die Schlüsselrollen mit ausreichend qualifizierten und erfahrenen Mitarbeitern besetzen?

Aus der Festlegung für ein Vorgehensmodell (= Prozessmodell) ergeben sich die notwendigen Rollen und spezifischen Vorgehensweisen, um die Software an sich zu bauen. Da über die einzelnen Prozessmodelle ausreichend Literatur existiert, werde ich auf diesen Teil nicht weiter eingehen, sondern verweise auf die entsprechenden Quellen. Wenn Sie sich jedoch einmal auf eine Vorgehensweise festgelegt haben, dann sollte es kein Zurück mehr geben. Daher ist es wichtig, sich vorher die Konsequenzen der geplanten Festlegung klar zu machen und nicht in reine Methodengläubigkeit zu verfallen. Somit ist eine Bewertung des ausgewählten Prozessmodells im projektspezifischen Bezugsrahmen an dieser Stelle unerlässlich. Dabei stehen diejenigen Fragen im Mittelpunkt, bei denen es darum geht, welche Konsequenzen, Risiken und Nebenwirkungen die gewählte Vorgehensweise auf den Gesamtkontext haben können und welchen Einfluss speziell die Auslassung bestimmter Teile der gewählten Vorgehensweise mit sich führen dürften. Hierzu ein paar zentrale Fragen, die dieser Bewertung nachgehen:


Checkliste Auf welche Teile des gewählten Prozessmodells wollen Sie verzichten bzw. welche Teile wollen Sie modifizieren? Warum? Wie können Sie die hieraus resultierenden Risiken ermitteln? Welche Konsequenzen wird ein ‚modifiziertes’ Prozessmodell gerade auf der letzten Meile haben39? Lässt sich das ausgewählte Prozessmodell überhaupt mit dem vorhandenen Team (Qualität und Quantität) realisieren40? Welches sind die Schnittstellen in die eigene Organisation und in welchem Maß ist auch hier die notwendige prozessuale Erfahrung gegeben? Werden Sie eher klassisch ingenieurmäßig arbeiten können (= relativ früher Abschluss der Anforderungserfassung) oder soll der Kunde möglichst lange im Projekt Änderungen und Ergänzungen äußern dürfen? Handelt es sich bei dem kommenden Produkt um ein Unikat oder ist mit einer Produktfamilie bzw. vielfacher Auslieferung zu rechnen? – Könnte dies Auswirkungen auf die Planungen nach Abschluss des Projektes haben – und welche sind dies? Wie viel Vorlauf braucht die eigene Organisation, um nach diesem Modell praktisch arbeiten41 zu können? Wie groß ist die gelebte Erfahrung bei den Teammitgliedern? Wie entwickelt ist das Qualitätsmanagement des eigenen Hauses, nach welchen Vorgehensweisen arbeitet man dort und sind die im Wunschprozess vorgeschlagenen Qualitätsüberwachungen in der eigenen Organisation realistisch? Wie entwickelt sind die Test- und Auslieferungsverfahren der Software in der eigenen Organisation und wie lassen sich diese Vorgehensweisen mit dem Prozess-Wunschkandidaten in Bezug setzen? – Wo ist mit Schwierigkeiten zu rechnen? 39 40

41

Methodisch betrachtet empfiehlt es sich hier, im Sinne eines Brainstormings mit anderen mögliche Spätfolgen im Projektverlauf durchzusprechen. Prozessmodelle mit viel Schreibarbeit und hohem wechselseitigem Controlling z. B. durch Reviews brauchen in der Phase der Softwareerstellung deutlich mehr Zeit als solche Modelle, die hierauf keinen so hohen Wert legen, sind aber im Sinne einer Lebenszyklus-Betrachtung effektiver. Daher muss durchgespielt werden, ob in der Erstellungsphase ausreichend Kapazität hierfür vorhanden ist, wenn Sie nicht Potemkin’sche Dörfer bauen wollen. An dieser Stelle geht es um Fragestellungen, die z. B. mit der organisationsweiten Einführung bestimmter Verfahren zu tun haben: Wenn Sie niemals „echtes“ Anforderungsmanagement im Einsatz hatten und dies nebenläufig unternehmensweit einführen möchten, so kostet dies eine ganze Menge Zusatzzeit außerhalb des eigentlichen Projektauftrags. Gleiches gilt, wenn Sie z. B. spezielle Versionierungswerkzeuge oder Prozessdokumentationswerkzeuge einführen wollen. Beides benötigt ebenfalls erhebliche Zusatzzeiten außerhalb des eigentlichen Auftrags.

212 7 Showdown Wie können Sie wechselnde Softwaretechnologien verhindern? Wie können Sie verhindern, dass es zu größeren Werkzeugwechseln kommt? Wie können Sie eine gute Kommunikation sicherstellen? Sind die Mitarbeiter entsprechend (Tools, Prozesse & Technologien) geschult?

Projektplanung ist eine Balance zwischen Beauftragung, Kreativität, Weitblick und der Berücksichtigung gegebener Rahmenbedingungen. Um diese Balance im Lot zu halten, reicht es nicht aus, nur auf die richtige Methode zur Erstellung von Software zu achten. Aus diesem Grunde sind weitere Themenschwerpunkte neben der rein prozessgetriebenen Sichtweise notwendig. Wenn Sie sich Abb. 7.2 anschauen, so werden Sie dort feststellen, dass bis hierhin von der Festlegung der Prozesse und Methoden wie auch ein wenig vom Team die Rede war. Alle anderen Aspekte wurden jedoch nicht weiter berücksichtigt. Ganzheitlicher Softwarebau ist – wie gezeigt – erheblich mehr als nur die Auswahl der richtig ausgebildeten Mitarbeiter und des korrekten Prozessmodells. Im Sinne der Projektvorbereitung ist es notwendig, über jeden der in der letzten Abbildung aufgeschlüsselten Bereiche und seine Abhängigkeiten zu

Abb. 7.2. Kernbereiche im optimalen Softwarebau


den jeweils benachbarten Themen Aussagen zu tätigen. Die Grafik leitet sich in ihren Kernaussagen von der „Lean Production“ ab und integriert moderne Ansätze des Software-Engineerings. Möglicherweise ergeben sich hieraus mittel- oder langfristige Konsequenzen für die Gesamtorganisation, die keineswegs im Rahmen des beschriebenen Projektes gelöst werden können, sondern sehr viel breiter berücksichtigt werden müssen. Dabei sind in den Randbereichen solche Themen zu finden, die zum einen direkt das aktuelle Projekt betreffen, zum anderen aber auch mittelfristige Grundsatzentscheidungen und -entwicklungen der Gesamtorganisation verlangen: Domaingetriebene Architektur und Bau. Kann Software so geplant und gebaut werden, dass sie mit erhöhtem Einsatz von Automaten aus Domainmodellen und deren entsprechenden technischen Repräsentationen gebildet werden kann42? Produktlinie. Kann die Software als Teil einer Produktstrategie des eigenen Hauses betrachtet werden und wurden hierfür (rechtzeitig) strategische wie auch praktische Konsequenzen abgeleitet, die eine hohen wenn auch adaptierte Mehrfachnutzung gestatten? Anforderungen und Beratung. Kurz gesprochen: Werden bei Ihnen noch primär Kundenwünsche eingesammelt und hieraus Anforderungen abgeleitet oder findet ein beratender kontinuierlicher Dialog zwischen dem Entwicklungsteam und dem Auftraggeber statt? Vermeidung von Redundanzen. Eine der Kernfragen, die im Verlauf des Projektes regelmäßig neu gestellt werden sollte, betrifft die Vermeidung unnützer Aufwände bzw. ineffizienter Arbeitsmethoden. Hierzu ein paar Beispiele: Wie kann die Arbeitsweise des Projektteams in seinen unterschiedlichen Rollen so gestaltet werden, dass Redundanzen an Arbeiten, Inhalten oder Strukturen vermieden werden? Oder: Welchen allgemeinen Konstruktionsrichtlinien muss das Produkt folgen, damit es in die eigene Produktlinie hineinpasst (falls dies der Auftrag zulässt)? Es ist sinnvoll, diese Themenbereiche zunächst in Verbindung mit dem kommenden Projekt zu betrachten, um danach die notwendigen projektübergreifenden Konsequenzen zu kommunizieren. 42

Zur Erinnerung: Je höher der Einsatz von Softwaregeneratoren ist, desto fehlerfreier können diese Softwareanteile generiert oder verändert werden. (Vorraussetzung ist natürlich, dass der Generator korrekt funktioniert und das Domainmodell richtig ist.) Grundsätzlich gilt, dass händische Bearbeitung von Code fast immer fehlerträchtiger ist, als automatische Coderegenerierung.

214 7 Showdown

7.4 Projektbeginn Da die einzelnen Prozessmodelle sehr unterschiedlich strukturiert sind und jeweils eigene Vorgehensweisen postulieren, soll es an dieser Stelle nur um solche Punkte gehen, die in der Praxis leicht vernachlässigt werden. Durch die getroffene Festlegung auf ein spezifisches Vorgehensmodell (RUP, V-Modell, Xtreme etc.) laufen projektintern die Wege deutlich auseinander und es macht wenig Sinn, dem jeweils ausgewählten Prozessmodell noch gute Ratschläge überzustülpen. – Wichtige Punkte, die im Umfeld der eigentlichen Arbeitsmethodik von Bedeutung sind, die also neben dem anlaufenden Projekt Aufmerksamkeit und Steuerung brauchen, sind in der folgenden Liste zusammengestellt:

Checkliste Rollen festlegen: Wer sind die Stakeholder, Team auswählen bzw. festlegen / Schlüsselrollen verteilen. Stakeholder-Analyse43: Welches sind die wichtigsten Erwartungen Ihrer Projektstakeholder? Wie können Sie ihnen gerecht werden? Und wie können Sie diese Stakeholder hierüber auf dem Laufenden halten? Wie können Sie das Zusammenwachsen des Teams aktiv unterstützen (neu zusammengesetzte Teams brauchen eine Findungsphase, die Zeit kostet)? Soziale Kontrolle44 – Welche Faktoren haben zu diesem Zeitpunkt positiven oder negativen Einfluss auf das Projekt? Wie soll mit dem Umfeld um das eigentliche Projekt herum kommuniziert45 werden? Sind die Mitarbeiter so ausgebildet, dass sie in ihre Überlegungen auch zukünftige Entwicklungen einbeziehen? Der Aufbau einer auch über das Projekt hinausreichenden effizienten Dokumentenstruktur samt Mechanismen zur eindeutigen und schnellen Wiederauffindung von Informationen ist zu planen.

43 44

45

Nur wenn Sie Ihre Stakeholder genau analysiert haben, werden Sie wissen, was deren Erwartungshorizont in Bezug auf das anlaufende Projekt ist. In den Bereich der sozialen Kontrolle gehört im Besonderen auch die Einstellung einzelner Personen und Personengruppen zu diesem Projekt. Hier kann durch gezielte Gespräche oder andere Maßnahmen die Haltung der Betroffenen zum Projekt (hoffentlich) zum Positiven verändert werden. Gerade durch Kritiker und Skeptiker kann andernfalls nicht unerheblicher Schaden im Projekt entstehen. Software ist ein Abstraktum – und wenn nicht aktiv nach Wegen der Außenkommunikation gesucht wird, werden „Flurgerüchte“ und Ammenmärchen die Runde über das laufende Projekt machen – und dies nicht immer in einer für das Projekt zuträglichen Form.

7.4 Projektbeginn 215 Wie kann durch geeignete Technik wie auch prozessuale und strukturelle Maßnahmen sichergestellt werden, dass eine Informationsredundanz46 innerhalb der entstehenden Dokumente vermieden wird? Wie kann eine möglichst hohe Automatisierung des Prozessablaufs mit wenigem Mehraufwand erreicht werden? Wie lassen sich die Zulieferer integrieren und steuern? – Welche Stärken und Schwächen sind hier bekannt? Wie kann erreicht werden, dass konstant nach Vereinfachungen in Bezug auf die Lösung und auch die Arbeitsweisen gesucht wird und diese nach entsprechender Prüfung übernommen werden? Was muss planungstechnisch getan werden, um zu einer hohen Nutzbarkeit der kommenden Software zu gelangen?

Es empfiehlt sich, dass Sie (in der Rolle des Projektmanagers), speziell bei größeren oder komplexeren Projekten, nach Wegen suchen, wie Sie das Projektteam mit der fachlichen Thematik aus Kundensicht frühzeitig vertraut machen. Methodisch bieten sich hierzu unterschiedliche Möglichkeiten an, z. B. im Rahmen eines etwas längeren Workshops sich von Experten, evtl. auch dem Auftraggeber, über dessen Arbeit im Kontext mit der geplanten Software berichten zu lassen. (Hierbei geht es nicht um die Erfassung der Anforderungen, sondern darum, dass das eigene Team inhaltlich versteht, worum es geht!) Ganzheitliche Vorgehensweisen, die möglichst starke Ideen oder Sinneseindrücke bei dem Team hinterlassen, sind dabei effektiver als lange, rein technische Vorträge oder die klassischen Werbepräsentationen des Auftraggebers. – Worum es in dieser frühen Phase des Projektes in Bezug auf das eigene Team geht, besteht darin, die Fantasie und Kreativität der Mitarbeiter anzustoßen oder um es anders zu formulieren: Zu diesem Zeitpunkt ist „Spinnen“ Pflicht. Entsprechend dem gleichnamigen Buchtitel von A. Meyer-Grashorn (Meyer-Grashorn 2004) geht es in dieser Phase noch nicht um ingenieurmäßige Lösungen. Hier ist die Interaktion zwischen Hersteller und Kunden gefragt. Hier gilt es zu planen, zu fantasieren und damit zu optimieren. Wenn Sie an das Kapitel über systemisches Denken und Handeln (S. 89 ff.) zurückdenken, so wurde dort genau dieser Mechanismus als eine wichtige Optimierungs- und Vereinfachungsgröße vorgestellt. Dies ist die Phase, in der mentale „Papiermodelle“ und fantastische Entwürfe entstehen dürfen und auch wieder verworfen werden. Die Frage nach dem theoretisch Machbaren, wie auch nach scheinbar utopischen Lösungen, muss hier erlaubt sein. Wenn 46

Spätestens an dieser Stelle ist es notwendig, sich Strategien überlegt zu haben, wie im anlaufenden Projekt verhindert werden kann, dass Informationen häufiger als an einer Stelle dokumentiert werden. Die Klärung dieser Frage ist in vielen Fällen keineswegs trivial und bedarf eigener Planungsaktivitäten.

216 7 Showdown

Sie in der Lage sind, dies im Beisein mit einem entsprechend darauf vorbereiteten Kunden und dessen Expertise zu durchlaufen, so ist dies eine hervorragende Möglichkeit, Kundenprobleme und Lösungungsmöglichkeiten einander annähern zu lassen. – Allerdings ist hierbei wichtig, dass der Kunde klar wissen muss, dass an dieser Stelle keine verbindlichen Anforderungen aufgenommen werden, sondern mögliche Lösungshorizonte andiskutiert werden. Auch für den Kundenrepräsentanten kann solch an Ansatz von großer Bedeutung sein, da der eigene Lösungshorizont und die Vorstellungen, wie man das Problem gelöst sehen wollte, durch möglicherweise andere Optionen neu bewertet werden kann. Um so ein Szenario Wirklichkeit werden zu lassen, bedarf es allerdings einer sehr guten und erfahrenen Moderation, da sich andernfalls viele Beteiligte sofort in Teilproblemen eingraben werden. Zum Ende dieser Phase sollte als wichtigstes Artefakt ein „VisionDokument“ durch den Projektmanager erstellt und mit dem Kunden abgestimmt worden sein. Es enthält die Kernthemen des anlaufenden Projektes, jedoch keine technischen Lösungsvorschläge. Hintergrund für dieses Dokument ist zweierlei: Zum einen kann auf diese Weise sichergestellt werden, dass der Auftraggeber tatsächlich das Gesamtproblem des Kunden verstanden hat, zum anderen hilft es später, die Außengrenzen des eigentlichen Projektauftrags festzulegen. In Anlehnung an die Lean-Production lohnt es sich, die dort formulierten Kernaussagen jetzt zu etablieren und für den Rest der Projektlaufzeit zum Standard des Teamhandelns werden zu lassen: Checkliste Suche nach Möglichkeiten, das Unmögliche möglich zu machen. Ausreden und Entschuldigungen lösen keine Probleme, daher sind sie unnötig. Suche einfache Lösungen, aber keine perfekten. Benutze Deine Fantasie und nicht Deinen Geldbeutel. Probleme sind Chancen. Hinterfrage alles. Suche die Ideen vieler Menschen. Du darfst Dein gewohntes Denken aufgeben. Denke immer in Lösungen und nicht in Problemen. Stelle all Dein bisheriges Tun und dessen Erfolge in Frage. Es gibt keine perfekte Lösung, deshalb suche die naheliegendsten Verbesserungen. Melde und korrigiere Fehler sofort, sonst vermehren sie sich im Nu. Suche die Ursache für den Fehler. Suche auch dann nach Verbesserungen, wenn keine offensichtlichen Fehler vorliegen. Im Team Fehler zu finden ist bei weitem einfacher! Verbesserung ist ein kontinuierlicher Prozess ohne Ende.

7.5 Projektumsetzung 217

7.5 Projektumsetzung Inzwischen ist die Projektumsetzung in vollem Gange und je nach ausgewähltem Prozessmodell wird diese Arbeit iterativ, phasenabhängig oder auch in gewissem Maße linear ablaufen. Das vom Projektmanagement ausgewählte Prozessmodell und die hiermit verbundene Dokumentation wird auf viele voneinander abhängige Vorgehensweisen eingehen, um Anforderungen, Entstehung der IT-Architektur, Aufbau eines entsprechenden Testmanagements bzw. die Überwachung der Qualität zu regeln. Die nachfolgende Liste wird sich daher nicht mit diesen Aspekten befassen, sondern solche Punkte herausgreifen, die immer wieder am Rande liegen bleiben und dadurch die Effizienz der Projektarbeit einschränken können. Checkliste Wo steht der Teambildungs-Prozess und welche Schritte müssen Sie tun, um sich langsam in Richtung eines effizienten Teams zu bewegen? Wie kann konstant die Automatisierungsquote47 erhöht werden, ohne vorher gigantische Planung zu betreiben und ohne hierdurch das Projekt zu verzögern, wenn an zwei Stellen parallel an demselben Thema gearbeitet wird? Welches sind die Hauptrisiken und welche davon sind am größten und wahrscheinlichsten? – Bekämpfen Sie die Hauptrisiken zeitnah. Wo sind die aktuellen Flaschenhälse48 – welches ist dabei der größte und was tun Sie jetzt konkret, um diesen Flaschenhals zu weiten? Welches sind die größten „Feinde“ des Projektes außerhalb der eigenen Projektmannschaft? Achten Sie darauf, dass niemand von der Papierarbeit erschlagen wird, zugleich aber alle wichtigen Dinge zeitnah und vollständig dokumentiert sind. Prozesse sind zur Unterstützung der Arbeiten da – wie effizient sind die eingesetzten Prozesse und wo werden Dinge mitgeschleppt, die Zeit kosten, aber keinen Wert haben? Nutzen Sie Tools, um alle Teilaufgaben und deren Fortschritt im Blick zu haben, aber werden Sie nicht toolgläubig! 47

48

Reduktion der Handarbeit wo immer möglich: Menschen können denken, aber machen Fehler. Maschinen hingegen können sehr schnell und sehr präzise bestimmte Prozesse immer und immer wiederholen! – Aus diesem Grunde ist es sinnvoll und notwendig, sich immer wieder neu zu fragen, wo Handarbeit als Kostenfaktor reduzierbar ist und durch Automaten abgelöst werden kann. – Nicht nur, dass hierdurch dauerhaft die Effizienz gesteigert wird, nein gleichzeitig geht die Gesamtfehlerrate auch nach unten, da der „Human factor“ schrittweise zurücktritt! Flaschenhälse nicht aufzubohren heißt Ressourcen zu vergeuden, da genau hier die für das Projekt am meisten limitierenden Faktoren liegen.

218 7 Showdown Kennen Sie die größten Probleme in jeder einzelnen Disziplin? Vermeiden Sie Parallelwelten – wenn an zwei Stellen parallel an demselben gearbeitet wird, so können sehr leicht Redundanzen entstehen! Überwachen Sie Ihre Zulieferanten konstant, ganzheitlich und gründlich. Kennen Sie diejenigen Dinge, die Ihr Projekt zum Stoppen bringen können. Haben Sie die letzte Meile des Projektes im Blick und fangen Sie bereits jetzt an, notwendige Planungen hierfür anlaufen zu lassen. Denken Sie über die Ausreifung des Produktes nach. Wie soll die Güte der kommenden Software gemessen werden? Falls die Software als Produktionsmittel eingesetzt werden soll, so ist hier mit der Produktionsplanung zu beginnen49. Ungewartete Software wird verwildern, daher muss jetzt damit begonnen werden, Wartungsstrategien zu entwickeln und diese Vorgehensweisen zu planen50.

7.6 Die Ausreifungsphase In vielen Fällen des Alltags wird so geplant, als sei neu gebaute Software mit der Umsetzung des letzten Usecases und der Fertigstellung der entsprechenden Dokumentation quasi fertig und könne ausgeliefert werden. Wenn Sie sich an Kap. 4.4, S. 124 ff. zurückbesinnen, so war dort von einer infantilen und einer juvenilen Phase die Rede. Die infantile Phase ist

49

50

Vielfach wird Software als Produktionswerkzeug eingesetzt, etwa indem eine Layoutsoftware gebaut wird, mit deren Hilfe die speziellen Datenausgabestrukturen für die eigentlichen Kunden individuell entwickelt werden. In solchen Fällen wird die entstehende Software wie eine Maschine in einer Fabrik eingesetzt. Die Einplanung dieses Produktionsmittels, die rechtzeitige Vorbereitung einer geeigneten Infrastruktur um diese Software wie auch die rechtzeitige Ausbildung der Bedienungsmannschaft sind hier einige wenige Aspekte, die sehr früh in eine eigene Planung übernommen und auf die werdende Software abgestimmt werden müssen. Da Software ein extrem schnell alterndes Gut darstellt, ist es notwendig, bereits aus der Bauphase heraus Strategien festzulegen und auch mit den Projektsponsoren abzustimmen, die unnötig teure spätere Reengineering-Arbeiten zumindest deutlich einschränken. Ob dies nun im Sinne des klassischen Refactorings geschieht oder durch regelmäßige Überwachung und ggf. softwaretechnische Nachführung auf aktuelle Versionen von „Third-Party“-Komponenten ist projektabhängig oder auch Geschmackssache. Entscheidend ist, dass hierüber nachgedacht und geklärt wird, wie mit den hierdurch entstehenden konstanten Aufwänden zu verfahren ist.

7.7 Produktionsbetrieb 219

identisch mit der Umsetzungsphase aus dem letzten Abschnitt, die juvenile Phase bezieht sich auf die eigentliche Ausreifung des Programms. Allein die Tatsache, dass Software stabil läuft und im Sinne der Anforderungen vollständig ist, macht sie noch nicht unbedingt zu einem Güteprodukt. Wurden z. B. nur die aufgestellten Anforderungen ingenieurmäßig korrekt und vollständig umgesetzt, so erfüllt das Softwareprodukt die gestellten Anforderungen, dürfte aber in vielen Fällen für den Anwender funktional korrekt, jedoch eher fade erscheinen. Selbst wenn man den idealsten aller Fälle unterstellt, nämlich dass die Software mit Hilfe eines äußerst guten Test- und Qualitätsmanagements nur noch sehr wenige Fehler aufweist, so treten erst beim Umgang mit ihr diejenigen Dinge zutage, die eine Software braucht, um in vollem Umfang praxistauglich zu werden. Ähnlich wie bei Autos oder auch Flugzeugen sollte daher ganzheitlicher Softwarebau nicht nur auf die Beseitigung von Softwarebugs achten, sondern unter Gesichtspunkten der Praxistauglichkeit und Nutzungseffizienz ausreifen dürfen. Hier also gilt es, die Usability des Produktes zu validieren und ggf. nachzubessern. Wenn Sie zu Abb. 5.1 auf S. 129 zurückgehen, so ging es dort um Dinge, die ein Kunde als Selbstverständlichkeiten von einer Software erwartet. Davon alleine ist die Applikation jedoch noch nicht herausragend.

7.7 Produktionsbetrieb Der allerletzte Schritt betrifft die Überführung der Software in das wirkliche Leben. Es geht nicht mehr um Fehler im Code oder technische Dokumentationen, sondern darum, dass das entstandene Produkt in eine geplante Infrastruktur eingebettet sein muss – soweit diese nicht schon generell vorhanden ist. Bereits in Kap. 7.5 war von entsprechenden Vorwegplanungen die Rede gewesen. An dieser Stelle möchte ich in einer finalen Liste einige bedenkenswerten Aspekte zusammentragen, die bis zu diesem Zeitpunkt bedacht und fertig geplant sein sollten.

220 7 Showdown

Checkliste Wollen Sie die Software im Rahmen eines standardisierten Betreibermodells (z. B. ITIL51) einsetzen? Nach welchen Mechanismen soll die Software weiterentwickelt werden und in welcher Weise soll dies im Kontext mit der eigenen Produktstrategie stehen? In welchem Maß und wie soll der Kunden-Support für dieses konkrete Produkt aussehen? Wird die entwickelte Software in Bereichen mit hohen Sicherheitsanforderungen bzw. Verfügbarkeiten eingesetzt, so müssen Vorgehensweisen für Betriebsstörungen organisiert sein. Wie ist mit wartungsbedingten Pausen zu verfahren? Wie ist mit den durch das Programm generierten Daten auch im Sinne der Datensicherung zu verfahren? Wie lässt sich für die Kunden ein gewisser Investitionsschutz aufbauen? Nach welchem Betreibermodell soll die Software weiterentwickelt werden (z. B. Aboservice für automatische Patches und Releases oder aktiver Erwerb von Upgrades mit deutlichen funktionalen Änderungen)? Feedback-Mechanismen sind einzurichten, um rechtzeitig und schnell auf Fehler oder Unregelmäßigkeiten zu stoßen. Wie viele und welche Entwickler sollen weiterhin für die Produktbetreuung vorgehalten werden?

51

ITIL ist ein Vorgehensmodell aus Großbritannien und deckt die Bereiche: Service Support, Service Delivery, Security Management, Application Management, IT Infrastructure Management und Supply Chain Management ab. Kurz: Die Entscheidung für solch ein Modell an dieser Stelle deckt – wenn es etabliert ist – alle wesentlichen Aspekte für den Produktivbetrieb der Software ab.

Epilog

Die Wahrheit triumphiert nie, ihre Gegner sterben nur aus. (Max Planck) Es lebte einmal ein sehr armer, alter Mann in einem Dorf. Er besaß das schönste Pferd der ganzen Gegend, auf das viele neidisch waren und mit dem er eine fast freundschaftliche Beziehung pflegte. Eines Morgens war das Pferd verschwunden. Die Nachbarn kamen und machten ihm Vorwürfe: „Wir wussten schon längst, dass das so nicht gutgehen kann. Dein Pferd wurde gestohlen – du hättest schon auf uns hören und es verkaufen sollen.“ Dem alten Mann ging dies zu weit. Er sprach: „Es ist richtig, dass mein Pferd nicht im Stall ist, aber ich kann nicht beurteilen, ob dies von Nutzen oder Schaden für mich ist!“ Daraufhin verlachten ihn seine Mitbewohner, gingen ihrer Wege und verstanden ihn nicht. Zwei Wochen später geschah das Unglaubliche: Das Pferd kehrte zurück, begleitet von einem Dutzend wilder Pferde. Erneut kamen die Dorfbewohner, um dem Mann zu seinem überraschenden Glück zu gratulieren. Wiederum sprach dieser: „Es ist richtig, dass mein Pferd wieder da ist und zwölf Wildpferde es begleitet haben, aber ich weiß nicht, ob dies von Nutzen oder Schaden für mich ist!“ Daraufhin verlachten ihn seine Mitbewohner, gingen ihrer Wege und verstanden ihn nicht. Der einzige Sohn des alten Mannes begann die Pferde einzureiten. Sehr rasch kam es zu einem Missgeschick, er fiel von einem der Pferde und brach sich die Beine. Die Dorfbewohner kamen, um den alten Mann und seinen Sohn zu trösten. Dieser aber sprach: „Es ist richtig, dass sich mein Sohn verletzt hat, aber ich kann noch nicht beurteilen, ob dies von Nutzen oder Schaden für mich ist!“ Daraufhin verlachten ihn seine Mitbewohner, gingen ihrer Wege und verstanden ihn nicht. Bald danach kam Krieg über das Land und alle jungen Männer wurden eingezogen – nur einer nicht … (Frei nacherzählt aus: (Peseschkian 1979)) Ich wünsche Ihnen, dass Sie sich nicht durch Kollegen oder Vorgesetzte irritieren lassen, die tote Pferde reiten wollen und Ihre eigenen Vorgehensweisen nicht verstehen und deshalb in Frage stellen. Wenn es Ihnen trotz aller Unkenrufe möglich ist, Software so zu bauen, dass sie auch übermorgen noch den Kundenwünschen entspricht und der eigenen Organisation

222 Epilog

die erhofften Ergebnisse beschert, so geht es Ihnen wie dem alten Mann, dessen Weisheit und Geduld ihm dabei halfen, sein „Baby“ als einziger erfolgreich behalten zu können. Viel Erfolg Ihr Patrick Hamilton

Quellenübersicht

Ashby, R. (1974). Einführung in die Kybernetik. Frankfurt, Suhrkamp. Atlee, T. (2003). Is Collective Intelligence Like Individual Intelligence? The Co-Intelligence Institute. Atlee, T., J. Lynn et al. (2003). The Tao of Democracy: Using Co-Intelligence to Create a World That Works for All. Writers' Collective. Baguley, P. (1999). Optimales Projektmanagement. Niedernhausen/Ts., Falken Verlag. Baumgartner, P. (1993). Der Hintergrund des Wissens. Vorarbeiten zu einer Kritik der programmierbaren Vernunft. Klagenfurt, Kärntner Druck- und Verlagsgesellschaft. Belbin, R. M. (1996). Team Roles at Work. Oxford, Butterworth-Heinemann. Bennis, W. und P. W. Biederman (1998). Geniale Teams, das Geheimnis kreativer Zusammenarbeit. Frankfurt/Main, Campus Verlag. Berne, E. (1999). Spiele der Erwachsenen. Hamburg, Rowohlt Taschenbuch Verlag. Brooks, F. P. (1995). The Mystical Man Month. Essays on Software Engineering. New York, Addison-Wesley. Clark, A. (1998). Being There: Putting Brain, Body, and World Together Again. Cambridge, Mass., MIT Press. Conrad, B., B. Jacob et al. (2003). Konflikt-Transformation, Konflikte werden gelöst – Unterschiede bleiben. Paderborn, Junfermann Verlag. deBono, E. (2000). Six Thinking Hats. London, Penguin Books Ltd. deBono, E. (2005). De Bonos neue Denkschule. Kreativer denken, effektiver arbeiten, mehr erreichen. Heidelberg, mvg-Verlag. DeMarco, T. (1997). Der Termin – Roman über Projektmanagement. München, Wien, Carl Hanser Verlag. DeMarco, T. (2001). Spielräume, Projektmanagement jenseits von Burn-out, Stress und Effizienzwahn. München, Wien, Carl Hanser Verlag. Dijkstra, E. W. (1972). The humble programmer. Commun. ACM. 15: 859-866. Dörner, D. (2006). Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Reinbek, rororo. Dueck, G. (2001). Die Beta-inside-Galaxie. Heidelberg, Springer-Verlag. Dueck, G. (2005). Topothesie – Der Mensch in artgerechter Haltung. Heidelberg, Springer-Verlag. Dutke, S. (1994). Mentale Modelle: Konstrukte des Wissens und Verstehens. Göttingen, Verlag für angewandte Psychologie. Eiffert, S. D. (2001). Eine Gehirnhälfte ist nicht genug. Landsberg/Lech, Moderne Verlagsges. Mvg. El Baze, N. (2005). Cracking Software Development Complexity, www.line56.com. Fowler, M. (2005). Refactoring. Oder wie Sie das Design vorhandener Software verbessern. München, Addison-Wesley.

224 Quellenübersicht Fukushima, K. (1987). A neural network model for selective attention in visual pattern recognition and associative recall. Applied Optics Nov. Fuller, G. (2000). Win-Win-Management – Führen mit Gewinn. Landsberg/Lech, mvgverlag moderne industrie. Gardner, H. (2000). Intelligence Reframed: Multiple Intelligences for the 21st Century. New York, Basic Books. Gerok, W. (1989). Ordnung und Chaos in der unbelebten und belebten Natur. Stuttgart, Wissenschaftliche Verlagsgesellschaft mbH. Gigerenzer, G. (2000). Adaptive Thinking: rationality in the real world. Oxford, New York, Oxford University Press. Grochowiak, K. und J. Castella (2002). Systemdynamische Organisationsberatung, Carl-Auer-Systeme Verlag. Grün, A. (2003). Führen mit Werten. München, Olzog Verlag. Grundmann, M. (2005). A CMMI Maturity Level 2 assessment of RUP. The Rational Edge, IBM Rational. 12/2005. Hamilton, P. (1995). Neuronale Experimente. Offenbach, Berlin, VDE Verlag. Katzenbach, J. R. und D. K. Smith (2003). Teams – der Schlüssel zur Hochleistungsorganisation. Frankfurt, Wien, Redline Wirtschaft bei Ueberreuter. Kirchner, B. (2001). Benedikt für Manager – die geistigen Grundlagen des Führens. Wiesbaden, Dr. Th. Gabler Verlag. Larman, C. (2004). Agile & Iterative Development – A managers guide. Boston, Pearson Education. Latniak, E. und A. Gerlmaier (2006). Zwischen Innovation und täglichem Kleinkrieg. Zur Belastungssituation von IT-Beschäftigten. Gelsenkirchen, Wissenschaftszentrum NRW, Institut Arbeit und Technik: 10. Leman, K. und B. Pentak (2004). Das Hirtenprinzip. Gütersloh, Gütersloher Verlagshaus GmbH. Marr, D. (1983). Vision. New York, Henry Holt & Company. Maxwell, J. C. (2002). Charakter und Charisma. Gießen, Brunnen Verlag. Meyer-Grashorn, A. (2004). Spinnen ist Pflicht. Augsburg, mvg-Verlag. n.n. (2002). The next Big Thing on the Software Horizon. Thing Tank Session, The Silicon Valley World Internet Center. n.n. (2003). Pferdehintern und Spaceshuttle, Living Universe Foundation e.V. Nonaka, I. und H. Takeuchi (1995). The Knowledge-Creating Company. How Japanese Companies Create the Dynamics of Innovation. Oxford, New York, Oxford University Press. Nothdurft, M. (2000). Im Team an die Spitze: Handbuch für Teamarbeit. Offenbach, GABAL Verlag. Nystedt, S. und C. Sandros (1999). Software Complexity and Project performance. Dept of Informatics. Gothenburg, Sweden, School of Economics and Commercial law: 118. Peseschkian, N. (1979). Der Kaufmann und der Papagei. Frankfurt/Main, Fischer Taschenbuch Verlag GmbH Poppendieck, M. (2003). Lean Development Software. An Agile Toolkit for Software Development Managers. Boston, Addison-Wesley. Putnam, L. H. (2000). Linking the QSM Productivity Index with the SEI Maturity Level, Quantitative Software Management Inc., MacLean, VA. Rainwater, J. H. (2003). Katzen hüten. Bonn, mitp-Verlag.

Quellenübersicht 225 Ratey, J. J. (2003). Das menschliche Gehirn: eine Gebrauchsanweisung. Düsseldorf, Zürich, Walter Verlag. Rifkin, S. (2001). Climbing the SEI CMM Makes a Difference on Software Projects. IT Metrics Strategies, The Cutter Consortium Rush, M. (1992). Die Persönlichkeit des Managers. Asslar, Verlag Klaus Gerth. Schulz von Thun, F. (1981). Miteinander Reden – Störungen und Klärungen. Reinbek, rororo. Schulz von Thun, F. (1989). Miteinander Reden – Stile, Werte und Persönlichkeitsentwicklung. Reinbek, rororo. Schulz von Thun, F. (1998). Miteinander Reden – Das „Innere Team“ und situationsgerechte Kommunikation. Reinbek, rororo. Schütz, P. (2005). Grabenkriege im Management – wie man Bruchstellen kittet und Abteilungsdenken überwindet. Frankfurt, Wien, Wirtschaftsverlag Carl Ueberreuter. Seckel, A. (2004). Große Meister der optischen Illusionen. Wien, Tosa Verlagsgesellschaft. Senge, P. M. (1994). The fifth discipline: the art and practice of the learning organization. New York, Currency Doubleday. Singer, W. (2006). Ein neues Menschenbild? Gespräche über Hirnforschung. Frankfurt, Suhrkamp. Versteegen, G. et al. (2003). Software Management – Beherrschung des Livecycles. Heidelberg, Springer-Verlag. Wegener, F. (2001). Memetik. Der Krieg des neuen Replikators gegen den Menschen. Gladbeck, KFVR – Kulturförderverein Ruhrgebiet e.V. Weiss, L. (2000). Erfolg trotz Ehrlichkeit. Landsberg/Lech, Verlag moderne Industrie. Wheeler, G. (2006). Jenseits des Individualismus, Für ein neues Verständis von Selbst, Beziehung und Erfahrung. Wuppertal, Peter Hammer Verlag. Womack, J. P. und D. T. Jones (2005). Auf dem Weg zum perfekten Unternehmen. München, Heyne Verlag. Womack, J. P., D. T. Jones et al. (1991). The machine that changed the world: the story of lean production. New York, Harper Perennial.

Index

A Airbus 19 Anforderungen nichtfunktionale 130 Apollo-Syndrom 186 Architektur Informations- 91, 131 Artefakt 57, 63 ASD 80 Ashby, Ross 90 Atlee, Tom 192 Autismus 19 Automatisierung 91

B Belbin, Meridith 182 Berne, Eric 70, 156 Best Practices 5, 44, 77, 168, 199 Boehm, Barry W. 45, 73 Brooks, Fred 29 Burnout 161

C CMM 43 Cockburn, Alistair 80 Commonalities 85 Computer ENIAC 60 UNIVAC 61 Corpus Callosum 115 Crystal 80

D da Vinci, Leonardo 116 Dawkins, Richard 123

de Rosnay, Joel 111 deBono, Edward 100 Deming Zyklus 113 Denken analytisches 112 Gruppen- 117 kreatives 100 laterales 100 lineares 92 synthetisches 112 systemisch 108 vertikales 100 Development Rapid Application 80 Dijkstra, Edsger 64, 104 Disney, Walt 173 Di-Stress 163 Dokument Vision- 138 Domain Struktur 32 Wissen 17, 132

E Eclipse-Plattform 23 Einstein, Albert 116 El Baze, Nicolas 119 Elegance Creeping 31 Emergenz 119, 180 Enterprise Architecture 148 Entropie 122 Epipyten 67 Eu-Stress 163 Extreme Programming 79

228 Index

F Featurism Creeping 31 Fehler 3. Art 92 systematische 57 Verkettung 117 Vermeidung 134 Fehlerfortpflanzungsgesetz 12 Fehlerkosten 10er-Regel 25 Fehlerkostenregel 46 Forrester, Jay 108 Freeware 32 Freud, Siegmund 167

G Geheimnisprinzip 35 Gesetz Ashbys 90 Brooks’sches 29 Fehlerfortpflanzungs- 12 Moore’sches 119 Nathans 119 Glossar 56 Google 170 Gruppendenken 117 GUI 38

H Hemisphärentheorie 115 Hippokrates 114 Hochleistungsteam 84 Holberton, Betty 61 Holismus 134 Hollywood-Syndrom 190 Hurry Sickness 161 Hypothese reduktiv 94

I IDE Eclipse 23 IN3 3

Indeterminismus 120 InformationsArchitektur 38, 91 Redundanz 33 Informavor 50 Intelligenz 192 künstliche 50 IT-Architekt 52

J Java 2, 120 Johnson-Laird, Philip N. 99

K Kaizen 150 Kausalkette 92, 109 Kay, Alan 63 Kognitionswissenschaft 50 Kognitionswissenschaften 179 Kollaboration 180 Komplexität Detail- 111 dynamische 92, 111 Netzwerke 147 Komplexität-Formen 53 Komplexitäts Transformation 48 Komplexitätsmaß 90 Kopplung lose 22, 31 Kritikalität 81

L Landkarte kognitive 99 Lean Production 142 Thinking 118 Lean Production 143 Lean Thinking 118 Legosteine 18 Locke, John 155 Logik 155 Luther, Martin 4

Index 229

M

N

Performance Software 31 Persönlichkeitsstruktur 153 PMBOK 145 Productline Engineering 85 Produktlinie 17 Project-Charter 207 Projekt Steeringboard 139 Turnkey 130 Vereinbarung 34 Projektdokument Glossar 56 Projektmanagement holistisches 5 Projektsponsor 139 Projektvertrag 202 Provokation mentalen 101 Prozess agiler 78 Prozessmodell agile 78 Crystal 80 iterativ-inkrementell 56 RUP 77, 168 SCRUM 79 Pseudoteam 187

Nernst, Walther 122 Nicht-Linearität 120

R

Management Anforderungs- 69 Automatisierungs- 149 Content 56 Wissens- 39 Manager Konflikt- 177 Manifest agiles 78 Marr, David 50 Mediator 177 Mem 123 Mensch-Maschine-Schnittstelle 38 Modell agiles 78 CMM 43 Mentales 99 Scrum 79 Spiral- 76 Unified 77 Wasserfall 75 Moore, Gordon 119 muda 143 Myhrvold, Nathan P. 119

O Offshoring 57 Ohno, Taiichi 118, 142 Ontologien 65, 199 Operation Refactoring 152 Organisation lernende 39

P Parnas, David 35, 122 Pattern Refactoring 152

Rapid Application Development 80, 148 Rapid Architecture 65 Refactoring 24, 31 RUP 44

S Schulz von Thun, Friedemann 71 Slobby 163 Softskills 19 Software Collaboration-Tools 56 Krise 64 Lifecycle 4 Stack 32

230 Index

Software Development adaptive 80 Software-Engineering 63 Softwarekrise 64, 121 Sperry, Roger 115 Stakeholder 102, 103 Interview 137 Stückkosten 5 SWEBOK 145 Systemanalyse 92

T Taxonomie 34, 109 Taylorismus 171 Team internationale 73 Team Thinking 189 Teamdynamik 84 Teamfähigkeit 45 Teamkultur 70 Teamsoftware 180 Testen automatisiertes 149 Theorie Eisberg- 167 Time Life Balance 162 TQM 133 Tracebility 34 Transaktionsanalyse 156 Transformation Konflikt- 70 Trouble-Ticket 25, 54 Tschernobyl 117

U Überqualität 133 UML 2 Usability 219 Usecase 147

V Variabilities 85 Varietät 90 Versteegen, Gerhard 73 Vier-Ohren-Modell 71 Vision-Dokument 216 V-Modell XT 76

W Wasserfallmodell 75 Wiener, Norbert 111 Win-Win 143 Wissensmanagement 39, 65 Wissensschaffung 136 Womack, James P. 118 Workflow 130 Wynne-Edwards, Vero 186

Y Y2K-Problem 40, 64

Z Zeitökonomie 164 Zuse, Konrad 48

Dynaxity: Management von Dynamik und Komplexität im Softwarebau

Modellbildung und Simulation der Dynamik von Kraftfahrzeugen

Die Weltbevölkerung: Dynamik und Gefahren

Prozesse und Dynamik des Netzwerkwandels

Raumflugmechanik: Dynamik und Steuerung von Raumfahrzeugen (German Edition)

Die Dynamik von Privatheit und Offentlichkeit in modernen Gesellschaften

Die Weltbevölkerung. Dynamik und Gefahren

Leben im Plattenbau: Zur Dynamik sozialer Ausgrenzung

Motivation und Bindung von Mitarbeitern im Darwiportunismus

Von der Dynamik sozialer Rollen beim Wissensmanagement

Leben Im Plattenbau: Zur Dynamik Sozialer Ausgrenzung

Outsourcing von Personalfunktionen: Motive und Erfahrungen im Spiegel von Experteninterviews

Finite Elemente in der Statik und Dynamik

Kapitalistische Dynamik

Management und Bilanzierung von Zinsschrankenrisiken: Qualitative Rechts- und quantitative Steuerwirkungsanalyse

Management und Bilanzierung von Emissionsrechten: Strategien und Handlungsoptionen

Väter im Aufbruch?: Deutungsmuster von Väterlichkeit und Männlichkeit im Kontext von Väterinitiativen

Im Zeichen von Thoregon

Im Labyrinth von Eysal

Im Zeichen von Thoregon

Im Zeichen von Ragnarök

Im Wald von Lomza

Im Labyrinth von Eysal

Im Zeichen von Ragnarök

Im Zeichen von Thoregon

Im Zeichen von Thoregon

Im Dschungel von Kalamdayon

Im Golf von Papua

Im Dschungel von Kalamdayon

Im Dschungel von Kalamdayon

Dynaxity: Management von Dynamik und Komplexität im Softwarebau

Modellbildung und Simulation der Dynamik von Kraftfahrzeugen

Die Weltbevölkerung: Dynamik und Gefahren

Prozesse und Dynamik des Netzwerkwandels

Raumflugmechanik: Dynamik und Steuerung von Raumfahrzeugen (German Edition)

Die Dynamik von Privatheit und Offentlichkeit in modernen Gesellschaften

Die Weltbevölkerung. Dynamik und Gefahren

Leben im Plattenbau: Zur Dynamik sozialer Ausgrenzung

Motivation und Bindung von Mitarbeitern im Darwiportunismus

Von der Dynamik sozialer Rollen beim Wissensmanagement

Leben Im Plattenbau: Zur Dynamik Sozialer Ausgrenzung

Outsourcing von Personalfunktionen: Motive und Erfahrungen im Spiegel von Experteninterviews

Finite Elemente in der Statik und Dynamik

Kapitalistische Dynamik

Management und Bilanzierung von Zinsschrankenrisiken: Qualitative Rechts- und quantitative Steuerwirkungsanalyse

Management und Bilanzierung von Emissionsrechten: Strategien und Handlungsoptionen

Väter im Aufbruch?: Deutungsmuster von Väterlichkeit und Männlichkeit im Kontext von Väterinitiativen

Im Zeichen von Thoregon

Im Labyrinth von Eysal

Im Zeichen von Thoregon

Im Zeichen von Ragnarök

Im Wald von Lomza

Im Labyrinth von Eysal

Im Zeichen von Ragnarök

Im Zeichen von Thoregon

Im Zeichen von Thoregon

Im Dschungel von Kalamdayon

Im Golf von Papua

Im Dschungel von Kalamdayon

Im Dschungel von Kalamdayon

Recommend Documents