Kreativität im Software Engineering
"Kreativität? Dieses Kapitel können wir überspringen, sowas machen wir hier nicht!" So höre ich das gelegentlich in Firmenschulungen. Diese Aussage schockiert und verblüfft mich immer wieder. Wieso arbeiten Berater und Programmierer nicht kreativ? Ich knoble ständig an kreativen Aufgaben – proaktiv oder zumindest reaktiv!
Proaktive Kreativität im Software Engineering geht so: "Der Kunde hat uns damit beauftragt, die alte Software neu zu programmieren, mit derselben Funktionalität, nur doppelt so schnell. Doch wenn wir schon dabei sind, das gesamte System von null an neu zu erstellen, dann nutzen wir die Gelegenheit, um den Arbeitsprozess zu optimieren. Vielleicht erfinden wir sogar Benutzerinteraktion ganz neu. Wie kann unsere Technologie die Anwender optimal unterstützen?" Das macht vermutlich wirklich nicht jedes Projektteam, aus Mangel an Zeit und Budget. Aber schade ist das schon.
Reaktive Kreativität im Software Engineering geht so: "Mist, so wie wir uns das gedacht hatten, funktioniert es technisch nicht. Was tun? Irgendwie müssen wir die Software trotzdem zum Fliegen bringen!" Jedes Problem, das sich nicht sofort mit einer offensichtlichen Standardlösung beheben lässt, fordert unsere Kreativität.
Kreativ zu sein bedeutet, auf eine Frage eine nicht offensichtliche Antwort zu finden, für ein Problem eine nicht offensichtliche Lösung. Kreativitätstechniken helfen dabei, um strukturiert solche Ideen zu entwickeln und zu bewerten. Manchmal genügt aber auch das ganz normale systematische Software Engineering.
Man kann sich den kreativen Prozess vorstellen wie eine Raute: Zuerst definiert man eine eng formulierte Arbeitsfrage, dann denkt man in die Breite und sucht nach möglichst vielen Antworten. Anschließend engt man das Feld der möglichen Lösungen durch rationale Überlegungen immer mehr ein, bis am Ende die optimale Idee übrig bleibt, die man umsetzen möchte.
Das gilt für alle Bereiche des Software Engineering, in denen man kreativ werden kann: Im Requirements Engineering, im Architekturentwurf, beim Programmieren, Testen oder bei der Projektleitung. Im Folgenden sehen wir uns zunächst diese Tätigkeiten einzeln an und anschließend einige praktische Tipps und Techniken.
Kreativität im Requirements Engineering
Am Anfang des Projektes erwartet man Kreativitätssitzungen am ehesten: Wenn im Start-up auf der grünen Wiese ein ganz neues Produkt erschaffen wird, dann lässt man die Gedanken schweifen, denkt kreuz und quer und dann zeigt man den etablierten Langweilern mal so richtig, was sie bisher übersehen haben.
In den meisten Software-Projekten startet man jedoch weder auf der grünen Wiese, noch empfiehlt es sich, ein Produkt ganz neu zu erfinden oder gar die Art der Benutzerführung zu revolutionieren. Oft ist der durch die Software zu unterstützende Arbeitsprozess bereits vorgegeben, durch den Kunden oder durch Branchenstandards. Erwartungskonformität gehört zu Recht zu den Kriterien der Benutzerfreundlichkeit, denn der Anwender erwartet doch die gewohnten Bedienelemente, um sich schnell zurecht zu finden. Eine allzu kreative Benutzerführung garantiert geradezu das Irregehen des Benutzers. Der Raum für Innovationen ist also eingeschränkt. Man sollte aber nicht den Kunden allein kreativ sein lassen. Der denkt sich leicht aberwitzige Funktionen aus, die eher in einen Science-Fiction-Film passen als zur verwendeten Technologie. Besser sollte der Auftragnehmer sich Funktionen ausdenken, die technisch leicht zu realisieren sind und dennoch nützlich.
Sogar im Requirements Engineering ist Kreativität oft reaktiv, beispielsweise wenn man beim Prototypenbasteln feststellen muss, dass nicht alle gewünschten Informationen auf den Bildschirm passen oder wenn der Kunde sich etwas ausdenkt, das technisch nicht funktionieren kann. In diesen Fällen hilft es, einen Schritt zurückzutreten. Die gewünschte Software-Funktion lässt sich so nicht umsetzen, aber was ist deren Zweck? Lässt sich dieser Zweck auch anders erreichen?
Kreativität bei Entwurf und Implementierung
Auch bei der Auswahl der Technologie, dem Entwurf der Architektur und der Implementierung bleibt Raum für Kreativität, da oft mehrere Lösungen zur Verfügung stehen, welche die Anforderungen mehr oder weniger gut erfüllen. Tatsächlich wird der erfahrene Softwareingenieur hier auf bewährte Standardlösungen wie Programmierparadigmen, Muster, Bibliotheken und Wiederverwendung setzen. Die einfachste Lösung ist oft die beste. Reaktive Kreativität zur Problemlösung ist jedoch auch hier vonnöten. Nicht immer tut die gewählte Technologie das, was versprochen war. Ein paar Beispiele aus meiner Praxis: Der Hardwarelieferant hatte die Abmessungen seines Produktes derart geändert, dass das Teil nicht mehr mit den anderen zusammenpasste. Nein, die hatten keines von den alten Modellen mehr in ihrem Lager rumliegen. Die Lösung bestand darin, aus unserem eigenen Fundus ein gebrauchtes Teil zu verwenden, das sich entbehren ließ. Als kurzfristige Lösung funktionierte das, für die nächsten Projekte musste natürlich eine Recherche durchgeführt und gleich etwas anderes bestellt werden. Eine typische Falle ist auch die Verwendung von Drittsoftware. Man klickt auf einen Button oder ruft eine DLL auf und bekommt die mehr oder weniger direkte Meldung "Diese Funktion ist noch nicht implementiert." Und nun? Gerade Zeitdruck fordert Kreativität, weil die naheliegende Idee, die Funktion selbst zu programmieren, sich nicht immer noch spontan bis zum Abgabetermin umsetzen lässt.
Kreativität beim Testen
Der gute Tester ist genauso kreativ wie der DAU und der bösartigste Hacker zusammen.
Das Testen einer Software ist eigentlich eine systematische Tätigkeit: Man nehme die Anforderungen und teste, ob diese alle erfüllt sind, einschließlich aller Fälle und Sonderfälle. Der gute Tester jedoch prüft nicht nur, ob der Idealverlauf eines Benutzungsszenarios funktioniert, also das System das Richtige tut, sondern auch, ob das System das Falsche nicht tut. Wie werden Benutzerfehler abgefangen? Und was, wenn jemand böswillig versucht, das System auszutricksen? Der gute Tester ist genauso kreativ wie der DAU ("Dümmster Anzunehmender User") und der bösartigste Hacker zusammen. Er treibt das System an dessen Grenzen und darüber hinaus.
Kreativität im Projektmanagement
"Alles was schief gehen kann, geht schief", besagt Murphy's Gesetz. Doch wir brauchen uns vor Risiken nicht zu fürchten, wenn wir sie kommen gesehen haben und die passende Gegenmaßnahme bereit halten. Eine Sitzung für die Risikoidentifikation am Projektanfang ist eigentlich ein proaktiver Kreativitätsworkshop. Falls irgendein Risiko das Projekt dann doch eiskalt erwischt, kommt zur proaktiven Kreativität wieder die reaktive dazu.
Der kreative Prozess
Systematisch! Bei meinen Vorträgen über Kreativität wundern sich viele, wie systematisch man Kreativität organisieren kann. Ich halte wenig davon, bunte Wattebällchen herumzuwerfen oder mit anderen Kinderspielchen die Kreativität anzuregen. Kreativität im Software Engineering beruht auf Fakten und Erfahrung. Ich empfehle darum folgendes Vorgehen:
Erstens: Verantwortlichen festlegen
Eine Person muss den kreativen Prozess moderieren und antreiben. Insbesondere wenn er ins Stocken gerät. Die proaktive Kreativität gilt als optionales, eventuell unnötiges Add-on, die reaktive schmerzt, weil man sich mit schwer zu lösenden Problemen beschäftigt. Eine nicht-kreative Lösung war nicht gut genug und jetzt ist man vorübergehend ratlos. Das tut weh. Darum schläft der kreative Prozess ohne Antreiber gerne ein, bevor die Lösung gefunden ist.
Zweitens: Fakten sammeln
Zuerst müssen wir wissen, wo wir stehen, dann, wo wir hin wollen, und dann finden wir schon den Weg vom Ist zum Soll. Zuerst sammeln wir also Fakten: Wo stehen wir? Worin genau besteht die Herausforderung, das Problem, die zu beantwortende Frage, das zu erreichende Ziel? Was sind Kriterien für eine gute Lösung? Was wissen wir? Was wissen wir nicht? Wer, warum, wie, wozu, wohin, wann, seit wann, bis wann?
An diesem Faktensammeln beteiligt man möglichst viele Wissensträger:innen. Da Workshops mit mehreren Personen schwierig zu organisieren sind und wir für die späteren Schritte stärker die Diskussion unter unseren Experten benötigen, sammle ich diese Fakten durch Einzelgespräche mit allen, die sich irgendwie auskennen mit dem Problem oder der Lösung oder vielleicht sogar unbeteiligte Dritte. Zuerst nennt man ihnen das Thema, dann setzt man sich ein paar Tage später zum Gespräch zusammen. So erhält das Gehirn des Ansprechpartners Zeit, um sich – auch unterbewusst – damit zu beschäftigen. Tags darauf erhalte ich eventuell noch eine Follow-up-Mail oder einen kurzen Anruf, weil demjenigen noch etwas eingefallen ist. Das ist ein ganz normaler Effekt im kreativen Prozess. Was auch immer dabei zusammenkommt, wird aufgeschrieben und sortiert. Obwohl das Ziel eigentlich war, Fakten zu sammeln, kommen jetzt auch schon Meinungen, Einschätzungen und Lösungsideen zusammen. Aufschreiben, aber separat!
Drittens: Problem formulieren
Bei der genauen Analyse der Fakten stellt sich oft heraus, dass das Problem nicht dort liegt, wo man zuerst glaubte. Man sollte möglichst zu den Ursachen zurück gehen. Der Auslöser, der den kreativen Prozess angestoßen hat, ist eventuell nur das Symptom für ein tieferliegendes anderes Problem. Wichtig ist es, das zu lösende Problem oder die zu beantwortende Frage möglichst präzise zu formulieren. Je konkreter die Frage, umso konkreter und passender die Antworten.
Viertens: Ideen sammeln
Jetzt erst kommt das, was man allgemein für die kreative Arbeit hält: das Erzeugen von Ideen. Hier empfiehlt sich ein Workshop mit Beteiligten, die möglichst alle Sichten abdecken: Benutzersicht, technische Sicht, Managementsicht. Das Auswahlkriterium für die Teilnehmer:innen ist vor allem ihre Expertise. Zusätzlich müssen sie alles über die Vorarbeiten erfahren: Was ist das Problem? Was ist bekannt? Was ist das Ziel?
Wichtig ist im Workshop erstens eine gute Moderation, die eine offene, konstruktive und entspannte Atmosphäre schafft und auf Ergebnisse hinarbeitet. Zweitens müssen alle Ideen zuverlässig protokolliert werden. Am besten führt darum das Protokoll nicht der Moderator, weil es sehr schwierig ist, gleichzeitig das gerade Gesagte zu notieren und den weiteren Verlauf zu steuern.
Die besten Ideen entstehen nicht nur spontan in der Sitzung. Diese reifen oft auch noch im Nachgang. Schaffen Sie eine Möglichkeit, wie die Teilnehmer:innen in den folgenden Tagen noch Ideen nachliefern können.
Fünftens: Ideen auswählen
Erst nachdem man so viele Ideen gesammelt hat wie möglich, beginnt das Sortieren und Bewerten. Manche zunächst nicht machbar erscheinende Lösung stellen sich bei näherer Betrachtung als machbar heraus, zumindest in einer Variante. Darum gilt grundsätzlich: erst sammeln, dann sortieren.
Von Anfang sollten ja die Kriterien für eine gute Lösung bekannt sein. Diese verwenden Sie nun, um aus allen gesammelten Ideen zunächst die unbrauchbaren auszusortieren und den Rest zu priorisieren. Gerade technische Lösungen können nicht ad hoc bewertet werden, sondern es werden dann Recherchen oder die Erstellung eines Prototyps nötig. Darum kann diese Bewertung meist nicht in einer einmaligen Expertensitzung erledigt werden. In so einer Sitzung sammelt man erstmal nur Vermutungen und Ansätze für das weitere Vorgehen. Was wissen wir schon, was nicht? Und wo besorgen wir uns das fehlende Wissen? Wer macht es und bis wann?
Auch hier ist der Moderator des kreativen Prozesses gefragt, der immer wieder nachhakt, bis alle nötigen Informationen zusammengetragen sind und die Lösung ausgewählt werden kann. An Qualitätskriterien für die Bewertung von Lösungen fehlt es nicht, gibt es dafür doch Standards wie die ISO 25010 und ISO 9241 und zusätzlich die Kundenanforderungen.
Sechstens: Nachverfolgung
Bis die ideale Lösung gewählt ist, kann es noch dauern wegen der Nacharbeiten: Recherchen, Prototypen, Gespräche, Machbarkeits- und Kostenanalysen und so weiter. Diese Aktivitäten könnten leicht im Sand verlaufen, wenn nicht der Verantwortliche sie weiterverfolgt bis die Lösung endgültig gewählt, dokumentiert und umgesetzt ist. Nach all dem Aufwand ist es wichtig, dass eine ordentliche Dokumentation darüber vorliegt, welche Ideen geprüft und aus welchem Grund verworfen wurden. Dies schützt nicht nur davor, bei nächster Gelegenheit nochmal von vorne anzufangen ("Hätten wir nicht besser doch dies oder das gemacht?") oder später Schwierigkeiten zu bekommen, wenn sich die gewählte Lösung als nicht optimal herausstellt. Meiner Erfahrung nach weiß man ein Jahr später nicht mehr genau, wie der Entscheidungsprozess damals abgelaufen ist, und man tut sich schwer damit, sich wieder auf den damaligen Wissensstand zurückzuversetzen. Inzwischen ist man natürlich klüger.
Kreativitätstechniken
Meine Lieblingstechnik für die Erzeugung wirklich neuer Ideen ist die 635-Methode, die ohne Vorbereitung und nur mit Papier und Stiften durchgeführt werden kann. Jeder Teilnehmer erhält ein Blatt Papier und einen Stift. In die oberste Zeile schreibt jeder in fünf Minuten drei Ideen. Dann reicht er seinen Zettel an seinen Nachbarn. Dieser ergänzt in fünf Minuten drei weitere Ideen. Nach sechs Runden und 30 Minuten erzeugen so sechs Personen 108 Ideen. Die Ergebnisse werden nach unten hin immer besser, weil nach spätestens drei Runden die offensichtlichen Ideen ausgehen.
Bei Konfrontationstechniken wird die vorliegende Fragestellung konfrontiert mit eigentlich themenfremden Inhalten, beispielsweise mit Reizworten (z. B. spontan und willkürlich aus einem Wörterbuch herausgefischt) oder mit fremden Anwendungsdomänen, in denen ein ähnliches Problem bereits gelöst wurde (Analogie-Technik). Da unser Gehirn auch beliebigen Kombinationen einen Sinn verleihen kann, wird es dazu angeregt, neue Ideen zu erzeugen.
Im Software Engineering benötigen Sie überhaupt keine spezielle Kreativitätstechnik. Die üblichen Konzepte und Fragen des Requirements Engineerings triggern bereits Ideen an: Wer benutzt dieses System und was sind dessen Ziele (Personas)? Wie wird das System benutzt werden (Nutzungsszenarien bzw. Use Cases)? Was könnte dabei schief gehen (Misuse Cases)? Wie sieht eine bestimmte Persona oder ein Hacker dieses System (Perspektivenwechsel)?
Die folgenden Kreativitätstechniken eignen sich ebenfalls dafür, für ein existierendes Produkt Verbesserungen zu entwickeln: Konfigurationstechniken rekombinieren Eigenschaften des Produkts systematisch neu. Dazu geeignet sind der Morphologische Kasten, die Osborn- oder SCAMMPERR-Checkliste, die Fragen stellt wie "Kann man es größer machen?" oder "Kann man es für etwas anderes verwenden?" Auch Perspektiven-Wechsel-Methoden wie die 6 Hüte von de Bono oder das Einnehmen der Standpunkte der Personas fördern neue Aspekte zutage.
Zusammenfassung und Ausblick
Sie sehen: Kreativität ist nicht nur etwas für Künstler:innen, sondern gerade auch für den Software-Ingenieur. Jeder kann kreativ sein und sollte es auch. Probleme gibt es genug zu lösen! Probieren Sie es aus!
- Wikipedia: Methode 635
- Wikipedia: Morphologische Analyse (Kreativitätstechnik)
- Wikipedia: SCAMPER
- Wikipedia: Denkhüte von De Bono
