Im zweiten und dritten Teil meines Artikels möchte ich drei zentrale Prinzipien vorstellen, die nach meiner Erfahrung zu einer deutlich höheren Qualität im Anforderungsmanagement führen können.

Den Kunden als Partner integrieren

Je komplexer und innovativer IT-Projekte sind, desto eher sollte man davon ausgehen, dass Kunden keine klare Vorstellung haben, was sie wollen und dass die Kommunikation zwischen Kunden und IT-Experten alles andere als reibungslos funktioniert. Dies ist keine Schwäche der beteiligten Akteure, sondern zu erwartende Normalität. Aus diesem Grund funktioniert das klassische Rollenverständnis, wie im ersten Teil des Artikels beschrieben, hier auch nicht. Der Kunde darf nicht mehr nur die Rolle des Auftraggebers einnehmen, sondern muss sich vielmehr als Entwicklungspartner verstehen. Der Kunde bzw. Endnutzer ist letztlich selbst Mitglied des Entwicklerteams und kann damit durch den intensiven und ständigen Austausch von Anforderungen, Ideen und Konzepten sein eigenes Bild schärfen und im Laufe der Zeit seine konkreten Anforderungen entwickeln und adäquat kommunizieren.

Diese Vorgehensweise erfordert jedoch zum einen die Bereitschaft des Kunden, deutlich mehr Zeit für die Entwicklung der Software zu investieren, als es im traditionellen Rollenverständnis nötig war. Zum anderen erfordert eine partnerschaftliche Zusammenarbeit mit dem Kunden eine extrem hohe Professionalität seitens der IT-Experten. Der Kunde ist also nicht nur Gast, den man im metaphorischen Sinne zum Dinner empfängt. Nein, er steht selbst in der Küche und schmeckt die Suppe ab, bedient sich am Kühlschrank, probiert das Gemüse des Hauptgangs und verfeinert zusammen mit den Gastgebern das Dessert. Die Gäste werden also nicht erst zum Essen im Wohnzimmer begrüßt, sondern schon zum Kochen in der Küche. Dies erfordert jedoch einen extrem professionellen „Kochstil“ von beiden Seiten mit einem stark veränderten Organisationsablauf, mit neuen Aufgaben und einer angepassten Arbeitsteilung zwischen IT-Experten und Kunden.

Experimentieren

Experimentieren ist das wahre Leben. Es hat nur leider in unserer Arbeitskultur einen schlechten Ruf. Experimentieren scheint das Gegenteil von gewissenhafter Planung zu sein, bei der man ein Softwareprojekt bis ins kleinste Detail im Vorfeld definiert und dann einen möglichst standardisierten Entwicklungsprozess (mit sequentiell aneinander gereihten Phasen) abspult. Nur damit wird man in den seltensten Fällen der Realität gerecht. Zu oft musste ich in der Vergangenheit ansehen, wie eine schlichte Unplanbarkeit von IT-Projekten durch Zeitpläne, Anforderungsanalysen und Spezifikationen mit einem schwindelerregenden Detaillierungsrad und verwissenschaftlichen Formulierungen verdeckt wurde.

Die Beteiligten erzeugten sich damit das trügerische Gefühl, alles im Griff zu haben. Dass dies nicht so war, zeigte sich dann erst einige Zeit später. Oder wie der Autor Tom DeMarco es formuliert: „Der ‘richtige’ Zeitplan ist der, dessen Einhaltung völlig unmöglich ist, dem man dies aber nicht auf den ersten Blick ansieht.“ Ein gedachter Plan (= Spezifikation) ist nicht die Realität, sondern, wie wir uns eine zukünftige Realität denken. Ein guter Plan berücksichtigt daher, dass die Welt nicht vollständig planbar ist.

Ständiges Ausprobieren von Ideen und Lösungsvarianten sollte daher auch schon im Anforderungsmanagement von innovativen Softwareprojekten einen festen Platz haben. D.h. wir planen nicht nur um zu entwickeln, sondern wir entwickeln (= experimentieren), um überhaupt planen zu können. „Fail early and often to succeed sooner!“ Dieser Satz stammt aus dem Mund von Stefan Thomke, Professor an der Harvard Business School, und einer der aktivsten Promotoren für experimentelles Vorgehen im Kontext von Innovationsvorhaben. Er schreibt weiter in seinem Artikel „Enlightened Experimentation“ (Harvard Business Review):

„Rather than stigmatizing failure, invite it. Experiment with many diverse and even absurd ideas. Early failure can expose important gaps in expertise and knowledge, helping you eliminate unfavourable options and focus on more promising alternatives. But don’t confuse failure with mistakes – badly conducted experiments and repetitions of prior failures. Mistakes don’t produce new or useful information.“

Wer durch Experimentieren frühzeitig erkennt, was funktioniert (und was nicht), kann Fehler (= failure) frühzeitig eliminieren, erspart sich kosten- und zeitaufwändige Nacharbeiten in späteren Phasen und vermeidet spätere Fehlschläge. Selbst wenn diese Vorgehensweise auf den ersten Blick extrem ineffizient wirkt, zeigt aktuell Forschung, dass Innovationsprojekte mit einem derartigen experimentellen Ansatz am Ende öfter erfolgreich sind. Der Trend der agilen Softwareentwicklung und die „eXtreme Programming“-Bewegung greifen diese Denkweise bereits seit einigen Jahren auf.

Wesentlich bei der Durchführung von derartigen Innovationsexperimenten ist die Abbildung von Ideen und Konzepten in Form von Modellen, Prototypen und Simulationen.

Im dritten und letzten Teil des Artikels möchte ich daher diskutieren, welche besondere Wirkung die Visualisierung von Ideen und Konzepten sowohl auf die Interaktion zwischen Entwicklerteam und Kunden, als auch auf die Zusammenarbeit innerhalb des Teams hat.

* Titelzitat nach Nathaniel S. Borenstein

Über den Autor

Bernhard Doll ist Gründer mehrerer IT- und Dienstleistungsunternehmen und hat in den letzten Jahren ein paar Dutzend Unternehmen in ihrem Gründungsprozess begleitet. Bernhard hat Informatik studiert, einen Master im Bereich Betriebswirtschaftslehre sowie Arbeits- und Organisationspsychologie absolviert und an der TU München über die Wirkung von Prototyping auf die Teamarbeit im Gründungsprozess promoviert. Darüber hinaus ist er als Dozent und Lehrbeauftragter an mehreren deutschen Universitäten zum Thema Innovationsmanagement tätig. Aktuell beschäftigt sich Bernhard mit neuartigen Methoden zur Entwicklung von Service-Innovationen. Weitere Informationen zur Person siehe http://bernharddoll.wordpress.com, Kontakt: bernharddoll@me.com

GD Star Rating
loading...
„Listen to your customers, but ignore what they say!“ - Teil 2: Die Qualität im Anforderungsmanagement erhöhen, 5.0 out of 5 based on 1 rating
Alle Bilder in diesem Artikel unterliegen der Creative-Commons-Lizenz (Namensnennung-Keine Bearbeitung, CC BY-ND; Link zum rechtsverbindlichen Lizenzvertrag). Ausgenommen sind anders gekennzeichnete Bilder unter anderem von Panthermedia, Fotolia, Pixelio, Morguefile sowie Pressefotos oder verlagseigenes Bildmaterial.