Der Kunde im Projekt – braucht es das wirklich? Schauen wir erst einmal, wie die verschiedenen Projektmanagement-Ansätze damit umgehen.

Umgangs-Formen

Aepfel_KundeImProjektIn klassischen Projekten entstehen, ehe die eigentliche Implementierung der Funktionalitäten beginnen kann, in der Regel mehr oder weniger schwergewichtige Dokumentationen und Feinkonzepte. Das Ziel ist dabei, möglichst genau festzuschreiben, was entwickelt werden soll. Je größer die Vorhaben, um so komplexer sind jedoch die Herausforderungen und ab einer gewissen Größe können nicht mehr alle Einzelheiten im voraus bedacht und spezifiziert werden. Hinzu kommt, dass das geschriebene Wort interpretierbar und damit missverständlich ist – wie im übrigen jedwede Kommunikation. Und: Man kann als Entwickler mit einem Stoß Papier (dem Feinkonzept) schlecht über die konkreten Anforderungen sprechen.

Agiles Vorgehen erkennt an, dass sich Anforderungen im Laufe der Zeit ändern können und werden. Das beste, umfangreichste, ausführlichste und feingranularste Konzept kann immer nur einen Schnappschuss des aktuellen Kenntnisstands des Kunden widerspiegeln und schon morgen (oder in einem Monat …) veraltet sein. Deshalb also direkt an die Quelle ran und den Kunden ins Projekt geholt!

Eine der radikalsten Formen findet man – wie der Name schon nahelegt – im Ansatz des Extreme Programming. Der Kunde wird zum Teil des Entwicklungsteams und ist permanent und rund um die Uhr für Fragen und Entscheidungen verfügbar. Auf diese Weise kann der Anteil der Vorab-Spezifikation und -Dokumentation extrem reduziert werden.

Nicht ganz so vereinnahmend sind andere agile Herangehensweisen bei ihren Ansprüchen an den Kunden. Allen gemein ist jedoch, dass mindestens in festen Abständen (2-4 Wochen) auf der Basis lauffähiger Software-Stände mit dem Kunden das weitere Vorgehen im Projekt abgestimmt wird. Der klassische Schöpfungsakt eines Feinkonzepts wird im agilen Kontext in viele kleine Teilschritte zerlegt. Quasi Just-In-Time werden die fein ausspezifizierten Anforderungen geliefert und besprochen, auf der Basis des aktuellen Projektforschritts.

Offensichtlich ist es also sinnvoll und hilfreich, den Kunden während des Projekts so nahe wie möglich an sich heranzuziehen.
Wie eine solche enge Kooperation zwischen Entwicklern und Kunden aussehen kann, ist mir vor kurzem bei einer Supervision eines Scrum-Projekts begegnet.

Das Projekt hatte zur Aufgabe, auf Basis einer bestehenden Anwendung neue Funktionalitäten für vergleichbare Prozesse anderer Bereiche des Unternehmens zu schaffen. Gleichzeitig sollte sich die produktive Anwendung weiterentwickeln. Das hatte zur Folge, dass mehrere Interessengruppen ihre Anforderungen an das neue System formulierten. Wollte man all das im voraus detailliert spezifizieren, wären endlose Diskussionen um nicht verifizierbare Details sicher nicht zu vermeiden.

Key-User im Scrum-Team

Um all dem vorzubeugen, wurden in diesem Projekt die Key-User der (bestehenden und der künftigen) Anwendung in das Scrum-Team aufgenommen. Sie nehmen aktiv am Daily Scrum teil, spezifizieren und priorisieren gemeinsam mit dem Product Owner, bauen Testdaten auf, testen im laufenden Sprint die fertig entwickelten Stories und präsentieren am Sprintende im Review ‘ihre’ neuen Funktionalitäten. Das sichert eine ungeheuer tiefe Einbeziehung in die Entstehung des Produkts, fördert die Abstimmung zwischen der sich zum Teil widersprechenden Interessen der Stakeholder, schafft ein tiefes Verständnis für die entstehende Anwendung und garantiert eine Verfügbarkeit der fachlichen Ansprechpartner, die beispielhaft ist.
Das ist ‘on-site customer’ @ its best!

Einbeziehung der Endanwender

Allerdings – wie so oft – schafft die Lösung eines Problems wieder neue. In diesem Fall war es so, dass das Team zunehmend das Gefühl hatte, dass das Review gar kein ausreichendes Kundenfeedback mehr liefert. Durch die tiefe Integration der Key-User, die auch noch selbst präsentierten, war das Review am Ende zu einer internen Veranstaltung des Teams und damit eigentlich überflüssig geworden.

Kann man sich nun die Frage stellen: Wer sind hier eigentlich die Kunden? Sind es wirklich die Key-User? Oder sind es nicht vielmehr die Kollegen der Key-User, also die Endanwender, die später mit der Anwendung arbeiten werden? Hat das Team die ‘richtigen’ Kunden im Projekt?

Um wieder ausreichend externes Feedback zu bekommen, entschloss sich das Team, künftig am Sprintende in die Abteilungen der Key-User zu gehen und als Review gezielt vor den Endanwendern zu präsentieren. Ob diese Anpassung den gewünschten Erfolg haben wird? Das Ergebnis des Experiments steht noch aus.

Foto: © http://www.sxc.hu/photo/916599

Auch veröffentlicht auf www.holisticon.de