Strukturskizze Interdisziplinäres Arbeiten

Die gegenwärtige Praxis der Webseitenentwicklung entspricht oft nicht mehr den heutigen technischen Möglichkeiten. Das bezieht sich weniger auf die Ergebnisse selbst – da steckt manchmal mehr Technik drin, als irgend jemand braucht, sondern vielmehr auf den Entwicklungsprozess an sich. Dieser ist oft enorm zeit- und kostenaufwendig und das nicht nur auf Seiten der Agentur. Ebenso hoch sind oft die zusätzlichen Anforderung an das Zeitbudget von Entscheidern und Stakeholdern

  Trotz dieses hohen Zeitaufwandes bleiben am Ende oft genug berechtigte Wünsche und Anforderungen unberücksichtigt. Oder noch schlimmer: Wenn das Ergebnis zahlloser Meetings und Mann-Monate dann endlich online geht, entspricht es schon nicht mehr den aktuellen technischen Möglichkeiten oder Besucher/Kundenanforderungen.

Die aktuellen Content-Management-Systeme – und das gilt für fast alle – bieten die Möglichkeit, den Prozess der Neuentwicklung oder des Relaunch von Websites auf neue Weise zu gestalten. Arbeitsgänge, die bisher mehr oder weniger streng voneinander getrennt nacheinander abliefen, lassen sich kombinieren oder fallen sogar ganz weg.

Die Integration nimmt zu, die Fähigkeit zur Reaktion auf Veränderungen (intern wie extern) steigt, der Zeitaufwand wird geringer. Webentwickler diskutieren die neue Vorgehensweise unter dem Begriff „agiles Development“ - das entspricht in etwa dem, was in der Fertigungstechnik als „Rapid Prototyping“ schon seit längerem erfolgreich praktiziert wird.  

In 11 Schritten und x Runden zum Ziel?

Bisherige Verfahren des Webseiten-Baus beruhen weitgehend auf folgendem Ablauf:

  1. Der Auftraggeber / Konzeptor macht sich Gedanken über Ziele und Zielgruppen des geplanten Webauftritts und entwickelt
  2. Vorstellungen für die aufzunehmenden Inhalte/Funktionen, die sich in einer
  3. Gliederung für die Inhalte bzw. die Navigation niederschlagen. Auf dieser Grundlage macht beim Webdienstleister
  4. der Grafiker mehrere statische Entwürfe (Photoshop-Bildchen) für die Gestaltung, während die
  5. Systemarchitekten und Programmierer damit beginnen, Diagramme für den Aufbau der Site und die Funktionalitäten zu zeichnen. Beides oft wenig koordiniert. Die Ergebnisse werden dann
  6. beim Auftraggeber präsentiert, diskutiert und modifiziert und anschließend oft
  7. ein zweites Mal präsentiert und meistens erneut modifiziert. Anschließend macht sich die Agentur an die
  8. Programmierung und Umsetzung in einem Content-Management-System, während der Auftraggeber an die
  9. Zusammenstellung von Inhalten geht – sofern er es nicht vorzieht, auch diese Arbeit an den Dienstleister auszulagern. Die Ergebnisse dieser Arbeiten werden dann
  10. in einem ersten Prototyp zusammengeführt und erneut
  11. präsentiert, diskutiert und meistens erneut modifiziert.

Bis zur endgültigen Freigabe wird der Zyklus von Präsentation und Modifikation gegebenenfalls mehrfach durchlaufen. In ungünstigen Fällen verändern sich beim Auftraggeber auch noch Rahmenbedingungen oder Personalwechsel bringen neue Stakeholder mit neuen Vorstellungen ins Spiel. Besonders hinderlich ist, dass die einzelnen Arbeitsgänge beim Auftraggeber und beim Dienstleister relativ unabhängig voneinander ablaufen und im wesentlichen nur bei den „Präsentationen“ von vorher festgesetzten „Meilensteinen“ abgestimmt werden – das kann die Sache erheblich in die Länge ziehen.

Das ganze Verfahren erinnert noch sehr an die Zeit, wo es Manager für „unter ihrer Würde“ hielten, selbst am Computer Hand anzulegen: Für den Email-Verkehr hatten sie ihre Sekretärin oder einen Assistenten, der die Vorauswahl traf, das Wichtige Ausdrucken und dem Chef per Postmappe vorlegen ließ – worauf dieser am nächsten oder übernächsten Tag einer Schreibkraft die Antwort diktierte, die dann wieder in ein Mailsystem übertragen wurde.

3. Verfahren und Nutzen der agilen Entwicklung

Beim „agile development“ gibt es keine Papier- oder Bildchenphasen. Die wesentlichen Entwicklungsschritte finden von Anfang an auf der Grundlage statt, auf der später der Webauftritt betrieben werden soll. Problemstellen werden frühzeitig erkannt, Alternativwege können gesucht werden, bevor viel Zeit und Geld in den Ausbau von Sackgassen gesteckt wird.

Bei agile Development erfahren die Beteiligten nicht nur frühzeitig wie die Sache aussieht, sondern auch wie sie sich anfühlt.

Navigationswege werden nicht nur auf Flowcharts oder Wireframes behauptet, sondern sie können in weitem Rahmen jederzeit nachvollzogen werden. Sogar aufwendige Formulare oder Funktionalitäten lassen sich „begreifen“ (wenn auch technisch zunächst nur als Simulation). Bei Meetings, die teilweise auch in Telekooperation durchgeführt werden können, lassen sich Fragen oder Einwände sofort klären. Man ändert im System einige Parameter – und nach wenigen Sekunden kann man sehen, wie die vorgeschlagene Änderung sich auswirken würde, und diskutieren, ob sie sinnvoll ist oder nicht. 

