Knigge für Softwarearchitekten

Dr. Gernot Starke

Peter Hruschka

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 ([1], [2]) und dazu passende Lösungs- oder Abhilfemaßnahmen entwerfen ([2]).

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, [1]), 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 (siehe Abbildung 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. Diese Enthusiasten 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.

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 „Aufmerksamkeit-schenken“ 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.

Prüfen Sie in jedem Fall 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 ([3]) 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 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 widerholt – 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 das „kill-the-messenger“ wörtlich, heute drohen aktiver Widerstand und passives „Auflaufen-lassen“.

Sie können Widerstand und Opposition fast nie mit rein sachlichen Argumenten auflösen, vielmehr benötigen Sie Hilfe aus Politik, Wirtschaft und Psychologie (möglicherweise würde es darüber hinaus helfen, das berühmte Werk „Die Kunst des Krieges“ [4] verinnerlicht zu haben).

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 [2] nennt diese Praktik Problem Cost). Zu guter Letzt hilft Psychologie beim Umgang mit Opposition Ihnen, die Emotionen Ihrer Gegner zu adressieren (siehe [5]).

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 zurecht, 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 in Sourcecode oder 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!

Referenzen