Hinter den Kulissen eines Website-Entwicklungsprojektes (Teil 1)
Einmal neu und mit allem: Die Anforderungen an eine neue Website bündeln
Die Website soll einen neuen, frischen, modernen Eindruck hinterlassen, soll gut und übersichtlich für den User, aber auch für das Team, welches das Content Management System bedient, sein. Außerdem muss sie natürlich mit Mobile First-Ansatz entwickelt und umgesetzt werden, emotionalisieren mit großen Bildern oder, noch besser, mit Bewegtbild. Achja und da war doch noch diese Sache mit der Suchmaschinen-Optimierung (SEO)…
Ein Relaunch ist für fast alle Unternehmen und deren Agenturen ein wahrlicher Kraftakt. Oftmals sprechen auf Seite des Kunden mehrere Abteilungen mit, wollen viele Dinge auf einmal. Dinge, die für die Nutzer der neuen Seite vielleicht gar nicht so relevant sind. Gute Beratung und ein Team, das all diese Anforderungen nicht nur umsetzen kann, sondern sowohl den Kunden als auch die Kunden der Kunden, sprich die Nutzer, versteht, sind da natürlich Gold wert – und offensichtlich (wie unser Firmenname es schon andeutet) sind wir das auch.
Die Deadline als treibende Kraft
Bevor es dazu kommt, sich über das Layout Gedanken zu machen, geht es im ersten Schritt zunächst um die Deadline-Problematik. Der Kunde erwartet eine Website innerhalb weniger Tage, am besten schon gestern. Der Head of Digital Presences, in unserem Fall Aleks Oczos, bekommt eine beunruhigend pulsierende Ader wenn das Key Account Management mit der Timeline daherkommt und die Entwickler sehen sich schon Nachtschichten mit Energy Drinks und fettiger Pizza schieben. Aber, alles natürlich halb so schlimm, denn schon nach dem ersten Gespräch sondiert sich die Lage und alle beginnen, langsam aber sicher, an einem Strang zu ziehen.
Wir beginnen also mit einer IST-Analyse und Zieldefiniton: Was muss die Seite überhaupt können, wer ist die Zielgruppe, welche Funktionen sind gewünscht (und ergeben auch Sinn), welche Prozesse müssen berücksichtigt und abgebildet werden, was kann man effizienter gestalten? Aus diesen Fragen ergibt sich dann ein erster Entwurf einer Informationsarchitektur, sowie eine erste Customer Journey. Für eine gute Übersicht der Customer Journey arbeiten wir mit Wireframes: hierbei werden die grundlegenden Elemente der Website festgehalten, ohne ein vollendetes Design darzustellen. Das ist insofern praktisch, da sich unser Frontend-Team so wirklich auf die Benutzerführung und -erfahrung konzentrieren kann. Durch diesen ersten Schritt vermeiden wir das altbekannte „Pferd-von-hinten-aufsatteln“, da der Fokus auf der Konzeption und nicht auf dem Design – also Farben, Schriften, Buttons, etc. – liegt.
Das Pflichtenheft als Grundstein
Parallel zu den Wireframes und aufbauend auf der IST-Analyse macht sich nun Aleks an ein Pflichtenheft, um so sämtliche Anforderungen und Features in der Übersicht zu haben und um diese strukturiert an sein Entwicklerteam weitergeben zu können. Die Entwickler machen jeweils eine eigene Aufwandsschätzung: wie viele Tage werden für welche Entwicklungsschritte vonnöten sein? Im Anschluss steckt das Digital Presences Team wieder die Köpfe zusammen um die individuellen Schätzungen zu besprechen – das kann schon mal zwei Tage in Anspruch nehmen, je nach Umfang der Website und Kundenwünsche. Hier wird auch der Grundstein gelegt welches Framework/CMS genutzt werden soll, was vom Kunden angeliefert werden kann und wie die Kapazitäten Planung innerhalb des Teams aufgeteilt wird.
Apropos Kapazitäten – an diesem Punkt scheiden sich gerne die Geister zwischen Kunde, Key Account Management und Developer. Aus diesem Grund ergibt es Sinn sich zu überlegen mit welchem Entwicklungsmodell das Team an das Projekt herangeht: Waterfall oder Agile? Der Unterschied zwischen den beiden Modellen ist, simpel erklärt, folgender: Beim Waterfall-Modell hangeln sich die Entwickler von einem Milestone zum nächsten – dabei ist jeder Milestone die Basis für den darauffolgenden. Somit ist das Projekt planbar, aber äußerst sensibel was Änderungen betrifft.
Das Agile-Modell hingegen ist flexibler, hier arbeiten die Entwickler an kleineren Modulen, die in wöchentliche oder monatliche Sprints eingeteilt werden. Nach jedem Sprint wird der Output sowie die nächsten Schritte evaluiert und Feedback vom Kunden eingeholt. Hierdurch können auch kurzfristige Änderungen an der Umsetzungspipeline vorgenommen werden. Fazit: Keines der beiden Modelle ist per se besser oder schlechter. Die richtige Wahl hängt natürlich vom jeweiligen Projekt, dem Projektteam und dem Kunden ab.
Das perfekte Angebot als Ergebnis der Anstrengungen
Das Ergebnis der zahlreichen internen Besprechungen und Planungen stellt schließlich das Angebot für den Kunden, inklusive Milestone/Sprint-Planung, dar, welches als Basis für das folgende Abstimmungsmeeting dient. Nun wird das Angebot gemeinsam mit dem Kunden durchgesprochen: Welche Wünsche sind noch offen, was muss in der Milestone-Planung noch verschoben werden, sind in der Zwischenzeit noch Themen hinzugekommen, die berücksichtigt werden müssen? Ist all das geklärt, werden sowohl die Deadlines als auch die Kapazitäten entsprechend festgesetzt. Von hier an kann es also losgehen.
Wie die Umsetzungsphase bei uns aussieht, wird im nächsten Blogbeitrag verraten. Hier geht es um die Einbeziehung der Corporate Identity, das Projektmanagement und die Qualitätssicherung. Also, stay tuned!