Blick von oben auf einladenden Lounge-Bereich mit locker gruppierten hellen Sesseln und Beistelltischen

Web-Lounge – IT à la carte?

Wie wäre es, wenn man IT in einem Restaurant bestel­len würde? Dieser Frage nachzugehen, ist immer wie­der ein nettes Gedankenexperiment, denn die Über­tragung von Prozessen rund um die IT in die kulinari­sche Welt führt oft zu interessanten Überlegungen. Beginnen wir mit der „Beschaffung“: Eine Pizza Hawaii hat immer die gleichen Basiszutaten – Pizzateig, To­matensauce, Käse, Schinken und Ananas. Und doch wird man nicht unbedingt auf die Idee kommen, das billigste Angebot zu nehmen, denn die Qualität der Zutaten und die Zubereitung spielen eine wichtige Rolle. Selbst wenn alle Zutaten in Gramm und Millili­tern, alle Zeiten in Minuten angegeben werden, dürf­ten die Ergebnisse recht unterschiedlich ausfallen. Aber das ist ein anderes Thema.

Im Schwerpunkt dieser INFORM geht es um Agilität. Stichworte wie Kundenzufriedenheit, Flexibilität, In­teraktion mit den Kunden und „funktionierendes Pro­dukt“ tauchen darin auf. Kundenzufriedenheit und funktionierende Produkte – sprich: gutes Essen – ha­ben hier einen hohen Stellenwert. Und Flexibilität? Die Küche wird sicher auf Kundenwünsche eingehen – im Rahmen der Möglichkeiten. Aber auch hier bedeu­ten Flexibilität und Kundenorientierung nicht, dass man sich nach der Bestellung noch beliebig oft um-entscheiden kann. An dieser Stelle kommen beim Vor­gehen nach agilen Methoden „Zwischenprodukte“ zum Einsatz, die es den Kunden erlauben, Feedback zu geben und notwendige Anpassungen anzustoßen. Nun wird ein und dieselbe Pizza nur einmal serviert, aber über die Zeit kann das Feedback von Kunden auch in Restaurants dazu beitragen, das Produkt zu „verbessern“ und z. B. die Schärfegrade von Speisen an lokale Gewohnheiten anzupassen.

Ein weiterer Punkt, an dem es Ähnlichkeiten zwischen Küche und Softwareentwicklung gibt, ist der Einsatz von Spezialisten: Bei beiden mag es Mitarbeiterinnen und Mitarbeiter geben, die universell einsetzbar sind. Aber auch hier bedeutet Flexibilität nicht, dass alle das machen, wozu sie gerade Lust haben. Nur, wenn die Zuständigkeiten klar sind, gelingt das reibungslo­se Zusammenspiel zahlreicher Teilprozesse in einem „Sprint“ – etwa die Bestellung für Tisch 7 – und führt zu einem ordentlichen „Deliverable“.

Ein anderer Bereich, in dem Kundenorientierung, In­teraktion, Flexibilität und „funktionierende Produkte“ eine Rolle spielen können, sind Großprojekte wie eine Feier mit vielen Gästen. Ein erster „Papierprototyp“ in Form eines Menüvorschlags ist recht schnell erstellt. Den kann man ein- oder zweimal konkretisieren bzw. revidieren. Dann steht vielleicht noch ein Probeessen an und letzte Änderungen aufgrund von Vorlieben oder Allergien werden vereinbart. Ein oder zwei Tage vor der Veranstaltung stellt sich womöglich heraus, dass ein eingeplantes Gemüse aufgrund von Liefer­engpässen nicht in der benötigten Menge oder Quali­tät zur Verfügung steht. Auch hier ist Flexibilität ge­fragt – sowohl im Erstellungsprozess als auch auf Sei­ten der Gäste, die ein Produkt bekommen, das von der Dokumentation, also der Menükarte, abweicht.

Die Analogien und Vergleiche zwischen IT-Projekten und einem Restaurantbetrieb ließen sich noch weiter fortführen. An manchen Stellen sind sie originell, an anderer Stelle hinken sie. Aber vielleicht können der­lei Gedankenspiele dazu anregen, die verschiedenen Aspekte klassischer und agiler Entwicklungsansätze, wie sie im Themenschwerpunkt beschrieben werden, in ein anderes Licht zu rücken.

Autor des Beitrags

Dr. Markus Beckmann
HZD-Mitarbeiter Architektur, Produkte und Standards