Mittwoch, 23. Mai 2012


Artikel

Februar 2009 | Artikel

Wie wir einmal Kunden waren (aber leider keine Könige)

(Link zum Artikel: http://www.entwickler.de/jaxenter//002161)

Perspektivenwechsel Teil 6

Text: Henning Wolf und Arne Roock
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
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?
Teil 1   Teil 2   

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.

Teil 1   Teil 2   

andere Artikel dieser Serie

Kommentare