This post in English

Ein immer wieder auftretendes Muster bei der Softwareentwicklung spielt sich in der Anfangsphase des Projektes ab: Der Auftraggeber (Kunde) beschreibt seine Anforderungen. So weit so klar und auch gewünscht. Allerdings fällt hierbei auf, dass die Anforderungen derart formuliert werden, dass sie einen konkreten Lösungsweg festschreiben. Dieses Vorgehen ist dem Auftraggeber schon so bekannt, normal und eingespielt, so dass es quasi als einziger Weg zum Ziel gesehen wird. Der Gedanke dahinter: Wenn nur genau genug die Lösung formuliert wird, lassen sich Termine und Kosten direkt ableiten und bei der Realisierung kann nichts mehr schief gehen.

Ist dem wirklich so?

Wo liegt das Problem?

Wenn nur der Lösungsweg formuliert wird, bleiben viele Aspekte verborgen, die den Kontext beschreiben, der zu dieser Lösung führte. Genau dieser Kontext ist dem Auftraggeber bestens bekannt, aber dem Auftragnehmer mitunter nicht. Warum aber sollte ihn das interessieren? Er ist doch nur für die Umsetzung verantwortlich und es dauert ja auch viel zu lange, das auch noch zu erklären. Der Auftragnehmer soll exakt das machen, was man ihm über den Umweg Lastenheft sagt.

Es gibt Beispiele, bei denen dieses Vorgehen gut funktioniert und auch Vorteile bringt. Aber nicht immer…

Die Fallen

Der unbändige Wunsch des Auftraggebers eine Software auf CD gebrannt in Time and Budget zu erhalten, nachdem er das Lastenheft übergeben hat, ist verständlich. Die Chance, dass er mit diesem Ansatz die optimale Lösung erhält, ist dabei allerdings geringer:

• Ein fehlender Kontext führt zu mehr Missverständnissen bei der Interpretation der Anforderungen
• Am echten Endanwender vorbei vorgefertigte Benutzerinteraktionen reduzieren die Akzeptanz der Anwendung
• Ungenutzte Synergien reichern die Anwendung mit vermeidbarem Ballast an
• Fehlendes Wissen über die aktuelle Architektur und Implementierung führen zu nicht angemessenen Lösungswegen

Der andere Prozess

Jeder Lösungsweg beschreibt die Lösung eines Problems. Zu oft wird dieses Problem und dessen Kontext nicht explizit benannt oder es ist sogar dem Auftraggeber unklar, so dass nicht einmal ein sinnvoller und tragfähiger Lösungsweg aufgezeichnet werden kann.

Idealerweise findet man fast von alleine die richtige Lösung, wenn man sich folgendem bewusst wird, und dann auch festhält:

• In welcher Situation treffe ich
• auf welches Problem und
• was für Implikationen ergeben sich daraus für mich, wenn es nicht
• und welchen Nutzen habe ich, wenn es doch gelöst wird?

Diese Methode wird SPIN genannt, wird häufiger im Vertrieb benutzt, führt aber auch hier fast wie von selbst zu der eigentlichen Anforderung – noch nicht der Lösung! Ebenso wird hier das Fundament gelegt, um Lösungen zu bewerten, d.h. eine Kosten/Nutzen-Analyse anzuwenden.

“Sag mir wie Dein Projekt anfängt und ich sage Dir wie es endet”

Womit beginnt ein Projekt? Ja genau. Mit der Beschreibung der Anforderungen. Dazu benötigen wir allerdings eine gute Basis – die aktuelle Situation und die Probleme daraus. Auch hier wird allzu oft ein gravierender Fehler bei der Stakeholderanalyse im Projekt gemacht. Diese werden des öfteren nicht als wichtiger Informationsgeber sondern als Gefahr für das Projekt betrachtet, die man nur richtig managen muss. Ein entscheidender Stakeholder in jedem Softwareentwicklungsprojekt sind die Endanwender – also diejenigen, die die Lösung benutzen und davon profitieren sollen.

Auf der Suche nach dem echten Endanwender gibt es typischerweise projektrelevante Personen, die mit folgenden Aussagen den Weg versperren:

• “Vertrauen Sie mir, ich habe das jahrelang selber gemacht.”
• “Unsere Prozesse funktionierten schon immer so.”
• “Sind Sie verrückt, ich frage doch nicht die Fachabteilungen, was sie wollen: Das endet ja im Wünsch-Dir-Was!”

In der Anforderungsanalyse werden die entscheidenden Fehler am Anfang des Projektes gemacht. Es wird die Chancen vertan, eine Lösung zu entwerfen, deren Akzeptanz nicht über “Dienstanweisungen” verordnet werden muss.

