Uwe Vigenschow ist Abteilungsleiter bei Werum IT Solutions GmbH. Daneben ist er auch als Mediator und Fachautor mehrerer Bücher und zahlreicher Artikel aktiv. In dieses Buch sind über 30 Jahre Erfahrung als Entwickler, Berater, Freiberufler, Projektleiter und Führungskraft bei verschiedenen Firmen und in unterschiedlichen Branchen eingeflossen.
Björn Schneider ist als Leiter People & Organisation bei der Hypoport AG beschäftigt. Sein Bereich ist für die Personal- und Organisationsentwicklung auf Basis des agilen Mindsets von ca. 1500 Mitarbeitern bei dem stark wachsenden Finanzdienstleister zuständig. Neben der Leitung führt er persönliche Coachings, Beratungen und Trainings durch und konzipiert bzw. moderiert Workshops. Seit 1995 hat er verschiedene Rollen durchlebt, wie z.B. Softwareentwickler, (Multi-)Projektleiter, Führungskraft, personalverantwortlicher Bereichsleiter, Trainer und Berater, Geschäftsführer eines Beratungsunternehmens sowie Coach für Führungskräfte.
Ines Meyrose ist selbstständige Imageberaterin und Mediatorin. Die Kommunikationswirtin bietet seit 2005 Seminare, Workshops und Einzelcoachings zu Kommunikation und Außendarstellung von Firmen und Menschen an. Zuvor arbeitete sie langjährig im Dienstleitungs- und Vertriebsbereich mit Personalverantwortung. Als Moderatorin begleitet sie Projekte und Prozesse, als Mediatorin ist sie im Konfliktmanagement für Unternehmen tätig. Ines Meyrose ist Mitglied der Versammlung Eines Ehrbaren Kaufmanns zu Hamburg e.V. und Mentorin an der Hamburg School of Business Administration.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Fragetechniken, Konfliktmanagement,
Kommunikationstypen und -modelle
4., überarbeitete Auflage
Uwe Vigenschow
uwe@vigenschow.com
Björn Schneider
mail@bjoernschneider.de
Ines Meyrose
info@konflikte-mediation.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: Uwe Vigenschow
Herstellung: Frank Heidt
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print978-3-86490-697-8
PDF978-3-96088-825-3
ePub978-3-96088-826-0
mobi978-3-96088-827-7
4., überarbeitete Auflage 2019
Copyright © 2019 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Hinweis:
Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: hallo@dpunkt.de.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
»Warum Entwickler nicht zuhören und Fachbereiche nicht entwickeln können« – so hätte dieses Buch auch heißen können. Es geht um den zentralen Erfolgsfaktor Kommunikation. Projekte scheitern unserer Meinung nach nur selten aufgrund technischer Probleme. Dafür sind wir Softwareentwickler viel zu gute Problemlöser. Viel öfter scheinen die Ursachen im Bereich der Soft Skills zu liegen. Mit Themen wie Fragetechniken, Kommunikationsmodellen oder Konfliktmanagement haben wir im Gegensatz zu technischen Inhalten während unserer Ausbildung meist nur wenig Berührung gehabt.
Warum nur machen uns die anderen immer das Leben so schwer? Dabei könnte es doch so einfach sein. Bereits seit längerer Zeit arbeiten wir ganz agil direkt mit den Fachbereichen am Whiteboard zusammen. So entstehen Konzepte, deren Umsetzung bei den Anwendern eine hohe Akzeptanz haben wird. Es werden nur jene Aufgaben betrachtet, die wirklich realisiert werden sollen und zu gut wartbarem Code führen (Abb. 1).
Abbildung 1: In einer idealen Welt kommunizieren Entwickler und Mitarbeiter aus den Fachbereichen direkt und konfliktfrei.
Doch wie sieht es oftmals wirklich aus? So toll funktioniert das nicht mit der direkten Kommunikation. Häufig werden sogar mehr Konflikte offenkundig, als vorher durch schriftliche Konzeptübergaben auftraten (Abb. 2). Wird unsere Kommunikation also schlechter? Nein, dieser vermeintliche Nachteil ist einer der wesentlichen Vorteile: Die Konflikte werden früher sichtbar! Unterschwellig sind sie oft bereits vorhanden, bei indirekter Kommunikation können wir ihnen nur einfacher aus dem Weg gehen. Zumindest vorerst …
Abbildung 2: Häufig erleben wir in unserer realen Welt eine alles andere als konstruktive Kommunikation. Die gegenseitige, abwertende Meinung legt den Grundstein für aufkommende Konflikte.
Was sind die Ursachen dafür? Wie entstehen solche Konflikte und was können wir dagegen tun? Fangen wir mit den Ursachen an: Es sind die kleinen Grenzverletzungen und das tägliche Wildern im Verantwortlichkeitsbereich des anderen (Abb. 3).
Was passiert, wenn wir so etwas tun? Wir treten dem anderen bildlich auf die Füße, und dieser wird entsprechend reagieren. Nun werden wir glücklicherweise in unserem Berufsalltag nicht gleich handgreiflich. Die Reaktionen haben dennoch die gleichen Konsequenzen. Viele Konflikte finden darin ihre Ursache.
Warum tun wir das? Häufig liegt einem solchen Verhalten eine abwertende innere Einstellung zugrunde: Ich bin O.K., du bist nicht O.K. Typische Aussagen, die wir in diesem Zusammenhang von Entwicklern immer wieder gehört haben, lauten z. B.:
Abbildung 3: Konkrete Ursachen für Konflikte sind häufig die Grenzverletzungen an den gegenseitigen Verantwortlichkeitsbereichen. Entwickler mischen sich z. B. in die Anforderunganalyse ein oder Fachbereiche machen technische Vorgaben.
Wenn wir versuchen, die andere Seite zu verstehen und uns in sie hineinversetzen, wird schnell klar, warum sie aggressiv oder ablehnend reagiert. So wie in Abbildung 4 möchten wir auch nicht behandelt werden. Wir werden auf diese Sicht auf Seite 87 ausführlich zurückkommen.
Greifen wir wieder unseren roten Faden auf: Wer arbeitet schon gerne mit arroganten Menschen zusammen, die einen nicht ernst nehmen? Wer möchte dann nicht schadenfroh die eine oder andere Falle stellen oder mal richtig auf den Putz hauen?
Wie können wir angemessener kommunizieren und eine offenere Einstellung den anderen Bereichen gegenüber entwickeln? Wir werden dazu im Weiteren die Problematik analysieren, Modelle erläutern und daraus Techniken für ein konstruktives Miteinander im Umfeld der Softwareentwicklung ableiten. Die Entwicklung unserer Soft Skills ist dabei essenziell für den Projekterfolg. Diesen Zusammenhang wollen wir mit einer Metapher illustrieren. Adrian Fröhlich hat das Bild von Auto und Straße für Projekt und Projektumfeld geprägt [27]. Die Entwicklung des Automobils wäre ohne die parallele Entwicklung des Straßennetzes kaum vorstellbar. Ebenso sind Projekte und ihre Infrastruktur eng miteinander verwoben. Dabei sind die Soft Skills wie die Reifen eines Autos. Sie sind die Überträger unserer Leistungsfähigkeit auf die Straße (Abb. 5).
Abbildung 4: Wie wirken die beiden echten Programmierer auf Sie?
Abbildung 5: Unsere Soft Skills sind wie die Reifen an einem Auto. Über sie wird unsere Leistungskraft auf die Projektstraße übertragen.
Eine zweite Metapher für unsere Ziele, die wir mit dem Buch verfolgen, ist die Brücke. Besser ausgebildete Soft Skills sind gerade in der IT so wichtig, da wir dort häufig die Brücke schlagen zu den verschiedenen Fachbereichen, zum Management, in Richtung Marketing und Produktmanagement sowie zum Anwender bzw. Kunden. Je angemessener wir mit den verschiedenen Gruppen kommunizieren können, umso belastbarer werden diese Brücken werden.
In diesem Buch haben wir einen großen Teil unserer Erfahrungen mit Themen aus dem Bereich der Soft Skills zusammengefasst und aufbereitet. Wir befassen uns z. T. seit über zehn Jahren mit Aspekten aus der Arbeitspsychologie, auf die wir in diversen Seminaren gestoßen sind. Wir halten sie für essenziell in unserer täglichen Projektarbeit und möchten sie Ihnen auch ein Stück näherbringen. Uns haben sie gerade in heiklen Situationen oft geholfen.
Eine zweite Motivation kommt für uns dazu: Soft Skills machen Spaß. Sicher, es ist nicht unbedingt einfach, sich auf diesen Bereichen weiterzuentwickeln. Doch geht eine starke Faszination von den psychologischen Zusammenhängen aus, die uns dauerhaft dabeigehalten hat. Begleiten Sie uns ein Stück auf dem Weg, unsere individuelle Leistungsfähigkeit noch besser nutzen zu können.
Uwe Vigenschow und Björn Schneider
Hamburg und Herrnburg, November 2006
Wir freuen uns sehr über den Erfolg der ersten Auflage dieses Buchs. Mittlerweile haben wir bereits ein zweites Buch zum Thema Soft Skills in der IT für Führungskräfte und Projektleiter veröffentlicht und ein drittes für IT-Berater und Veränderungsmanager ist in Arbeit. Unter diesen Umständen haben wir gerne eine Überarbeitung dieses Buchs eingeschoben. Was hat sich gegenüber der ersten Auflage geändert?
Zurecht ist der Teil zum Thema Konfliktmanagement als etwas zu optimistisch kritisiert worden. Hier haben wir die umfangreichsten Anpassungen und Ergänzungen vorgenommen. Wir konnten dazu die Erfahrungen der vergangenen drei Jahren intensiv nutzen und einfließen lassen. Sowohl Ines Meyrose als auch Uwe Vigenschow haben als ausgebildete Mediatoren tiefere praktische Erfahrungen auf diesem Gebiet sammeln können. Die beiden haben die entsprechenden Kapitel komplett neu geschrieben und das anschließende Kapitel über Verhandlungstechnik gleich mit überarbeitet.
Zusätzlich sind diverse kleine Verbesserungen inhaltlicher und struktureller Art erfolgt, und ein kleines Facelifting mit einer Anpassung an das Layout unseres zweiten Soft-Skills-Buchs hat auch stattgefunden. Ansonsten haben wir versucht, all das zu bewahren, was dieses Buch so erfolgreich gemacht hat. An diversen Stellen haben wir weiterführende Hinweise auf das zweite Soft-Skills-Buch ergänzt. Wenn Sie einzelne Themen vertiefen möchten, legen wir Ihnen dieses Buch ans Herz [84].
Natürlich freuen wir uns sehr über Feedback von Ihnen. Ihre Anregungen sind uns herzlich willkommen.
Uwe Vigenschow, Björn Schneider und Ines Meyrose
Hamburg und Lübeck, Oktober 2010
Als wir 2006 damit begonnen haben, ein Buch über Soft Skills in der IT zu schreiben, haben wir nicht ansatzweise damit gerechnet, was sich im Laufe der Jahre daraus ergeben würde. So decken alleine die Publikationen beim dpunkt.verlag ein breites Spektrum der sogenannten weichen Themen ab: Peter Siwon stellte 2010 Die menschliche Seite des Projekterfolgs in den Mittelpunkt seiner anregenden Veröffentlichung. Jörg Dirbach, Markus Flückiger und Steffen Lentz haben 2011 mit Software entwickeln mit Verstand ein tolles Buch zum Thema Wissensarbeit verfasst. 2012 hat sich Alex Rammlmair mit der IT-Verkaufsberatung in der Praxis, einem für viele ITler doch eher schwierigen Thema, intensiv und spannend befasst. Heinz Hellerer hat sich in Soft Skills für Softwaretester und Testmanager ebenfalls 2012 den besonderen Herausforderungen dieser Rollen bezüglich Kommunikation und Stress- bzw. Konfliktmanagement gewidmet.
Soft Skills für Softwareentwickler ist nun nach 2007 und 2011 für den dritten Durchgang noch einmal von uns überarbeitet worden. Es bildet den Ausgangspunkt für zwei weitere Bücher, die wir zu Soft Skills in der IT geschrieben haben. Soft Skills für IT-Führungskräfte und Projektleiter stellt mittlerweile in der zweiten, aktualisierten und ergänzten Auflage von 2012 die Themen Führung, Coaching und Teambildung in den Fokus. In Soft Skills für IT-Berater (2012) stehen eine kundenorientierte Beratung und die Gestaltung von Veränderungen im Mittelpunkt.
Was hat sich in dieser Auflage verändert? Es gab für uns keinen Anlass zu größeren Umbauten wie noch zur zweiten Auflage. Im Laufe der Zeit haben sich jedoch viele einzelne Aspekte angesammelt, die wir gerne anpassen oder aktualisieren wollten. Insgesamt sind fast 60 Textpassagen, Abbildungen oder Tabellen auf 62 Seiten bearbeitet oder ergänzt worden.
Wir freuen uns sehr über den Erfolg und die Entwicklung in den letzten acht Jahren, für den wir uns bei Ihnen, den Leserinnen und Lesern, herzlich bedanken. Wir hoffen, Ihnen in Ihrem Alltag ein wenig helfen zu können, noch erfolgreicher und wirkungsvoller zu sein.
Uwe Vigenschow, Björn Schneider und Ines Meyrose
Hamburg und Lübeck, April 2014
Wie schnell die Zeit vergeht … Zum Jahresende 2006 kam die erste Auflage der Soft Skills für Softwareentwickler in die Buchläden und Onlineshops. Bereits fünf Jahre ist es her, dass wir dieses Buch zur 3. Auflage überarbeitet haben. Da wurde es Zeit, zu prüfen, was zur 4. Auflage anzupassen oder zu aktualisieren ist.
Das einleitende Kapitel 4 zu den Fragetechniken haben wir um weitere Fragearten und ein Fazit ergänzt und dazu die Struktur der Kapitel 4 und 5 verändert. So konnten wir die Unterschiede der einzelnen Fragearten noch klarer herausarbeiten.
Die Möglichkeit, Konflikte mit Mediationen zu lösen, ist in den letzten Jahren bekannter geworden. Immer mehr Unternehmen trauen sich, externe Mediatoren hinzuzuziehen, und machen damit gute Erfahrungen. Unsere neusten Erkenntnisse und aktuelle praktische Erfahrungen sind in die Überarbeitung des Kapitels 19 zum Konfliktmanagement eingeflossen.
Der stetige Erfolg dieses Buches nach fast 13 Jahre zeigt uns, dass wir auch heute noch aktuelle Themen behandeln. Diese Bestätigung unserer Arbeit freut uns sehr. Wir hoffen, dass es Ihnen genauso viel Spaß macht, sich mit Themen aus dem Bereich der Soft Skills zu befassen, wie uns. Vielleicht sind auch unsere beiden weiteren Bücher zu Soft Skills für Sie interessant und anregend. Soft Skills für IT-Führungskräfte und Projektleiter [84] liegt in der dritten, überarbeiteten Auflage vor und Soft Skills für IT-Berater [83] rundet den Themenblock mit Inhalten zur Beratung und der Gestaltung von Veränderungen ab.
Wenn etwas Spaß macht, werden wir darin besser. Über bessere Soft Skills erzielen wir mehr Wirkung. Damit sollten unsere Projekte erfolgreicher werden. Das ist doch ein schönes Ziel, oder?
Uwe Vigenschow, Björn Schneider und Ines Meyrose
Hamburg und Lübeck, Mai 2019
»Soft Skills für Softwareentwickler« gliedert sich in fünf Teile, in denen jeweils eine zentrale Frage thematisiert und geklärt wird:
Nachwort: Was verstehen wir unter People Driven Development?
Anhang: Wie sieht die Theorie hinter den beschriebenen Modellen aus? Welche einfachen Übungen können uns bei unserer Weiterentwicklung helfen?
Literaturverzeichnis: Was sind unsere Referenzen? Wie können Sie einzelne Themen weiter vertiefen?
Index: Wie finden wir unter der Fülle an Informationen etwas wieder?
Wir versuchen, möglichst viel zu visualisieren, weil wir der Meinung sind, dass sich komplexe Informationen so besser transportieren lassen. Daher finden Sie die Strukturübersicht in Abbildung 6 als Baum dargestellt.
Abbildung 6: Inhaltsübersicht in Form eines Baums. Die Äste stehen für die fünf Teile, das Nachwort und den Anhang, die Blätter für die einzelnen Kapitel.
IProjektarchitektur und Kommunikationsschnittstellen
1Software- und Projektstruktur
1.1Komplexität von Projektstrukturen
1.2Bedeutung für IT-Projekte
2Projektpolitik? Projektumfeldanalyse!
2.1Was sind Stakeholder?
2.2Stakeholder Elicitation: Wer hat Interessen?
2.3Situationsbeispiele
3Projektmarketing
3.1Wie funktioniert Marketing?
3.2Projektbegleitendes Marketing
3.3Begeisterungsqualität
3.4Events und Präsentationen
IIMit Fragetechniken zu besseren Informationen
4Grundlegende Fragetechniken
4.1Informationsfrage
Infobox: Offene und geschlossene Fragen
4.2Mit Fragen auf den Punkt kommen
4.3Anregende Fragen
4.4Fazit
5Die Sechs-Stufen-Fragetechnik
5.1In sechs Schritten zur Softwareanalyse
Infobox: Neurolinguistisches Programmieren (NLP)
5.2Ein kleiner Beispielfragenkatalog
5.3Fragetechniken in Reviews anwenden
Infobox: Stärken und Kritikpunkte des NLP
6Feedback und aktives Zuhören
6.1Warum überhaupt Feedback geben?
6.2So funktioniert es: Feedback-Regeln
6.3Aktiv zuhören: Verluste minimieren
6.4In kritischen Situationen auf die Meta-Ebene
Infobox: Standardlösung – Auf die Meta-Ebene gehen
IIIErfolgreich kommunizieren
7Effiziente Kommunikationsformen
7.1Modellieren und Visualisieren
7.2Rangliste effizienter Kommunikationsformen
7.3Störungskultur
Infobox: Regeln für eine langfristige Dokumentation
7.4Konflikte 1. Teil: Wertschätzung
7.5Kommunikation auf Augenhöhe
8Von Eisbergen und Schiffen
Infobox: Psychologische Modelle
8.1Das Eisbergmodell
Infobox: Bewusstsein oder nicht bewusst sein?
Infobox: Bewusstsein – Aufmerksamkeit, Gefühl und Gedächtnis
8.2Konflikte 2. Teil: Geschäftsordnung
8.3Konflikte 3. Teil: Unter Wasser
Infobox: Pacing – Brücken bauen
Infobox: Geschlossene Haltungen öffnen
9Aspekte der Kommunikation
9.1Vier Ohren und vier Schnäbel
9.2Konstruktiv mit Kritik umgehen
Infobox: Reframing – Umdeuten von Verhaltensweisen
9.3Das innereTeam
9.4Situationsabhängigkeit
10Ein einfaches Persönlichkeitsmodell
10.1Vier Präferenzen
10.2Anwendung in der Kommunikationssituation
10.3Die Unterschiedlichkeit nutzen
11Ich bin O.K., du bist O.K., ihr seid O.K
11.1Transaktionsanalyse
11.2Die Transaktionsarten
11.3Aufspaltung der Ich-Grundzustände
11.4Spiele: Das Drama-Dreieck
Infobox: Spiele der Erwachsenen
12Verantwortung oder Manipulation?
12.1Wir tragen Verantwortung!
12.2Was ist Manipulation?
12.3Mit Manipulationen umgehen
IVIT-Kommunikationstypen
13Kommunikationstypen in der IT
13.1Einführung
13.2Überblick aller zwölf Kommunikationstypen
14Entwickler-Kommunikationstypen
14.1Der No-Future-Entwickler
14.2AAAA – der allwissende, allgegenwärtige, arrogante Architekt
14.3XXPler – eXtreme eXtreme Programmer
14.4Der Hacker
14.5Mr. 120%
15Kommunikationstypen in den Fachbereichen
15.1Der bessere Verkäufer
15.2Der zurückgezogene Spezialist
Infobox: Timebox und Meilenstein
15.3Der Konzepteklopfer
15.4Der Visionär
16Projektleiter-Kommunikationstypen
16.1Der freundliche Kollege
16.2Der Choleriker
16.3Der formale Prozessler
VKonfliktmanagement
17Konflikte analysieren
17.1Konflikt definieren
17.2Verschiedene Arten von Konflikten
17.3Beziehungs- und Wertekonflikte
17.4Rollenkonflikte
17.5Dynamik in Konflikten
18Konfliktmuster rechtzeitig erkennen
18.1Schwierigkeit – Problem – Konflikt
18.2Entwicklungsstufen eines Konflikts
Infobox: Sieger und Verlierer
18.3Kommunikationsmuster in Konflikten
18.4Gruppendynamik
19Konflikte managen
19.1Kritikgespräche führen
19.2Moderationsleitfaden für die Win-win-Ebene
19.3Mediation für die Win-lose-Ebene
20Erfolgreich Verhandlungen führen
20.1Nach dem Harvard-Konzept verhandeln
20.2Das Harvard-Konzept
Nachwort: People Driven Development
VIAnhang
ADie theoretischen Grundlagen
A.1Persönlichkeitstheorie nach Freud
A.2Analytische Psychologie
A.3Typologie nach C. G. Jung
A.4Die Transaktionsanalyse
A.5Differenzielle Kommunikationstheorie
BÜbungen
B.1Verbale Kommunikation: Sagen und Verstehen
B.2Freies Sprechen: Drei-Wörter-Übung
B.3Freies Sprechen: Aber-zu-und-Übung
B.4Unsere Lieblingsrolle im Drama-Dreieck
B.5Projektion auf andere Menschen
B.6Werte priorisieren
Danksagung
Referenzen und weiterführende Literatur
Index
Software- und Projektstruktur 3
Unsere Projektstrukturen ähneln in ihrer Komplexität den Softwarestrukturen. Um unsere Softwarearchitektur kümmern sich Architekten, Designer und Entwickler. Aber wer kümmert sich um die Schnittstellen zwischen den Teams und zu den anderen Projektbeteiligten? Der Schlüssel für erfolgreiche Projekte liegt in der Architektur unserer Projektstruktur!
Projektpolitik? Projektumfeldanalyse! 13
Softwareprojekte sind so gut wie immer eng mit Projektpolitik verknüpft. Wir sollten wissen, wer und was alles mit unserem Projekt zu tun hat und welche Interessen dabei mitspielen, um nicht zur passiven Spielfigur zu werden. Die Projektbeteiligten verfolgen leider nicht immer dasselbe Ziel. Die Projektumfeldanalyse gibt uns ein Mittel in die Hand, die daraus resultierenden Probleme in den Griff zu bekommen.
Projektmarketing 25
Tue Gutes und rede darüber! Projekterfolg ist eine subjektive Größe, die sich im Auge des Betrachters ergibt. Ein paar kleine Projektmarketingaktivitäten können viel bewegen! Eine mögliche Schlüsselposition kann dabei der Begeisterung zukommen, die wir mit meist kleinen Anpassungen für die Anwender schaffen können.
Wir stellen im Rahmen von Projekten hochkomplexe Software her, die maßgeschneidert die Anforderungen erfüllt. Jedenfalls ist das unser Ziel. Die Zeiten, in denen tolle Projekte von einer einzelnen Person gestemmt wurden, sind lange vorbei. Die Komplexität der Anforderungen und der Integration in bestehende Systemlandschaften erfordert angemessene Projektstrukturen. Diese können schnell ähnlich komplex werden wie die zu realisierende Softwarestruktur (Abb. 1.1).
Abbildung 1.1: Heutige Projekte erreichen schnell eine komplexe Projektstruktur.
Wenn wir die Managementsicht aus Abbildung 1.1 technisch weiter auflösen und die Schnittstellen explizit modellieren, erhalten wir eine hochgradig vernetzte Struktur, die wir vermutlich in unserer Software nicht dulden würden (Abb. 1.2). Zu aufwendig wären Wartung und Erweiterungen. Die abgebildeten Interfaces sind nur Beispiele. Im Einzelfall kann Ihre Realität etwas einfacher oder noch komplexer aussehen.
Abbildung 1.2: Die Verfeinerung der Projektstruktur aus Abbildung 1.1 führt zu einem komplexen Kommunikationsnetzwerk. (Beispielhafte Darstellung in UML: Alle Interfaces sind bidirektional.)
Innerhalb unserer Teams finden wir zudem eine Mikrostruktur vor, die eigene Kommunikationsinterfaces ausgebildet hat (Abb. 1.3). Die Gesamtkomplexität wird so noch um eine Stufe erhöht.
Abbildung 1.3: Zusätzlich zur Struktur aus Abbildung 1.2 finden wir innerhalb unserer Teilteams eine Mikrokommunikationsstruktur vor. (Beispielhafte Darstellung in UML: Alle Interfaces sind bidirektional.)
Glücklicherweise brauchen wir uns der Projektstruktur nicht machtlos zu ergeben. Wir sollten dies auch nicht tun, denn gerade in den Kommunikationsschnittstellen liegt der wesentliche Schlüssel zum Projekterfolg! Genauso, wie wir technische Mittel besitzen, um die Abhängigkeiten innerhalb unserer Software in den Griff zu bekommen, gibt es Techniken für die Projektstruktur und Kommunikationsschnittstellen.
Die Themen Selbstorganisation und komplexe Systeme behandeln wir in diesem Buch nicht weiter. Damit haben wir uns eingehend in unserem Buch Soft Skills für IT-Führungskräfte und Projektleiter befasst, das wir Ihnen als Weiterführung empfehlen [84].
Wo liegt nun eigentlich das Problem? Die Schnittstellen sind eindeutig definiert und die erwarteten Ergebnistypen detailliert vorgegeben. Es sollte doch alles klar sein!? Doch egal, wie wir kommunizieren: Der Vorgang lässt sich gut mit einem Filterprozess vergleichen. Bei jedem Transfer bleibt etwas auf der Strecke! Die Anteile können je nach Kommunikationskanal und beteiligten Personen variieren, aber es geht immer Kommunikationsinhalt verloren: Wir haben ein Sender-Empfänger-Problem!
Ein einfaches Kommunikationsmodell beschreibt Kommunikation als Folge von Transformationen [69]. Dabei kann es bei jeder Transformation zu Verlusten im Informationsgehalt kommen. Dies erfolgt sowohl zwischen Personen wie auch innerhalb eines Menschen (Abb. 1.4).
Abbildung 1.4: Kommunikation als Transformations- und Filterprozess: das Kommunikationsmodell nach Shannon und Weaver [69]
Jede Wahrnehmung ist subjektiv. Dazu kommt das Ausfiltern von Informationen aufgrund der physikalischen Einschränkungen unserer Wahrnehmung. Das Wahrgenommene wird transformiert und als Erinnerung im Gehirn abgelegt. Bei dieser Transformation helfen uns unsere bisherigen Erfahrungen. Sie erleichtern uns das schnelle Erfassen, filtern aber erneut Informationsgehalt aus. Außerdem ist unsere Wahrnehmung durch unsere individuelle Auffassungsgabe begrenzt.
Bei der Rücktransformation aus unserem Gehirn in extern Kommunizierbares, also z. B. Sprache, bleibt erneut einiges auf der Strecke. Besonders bewusst wird uns dies, wenn wir nicht in unserer Muttersprache, sondern in einer Fremdsprache kommunizieren müssen. Wir spüren förmlich, wie Informationsgehalt versickert. Bei unserem Gesprächspartner spielen sich noch einmal dieselben Prozesse ab.
Kommunikationsschnittstellen sind also an sich bereits kritisch. In Teil II ab Seite 41 werden wir Techniken kennenlernen, mit denen wir den Informationsverlust drastisch minimieren können. Das löst zwar noch nicht alle unsere Probleme, doch wir kommen damit deutlich besser voran. Die verbleibenden Probleme beruhen darauf, dass wir es nicht mit technischen Interfaces zu tun haben, sondern mit Menschen.
Wie die Objekte einer Klasse sind auch wir Menschen Individuen. Wir sind nach dem gleichen Bauplan erstellt, aber unsere Attribute lassen einen großen Spielraum an Individualität zu. Kommen wir mit Menschen in Kontakt, so verstehen wir diejenigen schneller, die ähnlich wie wir gestrickt sind. Andere hingegen scheinen uns völlig fremd zu bleiben (Abb. 1.5).
Abbildung 1.5: Menschen sind absolut individuell (links). Derselbe Mensch kann in bestimmten Situationen unterschiedliche Rollen einnehmen (rechts).
In homogenen Gruppen kann dies leicht dazu führen, dass Menschen, die »anders« sind, abgewertet werden. Gruppen von Softwareentwicklern verhalten sich da nicht anders. Die Anwender haben sowieso keine Ahnung, die Administratoren machen alles kaputt und der Fachbereich weiß nicht, was er will, obwohl die eigene Lösung doch eigentlich perfekt ist. Und Manager lassen sich von bunten Bildern eher beeindrucken als von detaillierten Informationen. Wie können wir in so einem Umfeld überhaupt arbeiten?
Achtung! Was wir hier vorschnell machen, ist eine abwertende Klassifizierung. Wir packen die Menschen in »Schubladen«, die so negativ vorbelegt sind, dass wir sie dann gar nicht mehr ernst nehmen können. Hier lauert eine enorme Gefahr, die uns isolieren und projektgefährdende Konflikte erzeugen kann!
Schauen wir uns dazu noch einmal Abbildung 1.1 an. Ob wir wollen oder nicht, wir haben es mit einer Reihe von Menschen zu tun, die keinen technischen Background mitbringen. In deren Bereichen sind ganz andere Qualifikationen notwendig. Wenn sie diese nicht hätten, sondern eher technische, wären sie vermutlich unsere Kollegen. Wenn wir ihre Qualifikationen hätten, säßen wir an deren Stelle!
Diese Heterogenität ist besonders wichtig. Um so etwas Komplexes wie ein Softwareprojekt erfolgreich gestalten zu können, sind verschiedenste Qualifikationen erforderlich. Unsere technischen Fähigkeiten sind dafür absolut notwendig, aber eben nicht ausreichend. In Teil III ab Seite 79 wollen wir Ihnen zeigen, wie wir einen angemessenen Zugang zu Menschen aufbauen können, die ganz anders als wir gestrickt sind. Zusätzlich erfahren Sie dabei, wie Konflikte vermieden werden können. Wir werden uns auch »Schubladen« bauen, die im Gegensatz zu unseren bisherigen (Vor-)Urteilen positiv formuliert und belegt sind.
»Ja natürlich mag es Softwareprojekte geben, in denen die Kommunikation eine besondere Bedeutung hat. Aber doch nicht in meinem Projekt oder meinem Team. Da ist alles klar und geregelt.« Auf solche oder ähnliche Gedanken können Sie nach dem Lesen der ersten Seiten kommen. Und vielleicht ist Ihr Umfeld genau die Ausnahme, die die Regel bestätigt. Aber wie wahrscheinlich ist das?
Vielen Lesern mag es einleuchten, dass die Kommunikation in agilen Projekten einen besonderen Wert hat. Wir gehen jedoch davon aus, dass so gut wie alle Softwareprojekte primär Kommunikationsprojekte sind und sich nur sekundär mit technischen Themen befassen. Verstehen wir wirklich, was die Stakeholder brauchen? Verstehen wir wirklich, welche Probleme der Architekt oder das parallel arbeitende Team sieht? Betrachten wir zur Illustration kurz den Wert von Komunikation und Zusammenarbeit in zwei sehr unterschiedlichen Kontexten.
Der Begriff agil bedeutet so viel wie beweglich oder leicht zu führen [20]. Im Agilen Manifest [1] sind die folgenden Prinzipien einer leichtgewichtigen Softwareentwicklung festgelegt:
Menschen und Zusammenarbeit vor Prozessen und Werkzeugen
Funktionierende Produkte vor umfassender Dokumentation
Zusammenarbeit mit dem Kunden vor vertraglichen Verhandlungen
Reaktion auf Veränderung vor der Einhaltung eines Plans
Die Punkte auf der rechten Seite der Aussagen sind wertvoll, aber kein Selbstzweck. Sie sollen die wichtigeren Punkte der linken, hervorgehobenen Seite sinnvoll und angemessen unterstützen. Dabei sind die Art und der Grad des Einsatzes der unterstützenden Maßnahmen genau zu bestimmen. Was steckt hinter den vier Punkten? Es gibt für die Toolfrage keine Silver Bullet. Wichtig ist, wie wir im Prozess oder mit Werkzeugen arbeiten. Unser methodisches Wissen ist gefragt. Es kann weder durch ein Vorgehensmodell noch durch ein Tool ersetzt werden: A fool with a tool is still a fool!
Was nützen vollständige Analyse- und Designdokumente, wenn unsere Software nicht einsatzfähig ist, weil sie entweder nicht das macht, was eigentlich gebraucht wird, oder aber zu fehlerhaft ist? Ein umfangreiches Vertragswerk scheint eher zum Verstecken der wenigen relevanten Abschnitte zu dienen als zur Klarheit. Selbst mit noch so viel Aufwand und den besten Rechtsanwälten wird uns kein wasserdichter Vertrag gelingen. Und wenn doch, was machen wir, wenn unser Softwarepartner in Konkurs geht?
Was nützt es dem Auftraggeber, wenn der Plan eingehalten wurde, aber sich in der Zwischenzeit die Anforderungen geändert haben? Dies kann bei einer falschen Priorisierung von Bewertungsfaktoren zu seltsamen Auswüchsen führen.1 Bei der Bewertung von Aktiengesellschaften kann es dazu kommen, dass, nur um die geplanten Gewinne eines Quartalsberichts einzuhalten, auf Gewinne verzichtet wird, weil von einigen Börsianern auch positive Abweichungen negativ beurteilt werden [12]. So etwas sollte uns Entwicklern nicht passieren. Dafür gibt es vier zentrale Prinzipien agiler Softwareentwicklung, die helfen können, diese Probleme zu vermeiden [3]:
Die Kommunikation und damit die Kommunikationsfähigkeit wird also als zentraler Erfolgsfaktor gesehen. Dies deckt sich mit unserer Erfahrung aus diversen Negativbeispielen. Obwohl agile Projekte in der Regel von der beteiligten Personenzahl her kleine Projekte sind, spielt die direkte Kommunikation und Kommunikationsfähigkeit bei allen Beteiligten eine überproportional wichtige Rolle.
Schnell kommt es zu Missverständnissen zwischen Entwicklern und Nicht-Entwicklern aus den Fachbereichen oder dem Management. Dadurch entwickeln wir die falsche Software, und die Manager verstehen nicht, was eigentlich vor sich geht. Die Situation wird noch verschärft, indem sowohl die Fachbereiche als auch das Management erheblich mit ihren Erfolgen von uns Entwicklern abhängig sind. Sie sind also abhängig von Menschen, die sie nicht verstehen! Eine solche Situation wird beinahe zwangsläufig zu Ängsten führen – und Angst ist ein schlechter Berater.
Es kann auch sein, dass unser Gesprächspartner blockiert und wir nicht an die Informationen herankommen, die wir benötigen. Und wir merken das noch nicht einmal. Unser Auftreten kann so weit führen, dass wir uns politische Gegner schaffen, mit denen wir dann Machtspiele austragen, anstatt uns auf unser Projekt zu konzentrieren. Auch innerhalb unseres Entwicklungsteams entgehen uns schnell durch mangelhafte Kommunikation mögliche Synergien. So werden wir kaum eine effiziente Lösung finden können.
Dieses Buch befasst sich im Wesentlichen mit den direkten Kommunikationstechniken. In jedem Teil werden Sie daher Techniken kennenlernen, die Ihnen besonders in agilen Projekten helfen können.
Hinter SOA (Service-oriented Architecture) steckt eine Architektursicht zur flexiblen Umsetzung von Geschäftsprozessen in Software. Häufig etwas vorschnell wird SOA auf ein technisches Problem zur Bereitstellung von Webservices reduziert. Schauen wir uns erfolgreiche SOA-Projekte an, stellen wir fest, dass die Technologie gegenüber der Methodik häufig eher sekundär ist [73].
Der Rahmen für SOA-Projekte liegt entgegengesetzt zu den vorher behandelten agilen Projekten. Das Ziel ist dabei die Flexibilisierung der Softwareunterstützung von Geschäftsprozessen in Großfirmen und Konzernen. Waren früher Prozesse über lange Zeiträume konstant, fordert der Markt heute deutlich schnellere Reaktionen, sodass Prozesse durchaus alle paar Monate angepasst werden können (Abb. 1.6).
Abbildung 1.6: SOA ist mehr als die Integration von Anwendungen. Durch die Zerlegung in Services kann die Flexibilität der IT-Lösungen erhöht werden, um der Dynamik der Anforderungen besser gerecht zu werden.
Aus technischer Sicht wird mit SOA der bestehende heterogene Zoo von Anwendungen und Informationssystemen durch einen zentralen Enterprise Service Bus gekapselt, der als Schnittstelle für die Anwendungen Services zur Verfügung stellt.
Die zentrale Fragestellung lautet: Wie kommen wir zu den einzelnen Services? Dies kann nur in enger Zusammenarbeit mit den Fachbereichen erfolgen, um hinterher auch das angestrebte Ziel der Flexibilität zu erreichen. Ausgangspunkt sind die Geschäftsprozesse, die weiter zerlegt werden und zu statischen wie dynamischen Modellen führen, aus denen dann die konkreten Services abgeleitet werden. Um die gewünschte Dynamik an Änderungen und Erweiterungen realisieren zu können, erfolgt diese methodische Ableitung der Services im direkten Kontakt aller Beteiligten in Form von Workshops. Dabei werden die Geschäftsprozesse analysiert und, falls notwendig, IT-kompatibel modelliert. Des Weiteren werden in einem Domänenmodell Verantwortlichkeiten sowie Schnittstellen festgelegt (Abb. 1.7). Mit den so gefundenen Services können dann (hoffentlich) schnell Prozessanpassungen in unseren Anwendungen erfolgen, indem die Services als Bausteine aufgefasst und neu rekombiniert werden.
Abbildung 1.7: Die Entwicklung einer SOA ist primär ein organisatorischer und geschäftsprozessorientierter Ablauf.
Dabei wird auf IT-Seite eine neue Rolle definiert, eine Art technischer Prozessdesigner. Aufgrund der hohen Dynamik der Anforderungsänderungen ist das primäre Arbeitsmittel des technischen Prozessdesigners die Durchführung von Workshops. Er transformiert die Ergebnisse der Workshops in technische Modelle und stimmt diese mit den fachlichen Ansprechpartnern ab. Meist wird diese Aufgabe von einem kleinen Kernteam wahrgenommen. Für diese Rolle sind offensichtlich neben technischen und methodischen Fähigkeiten starke kommunikative Fertigkeiten notwendig.
In der direkten Kommunikation der Beteiligten werden die Abläufe optimiert und angepasst. Der Prozessdesigner sorgt für die Transformation der fachlichen Sicht in eine technische und für eine angemessene Modellierung. Damit ist er verantwortlich für die Dokumentation der statischen und dynamischen Sichten auf die Abläufe in den betrachteten Bereichen.
Bei Softwareprojekten ist meist viel Geld im Spiel. Damit eng verbunden sind Machtinteressen bestimmter Personen. Als Projektverantwortliche und Projektbeteiligte sind wir damit automatisch in die Projektpolitik eingebunden, ob wir wollen oder nicht. Auch wenn wir selbst eine Aversion gegen Machtspielereien haben, sollten wir zumindest wissen, was um uns herum passiert und wie die Machtverhältnisse aussehen. So gesehen hat Projektpolitik etwas von Schachspielen. Wer positioniert wo seine Figuren? Welchen Wert haben sie? Und wie gut spielen Sie Schach (Abb. 2.1)?
Abbildung 2.1: Projektpolitik lässt sich mit Schachspielen vergleichen.
Mit einer Projektumfeldanalyse versuchen wir, um in der Metapher zu bleiben, die Farbe und Wertigkeit der Spielfiguren herauszufinden. Dabei haben wir oft bemerkt, dass Softwareprojektpolitik noch viel komplexer ist, als Schach zu spielen. Es gibt mehr als nur zwei Farben und viel mehr Beteiligte als Spielfiguren beim Schach. Das Hauptziel der Projektumfeldanalyse ist es, die Interessen und Bedürfnisse aller Umfeldgruppen zu erfassen, um sie bei der Projektrealisierung so weit wie möglich berücksichtigen zu können.
Eine Projektumfeldanalyse besteht aus verschiedenen Teilen. Vielleicht ist Ihnen die sogenannte Stakeholder Elicitation bekannt, also das Identifizieren der Projektbeteiligten. Wir werden uns diesen Punkt im Einzelnen noch näher anschauen. Vorher ist es wichtig, dass wir die folgende Frage beantworten: Warum kann eine Projektumfeldanalyse unsere Projekterfolgsaussichten verbessern?
Projekt- und Problemlösungsprozesse haben verschiedene Abhängigkeiten. Die äußeren Bedingungen verändern sich während der Projektlaufzeit, und ebenso können sich auch die Einstellungen der beteiligten bzw. betroffenen Personen ändern. Mit einer Projektumfeldanalyse können wir diese Erfolgsfaktoren bewusst adressieren und analysieren. Unser Ziel ist, die Einstellungen und Motivationen aller Beteiligten zu erfassen sowie die Beziehungen der Personen zueinander zu erkennen.
Wir reduzieren so die Gefahr, projektpolitische Fehler zu machen, und wissen, auf wen wir uns in Krisenzeiten verlassen können bzw. wer eine besondere Behandlung braucht. In schwieriges Fahrwasser kommen wir vermutlich mit jedem Projekt irgendwann einmal. Die Ergebnisse der Projektumfeldanalyse geben uns dann Hilfestellung und Orientierungspunkte bei unserem Bestreben, wieder in ruhigere Gewässer zu gelangen.
Im Fokus einer Projektumfeldanalyse steht also, die Interessen und Bedürfnisse aller Umfeldgruppen bei der Projektrealisierung angemessen berücksichtigen zu können. Wir versuchen dazu, folgende Ergebnisse zu erreichen:
Projektmanagement ist somit ein ganzheitlicher Prozess. Sich dabei nur auf methodische, budgetäre oder ressourcentechnische Fragen zu konzentrieren, birgt enorme Gefahren. Leider gibt es kein »Kochrezept« für ein ganzheitliches Projektmanagement. Jede Situation ist anders, die beteiligten Personen sind andere oder haben sich verändert.
Glücklicherweise können wir ein methodisches Grundgerüst dafür aufbauen. Dazu durchlaufen wir grob gesagt die folgenden Schritte:
Die technischen Themen aus dem obigen Katalog liegen uns meist ganz gut. Wie aber analysieren wir dagegen unser personelles Projektumfeld? Und was sind eigentlich Stakeholder? Konzentrieren wir uns auf die Beantwortung dieser Fragen.
Woher der Begriff Stakeholder ursprünglich kommt, scheint nicht eindeutig geklärt. Eine passende Erläuterung für unseren Kontext lautet:
Stakeholder sind Stangen mit kleinen Schildern, die im 19. Jahrhundert in den USA benutzt wurden, um ein Gebiet für eine Person abzustecken. Die Person machte damit ihren Anspruch geltend.1
Stakeholder in unserem Zusammenhang sind Interessenhalter, also anspruchsberechtigte Personen bzw. Gruppen [88]. Sie haben entweder unmittelbar Einfluss auf das Projektergebnis oder sind von den Projektzielen direkt bzw. indirekt betroffen. Stakeholder tragen damit direkt oder indirekt zu den Anforderungen an das Projektergebnis bei. Das Project Management Institute, Inc. definiert den Begriff Stakeholder folgendermaßen [53]:
Um Sie zu einem Blick über den Tellerand anzuregen, sind in der folgenden Liste beispielhaft mögliche Stakeholder-Gruppen aufgeführt.
Eine ganz schön lange Liste … Wie bekommen wir die in den Griff? Die tiefere Betrachtung der Stakeholder erfolgt in der Stakeholder Elicitation.
Den Begriff Elicitation
