Fähigkeiten für eine IT der zwei Geschwindigkeiten

Eine IT der zwei Geschwindigkeiten versetzt Unternehmen in die Lage, für jedes Vorhaben das angemessene Tempo zu finden. Das Ziel der Sprint-IT ist dabei, die Wünsche ihrer Kunden treffsicher und schnell zu adressieren. Die Mitarbeiter benötigen neue technische und methodische Fähigkeiten, um

• zu entdecken, was Kunden wirklich brauchen,

• Ideen auszuprobieren,

• Stakeholder mitzunehmen und

• schneller Lösungen zu entwickeln und an den Markt zu bringen.

Wir wollen hier auf einige Ansätze eingehen, die wir dafür als besonders wertvoll erachten: Design Thinking, Prototypen, agile Methoden,DevOpsDevOps und Cloud-Technologien. Alles zu DevOps auf CIO.de

Vorhaben, die auf den Geist von Design Thinking setzen, bleiben nah am Menschen. Beispielsweise, indem sie aus dem Wissen über Kundengruppen konkrete Personas bilden und so den abstrakten Kunden zu einer erlebbaren Person machen. Prototypen machen eine Idee anfassbar; Teams begeistern so schnell und mit wenig Aufwand Kunden und Vorgesetzte für ihre Ideen. Die Software-Entwicklung realisiert mit agilen Methoden eine kürzere Time-to-Market, DevOps ist die Grundlage dafür, dass Lösungen schnell live gehen. Cloud-Technologien schaffen schnell skalierbare Umgebungen für Entwicklung, Test und Produktion.

Design Thinking stellt den Mensch in den Mittelpunkt

"Das ist ja meine Tante!", sagt Herr Geldorf aus dem Fachbereich über "Hildegard": eine weibliche Silver-Agerin kurz vor der Rente. Viel unterwegs mit großer Begeisterung und ohne Smartphone. Diese Persona ersetzt - zusammen mit "Holger", "Gudrun" oder "Melek" - anonyme Kundengruppen durch konkrete Menschen. Personas verdichten Daten aus der Nutzerforschung zu fiktiven Personen mit Namen und Gesicht, Familienstand und Wohnort, Hobbys und Charaktereigenschaften. Details zu ihrem Lebenslauf und ihrem Verhalten reichern diese Archetypen zu fast realen Personen an.

Personas sind von Design Thinking inspiriert, ähnlich wie Customer Journeys oder Empathie-Karten. Die Methoden folgen einer gemeinsame Logik: Sie stellen den Menschen in den Mittelpunkt. Die Persona Hildegard ist Herrn Geldorf und jedem Marketing- oder Vertriebsmitarbeiter im Unternehmen viel näher als eine Sammlung statistischer Daten.

Durch die Vermenschlichung der Daten finden wir zielgenau heraus, was Kunden brauchen. Wir erkennen in Hildegard jemanden wieder - sei es Oma, Tante oder Nachbarin. Wir können uns leicht in sie hineinversetzen und wir entwickeln Empathie. Wir können aus der Perspektive dieser Person nachempfinden, welche Bedürfnisse sie hat und welche Produktneuerung für den Nutzerkreis, für den sie steht, hilfreich ist.

Design Thinking gibt Menschen Raum, um eigene Lösungen zu finden. Teilnehmer erarbeiten in Workshops selbst die Fragen, an denen sie konkret arbeiten. Sie finden Lösungen spielend - und manchmal spielerisch. Weil sie die Probleme selbst identifiziert haben, machen sie sich die gefundenen Lösungen stärker zu eigen als mit einer vorgegebenen Aufgabe.

Mit Produktideen auf Kundenfeedback reagieren

So macht Design Thinking Dinge sichtbar und greifbar: Statt langer Konzeptphasen lernt man direkt am Produkt und aus dem Kunden-Feedback. Der Endbenutzer entscheidet so zumindest indirekt, wie das User-Interface einer Software aussieht oder welche Funktionen entwickelt werden. Die Outside-in-Perspektive - Unternehmen antworten mit Produktideen auf Impulse von außen - ergänzt das. Was sich so banal und selbstverständlich anhört, dreht die Perspektive in vielen Unternehmen um.

