Perspektivenwechsel Teil 9

Wie wir einmal Entwickler waren (aber keine Untertanen)

In der Ausgabe März 2009 berichteten die Kollegen Arne Roock und Henning Wolf in „Wie wir einmal Kunden waren (aber leider keine Könige)“ über die Erfahrungen und Erkenntnisse, die sie bei einem Rollentausch als Kunde gemacht haben. In diesem Artikel wird nun das Gegenstück präsentiert: Mit einem Augenzwinkern berichten die Entwickler aus diesem Projekt und beschreiben die Erfahrungen, die sie mit dem Kunden gemacht haben. Was soll schon schlecht laufen in einem Projekt mit einem Kunden, der sich in der Softwareentwicklung sehr gut auskennt? Der Kunde in diesem Projekt hat nicht nur viel Erfahrung, es sind auch Kollegen, die über die meisten Themen, das Vorgehen und den Prozess sehr ähnlich denken. Wer erwartet in dieser Kon¬stellation schon Konflikte? Hätten die Entwickler Tagebuch geschrieben, dann könnte es jetzt so aussehen:

29.10.

Das Projekt startet, der Kunde nennt das auch „Kick-Off“. Fünf sehr erfahrene Entwickler sind versammelt und bekommen einen schicken HTML-Prototyp vorgestellt. Das Design gefällt allen, in Gedanken macht man hier und da schon kleine Änderungen, ist aber im Großen und Ganzen wi

rklich sehr zufrieden. Es herrscht Aufbruchstimmung – wir können die Welt beherrschen und Berge versetzen! In dieser wundervollen euphorischen Stimmung kommen bei uns Entwicklern die ersten Zweifel. Der Prototyp lässt sich durchklicken, und nun tut der Kunde so, als ob das ganze System schon fertig ist. Und dabei ist noch keine einzige Zeile Code geschrieben. Wir sind erfahrene Java-Entwickler. Groovy und Grails basieren zwar auf Java, und wir haben auch alle eine Schulung gemacht, aber trotzdem werden wir bestimmt noch über das eine oder andere Problem stolpern. Sollen wir deswegen die gute Laune verderben?

31.10.

Weiterhin hoch motiviert arbeiten wir Entwickler an der Infrastruktur für die Anwendung. Das Framework Grails erleichtert uns sehr viel Arbeit, denn das meiste ist als Konvention schon vorgegeben. Die Anbindung an den E-Mail-Server bereitet unerwartet Probleme. Außerdem haben wir den Anspruch, das Projekt kontinuierlich zu integrieren und einen Build-Server zu benutzen. Jede Änderung am Sourcecode im Repository führt zur Ausführung aller Tests. Nicht nur die Unit-Tests werden automatisch ausgeführt, sondern auch die Akzeptanztests gestartet. Hier stolpern wir über viele kleine technische Fallen. Warum ist es z. B. so kompliziert, mit SSL und Java per IMAP E-Mails abzurufen? Die Probleme bekommen wir in den Griff, sie kosten aber viel Zeit. Wir haben eine hohe Anfangsinvestition in unsere Infrastruktur, die der Kunde einfach nicht zur würdigen weiß („Hä? Was ist denn SSL und IMAP?“)! Ungefähr die Hälfte aller Seiten können wir modellieren und stolz vorzeigen. Dem Kunden ist die Enttäuschung anzusehen. Wir können ihm versichern, dass wir mit den Investitionen in unsere Test- und Build-Struktur an Geschwindigkeit zulegen werden.

02.11.

Wir sind fleißig, arbeiten Feature für Feature ab. Jedes Feature muss dabei durch unsere Akzeptanztests beschrieben werden. Für die Akzeptanztests benutzen wir erfolgreich Canoo-Webtests. Trotzdem brauchen wir manchmal sehr viel Zeit, um ein Feature durch einen Webtest richtig zu beschreiben und um unsere Webtests zu organisieren. Auch bei den Akzeptanztests wollen wir dem DRY-Prinzip (Don’t repeat yourself) folgen und eine Information nur an einer Stelle beschreiben und nicht an mehreren warten müssen. Der Kunde wird anscheinend durch unsere technischen Begriffe wie „XPath“, „JavaScript“, „prototype“ und „DOM“ nur verwirrt und sieht die kleinen Erfolge nicht. Der Kunde hat unsere Anwendung getestet und ist nicht mit allem zufrieden. Er bezeichnet sogar manche der fehlenden Features als „Bugs“ und behauptet etwas von „Selbstverständlichkeitsanforderungen“ …

