Kolumne

Knigge für Softwarearchitekten: Die Gegner

Gernot Starke, Peter Hruschka

©iStockphoto.com/WoodenheadWorld

Diese Folge unserer Kolumne skizziert mögliche Reaktionen, die Sie bei Reviews (auch genannt Bewertung, Analyse oder Audits) von Softwaresystemen erleben können. Wir beschäftigen uns mit Gegnern und verschiedenen Stufen der Ablehnung.

Ausgangspunkt: Ein Review

Vor Änderungen oder Verbesserungen an Software hilft es ungemein, wenn Sie sich zuerst einen Überblick über vorhandene Risiken, Probleme und deren Ursachen verschaffen. Sie können diese Probleme systematisch aufdecken, und dazu passende Lösungs- oder Abhilfemaßnahmen entwerfen.
Sie haben mit einem kleinen Team erfahrener Softwerker einen gründlichen Review eines Softwaresystems und der damit verbundenen Entwicklungsprozesse durchgeführt. Qualitative Analyse (nach ATAM), statische Codeanalyse, Laufzeitmessungen (Profiling) sowie die Analyse der beteiligten Daten, begleitet durch systematische Interviews der wesentlichen beteiligten Personen haben Ihnen geholfen, viele Risiken und Probleme aufzudecken. Sie haben technische Schulden entdeckt und einige frühere Entwurfs- und Implementierungsentscheidungen als Ursache für Qualitätsdefizite identifiziert.
Anschließend haben Sie Vorschläge für Verbesserungsmaßnahmen erarbeitet, sowohl für das Vorgehen im Projekt als auch strukturell oder konzeptionell in Architektur, Quellcode und Datenstrukturen der Software. Schließlich stellen Sie Ihre Ergebnisse im Rahmen einer Abschlusspräsentation den beteiligten Stakeholdern vor.

Die Stufen der Reaktion

Egal wie Ihre Untersuchungsergebnisse konkret aussehen – als Reaktion auf eine Liste von Risiken und Problemen werden Sie einige typische Verhaltensmuster erleben (Abb. 1):

• Einige Personen werden enthusiastisch zustimmen: „Das haben wir schon immer gesagt – aber niemand wollte auf uns hören!“. Wahrscheinlich haben Ihnen diese Enthusiasten in Interviews eine Menge Details aus dem Nähkästchen erklärt, Sie sozusagen auf direktem Weg auf die vorhandenen Probleme und Schwachstellen hingewiesen. Sie versprechen sich normalerweise von Ihren Ergebnissen eine direkte Verbesserung ihrer eigenen Situation.
• Manche Stakeholder stimmen Ihren Ergebnissen zu, ohne sich besonders dazu zu äußern.
• Wieder andere betrachten Ihre Resultate völlig neutral. Diese Stakeholder sind oft von den gefundenen Problemen oder Abhilfemaßnahmen nicht betroffen.
• Nun wird es langsam interessant – beziehungsweise es weht der kalte Wind der Ablehnung. Die weiteren Stufen möchten wir Ihnen etwas detaillierter präsentieren.

Abb. 1: Reaction Levels

Verwunderung

Manche Beteiligte am System oder Projekt werden Sie durch Ihre Ergebnisse völlig überraschen: „Das hätten wir aber nicht erwartet…“
Verwunderte Stakeholder benötigen Aufmerksamkeit – denn Verwunderung kann schnell in Zweifel oder Ablehnung umschlagen: Unserer Ansicht nach sollten Sie bei dieser Gruppe gründlich nachfragen, aus welchen Gründen sie verwundert oder überrascht sind – oder welche alternativen Resultate sie erwartet hätten. Das kann Ihnen relevanten Input zur Verbesserung liefern, andererseits auch Ihre eigene Argumentation verbessern helfen. Dieses „Aufmerksamkeitschenken“ nehmen Stakeholder als positiv wahr – was wiederum die Akzeptanz von Resultaten fördert. Verwunderte Stakeholder können Sie oftmals schon durch leichte Argumentation in zustimmende Stakeholder transformieren.

Zweifel

„Kann gar nicht sein!“ – solche oder ähnliche Ausdrücke des Unglaubens hören Sie von Personen, denen die Ergebnisse eines Audits oder einer Untersuchung nicht gefallen. Bei Zweiflern haben Sie Chancen mit rationalen, nachvollziehbaren Argumenten – aber Sie müssen vermutlich kräftig in Ihre Argumente investieren. Erläutern Sie, auf Basis welcher Fakten Sie Ihre Schlüsse gezogen haben – und manche Zweifler werden Ihnen zustimmen können. Falls Zweifler stark emotional geprägt sind (sprich: Argumente sind egal!), hilft nur noch Kommunikation für Fortgeschrittene: Sie müssen Ihre (für die Zweifler oft unbequemen) Ergebnisse emotional verpacken – eine schwierige Übung. Wir möchten hier auf keinen Fall vorschlagen, inhaltliche Zweifler durch „Druck von oben“ zum Schweigen zu bringen.
Prüfen Sie die Argumente der Zweifler: Es könnte gut sein, dass Sie von Zweiflern noch interessante (und für Sie neue) Aspekte des Problems kennen lernen.

Verniedlichung