Design Thinking ist nicht nur eine Methode, sondern vielmehr eine Haltung, die verschiedenen Leitsätzen folgt: Das bereits beschriebene "Fail often and early" gehört dazu, ebenso die Aufforderung "Have fun!" und "Dare to be wild!". Und ja, das erfordert ein wenig Mut in unserer erwachsenen Arbeitswelt. Ob spielerische Ansätze in der Anforderungsanalyse oder die Reduktion von umfassenden Datensätzen in überschaubare Personas: Business-Analysten, Produktmanager oder IT-Berater wagen etwas Ungewöhnliches, wenn sie in einem Unternehmen, dessen Mitarbeiter Präsentationen gewohnt sind, neue, spielerische Methoden auszuprobieren.

Sie trauen sich, Herrn Geldorf mit neuen Formaten zu überraschen - auf die Gefahr hin, dass er nicht mitzieht. (Randnotiz aus der Praxis: Das ist uns noch nie passiert.) Design Thinking braucht Menschen, die ein bisschen verrückt sind, die lieber experimentieren als sich in ihrer Komfortzone zu langweilen. Und eine Haltung im Unternehmen, die dafür Raum lässt. Da sind wir wieder bei der kulturellen Dimension als Grundlage für eine IT der zwei Geschwindigkeiten: Ohne eine Kulturtransformation verändern neue Methoden wenig.

Prototypen: Ideen zum Anfassen

Als Frau Brühl nach einem längeren Telefonat in den Anforderungsworkshop zurückkehrt, betritt sie eine veritable Baustelle: Die Kollegen basteln eifrig mit Schere, Kleber und Papier an Prototypen für die Benutzeroberfläche einer neuen Software. Der Spaßfaktor ist hoch, Frau Brühl steigt schnell in die Arbeit mit ihrem Team ein. Gemeinsam erleben sie den ganzen Tag mit Leichtigkeit, Schwung und Lust an spielerischem Herangehen. Als der Schlussgong ertönt, sind alle überrascht, mehrere Teilnehmer protestieren und wollen ihren Papier-Prototypen unbedingt zu Ende bauen. Die Ergebnisse machen die abstrakte Benutzeroberfläche der neuen Software greifbar und sichtbar. Es entstehen einleuchtende Lösungen für Probleme, an die die Verantwortlichen noch nicht gedacht hatten.

In der nächsten Runde werden die Lösungen, die die Workshop-Teilnehmer mit Papier-Prototypen für Klickstrecken und Menüführungen gefunden haben, digital nachgebildet: Mockups oder andere Prototypen machen die User Experience des fertigen Produkts sichtbar - zum Beispiel für Nutzertests im frühen Produktstadium oder um Projektsponsoren auf Vorstandsebene von der Idee zu begeistern.

Konkretes Zeigen spricht Menschen besser an als abstraktes Beschreiben. Statt theoretischer Empfehlungen am Ende einer Machbarkeitsstudie zeigt ein erfolgreicher Prototyp das Grundgerüst für den fachlichen Ausbau. Dazu gehört ein wenig Mut zu Lücke: Ein Prototyp zeigt die Leistungsfähigkeit einer Idee, dekliniert aber nicht systematisch jede potenzielle Problemkonstellation durch. Prototypen erfüllen andere Bedürfnisse, die in frühen Phasen von Projekten eine wichtige Rolle spielen: Sie begeistern Menschen und geben Sicherheit. Im Ausprobieren eines Prototyps wird jeder zum Kunden, der begeistert Funktionen entdeckt und aus seiner eigenen Perspektive und Erfahrungswelt neue Anwendungsfälle beisteuert. Wie bei einem Nutzertest bekommen Produktverantwortliche Feedback, was funktioniert, welche Funktion nicht intuitiv erfasst wird und was fehlt.

Frau Brühls Vorgesetzte entwickelt durch einen lauffähigen Prototypen ein besseres Verständnis für das Projekt als durch eine Präsentation. Ihr fällt die Budgetentscheidung dank Prototyp leichter, weil sie nicht die sprichwörtliche Katze im Sack kauft. Der Prototyp zum Anfassen sichert die Investition in die Produktidee ab.

Prototypen-Bauer spielen auf einer umfangreichen Klaviatur. Sie nutzen Balsamiq, Pop oder Axure für Mockups, D3.js für Visualisierungen oder Node-RED für IoT-Anwendungen, um nur einige Beispiele zu nennen.

Mehr Speed durch agile Methoden, DevOps, Cloud

