Kunde vor Ort

Lehrbuchmäßig bedeutet "Kunde vor Ort" (On-site customer), daß der Kunde Bestandteil des Programmierteams ist (Varianten). Die typische Aufgabe des Kunden ist es, seine Anforderungen mit Hilfe von Benutzergeschichten zu formulieren. Zu diesen Benutzergeschichten erstellt der Kunde Akzeptanztests, die dann wiederum dem Kunden helfen zu entscheiden, ob eine Benutzergeschichte vom System korrekt implementiert ist.

Eine weitere wichtige Aufgabe des Kunden vor Ort ist es, für die Programmierer jederzeit ansprechbar zu sein, um Detailfragen in Bezug auf Benutzergeschichten zu klären. Für das Planungsspiel werden die Benutzergeschichten nur bis zu einem Detaillierungsgrad definiert, der für die Auswahl zur Implementierung bzw. die Aufwandsabschätzung erforderlich ist. Wenn es dann an die konkrete Implementierung geht, ist es normal, daß weiterer Klärungsbedarf entsteht.

Beispiel:
Die Benutzergeschichte lautet: "Wenn ein Kunde Waren mit einem Gesamtwert von mehr als 80 DM bestellt, muß er keine Versandkosten bezahlen. Bei einem Bestellwert von weniger als 80 DM betragen die Versandkosten pauschal 10 DM."
Für die Aufwandsabschätzung ist dieser Detaillierungsgrad u.U. ausreichend. Für die Implementierung muß jedoch geklärt werden, was bei einem Bestellwert von genau 80 DM passieren soll.

Was passieren kann, wenn der Kunde mal einen Tag lang nicht ansprechbar war, zeigt folgendes Beispiel:

Die Benutzergeschichte lautete: "After pressing the Modify-button, selected fields loose their read-only status and can be modified." Der Kunde war nicht direkt verfügbar, und so mußten die Programmierer mit der Benutzergeschichte ohne Hilfe zurechtkommen. Sie lasen "selected" und nahmen an, daß der Bildschirm so gestaltet werden mußte, daß der Benutzer zunächst mit der Maus diejenigen Felder auswählen mußte, deren Inhalte er verändern wollte. Danach würde er auf den Modify-Knopf klicken und die zuvor ausgewählten Felder (und nur die!) würden dann ihren Nur-Lese-Zustand verlieren.

Leider meinte der Kunde etwas ganz anderes. Nachdem er wieder zur Verfügung stand, wurde ihm die neue Funktionalität gezeigt und er stellte die Diskrepanz fest. Richtig wäre gewesen, daß aus fachlicher Sicht bestimmte Felder niemals vom Benutzer veränderbar sein sollten, z.B. das Erstellungsdatum des Datensatzes. Nach dem Klicken des Modify-Button sollten alle anderen Felder veränderbar werden.

Das Beispiel zeigt aber auch, daß der angerichtete Schaden relativ gering war, da der Kunde nur einen Tag nicht verfügbar war. Positiv läßt sich auch vermerken, daß das Mißverständnis nicht erst am Ende des Releasezyklus entdeckt wurde (was in traditionellen Methodologien häufig passiert), sondern unmittelbar nachdem die Programmierer daran gearbeitet hatten. Die Änderung war daher sehr schnell vorgenommen, und der Prozess konnte seinen gewohnten Lauf nehmen.

Varianten

Auch wenn das oben gesagte die optimale Lösung darstellt, so stellt sich in vielen Fällen in der Praxis heraus, daß nicht immer ein Kunde vor Ort sein kann. Dann muß man über Alternativen nachdenken, wohl wissend, daß jede dieser Alternativen Nachteile gegenüber der Lösung "gemäß Lehrbuch" aufweist. In der Regel wird zusätzlicher Kommunikationsaufwand erforderlich sein.

Eine Möglichkeit besteht darin, eine Person aus den eigenen Reihen auszuwählen, die sozusagen als "Anwalt des Kunden" fungiert. Auch für diese Lösung kommen wiederum mehrere Varianten in Frage. In manchen Unternehmen werden Produktmanager dafür eingesetzt, in anderen Fällen übernimmt ein Programmmanager die Aufgabe. Schließlich gibt es noch die Möglichkeit, ein Mitglied des Programmierteams dafür zu verwenden. In jedem dieser Fälle wird diese Person dann quasi zum "Proxy".

Diese Varianten können insbesondere dann von Vorteil sein, wenn man an einem System arbeitet, das für viele Kunden vorgesehen ist. Es ist zum Beispiel relativ unpraktikabel, alle Benutzer eines Textverarbeitungsprogrammes ins Programmierteam zu holen.

Tipps

• Wenn ein Kunde vor Ort sich nicht realisieren läßt, so sollte doch zumindest ein Mitglied des Programmierteams diese Rolle einnehmen und als "Anwalt des Kunden" arbeiten.