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

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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,

2.2 Wer kauft Katzen im Sack?

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

2 Basteln Sie oder produzieren Sie schon?

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

2.2 Wer kauft Katzen im Sack?

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2.3 Wenn fehlende Strategien teuer werden

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 Basteln Sie oder produzieren Sie schon?

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

2.3 Wenn fehlende Strategien teuer werden

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2 Basteln Sie oder produzieren Sie schon?

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

2.5 Produktionsmüll

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

2 Basteln Sie oder produzieren Sie schon?

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

2.5 Produktionsmüll

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

2 Basteln Sie oder produzieren Sie schon?

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

2.5 Produktionsmüll

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

2 Basteln Sie oder produzieren Sie schon?

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.

2.5 Produktionsmüll

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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.

3.3 Softwarekomplexität

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

3 Willkommen in der Wirklichkeit

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

3.3 Softwarekomplexität

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

3 Willkommen in der Wirklichkeit

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

3.3 Softwarekomplexität

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3.5 Digitale Geschichte

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

3 Willkommen in der Wirklichkeit

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

3.5 Digitale Geschichte

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

3 Willkommen in der Wirklichkeit

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.

3.5 Digitale Geschichte

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

3 Willkommen in der Wirklichkeit

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

4 Von der Krisis zur Katharsis

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 Von der Krisis zur Katharsis

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

4.1 Dynamik, Chaos und Komplexität

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

4 Von der Krisis zur Katharsis

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:

4.1 Dynamik, Chaos und Komplexität

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

4 Von der Krisis zur Katharsis

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

4.1 Dynamik, Chaos und Komplexität

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

4 Von der Krisis zur Katharsis

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

4.1 Dynamik, Chaos und Komplexität

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