13.11.

Der Kunde hat immer verrücktere, neue Ideen für unsere Anwendung. Gemeinsam diskutieren wir, welche Features das Produkt haben sollte und in welches Release diese eingebaut werden sollen. Die Entscheidung, welches Feature mit welcher Priorität realisiert wird, liegt natürlich beim Kunden. Leider kennt der sich wohl doch nicht so gut aus, sonst würde er unsere Vorschläge nicht so niedrig priorisieren oder gar ablehnen. Aus den erledigten Features und der eingesetzten Zeit errechnen wir unsere Geschwindigkeit. Wir präsentieren offen und ehrlich unsere aktuelle Geschwindigkeit. Auf dieser Geschwindigkeit basiert auch unsere Prognose, wie viele der Features in diesem Release fertig gestellt werden. Der Kunde ist mit unserer Geschwindigkeit nicht zufrieden, bzw. er will ungeachtet der Geschwindigkeit, dieses und jenes Feature zusätzlich in dem Release haben.

26.11.

Bei der Sprint-Planung für das nächste Release wird der Kunde ungehalten über unseren Vorschlag, welche Features wir für diesen Sprint zusagen können. Auch uns kommen die Anzahl und der Umfang der Features gering vor, aber mit unserer momentanen Geschwindigkeit können wir leider nicht mehr versprechen. Ein weiterer Konflikt offenbart sich: Wir Entwickler würden gerne den aktuellen Stand in Produktion geben. Für häufige Releases haben wir doch die Installation („das Deployment“) voll automatisiert. Mit nur einem Klick wird der aktuelle Stand gebaut, getestet und produktiv gestellt. Die Entwicklungsversion wird so automatisch täglich neu gebaut, die produktive Variante dagegen nur auf Anweisung vom Kunden. Wir sind davon überzeugt, dass wir wertvolles Feedback von den Anwendern bekommen und sich dadurch auch die Priorisierung mancher Features eventuell ändert. Doch leider traut sich der Kunde trotz massiver Überzeugungsarbeit nicht zu einer Produktivstellung.

03.02.

Mittlerweile sind mehrfach neue produktive Versionen für den Anwender installiert worden. Wir bekommen wertvolles Feedback, die Anwendung läuft stabil und unsere Geschwindigkeit hat sich merklich verbessert. Das Team hat natürlich eine eigene Retrospektive durchgeführt und auch zusammen mit dem Kunden kritisch auf die zurückliegende Zusammenarbeit geschaut. Im Nachhinein erscheinen manche Missverständnisse relativ banal. Durch die Retrospektive können wir die Gründe für die Missverständnisse benennen und diese Probleme bei der weiteren Zusammenarbeit vermeiden. Und wir haben auch ein wenig Lob bekommen, das hört man doch immer wieder gerne!

Perspektivenwechsel

Das Projekt haben wir uns zu Beginn ganz anders vorgestellt. Der Kunde ist Experte in der Softwareentwicklung, das sind doch traumhafte Voraussetzungen! Und trotzdem stoßen wir in dieser anscheinenden Traumkonstellation auf die altbekannten Probleme! Dieser Perspektivenwechsel war auch für uns Entwickler sehr lehrreich. Häufig ärgert man sich über den Kunden, da man glaubt, er macht seine Aufgabe nicht richtig. Als Entwickler glaubt man auch, vieles besser zu wissen, für das ganz klar der Kunde zuständig ist. Mit dieser überheblichen Haltung steht man einem echten Dialog im Wege. Der Kunde und seine ureigentliche Kompetenz wird damit in Frage gestellt. Dabei mussten wir am Ende ganz natürlich auch eigene Fehler zugeben. Mit sehr frühen Aussagen und vagen Schätzungen über den Aufwand haben wir dem Kunden Versprechungen gegeben, die wir im Laufe des Projekts nicht einhalten konnten.

Diese Probleme lassen sich nur im Dialog erarbeiten. Für die Lösungen wird wechselseitiger Respekt benötigt. Den muss man zur Not einfordern, kann ihn aber von sich aus immer erbringen – auch wenn es sich anfangs vielleicht komisch anfühlt.

Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.