„Ist doch nicht schlimm…“ – in der Psychologie als „Minimisierung“ bezeichnet: Betroffene Personen erkennen einen Fehler oder ein Problem an, bestreiten aber dessen Ernsthaftigkeit. Das Problem wird sozusagen kleingeredet.
Bei diesen Stakeholdern beginnt die echte Gefahr für Ihre Ergebnisse: Wir haben erlebt, dass gerade Manager und Entscheider dazu tendieren, das Verniedlichen als Taktik gegen die Reviewer einzusetzen: Lauthals und auf breiter Front wird das „Ist doch nicht so schlimm“-Mantra wiederholt – und damit sowohl die möglichen Auswirkungen von Problemen in Abrede gestellt als auch mögliche Verbesserungen versteckt oder ignoriert. Da solche Manager in der Regel über ausgezeichnete politische und organisatorische Kontakte verfügen, haben Sie es als Reviewer äußerst schwer, dieser Reaktion mit entsprechenden Mitteln zu begegnen. Verniedlicher ziehen oftmals die Zweifler (siehe voriger Absatz) auf ihre Seite.
Unser Rat: Beschaffen Sie sich Rückendeckung hoch- und höchstrangiger Entscheider – das sorgt zumindest dafür, dass latent opportunistische Verniedlicher sich sehr schnell auf Ihre Seite schlagen werden.

Widerstand und Opposition

„Denen zeig’ ich es – die haben doch keine Ahnung!“. Starke inhaltliche Ablehnung, entweder offen ausgesprochen oder verdeckt lanciert wird Ihnen begegnen, wenn Sie eine Menge negativer Resultate bei Audits oder Reviews entdeckt haben.
Spätestens jetzt sollte Ihnen klar werden, dass Sie als Überbringer schlechter Nachrichten ein dickes Fell und gehöriges politisch-strategisches Geschick benötigen: Früher nahmen Herrscher „Kill the Messenger“ wörtlich, heute drohen aktiver Widerstand und passives „Auflaufenlassen“.
Sie können Widerstand und Opposition fast nie mit rein sachlichen Argumenten auflösen, vielmehr benötigen Sie Hilfe aus Politik, Wirtschaft und Psychologie (und evtl. die Lektüre des berühmten Werks „Die Kunst des Krieges“).
Politik ist nötig, um Ihren Argumenten auch organisatorischen Rückhalt im Management zu verschaffen. Nur mit technischen Argumenten klappt das nicht, daher benötigen Sie zusätzlich betriebswirtschaftliche Argumente: Beantworten Sie die Frage nach den Kosten der von Ihnen gefundenen Probleme (aim42 nennt diese Praktik Problem Cost). Zu guter Letzt hilft Psychologie beim Umgang mit Opposition Ihnen, die Emotionen Ihrer Gegner zu adressieren (siehe dazu folgendes Buch). Aber es kann noch schlimmer kommen…

Feindschaft

„Die mach’ ich fertig!“. In der Historie von Systemen haben Personen manchmal prägende (Fehl-)Entscheidungen getroffen – die Sie als Reviewer jetzt aufgedeckt haben. Wenn Personen solche Entdeckungen persönlich nehmen, kann das in extremen Fällen bis zur Feindschaft führen. Entweder als subtile Nadelstiche, versteckte Guerillataktik oder offene Auseinandersetzung, ist solche Feindschaft die schlimmste Reaktion auf das offene Aussprechen von Problemen. Stakeholder, die nach Reviews zu Feinden werden, fühlen sich (manchmal sicherlich zu Recht) beschuldigt. In solchen Fällen sollten Sie sich auf Mobbing seitens Ihrer Gegner einstellen, auf direkte Konfrontation, auf Diskreditierung oder Schuldzuweisungen. Jegliche Schwachpunkte Ihrer Argumentation werden diese Menschen nutzen, Sie als Person zu demontieren. Feinde begnügen sich nicht mit dem Entkräften einzelner Argumente – Feinde sinnen auf Rache für (angeblich) zugefügtes Unrecht. Sie werden insbesondere jegliche formale Schwäche ausnutzen (und solche Formfehlerchen können Ihre Feinde mit etwas Fantasie immer finden!), den gesamten Bericht in Frage zu stellen.

Sorgfalt schützt gegen Angriffe

Sie können Angriffe oder Beschuldigungen Ihrer Gegner nicht verhindern, durch Sorgfalt bei Recherche und Aufarbeitung Ihrer Ergebnisse aber deren Möglichkeiten für Ausreden oder Angriffe signifikant verringern. Stellen Sie Traceability Ihrer Thesen sicher: Jede (!) sollte durch Fakten verifiziert sein. Wenden Sie das Vier-Augen-Prinzip an und lassen Unabhängige Ihre Aussagen gründlich überprüfen. Führen Sie schriftliche Protokolle bei Interviews, merken Sie sich relevante Fundstellen im Sourcecode oder in anderen technischen Artefakten.
Kurzum – ganz klassisch gründlich arbeiten. In schwierigen Fällen darf das auch mal penibel wirken – Ihren Gegner nimmt das den Wind aus deren Segeln.

Fazit

Erwarten Sie Widerstand! Praktisch immer werden bei Reviews oder Audits manche der Beteiligten, eventuell die Verursacher der erkannten Probleme oder deren Sympathisanten, protestieren und Ihre Analyseergebnisse für ungültig oder fehlerhaft erklären.
Je gravierender die Probleme sind, die Sie bei Reviews oder Audits finden, desto mehr Sorgfalt müssen Sie bei deren Aufarbeitung und Nachweis aufbringen. Wir wünschen Ihnen viel Erfolg (und ein dickes Fell)!
PS: Wir bedanken uns vielmals bei Michael Mahlberg und Oliver Tigges für die hilfreichen Reviews dieses Artikels!

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: