XML ohne spitze Klammern

Wer kennt sie nicht, die ewigen Konflikte zwischen Entwicklern und Kunden? Als IT-Dienstleister haben wir diese Konflikte bisher immer aus Entwicklersicht miterlebt, und dabei entstand oft der Eindruck, dass Kunden eben schwierig sind und nicht genau wissen, was sie eigentlich wollen. Warum sonst gibt es wohl die ständigen Diskussionen, ob etwas Bug oder Feature ist? Warum können die Kunden nicht klar definieren, was sie eigentlich haben wollen? Und warum sehen sie nicht ein, dass in der Regel sie selbst (und nicht etwa die Entwickler) Schuld sind, wenn die Aufwandsschätzungen (ausnahmsweise) einmal nicht hinkommen?

Bei der Entwicklung einer eigenen Webanwendung hatten wir jetzt die Gelegenheit, selbst die Kundenrolle einzunehmen und alles besser zu machen. Hätten wir während dieser Zeit Tagebuch geschrieben – es hätte folgendermaßen ausgesehen:

29.10.

Heute war das Kickoff. Unser Team besteht neben uns beiden Kunden aus fünf Entwicklern – allesamt technisch versiert, sehr erfahren und hoch motiviert. Wir haben den Entwicklern unseren schicken HTML-Prototypen vorgestellt. Bis auf wenige Ausnahmen (z. B. automatisches Versenden von E-Mails) lässt sich der Prototyp komplett durchklicken. Damit sollten eigentlich alle Unklarheiten beseitigt sein.

Die Entwickler haben noch etwas von einem gewissen Risiko gemurmelt, weil die Anwendung komplett in Groovy und Grails erstellt werden soll und sie damit nur wenig Erfahrung hätten. Schon klar, dass wir am Anfang nicht unsere bekannte Java-Geschwindigkeit erreichen werden. Aber so arg wird der Unterschied schon nicht sein – immerhin wurden alle Teammitglieder vorher in Groovy und Grails geschult.

31.10.

Endlich bekommen wir eine erste Version zu sehen. Allerdings verlief die Präsentation ziemlich enttäuschend: Wir können keinen Unterschied zum Prototypen erkennen – außer dass nur noch die Hälfte der Seiten funktioniert („Diese Fehlermeldung bitte erst mal ignorieren…“). Die Anwendung war doch eigentlich so gut wie fertig. Wieso funktioniert nach vier Tagen Entwicklung weniger als vorher? Angeblich war die Technologie doch schwieriger zu dressieren als gedacht. Immerhin habe ich zwischen den Zeilen herausgehört, dass wir bald so richtig Fahrt aufnehmen.

02.11.

Wir haben die erste Version getestet und jede Menge Bugs entdeckt. Und anstatt diese kurz zu fixen, wollen uns die Entwickler weismachen, das wären keine Bugs, sondern neue Features mit zusätzlichem Aufwand. Unter anderem sind die Eingabefelder nicht mit dem Cursor vorbelegt (wie denn sonst?), und der Back-Button im Browser funktioniert nicht richtig (der funktioniert doch in JEDER Webanwendung immer gleich!!!)

Außerdem haben wir viel weniger Funktionalität bekommen als ursprünglich vereinbart. Dafür ist aber der Code in „sehr hoher“ Qualität geschrieben, „alles voll abgetestet“, und somit wird es in Zukunft auch bestimmt keine „Seiteneffekte“ geben. Können wir uns dafür etwas kaufen? So können wir mit der Anwendung auf jeden Fall nicht produktiv gehen.

05.11.

Die Entwickler werden nicht müde, die Vorteile von Groovy und Grails anzupreisen (alles total „dynamisch“. Und das „Scaffolding“ erst einmal). Leider sind diese Vorteile für uns nicht ersichtlich. Wir haben fast den Eindruck, wenn wir den ganzen Kram in Turbo Pascal selbst programmiert hätten, wären wir schon fertig.

13.11.

Uns fallen immer mehr super Features ein, die wir so schnell wie möglich benötigen. Aber wenn die Entwickler nicht bald einen Zahn zulegen, wird das erst am Sankt-Nimmerleins-Tag etwas. Dafür denken sich die Entwickler irgendwelche merkwürdigen Features aus, die sie für ganz toll halten und uns unterjubeln möchten. Als ob die Ahnung davon hätten, was wir brauchen.

16.11.

Ständig rufen die Entwickler an und fragen, wie dieses Feature gemeint ist und wie sie jenes implementieren sollen. Dabei ist doch alles klar im Sprint Backlog beschrieben. Wir haben zwar zugesagt, dass wir jederzeit für Rückfragen zur Verfügung stehen – aber ein bisschen müssen die Entwickler auch mitdenken. Wir haben schließlich noch andere Sachen zu tun!

26.11.