Neue Workshop-Formate machen uns agiler darin, Probleme zu verstehen und Lösungen zu finden. Agiler bedeutet auch, dass wir Kunden-Feedback und Marktentwicklungen schneller berücksichtigen. Das verkürzt die Zeit bis zur Marktreife von Funktionen. Bei den technischen Fertigkeiten braucht die Sprint-IT Pendants, um die Ideen schnell umzusetzen: Wir schlagen agile Methoden, DevOps und Cloud-Technologien vor.

Agile Methoden liefern schnell kleine Inkremente. Stakeholder sehen so nach jedem Sprint fertige Zwischenergebnisse. "Alle zwei Wochen ist Weihnachten", beschreibt einer unserer Kunden nach der Scrum-Einführung seinen Aha-Moment. So übertragen agile Methoden die flexible und schnell anpassbare Produktstrategie in die Produktentwicklung. Der Product Owner eines Scrum-Teams teilt die Produktvision in kleine, einzeln in Sprints umsetzbare Anforderungen und priorisiert sie nach Kriterien wie Geschäftsnutzen und Risiko. Das Kunden-Feedback auf die Sprint-Ergebnisse fließt unmittelbar in die Produktstrategie zurück - wenn sie schnell live geschaltet werden.

Das leistet DevOps. Die enge Zusammenarbeit von Software-Entwicklung und Betrieb während des kompletten Software-Lebenszyklus' automatisiert wiederkehrende Arbeiten: Features werden automatisiert getestet und ausgerollt, sobald der Software-Ingenieur sie in die Versionsverwaltung comittet. Mit "Infrastructure as Code" zieht der Applikationsbetrieb auf Knopfdruck Server mit vorkonfigurierten Einstellungen hoch. Konfigurations-Management-Tools wie Chef und Puppet helfen, komplexe Server-Landschaften schnell, nachvollziehbar und automatisiert zu managen. Monitoring-Tools sammeln und aggregieren Daten aus dem Produktionsbetrieb - weiteres Feedback für die Entwicklungsabteilung und die Produktentwicklung.

Cloud-Technologien liefern auf Knopfdruck skalierbare und schnell verfügbare Umgebungen für Test, Entwicklung und Produktion. Liefer- und Einrichtungszeiten für Hardware gehören der Vergangenheit an. Applikationen lassen sich zügig in eine Cloud-Infrastruktur auslagern, wenn die Architektur sauber definiert wurde. Zur Architekturdefinition gehört ein Cloud-fähiges Konzept für die Datensicherheit.

Agile Methoden, DevOps und Cloud-Technologien bauen auf einer gemeinsamen Grundhaltung auf: Die Kluft zwischen Software-Entwicklung und Applikationsbetrieb wird kleiner. Software-Ingenieure beschäftigen sich mit Betriebsfragen, um ihre Entwicklungsumgebung in der Cloud hochzuziehen. Sie arbeiten mit DevOps-Tools wie Puppet oder Ansible und kennen technische Rahmenbedingungen und Abrechnungsmodelle der Betreiber. Dabei muss nicht jeder alles machen: Scrum-Teams sind meistens multifunktional besetzt. Der Experte für ein Thema sitzt oft direkt am Nachbartisch.

In jeder Phase sprinten können

Mit Design-Thinking-Elementen wie Personas oder Customer Journeys finden wir heraus, was die Nutzer von einem Produkt erwarten. Diese Features werden als Prototyp getestet: schnell gebaut, schnell ausgerollt und schnell bestätigt - oder verworfen. Sie bescheinigen einem Vorhaben die Umsetzbarkeit und inspirieren als Ideen zum Anfassen.

Technische Fähigkeiten übertragen diese Geschwindigkeit und Flexibilität auf die Software-Entwicklung: Agile Methoden wie Scrum verkürzen die Time-to-Market von Features durch schnelle Entwicklungszyklen; DevOps rollt die Features zügig in den Live-Betrieb aus; mit Cloud-Technologien werden IT-Infrastrukturen ausreichend skalierbar. Zusammen genommen verkürzen diese Fähigkeiten die Zeitspanne, bis eine neue Funktion online ist, und sie lassen Raum für eine iterative Weiterentwicklung von Softwareprodukten.

Eine Randnotiz: agiles Vorgehen bedeutet nicht zwingend, Arbeiten schneller oder billiger zu erledigen. Es geht darum, die Kundenbedürfnisse besser zu treffen. Und das zählt.