Workflow (Folge 1): Fragen Sie Ihre Entwickler!

Unglückliche Entwickler überall – demotiviert, genervt und oft auch gelangweilt. Und dabei wäre es so einfach! Mindestens ebenso sehr an der Entwicklung einer Webseite beteiligt, wie der Kreative, ist der Entwickler. Konzeptionelle und kreative Phasen sind im Projekt hoch angesehen, die Ergebnisse dieser Phasen sind oft in Stein gemeißelt, während die Umsetzung nicht selten zur Sklavenarbeit unter Vernachlässigung des gesunden Menschenverstands wird.

Folgendes Szenario ist nicht nur wenig unrealistisch, sondern darüber hinaus auch keine Ausnahme:

1. Der Art Director gestaltet für einen Neukunden verschiedene Layoutvarianten.
2. Der Creative Director mag die Layouts, sie werden präsentiert.
3. Dem Marketingleiter auf Kundenseite gefallen die Layouts, er wählt eins aus und ist ab sofort verliebt.
4. Das Entwicklerteam, das nun mit der Umsetzung beschäftigt wird, erhält das Layout.

Bis hierher klingt das normal, oder? Der größte Fehler ist allerdings schon geschehen!

Nun beginnt der zweite Akt der Tragödie … nach und nach fallen den Entwicklern, die nun unter starkem Zeitdruck an der Umsetzung arbeiten, Probleme mit dem Layout auf, das sich so nicht exakt umsetzen lässt. Da der Launch kurz bevorsteht, beginnt die „Frickelei“.

An dieser Stelle ist das Kind bereits in den Brunnen gefallen! Die Entwickler sind frustriert, weil sie gezwungen werden, das Projekt weit unter ihrem eigentlichen Qualitätsstandard umzusetzen, was marginale Korrekturen des Layouts in einer früheren Phase des Projekts überflüssig gemacht hätten – nun will es aber der Kunde genau so, wie er es auf dem Layout gesehen hat. Die „Frickelei“ kostet das Projekt Code-Qualität, es wird schwer pflegbar, denn unter Zeitdruck sind die Projektkomponenten, die am stärksten leiden, die QA und die Dokumentation. Und, was langfristig natürlich wesentlich schlimmer ist: es kostet die Motivation und das Engagement der Entwickler.

Versucht man nun, dem Kunden eben jene marginalen Layout-Korrekturen stillschweigend unterzuschieben, die man vor der Präsentation ohne weiteres hätte vornehmen können, wird er es im schlimmsten Fall bemerken, bemängeln und auf korrekte Umsetzung bestehen. Hier beginnt nun auch die Unzufriedenheit des Kunden – und sie wird sich bis zum Launch weiter steigern.

Lösung

Das Entwicklungsteam muss früher in das Projekt integriert werden. Es bietet sich an, einen oder mehrere Entwickler bereits in der Endphase der grafischen Konzeption einzubinden. So kann vermieden werden, dass Features/Gimmicks vorgestellt werden, die in der Entwicklung zu einer Katastrophe werden. Setzt die Agentur das Projekt nicht selbst um, kann sie sich um ein Gutachten zur technischen Machbarkeit durch einen unabhängigen, freien Experten bemühen, oder den Partner um ein Urteil bitten, der im Anschluss an die Konzeption mit der Umsetzung betraut wird.

Vorteile

Gleichzeitig zur Lösung des initial geschilderten Problems bietet diese Vorgehensweise noch weitere Vorteile:

1. Grafiker sammeln im Gespräch mit Entwicklern Erfahrung und bilden eine Basis, auf der sie später die technische Machbarkeit ihrer Ideen selbst (eingeschränkt) beurteilen können.
2. Entwickler können Möglichkeiten aufzeigen, wie man die Umsetzung eines Layouts drastisch vereinfachen kann und dabei auf keine grafische Komponente verzichten muss – oft entstehen Probleme durch Überlagerung, Ausrichtung, Verschachtelung oder Positionierung.
3. Entwickler können Features vorschlagen, die sich die Grafiker aus der vagen Ahnung heraus, es könnte in der Umsetzung Probleme geben, nicht getraut hat, in das Layout zu integrieren.

Ergebnis

Das Ergebnis ist eine Win-Win-Situation:

• Der Kunde ist zufrieden, wurde nicht getäuscht und nimmt das Projekt exakt in dem Zustand ab, in dem er es erwartet hat.
• Die Agentur ist zufrieden, weil der Zeitplan eingehalten wurde, die Kalkulation aufgeht und die Marge hoch ist.

Bitte verstehen Sie diesen Vorschlag nicht als Plädoyer für simple Layouts oder faule Entwickler. Ich gehe natürlich davon aus, dass die hier erwähnten Entwickler technisch fähig und in der Lage sind, die Machbarkeit eines Projekts fachlich kompetent einzuschätzen. Die Unlust, ein bestimmtes Feature/Gimmick umzusetzen, darf niemals als Grund dienen, eine Empfehlung gegen die Integration eines solchen Features/Gimmicks auszusprechen.