Es ist möglich mit begrenzten Ressourcen die richtigen Anforderungen zu ermitteln und der Umsetzung zu garantieren. Die Möglichkeiten reichen in der Projektstartphase von Hospitierung, Eyetracking und Umfragen bis zu kontinuierlichen Akzeptanztests während der Projektlaufzeit. Dafür wird bei uns das Team User Experience (UX) von Anfang an in die Projekte einbezogen und begleiten das Projekt bis zum Ende. Die Rolle eines UX-Architekten ist genauso wichtig, wie die Rolle eines technischen Architekten.

Welche Lösung hätten Sie denn gerne?

Ist der Kontext klar und die Anforderungen lösungsneutral formuliert, können verschiedene Lösungsszenarien entwickelt werden. Auch hier wird noch keine Zeile Code geschrieben. Zur Veranschaulichung der potentiellen Lösung kommen digitale Papierprototypen (sogenannte Wireframes) zum Einsatz, die nicht nur das mögliche Äußere sondern auch den Workflow der Benutzerinteraktionen simulieren. Damit wird schnell ein Gefühl (die User Experience) der Anwendung vermittelt und die ersten Rückmeldungen der Anwender können Änderungen ohne relevante Zusatzaufwände ermöglichen. Durch die Wireframes muss allerdings auch dem Eindruck vorgebeugt werden, die Lösung sei bereits umgesetzt und fertig.

Ebenso sollten mindestens zwei Lösungsszenarien formuliert werden – mehr sind noch besser. Bauen diese sogar aufeinander auf, lässt sich auch schon eine Roadmap erstellen und abstimmen. Die Bewertung der Lösungsszenarien kann dann nicht nur durch Ja oder Nein, sondern durch Lösung A, B oder C erfolgen. Eine erste Aufwandsabschätzung ermöglicht zudem auch die Bewertung der Anforderung mit einer Kosten-Nutzen-Analyse und das perfekte Zuschneiden der optimalen Lösung.

Hindernisse

Warum wird das nicht immer so gemacht?

Der Kunde sieht sich oft in Zeitnot und hat schon genug Zeit investiert, seine Lösung aufzuschreiben. Der Mehrwert einer Anforderungsanalyse auf Basis der Nutzeranforderungen mit Hilfe von UX-Methoden scheint vorerst nicht klar. Es darf nicht unterschätzt werden, dass es ein langwieriger Prozess ist, den Kunden davon zu überzeugen, dass dieser Aufwand am Anfang gerechtfertigt ist und sich vielfach auszahlt.

Eine offene und ehrliche Betrachtung der Ergebnisse von Projekten, vor allem die Betrachtung der Akzeptanz der Nutzer – für die ja die Lösung gemacht wurde – führt zu der Erkenntnis, dass die Schäden durch nicht optimal unterstützte und damit nicht effizient gelebte Prozesse weit höher ist, als der initiale Invest am Anfang des Projektes.

Durch eine partnerschaftliche Kommunikation und eine Expertise in der Fachlichkeit und Anforderungsanalyse ist es möglich, gezielt und kompetent die Lösungsideen des Gegenüber zu hinterfragen und mehr über den Kontext zu erfahren. Wenn am Ende die originäre Lösung des Kunden aus der Vielzahl an Lösungen gewählt werden sollte, so ist dies auch die Chance verglichen zu haben und sich sicher zu sein, dass sie wirklich die Beste ist. Die Erfahrung zeigt allerdings sehr oft, dass dann doch eine andere Lösung als geeigneter gewählt wird.

Jeder Kunde, der diesen Weg einmal mit uns gegangen ist, schätzt heute die Vorteile für ihn und mag auch nicht mehr anders vorgehen.

Fazit

Der Weg zur richtigen Lösung beginnt bei der klaren Beschreibung des Problems. Dabei hilft die Frage: Welches Problem wird mit dieser Lösung gelöst?

Die Chancen für den Kunden aus vielen Lösungen wählen zu können sind enorm:

• Kosten/Nutzen-Analyse
• Nutzung von Synergien
• Definition einer Roadmap einer Funktionalität
• Lösungen mit einer zielgerichteten Akzeptanz der Anwender
• Entwicklung von zusätzlichen innovative Verbesserungen

Dieser Post ist der Anfang einer ganzen Reihe von Beispielen aus dem Alltag des Projektmanagements bei der akquinet tech@spree.

 

Tassilo Kubitz

akquinet tech@spree

(Mitglied der GPM-Fachgruppe Agile Management)