Freitag haben wir gemeinsam die Sprint-Planung für das nächste Release gemacht. Als wir uns heute noch einmal das Backlog ansehen, fallen wir fast vom Glauben ab: Da stehen plötzlich Sachen wie „Teste Cross Cutting Concerns in WebTests mit eigener invoke-Methode“ oder auch „Binde automatische DB-Migration in Build-Prozess ein“. Keine Ahnung, was das ist oder wofür man das braucht. UND DAS SOLLEN WIR BEZAHLEN?!?

29.11.

Wir haben immer noch die erste Schätzung im Ohr („Das ist nicht so schwierig, wird wohl in zwei Wochen fertig sein“). Obwohl diese Schätzung schnell korrigiert wurde und das Tracking etwas Anderes sagt, fällt es schwer, sich von dieser Vorstellung zu trennen und realistisch zu planen. Wenn die Entwickler sich doch nur an ihre ursprüngliche Schätzung halten würden.

04.12.

Heute kam die Nachfrage, wie ein bestimmtes Feature gemeint sei. Wir mussten erst lange überlegen, wie man das sinnvoll implementiert (und die ständigen Detailnachfragen verunsichern uns zusätzlich). Kein Wunder, dass wir uns nicht mehr erinnern – wir haben das ja vor mehreren Wochen überlegt, und erst jetzt fängt die Entwicklung dafür an.

20.12.

Vielleicht machen uns die Entwickler ein Weihnachtsgeschenk und teilen uns mit, dass sie im Geheimen die nächsten zehn Features schon fertig haben? Möglich ist das, immerhin haben sie in den letzen Wochen kaum etwas Neues präsentiert.

Perspektivenwechsel

Ganz toll hatten wir es uns vorgestellt, einmal Kunden zu sein. Alles wollten wir besser machen. Das hat so leider nicht geklappt, und es wäre unfair, alles auf die Entwickler zu schieben. Wenn man es positiv wendet, kann man sagen, dass wir eine Menge lernen durften. An erster Stelle: Kunde sein ist eine schwierige Aufgabe, die voller Herausforderungen steckt und sich nicht nebenbei erledigen lässt. Die zweite wichtige Erkenntnis: Bei einer Inhouse-Entwicklung spielt es keine Rolle, ob etwas ein Bug oder ein Feature ist. Geändert werden muss es in jedem Fall, wenn der Kunde das meint. Aus Kundensicht hält man alles für einen Bug, was man sich anders vorgestellt hatte, auch wenn man es gar nicht genau beschrieben hat. Daraus haben wir versucht zu lernen. Wir schreiben zwar immer noch keine Lastenhefte, definieren aber unsere Anforderungen noch präziser und geben auch möglichst viele Hinweise, wie das neue System zu bedienen ist.

In der Kundenrolle vertritt man zumindest teilweise ein anderes Interesse als die Entwickler. Im Zweifelsfall gilt es, die Vision des neuen Systems auch gegen die „coolen“ Featureideen der Entwickler durchzusetzen. Andererseits erwachsen viele einfache Lösungen und effektivere Varianten aus dem direkten Gespräch zwischen Kunde und Entwickler. Das gilt es zu nutzen, z. B. in Planungsmeetings mit allen Beteiligten.

Uns ist auch wieder bewusst geworden, wie sinnlos es ist, alle Anforderungen an ein neues System vor Projektstart festlegen zu wollen. Ganz egal, wie viele Gedanken wir uns gemacht und wie detailliert wir unsere Anforderungen auch aufgeschrieben haben: Wir mussten doch feststellen, dass es trotzdem einen Rest an wichtigen Features und Ausgestaltungen gibt, den man erst entdeckt, wenn man die Software einsetzt bzw. testet. Dieser Umstand ist nicht weiter schlimm, muss aber dazu führen, dass man für solche Verbesserungen in der Planung Puffer vorsieht und sich regelmäßig mit den Entwicklern kurzschließt.

Und was lernen wir für den Umgang mit unseren eigenen Kunden? Jemand, der viel Geld investiert, wird zu Recht nervös, wenn er nicht schnell und regelmäßig neue Systemversionen sieht. Er kann ja nicht beurteilen, ob im Hintergrund wichtige Entwicklungen laufen oder ob die Entwickler vielleicht unfähig sind und nur sein Geld verbrennen. Deshalb kann es auch eine gute Idee sein, zu Projektstart nicht die gesamte Infrastruktur komplett aufzusetzen, auch wenn es aus Entwicklersicht das Effizienteste ist, sondern möglichst früh die ersten Features zu präsentieren. Und es ist überaus wichtig, dass der Kunde (im Rahmen seiner Möglichkeiten) auch in technische Sachverhalte mit einbezogen wird. So wird er eher Verständnis zeigen, wenn eine Aufwandsschätzung nicht stimmt oder ein wichtiges Refactoring ansteht und deshalb zunächst keine neuen Features entwickelt werden können.

Kommentare

Schreibe einen Kommentar

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