In der Praxis: Nur im Team ist man wirklich stark.

  Erste Voraussetzung dafür, dieses Entwicklungsverfahren erfolgreich anzuwenden, ist eine offene Art des Umgangs zwischen allen Mitwirkenden. Die Beteiligten bilden im Idealfall nicht einzelne Teams, die nebeneinander her arbeiten und sich nur zum Abgleich von Zwischenergebnissen treffen . - In einem solchen Workflow sind unliebsame Überraschungen vorprogrammiert. - Stattdessen arbeiten alle Beteiligten so eng wie möglich zusammen, um Ergebnisse sofort füreinander nutzbar zu machen und unvermeidlich auftretende Fragen und Schwierigkeiten anzugehen, bevor sie sich zu echten Problemen auswachsen.

Grundlage einer solchen Art der Zusammenarbeit ist der Respekt vor den anderen Beteiligten und deren Kompetenzen. Agiles Arbeiten ist immer interdisziplinäres Arbeiten und setzt ausreichende Kompetenz bei allen Beteiligten voraus.

Jeder Webentwickler graust sich vor den Diskussionen mit dem Grafiker, der auf der Umsetzung seiner grafischen Entwürfe pocht, obwohl man ihn auf die technischen Nachteile und die steigenden Entwicklungskosten hingewiesen hat. Der Grafiker ärgert sich über den Techniker, der scheinbar immer alles abblockt.

Und dann kommt auch noch der Texter im späteren Entwicklungsprozess mit zweizeiligen Headlines und viel zu langen Wörtern um die Ecke – so war das gestalterisch und technisch ja gar nicht geplant. Und wenn es ganz schlimm kommt, hat sich zum Schluss die Marketingabteilung dann doch alles ganz anders vorgestellt. Diesen Stress kann man verhindern. 

Verständnis entsteht erst am lebenden Objekt.

  Grundlage eines jeden Webprojekts ist der Content. Der Inhalt und seine Nutzung bestimmen die Art der Präsentation. Es macht keinen Unterschied, ob man Schuhe verkaufen, Spenden einwerben, Einwohner informieren oder Fachinformation an den Mann und die Frau bringen will. Ein Webangebot ist immer auch ein inhaltliches Serviceangebot. Und wer den besten Service anbietet ist klar im Vorteil.

Den besten Service kann man nur bieten, wenn man sowohl inhaltlich, gestalterisch als auch technisch die Erwartungen des Kunden -über- trifft. Mit Hilfe von CMS-Systemen ist heute agiles, interdisziplinäres Arbeiten sehr viel leichter geworden. Inhalte und Navigationsstrukturen lassen sich recht schnell in die unterschiedlichen Systeme einfügen und je nach Bedarf verschieben oder umkategorisieren. Templates steuern den ausgegebenen HTML-Code und die Gestaltung. Die Templates liegen in der Hand des Frontendentwicklers und des Gestalters. 

Ich selbst male schon lange keine Photoshop- Bildchen mehr, sondern code meine Entwürfe direkt. Das spart Zeit – ein Arbeitsgang fällt weg. Und wenn es dann am Ende doch lieber Blau statt Rot sein soll ist dies - Dank den CSS-Perprocessoren – eine Arbeit von Sekunden.

 

  Nachdem die ersten Vorüberlegungen abgeschlossen sind und eine ungefähre Marschrichtung vorliegt, baut man innerhalb des Systems eine Basisstruktur auf, die allen Beteiligten als Arbeitsplattform dient. Der Texter fügt Texte ein , der Frontendentwickler kümmert sich in enger Absprache mit dem Gestalter um den HTML / CSS Code, während im Hintergrund die Backenddeveloper sich um Datenbankanwendungen etc. kümmern. Gemeinsam sieht man wie die Anwendung wächst und Formen annimmt. Passt irgendetwas nicht zusammen kann man recht schnell darauf reagieren, weil man sieht was der andere tut. Auch mögliche Usabilitymängel werden schnell erkennbar.

Eine möglichst frühzeitiger Beginn der Arbeit am Content hat zusätzliche Vorteile. Die Backendentwickler / Administratoren des Systems finden heraus wie Prozesse für den späteren Dauerbetrieb optimal und vor allem pflegeleicht zu gestalten sind. Ein weiterer Vorteil besteht darin, dass die Zeit zwischen Fertigstellung der technischen Grundlagen des Webauftritts und der Online-Stellung deutlich kürzer ausfällt.

Praktisch von Anfang an ist zumindest eine Basisausstattung von Inhalten vorhanden, die dann während des öffentlichen Betriebs weiter ausgebaut wird. Bei großen Projekten lassen sich bei früher Online-Stellung sogar erste Besucher-Reaktionen noch in die weitere Arbeit einbeziehen.

Als letzten Vorteil ist anzuführen, dass die im agile Development vorausgesetzte enge Kooperation aller Beteiligten die Abnahme von Projekten deutlich erleichtert. Der allgemeine Kenntnisstand über den Zustand des Projekts ist höher und das bei der gemeinsamen Arbeit entstandene Vertrauensverhältnis verringert die Gefahr, dass es kurz vor going online zu unliebsamen Überraschungen kommt. 

Ich nutze Cookies,
aber nur technisch notwendige Session-Cookies.