Was kann Softwareentwicklung von anderen Branchen lernen?
Von Flugzeugmechanikern, Piloten und Ärzten...
Softwareentwicklung ist immer noch eine relativ junge Disziplin. Zwar haben auch wir inzwischen Best Practices entwickelt und im Laufe der Zeit hinzugelernt, wie bestimmte Dinge besser gestaltet und gemanaged werden können, aber dennoch finden wir uns häufig in Situationen wieder, wo wir uns denken "Wie konnte das bloß passieren?"
Hierbei hilft es, immer wieder einmal über den eigenen Tellerrand zu schauen und sich ein Beispiel an anderen Disziplinen oder Branchen zu nehmen. Wie werden dort häufig wieder kehrende Probleme gelöst? Was können wir uns davon für unsere eigene Arbeit abschauen?
In diesem Artikel wollen wir genau das tun: Außerhalb der eigenen Blase nach Inspiration suchen. Drei verschiedene Beispiele werden wir hierzu näher betrachten: Flugzeugmechaniker, Piloten und schließlich Ärzte bzw. medizinisches Personal im Allgemeinen. Dabei ist jedoch eine gewisse Vorsicht geboten: Auch, wenn manches als guter Denkansatz und Spiegel dienen kann die eigenen Prozesse und Abläufe kritisch zu hinterfragen, so ist es immer noch eben das: Ein Denkansatz oder ein Stups in die richtige Richtung. Wir sollten nicht den Fehler begehen und den Vergleich überstrapazieren oder gar die falschen Schlüsse ziehen, sondern immer wieder überprüfen, ob das Bild noch passt oder ein anderer Vergleich nicht vielleicht passender ist.
Lernen vom Flugzeugmechaniker
Sehen wir uns also die erste Berufsgruppe etwas genauer an: Den Flugzeugmechaniker.
Luftfahrt ist und bleibt ein hochkomplexes Umfeld mit vielen Beteiligten. Am Ende geht es jedoch immer darum, Passagiere und/oder Fracht mit einem Flugzeug von A nach B zu transportieren.
Damit dies möglichst reibungslos funktioniert und das Flugzeug als Transportmittel seine Aufgabe erfüllen kann, ist eine optimale Wartung eine der zentralen Voraussetzungen. Ein Flugzeug am Boden bringt keinen Umsatz, sondern kostet Geld – daher gilt es, diese Zeit so gering wie möglich zu halten und die Wartung so effizient wie nur möglich zu gestalten.
Optimale Vorbereitung
Eine Flugzeugwartung beginnt nicht von jetzt auf gleich damit, dass jemand den Schrauben schlüssel zückt und loslegt. Nach einem fein ausge arbeitetem Plan wird zunächst der eigene Arbeitsplatz vorbereitet und die einzelnen Bestandteile eines Flugzeugs werden separat präpariert. Nicht selten wird hierzu beispielsweise das Triebwerk komplett vom Flugzeug demontiert, um es in einer separaten Halle mit besserem Licht und besserem Zugriff auf die einzelnen Teile, frei von beispielsweise schützenden Hüllen oder Abdeckungen, besser warten zu können.
Beim Entwickeln oder Warten von Software sollten wir nicht anders vorgehen: Wenn es zum Beispiel darum geht, einen Fehler innerhalb des Persistence-Layers zu suchen und zu beheben, macht es beim Debugging nur selten Sinn, den kompletten Überbau der restlichen Anwendung mit zu starten. Und dennoch lässt sich immer wieder beobachten, wie ein kompletter Application server gestartet wird und ein HTTP-Request nach dem nächsten abgeschickt wird, um sich dann im Debugger einen Breakpoint "ganz unten" zu setzen und zu sehen, was denn in die Datenbank geschrieben wird.
Analog zur Triebswerksdemontage wäre es doch auch hier viel komfortabler, ließe sich der gesamte Zugriff auf die Datenbank "ausbauen" und isoliert betrachten. Eingaben von außen lassen sich hierbei beispielweise durch vorgefertigte Recordings oder sonstige Testszenarien simulieren und so deutlich schnellere Turnaroundzeiten erreichen.
Gerade Software hat im Vergleich zu realer Technik einen unverkennbaren Vorteil: Das Ausbauen oder Freilegen von bestimmten Systembestandteilen kann – vorausgesetzt, die Architektur unterstützt dies an den richtigen Stellen – auf Knopfdruck bzw. mit dem Setzen weniger Konfigurations parameter erreicht werden.
Es gilt daher bereits während der Entwicklung darauf zu achten, einzelne Systembestandteile möglichst gut voneinander zu isolieren und eine Art Wartungsmodus mit vorzusehen, der es ermöglicht, die "Innereien" bei Bedarf nach außen hin zu öffnen.
Daten sammeln und auswerten
Nach jedem Flugzeugabsturz ist eine der ersten Fragen, die gestellt wird: Wo ist der Flugschreiber? Welche Daten sind auf ihm gespeichert, die zur besseren Analyse dienen können? Die dort gespeicherten Informationen können wichtige Schlüsse zulassen, die zukünftige potentielle Probleme und weitere Katastrophen verhindern können.
Doch müssen wir uns gedanklich gar nicht unbedingt in ein Ausnahmeszenario begeben: Auch im Regelbetrieb funken moderne Flugzeuge eine Vielzahl an Daten "nach Hause". So lässt sich ein bevorstehender Ausfall oder eine Minderleistung eines Systems bereits frühzeitig erkennen. Korrekturen können so ebenso frühzeitig geplant und eingeleitet werden. Das Problem ist so bereits gelöst, bevor es überhaupt potentiell störende Auswirkungen erzeugen konnte.
Gute Software sollte sich genauso "gesprächig" verhalten und zentrale Informationen proaktiv speichern und zur späteren Auswertung zur Verfügung stellen.
Ob es nun Daten über die Auslastung einzelner Services oder Business-Kennzahlen sind: Nur wer eine valide Datenbasis zur Verfügung hat, kann wertvolle Schlussfolgerungen ziehen: Sind die Systeme noch gut genug dimensioniert? Sollten Prozessflüsse innerhalb der Anwendung nochmals überdacht werden, weil sie vom Benutzer nicht oder nicht wie gedacht angenommen werden? Welche Funktionalitäten werden tatsächlich intensiv verwendet und sollten daher bei Weiter entwicklungen im Fokus stehen?
Immer wieder zeigt sich, dass im voraus gemachte Prognosen über die Benutzer von Software und ihr Verhalten im Vergleich mit der Realität kaum übereinstimmen.
Und wenn es tatsächlich einmal zu einem Crash kommen sollte, lässt sich auch hier mit historischen Daten die Fehlersuche und Fehler behebung zumindest beschleunigen.
Bidirektionale Kommunikation
Flugzeugwartung findet nicht ohne eine ganze Reihe von zur Verfügung stehenden Informationen statt. Auf der einen Seite gibt es festgelegte Wartungsintervalle für bestimmte Komponenten, zusätzlich findet aber eine institutionalisierte zusätzliche "freie" Übergabe von Informationen statt.
Sowohl Piloten als auch das Kabinenpersonal haben Zugriff auf ein Wartungslogbuch in dem alle während eines Flugs aufgetretenen Probleme oder Anomalien eingetragen werden können. Egal, ob es nun um eine nicht funktionierende Kaffeemaschine, einen defekten Monitor des Entertainment-Systems oder seltsame Geräusche aus der Klimaanlage geht: Ein Logbuch, das hierüber detailliert Auskunft gibt, erlaubt es dem Wartungsteam direkt die erforderlichen Schritte einzuleiten.
Wie im vorherigen Kapitel "Daten sammeln und auswerten" bereits angedeutet, kann Software hier mit wenigen aber dafür gut positionierten Datensammelpunkten ebenfalls frühzeitig auf bestimmte Probleme hinweisen und wertvolle Tipps geben. Eine Exception wurde ausgelöst, die eigentlich so im Kontrollfluss nicht vorgesehen war? Durch einen Eintrag im Logfile mit entsprechenden Kontext informationen lässt sich schnell und einfach nachstellen, was genau zu der Ausnahmesituation geführt hat und erlaubt eine schnelle Behebung für zukünftige Benutzer.
Ruhe und Besonnenheit
Viele, die die Wartungshalle einer Flug gesellschaft betreten, sind als erstes verwundert und fragen sich: "Wo sind denn die ganzen Leute?". Typischerweise sind nur wenige Mechaniker gleichzeitig am Flugzeug zu Gange – und das hat einen guten Grund, der sich vielleicht am besten mit dem Vergleich "Zu viele Köche verderben den Brei" beschreiben lässt. Wenn jeder gleichzeitig an allen Teilen des Flugzeugs beschäftigt ist, geht die Übersicht verloren und es schleichen sich Fehler ein. Fehler sind jedoch genau das, was man vermeiden möchte, also gilt auch hier: Weniger ist mehr.
Auch und gerade in der Softwareentwicklung kann uns dies als Beispiel dienen. Wer hat es nicht schon einmal erlebt: Bei einer der von uns betreuten Anwendungen tritt ein Produktions defekt auf. Wie vom Blitz getroffen lässt das gesamte Entwicklungs team alles fallen und jeder versucht, sich auf seine Art und Weise an der Problemlösungsfindung zu beteiligen. Viel sinnvoller wäre jedoch auch hier, sich zunächst zu überlegen: Wer kann wirklich sinnvoll etwas tun und für wen ist es nicht besser, sich auf andere Dinge zu konzentrieren und denjenigen, die tatsächlich an der Störungsbeseitigung arbeiten, einfach freien Raum zu geben?
Lernen vom Piloten
Als nächstes wollen wir uns eine weitere Berufsgruppe ansehen, die thematisch noch eng mit dem Flugzeugmechaniker verbunden ist: Der Pilot.
Der Pilot muss ein komplexes System bestehend aus einer Unmenge von Teilsystemen durchblicken und in Problemsituationen innerhalb von kürzester Zeit wichtige Entscheidungen treffen, die im einfachsten Falle "nur" über das pünktliche Eintreffen am Zielort und im Extremfalle über Leben und Tod entscheiden können.
Routine ist einer der größten Feinde der Professionalität.
In der Luftfahrt gibt es daher seit langem etablierte Prozesse und Hilfsmittel, die es einem Piloten erlauben, schwierige Situationen zu meistern, oder besser noch solche Situationen möglichst gar nicht erst entstehen zu lassen.
Checklisten
Einer der sichtbarsten Punkte hierbei ist sicherlich das Abarbeiten von Checklisten. Nicht nur in Ausnahmesituationen, wie dem Ausfall eines Triebwerks, sondern auch bei alltäglichen Dingen, wie Start oder Landung, werden diese Checklisten penibel abgearbeitet.
Doch warum braucht ein Kapitän, der seit über 20 Jahren ein Flugzeug fliegt, überhaupt noch solche Checklisten? Sollte man nicht meinen, dass ihm die Abläufe bei Start und Landung nicht längst ins Blut übergegangen sind? Sehr wahrscheinlich sind sie das – doch gerade das bietet Raum für neue Fehler: Routine ist einer der größten Feinde der Professionalität.
Gerade bei immer wiederkehrenden und immer gleichen Aufgaben bringt ein unbestechliches Stück Papier dauerhafte Sicherheit. Wem von uns ist es nicht auch schon einmal passiert, dass bei einem Deployment einer neuen Anwendungsversion auf das Zielsystem ein kleiner Fehler dazu geführt hat, dass am Ende eben doch keine lauffähige Anwendung zur Verfügung stand? Ob es nun eine nicht durchgeführte Datenbankmigration oder vielleicht sogar das simple Vergessen eines Neustarts ist: Niemand von uns ist sicher vor solchen kleinen Ausrutschern.
Warum also nicht auch für Routineaufgaben während der Softwareentwicklung Checklisten verwenden? Eine Handvoll Überprüfungen kosten kaum Zeit, schaffen jedoch Sicherheit. Gehen wir noch einen Schritt weiter, so sind Checklisten geradezu Musterbeispiele und Blaupausen für Automatisierungsaufgaben. Wenn ich beim Deployment einer neuen Anwendungsversion eine Checkliste mit zehn Einträgen roboterhaft durchlaufe, um keine Fehler zu machen: Wieso dann nicht direkt die Checkliste nehmen und als Skript kodieren, welches mit einem simplen Knopfdruck gestartet werden kann?
Wieder haben wir etwas Zeit gewonnen, die wir nutzen können, um uns auf die viel interessanteren Aufgaben zu konzentrieren, die tatsächlich die volle Aufmerksamkeit und unsere Problemlösungskompetenz benötigen.
Cockpit
Das Cockpit als Arbeitsplatz des Piloten hat eine simple Aufgabe: Alle verfügbaren Informationen an zentraler Stelle zur Verfügung zu stellen und alle Operationen von ebenso zentraler Stelle zu ermöglichen. Ob es nun um die Navigation des Flugzeugs, die Kommunikation mit der Bodenkontrolle oder die Einstellungen von technischen Parametern des Triebwerks geht: Alles lässt sich vom Pilotensitz aus mit wenigen Handgriffen erledigen.
Wie anders erleben wir das häufig im täglichen Entwicklerleben? Schon alleine das Aufrufen von Informationen zwingt uns dazu eine Vielzahl an unterschiedlichen Systemen zu bedienen: Quellcode ist im Repository zu finden, Fehlermeldungen je nach Schwere und Inhalt in verschiedensten Logfiles, System informationen in wieder anderen Monitoring anwendungen, Businesskennzahlen werden als Exceldokumente in regelmäßigen Abständen auf einen FTP-Server übertragen – und so weiter.
Sicherlich: Oftmals haben alle diese Systeme ihre Daseinsberechtigung und führen die ihnen übertragenen Aufgaben richtig aus, doch die Aggregation artet schnell zu einer Sisyphusarbeit aus.
Eine Komplettlösung, die alle Probleme auf einmal behebt, ist sicherlich schwer zu finden, wenn nicht sogar unmöglich. Doch was hält uns davon ab, die Idee eines Cockpits auch auf eine Anwendungslandschaft zu übertragen? Ein simples Dashboard, das aggregiert bestimmte Informationen anzeigt, ist hier bereits ein wertvoller erster Schritt: Unterschiedliche Kennzahlen nebeneinander zu sehen und vergleichen zu können, erlaubt bereits gute Schlussfolgerungen und eine Ableitung nächster Schritte: Die Auslastung der Hardware steigt plötzlich rasant an. Können wir direkt daneben erkennen, dass auch die Benutzer anfragen an das System in gleichem Maße ansteigen, so ist die Quelle ausgemacht und ein Hardwarefehler erscheint nicht als wahrscheinliche Ursache. Sind dann auch Businesszahlen bzw. Informationen verfügbar, die beispielsweise belegen, dass ein neuer Angebotszeitraum begonnen hat, so erscheint die Zunahme als logische Schlussfolgerung und deutet nicht auf ein außergewöhnliches Ereignis hin, das näher untersucht werden muss.
Auch Aktionen lassen sich so an einem zentralen Ort zusammenfassen: Das Ändern bestimmter Konfigurationswerte oder sonstiges "Finetuning", das basierend auf den zur Verfügung gestellten Informationen angestoßen werden kann, erlaubt ein schnelles und einfaches Anpassen der Software sowohl auf technischer aber auch auf Business-Seite.
Standardisierte Sprache
Wer einmal eine Fernsehdokumentation aus der Cockpit-Perspektive gesehen hat, dem wird vielleicht der gefühlte "Mischmasch" aus Sprachen aufgefallen sein, der dort gesprochen wird. Obwohl zwei deutsche Piloten im Cockpit einer deutschen Fluglinie sitzen und sich über die tolle Aussicht auf Deutsch unterhalten, fallen plötzlich Sätze in Englisch. Warum diese Mischung?
Um für Konsistenz zu sorgen, sind die Piloten verpflichtet, sämtliche für den Flugbetrieb relevante Kommunikation in Englisch zu führen. Das schafft zusätzliche Sicherheit. Ist ein Pilot beim nächsten Flug mit einem internationalen Kollegen unterwegs, der kein Deutsch versteht, so benötigt er keinerlei Umgewöhnung oder Zeit, sich zu überlegen, wie bestimmte Sachverhalte in Englisch beschrieben werden.
Auch der Inhalt der Kommunikation ist häufig präzise definiert. Nach einer Flugkatastrophe 1977 am Flughafen von Teneriffa wurde zum Beispiel der Unterschied zwischen "Departure" und "Take off" nochmals klar definiert. Departure wird hier für alle Aktionen am Flughafen verwendet, die vor dem Start passieren. Erst bei der Freigabe "cleared for take off" durch die Flugsicherung darf der Pilot tatsächlich das Flugzeug in die Luft bewegen. Auch und gerade im Projekt und Entwicklungs alltag können wir von einer solchen standardisierten Ausdruckweise nur profitieren.
Wer hat es nicht schon erlebt, welche geradezu monumental unterschiedlichen Auffassungen verschiedene Projektteilnehmer mit der Aussage "Ich bin fertig" verbinden. Wo der eine mit dieser Aussage impliziert, dass die gewünschten Änderungen bereits umgesetzt wurden, die Build pipeline durchlaufen wurde, alle Tests grün sind und die neueste Version der Software schon auf den Produktionssystemen zur Verfügung steht, impliziert die Aussage, getroffen von einem anderen Kollegen, vielleicht nur, dass er sich Gedanken über potentielle Auswirkungen gemacht hat, aber noch keinerlei tatsächliche Aktionen durchgeführt hat.
Eine gemeinsame "Definition of Done", in der sich das Entwicklungsteam selbst einen Satz an Regeln gibt, die während des Entwicklungs prozesses eingehalten werden müssen, schafft nicht nur einen Rahmen, der potentielle Missverständnisse von Anfang an minimiert, sondern führt typischerweise auch zu einem erhöhten Qualitätsbewusstsein. Wer möchte schon derjenige sein, der durch Unachtsamkeit oder das Nichtbefolgen der selbst gesetzten Regeln dafür verantwortlich ist, die Kollegen am Fortkommen zu hindern?
Plan B
Kaum ein Pilot geht vor jedem Start tatsächlich davon aus, dass während des Abfluges ein größeres technisches Problem auftritt, dass ihn dazu zwingen wird, den Start abzubrechen oder sonstige gravierende Änderungen am Flugprofil machen zu müssen. Und dennoch werden für die verschiedensten Fälle frühzeitig Alternativen durchgesprochen und als "Plan B" festgehalten. Bis zu welcher Geschwindigkeit lässt sich im Falle von Vogelschlag der Start noch abbrechen? Welche Ausweichflughäfen stehen zur Verfügung, sollte am Zielflughafen entgegen der Vorhersage doch ungeplant schlechtes Wetter auftreten? Diese und ähnliche Situationen werden im Vorfeld intensiv besprochen, um entsprechende Alternativen ohne große Verzögerung abrufen zu können.
Auch in der Softwareentwicklung begegnen uns immer wieder ungeplante Ereignisse. Schnittstellen zu Drittsystemen, die nicht rechtzeitig zur Verfügung stehen. Updates vom Betriebssystem oder anderen Komponenten, die sich doch nicht so schmerzlos, wie ursprünglich gedacht, herausstellen. Vorhersagen bezüglich Nutzerverhalten oder Zugriffszahlen, die sich beim Kontakt mit der Realität eher als Wunschträume denn als belastbare Werte herausstellen. Dies sind nur ein paar Beispiele von Dingen, die uns das Leben schwer machen. Und dennoch ist es erstaunlich, wie häufig Annahmen ungeprüft übernommen werden, auf die dann nächtelange "Feuerwehraktionen" oder andere Recovery-Maßnahmen getroffen werden müssen.
Dabei muss gar nicht für jedes Problem im vorhinein eine komplette Lösung bereits feststehen – es reicht oftmals schon, sich die nächsten Schritte klar zu machen. Ein Deployment einer neuen Softwareversion soll stattfinden? Auch wenn die Abnahme bereits erreicht wurde und alle Testfälle grün sind, fühlen sich alle Beteiligten sicherer, wenn ein Entwickler für einen halben Tag bereitsteht, um potentielle Probleme schnell analysieren zu können.
Wie auch in der Luftfahrt wird in den allermeisten Fällen von solchen Notfallmaßnahmen kein Gebrauch gemacht werden müssen, aber sollte es doch zum Fall der Fälle kommen, werden alle Beteiligten hinterher beruhigt resümieren: "Gut, dass wir uns darauf vorbereitet hatten".
Lernen vom Arzt
Die letzte Berufsgruppe, die wir uns in diesem Vergleich anschauen wollen, ist der Arzt. Zwar werden auch hier nicht an jedem Arbeitstag jede Minute Entscheidungen verlangt, die über Leben und Tod entscheiden, dennoch ist der Beruf immer mit einer großen Verantwortung verbunden.
Patientenverständnis
Ein zentrales Element in der Kommunikation zwischen Arzt und Patient ist das gegenseitige Verständnis. Welcher Patient würde sich schon gerne von einem Arzt behandeln lassen, bei dem nach der Erklärung der Diagnose mehr Fragen offen als geklärt sind? Natürlich ist medizinische Fachsprache wichtig: Sie erlaubt es Medizinern, untereinander komplizierte Sachverhalte kurz und knapp zu beschreiben. Dennoch erwarten wir als Patienten (zu Recht) von jedem Arzt die Fähigkeit, die Befunde in einer auch für uns Laien verständlichen Sprache zu erläutern. Doch verhalten wir uns in der IT tatsächlich so viel besser?
Fachbereiche bzw. Auftraggeber von Softwarelösungen werden hier sicherlich häufig mit "Nein" antworten. Ebenso wie Ärzte bzw. Mediziner im Allgemeinen ihre Fachsprache verwenden, so haben wir in der IT unser ganz eigenes Vokabular. Auch uns hilft es, komplizierte Sachverhalte zu verkürzen und damit Zeit zu sparen. Kaum jemand von uns würde zu einem Kollegen sagen: "Ich muss zunächst den aktuellen Quellcodestand eindeutig markieren und anschließend aus den vorliegenden Artefakten eine Binärversion erzeugen, die ich dann mit Hilfe von vorgefertigten technischen Produkten in eine Produktivumgebung überführe, von wo aus sie dann dem Endbenutzer zur Verfügung gestellt wird". Stattdessen werden wir wahrscheinlich sagen: "Ich werde ein getaggtes Release auf Produktion deployen".
Wer selbst einen Puls von 120 hat, wird den Puls eines anderen Menschen nicht korrekt ertasten.
Unsere Zusammenarbeit und die Wahrnehmung unserer Kompetenz (und letzten Endes auch unsere eigene Daseinsberechtigung) hängt aber davon ab, von den fachlich Verantwortlichen nicht nur verstanden, sondern geschätzt zu werden. Software existiert nicht in einem Vakuum, sondern muss immer Lösung für real existierende Probleme sein. Nur, wenn sowohl die eigentlichen Probleme als auch die vorgeschlagenen Lösungen von allen Beteiligten mit einem gemeinsamen Vokabular verstanden werden, lassen sie sich auch korrekt implementieren und damit wertbringend einsetzen.
Ruhe und Besonnenheit
Wir alle kennen es aus diversen Arztserien: Der Patient liegt an einer Unfallstelle und muss sofort medizinisch versorgt werden. Es zählt jede Sekunde. Die Retter tun alles, um so schnell wie möglich zum Patienten zu kommen: Wildes Slalomfahren entgegen der Einbahnstraße und im Anschluss einen Marathonlauf um zur abgelegenen Unfallstelle zu kommen.
Doch ist dies alles realistisch? Wohl eher nicht. Wer einmal einen Arzt oder einen Rettungs sanitäter bei der Anfahrt zum Unfallort gesehen hat, der wird schnell merken: Natürlich wird dort keine Zeit vertrödelt, aber Vorankommen um jeden Preis wird man dort auch nicht finden – und das hat gute Gründe. Ein Arzt, der vollkommen aus der Puste nach einem Fünfhundertmetersprint beim Patienten eintrifft, wird ihm dort keine große Hilfe sein. Wer selbst einen Puls von 120 hat, wird nicht in der Lage sein, den Puls eines anderen Menschen korrekt zu ertasten. Wer selbst vor Erschöpfung eine Pause benötigt, wird keine lebensrettenden Entscheidungen treffen können. Und wer vorher mit Kamikazemanövern im Straßenverkehr den Rettungswagen in den Graben gefahren hat, wird selbst Hilfe benötigen und nicht in der Lage sein, eben diese jemand anders zur Verfügung zu stellen. Es ist daher auch im Sinne des Patienten, wenn der Arzt seine eigenen Grenzen kennt und sich entsprechend ruhig und besonnen bewegt.
In der Softwareentwicklung finden wir häufig jedoch genau das zuerst geschilderte Verhalten: kopf- und sinnloses Agieren frei nach dem Motto "Irgendwas zu tun, ist immer besser, als nichts zu tun".
Anstatt sich bei einem Major Defect im Produktionssystem zunächst zu überlegen: Wer kann zur Problemlösung beitragen und welche Ressourcen sollten wir jetzt involvieren?, läuft jedes Team-Mitglied auf eigene Faust los und glaubt, mit genügend hohem Einsatz lässt sich alles schon irgendwie lösen. Doch auch hier sollte man sich die Frage stellen: Ist das tatsächlich der richtige Weg? Welche konkreten Auswirkungen hat der Defect? Ist es gerechtfertigt, das gesamte Entwicklungsteam von anderen Dingen abzuziehen und diese (vielleicht ebenso wichtigen Punkte) komplett zu ignorieren? Auch und gerade in Ausnahmesituationen überlegt zu handeln, führt üblicherweise nicht nur zu einer schnelleren Lösung des Problems, sondern erzeugt auch die wenigsten "Kollateralschäden" bei der Behebung.
Zusammenfassung
Auch wenn Softwareentwicklung ihre eigenen Anforderungen, Regeln und Gesetze hat, so hilft es doch immer wieder, gedanklich einen großen Schritt zurück zu treten und von außen auf festgefahrene Prozesse und Dinge zu schauen, "die wir immer schon so gemacht haben". Sich hierbei von ganz anderen Berufen inspirieren zu lassen kann dabei helfen, aus der eigenen Blase herauszutreten und Verbesserungen zu sehen, die das eigene Leben einfacher machen.
Die hier vorgestellten Beispiele sollen dazu dienen, eine Inspiration zu geben, wie ein solcher Vergleich aussehen kann und welche Schlüsse man hieraus ziehen kann. Auch für uns gilt das Zitat von Irmgard Nägele: "Der Blick über den Tellerrand ermöglicht nicht nur einen neuen Horizont, er zeigt auch die eigenen Begrenzungen auf."
