9 Stolpersteine bei der Website-Entwicklung – und wie Sie sie mit Drupal vermeiden

Bestätigen Sie, dass Drupal das richtige CMS für Ihre Bedürfnisse ist. Drupal ist leistungsstark, aber wenn Ihre Ziele mit einer einfacheren Lösung erreicht werden können, sollten Sie dies frühzeitig erkennen. Umgekehrt, wenn Drupal die richtige Lösung ist, stellen Sie sicher, dass das Projekt seine Stärken (z.B. komplexe Workflows, robuste Inhaltsmodellierung) im Dienste Ihrer Geschäftsziele nutzt.

Führen Sie eine offene Diskussion über das Budget, bevor die Entwicklung beginnt. Setzen Sie Prioritäten zwischen Ihren "Must-haves" und "Nice-to-haves". “Denken Sie daran, dass Sie wahrscheinlich nicht alle Ihre Wünsche im Rahmen des Budgets verwirklichen können, also überlegen Sie sich von Anfang an, was Sie unbedingt brauchen, und machen Sie sich über das Budget so klar wie möglich” [2]. Es ist üblich, "ein kleines, kurzfristiges Budget mit einer Vision für sofortige, erstaunliche Ergebnisse" [2] zu sehen - und damit vorprogrammierte Enttäuschungen. Richten Sie stattdessen die Funktionen danach aus, was das Budget realistischerweise hergeben kann. Wenn der gewünschte Umfang unerreichbar ist, sollten Sie das Budget entweder reduzieren oder erhöhen, bevor die Arbeit beginnt.

Ordnen Sie in der Findungsphase jede wichtige Funktion einem Unternehmensziel zu. So stellen Sie sicher, dass Sie etwas bauen, das einen echten Nutzen bringt. Ein Projekt, das nicht an den Geschäftszielen ausgerichtet ist, kann in nette, aber überflüssige Funktionen abdriften. Sowohl der Kunde als auch die Agentur sollten klar verstehen, warum jede Funktion entwickelt wird. Das hilft auch, wenn schwierige Budgetentscheidungen anstehen - Sie können alles streichen oder zurückstellen, was nicht zu den Kernzielen beiträgt.

Betrachten Sie das Budget als einen lebendigen Parameter. Wenn Sie die Anforderungen verfeinern (oder wenn neue Bedürfnisse auftauchen), überprüfen Sie das Budget. Es ist weitaus besser, mitten im Projekt ein ernsthaftes Gespräch über die Reduzierung des Budgets zu führen, als stillschweigend zusätzliche Funktionen zu übernehmen, bis die Kosten in die Höhe schnellen. Transparenz schafft hier Vertrauen - niemand mag überraschende Rechnungen. Bei agilen Projekten ist jede Sprintplanung eine Gelegenheit, den Umfang mit den Ausgaben abzugleichen.

Die Kundenorganisation muss eine Person als Hauptverantwortlichen für das Projekt benennen (manchmal auch Produktverantwortlicher oder Vertreter der Interessengruppen genannt). Diese Person sollte die Befugnis haben, Entscheidungen zu treffen (oder schnell Genehmigungen einzuholen) und die Möglichkeit haben, zeitnah Feedback zu geben. Sie ist der erste Ansprechpartner für die Agentur. Durch einen engagierten Verantwortlichen “kann die Kommunikation gestrafft werden” [4] und ist nicht bruchstückhaft.

Es reicht nicht aus, jemanden zu benennen; er braucht die Unterstützung der oberen Führungsebene, um Entscheidungen zu treffen. Machen Sie intern klar, dass diese Person für das Projekt spricht. Wenn Fragen zum Umfang oder Design auftauchen, sollte das Wort des Projekteigners Gewicht haben. Auf diese Weise wird vermieden, dass eine genehmigte Entscheidung später von jemandem abgelehnt wird, der weniger beteiligt war. Ein befugter Projektverantwortlicher kann Änderungen genehmigen, Probleme lösen und das Projekt ohne unnötiges Hin und Her vorantreiben.

Der Projektverantwortliche sollte vom ersten Tag an (Anforderungen, Planung) bis zum Start beteiligt sein. Er nimmt regelmäßig an Statusbesprechungen oder Sprint-Demos teil und ist bereit, Anforderungen zu klären oder kleinere Streitigkeiten an Ort und Stelle beizulegen. Ein schneller, entscheidender Beitrag hält die Dynamik aufrecht. In einem technischen Artikel heißt es, dass mit einem Ansprechpartner für den Kunden "die Entscheidungsfindung schneller und effizienter wird, wodurch das Risiko verpasster Termine oder des Überschreitens des Projektumfangs verringert wird.” [4] Diese hohe Verfügbarkeit ist von entscheidender Bedeutung - wenn der Eigentümer häufig nicht verfügbar ist, kommt es erneut zu Engpässen bei Entscheidungen.

Natürlich sammelt der Projektverantwortliche immer noch Beiträge von verschiedenen Abteilungen (Führungskräfte, Endbenutzer usw.), aber dies sollte hinter den Kulissen geschehen. Intern fassen sie alle Rückmeldungen zu einer klaren Richtung für die Agentur zusammen. So muss das Entwicklungsteam nicht mit vielen Stimmen jonglieren. Wie eine Agentur für mobile Apps rät, "ernennen Sie einen einzigen, engagierten Ansprechpartner in Ihrem Team, der das Feedback und die Anforderungen des gesamten Teams priorisiert.” [5]
Die Agentur arbeitet dann mit dieser einen Stimme und ist sich sicher, dass sie die kollektiven Interessen des Kunden vertritt.

Vereinbaren Sie, wie Entscheidungen getroffen und dokumentiert werden sollen. Wenn z. B. neue Funktionsanfragen eingehen, wird der Projektverantwortliche diese bewerten (vielleicht nach Rücksprache mit den Beteiligten) und dann der Agentur ein klares Ja/Nein oder eine Priorisierung mitteilen. Auf diese Weise werden Unklarheiten vermieden. Wenn jeder weiß, wer für die Entscheidungen verantwortlich ist, werden Verwirrung und Verzögerungen vermieden.

Regelmäßige Besprechungen (wöchentliche Statusgespräche, Sprint Reviews usw.) sind wichtig. Warten Sie jedoch nicht auf geplante Treffen, um zu kommunizieren - wenn Sie ein Risiko erkennen oder Klärungsbedarf haben, melden Sie sich sofort. Proaktivität bedeutet, dass Sie Fragen oder Warnsignale frühzeitig ansprechen. Eine Empfehlung lautet, regelmäßige, proaktive Besprechungen abzuhalten, um Probleme zu erkennen, bevor sie eskalieren, anstatt passiv zu warten. Diese Kontaktpunkte schaffen Vertrauen und sorgen dafür, dass alle Beteiligten auf dem Laufenden bleiben.

Sowohl der Kunde als auch die Agentur sollten Bedenken äußern, sobald sie auftauchen. Sollte die Agentur vor einer möglichen Verzögerung oder einem Problem stehen, sollte sie es ansprechen und Lösungen vorschlagen - und es nicht verschweigen. Wenn der Kunde mit etwas nicht zufrieden ist oder sich seine Prioritäten ändern, sollte er die Agentur sofort informieren. Durch proaktives Vorgehen können Sie die Pläne gemeinsam anpassen, anstatt in letzter Minute unangenehme Überraschungen erleben zu müssen.

Kommunikation besteht nicht nur aus Reden, sondern auch aus Zuhören. Hören Sie sich in Besprechungen oder beim Lesen von E-Mails die Argumente der anderen Seite genau an und stellen Sie klärende Fragen. Zeigen Sie, dass Sie den Standpunkt der anderen Seite verstehen. Effektive Kommunikation "erfordert aktives Zuhören, Einfühlungsvermögen und die Fähigkeit, komplexe Ideen klar zu vermitteln". Indem sie "den Bedürfnissen und Anliegen ihrer Kunden aktiv zuhören, können Agenturen ihre Strategien besser anpassen und Lösungen liefern, die die Erwartungen erfüllen und übertreffen.” [8] Dies gilt in beide Richtungen. Kunden sollten auch auf den fachlichen Rat der Agentur hören

Denken Sie daran, dass es auf beiden Seiten Menschen gibt. Agenturen sollten sich in die geschäftlichen Zwänge des Kunden einfühlen (z. B. ein festes Einführungsdatum, Budgetbeschränkungen) und der Kunde sollte sich in die Herausforderungen der Entwicklung einfühlen (z. B. unvorhergesehene technische Hürden). “Wenn Probleme auftauchen, sollten Sie ihnen mit Einfühlungsvermögen und einem offenen, produktiven Dialog begegnen”. [8] Wenn sich beispielsweise eine Funktion verzögert, gibt ein einfühlsamer Kunde nicht sofort der Inkompetenz die Schuld - er fragt, was schiefgelaufen ist und wie man das Problem lösen kann. Ebenso erkennt eine einfühlsame Agentur die Frustrationen des Kunden an und sucht nach Lösungen, anstatt sich zu verteidigen.

Fördern Sie eine Kultur, in der sich die Mitarbeiter des Kunden und der Agentur als ein erweitertes Team fühlen und nicht als Anbieter oder Kunde. Nutzen Sie Tools für die Zusammenarbeit (gemeinsame Slack-Kanäle, Projektboards) und wenn möglich sogar gelegentliche persönliche Workshops, um ein gutes Verhältnis aufzubauen. Wenn alle das Gefühl haben, dass sie gemeinsam an einem Strang ziehen, besteht ein größerer Anreiz, reaktionsschnell und kooperativ zu sein. Wenn beispielsweise ein Problem auftaucht, krempeln beide Seiten die Ärmel hoch, um es zu lösen, anstatt mit dem Finger auf andere zu zeigen.

Eine proaktive Agentur wird manchmal Kundenbedürfnisse vorhersehen, die der Kunde nicht geäußert hat. Schicken Sie ihm beispielsweise einen Analysebericht oder eine Schulungsauffrischung, bevor der Kunde darum bittet, wenn Sie ahnen, dass er sie brauchen könnte. Ebenso könnte ein proaktiver Kunde beispielsweise Inhalte oder Genehmigungen vor dem Abgabetermin bereitstellen, wenn er weiß, dass das Entwicklungsteam sie bald benötigen wird. Diese durchdachten Maßnahmen zeugen von Respekt und schaffen Wohlwollen.

Investieren Sie zu Beginn des Projekts Zeit in eine detaillierte Definition des Umfangs. Dabei kann es sich um ein Anforderungsdokument, eine funktionale Spezifikation oder ein Backlog mit User Storys handeln - das Format kann variieren, aber es sollte klar umreißen, was zum Projekt gehört (und implizit, was nicht). Sowohl der Kunde als auch die Agentur sollten dies abzeichnen. Ein klarer Umfang ist der Nordstern des Projekts. Wenn später eine Anforderung auftaucht, können Sie schnell feststellen, ob sie zum Umfang gehört oder ein Zusatz ist. Diese Klarheit im Vorfeld sorgt dafür, dass jeder weiß, was er versprochen hat. Denken Sie daran: "Wenn die Projektanforderungen nicht von Anfang an klar definiert sind, kann es leicht zu Missverständnissen kommen und der Kunde kann im Laufe des Projekts zusätzliche Funktionen oder Änderungen verlangen.” [10] Klarheit zu Beginn verhindert später eine Menge Ärger.

Es ist unrealistisch zu sagen: "Niemals Änderungen". Umfangsänderungen können und werden vorkommen - Prioritäten verschieben sich, oder Sie entdecken etwas Neues während der Entwicklung. Der Schlüssel ist ein bewusster Umgang mit Änderungen. Vereinbaren Sie einen Prozess: Bei jeder neuen Anfrage oder signifikanten Änderung prüft das Team die Auswirkungen auf den Zeitplan und das Budget und genehmigt (und dokumentiert) die Änderung, bevor die Arbeit ausgeführt wird. Dies kann die Erstellung eines Änderungsantrags und die Genehmigung des Kunden für zusätzliche Kosten oder Zeit beinhalten. Auf diese Weise behalten Sie die Kontrolle. Wenn der Kunde z. B. darum bittet, einen Forenbereich hinzuzufügen, der nicht zum Umfang des Projekts gehört, sollten Sie dies nicht stillschweigend tun (und damit das Budget sprengen), sondern den Kostenvoranschlag dafür berechnen und ihn entweder mit einer anderen Funktion verrechnen oder als zusätzliche Arbeit behandeln, die zusätzlich in Rechnung gestellt wird. Auf diese Weise wird nichts unwissentlich "umsonst" hinzugefügt - alle Beteiligten bleiben auf dem gleichen Stand. Es ist auch ratsam, ein Protokoll über alle Umfangsänderungen und Genehmigungen zu führen, um Streitigkeiten zu vermeiden.

Nicht alle Funktionen sind gleich. Arbeiten Sie mit den Beteiligten zusammen, um festzulegen, welche Anforderungen für die Einführung entscheidend sind und welche optional sind oder später eingeführt werden können. Wenn der Druck steigt, den Umfang zu erweitern, können Sie sich auf diese Priorisierung beziehen. Vielleicht kann ein "zusätzliches" Feature ein anderes Element mit niedrigerer Priorität ersetzen, anstatt den Stapel einfach zu vergrößern. Dieser Ansatz (manchmal auch MoSCoW-Methode genannt - Must, Should, Could, Won't) hilft beim Aushandeln des Umfangs: Wenn neue Ideen auftauchen, haben Sie eine Grundlage, auf der Sie sagen können: "Wenn wir dies hinzufügen, können wir vielleicht jenes entfernen oder verzögern." So bleibt das Projekt auf die Bereitstellung des Kernwerts konzentriert.

Viele Umfangsprobleme sind eigentlich Erwartungsprobleme. Der Kunde ist sich vielleicht nicht bewusst, dass eine "schnelle Änderung" in Wirklichkeit einen beträchtlichen Aufwand bedeutet, oder die Agentur hat nicht geklärt, welche Auswirkungen die Änderungen haben. Klären Sie sich gegenseitig auf. "Wenn man von Anfang an realistische Erwartungen an den Kunden stellt” , indem man ihm die Ziele, Einschränkungen und Risiken des Projekts darlegt, ist die Wahrscheinlichkeit geringer, dass er später spontane Ergänzungen verlangt [10]. Wenn alle Beteiligten den Aufwand verstehen, der damit verbunden ist, zögert man eher, den Plan einfach zu ändern. Erläutern Sie auch nicht-technischen Beteiligten das Konzept der schleichenden Ausweitung des Projektumfangs; sobald sie sehen, wie das Projekt dadurch gefährdet werden kann, werden sie sich bei Änderungswünschen disziplinierter verhalten.

Wenn Sie einen agilen Ansatz verwenden (der flexibler auf Änderungen reagieren kann), sollten Sie den Umfang innerhalb jeder Iteration im Auge behalten. Agil bedeutet nicht unendlich viel Spielraum, sondern einen nach Prioritäten geordneten Spielraum. Änderungen können für künftige Sprints geplant werden, anstatt sie ad hoc in den aktuellen Sprint einzubauen. Halten Sie das Product Backlog in Ordnung und verpflichten Sie sich nur zu dem, was das Team in einem Sprint erreichen kann. Dies verhindert, dass der Umfang in der Mitte des Sprints zu groß wird. Behalten Sie außerdem eine klare Definition für jede Funktion bei, damit sich der Funktionsumfang nicht innerhalb einer einzelnen User Story ausweitet.

Das ist hart, aber wichtig. Wenn eine geforderte Änderung dem Erfolg des Projekts schadet (z. B. den Zeitplan für ein unverrückbares Ereignis sprengt), ist es in Ordnung, zurückzuschlagen und Alternativen anzubieten. Zum Beispiel: "Diese Funktion ist eine großartige Idee, aber wenn wir sie jetzt hinzufügen, riskieren wir unseren Starttermin. Lassen Sie uns das für Phase 2 planen, damit wir es richtig machen können. Kunden wissen Ehrlichkeit zu schätzen, wenn sie auf den Schutz ihrer Ziele ausgerichtet ist. Jedes "Ja" sollte ein informiertes Ja sein (mit dem Wissen, was es mit sich bringt). Manchmal ist ein höfliches "Nein für den Moment" der beste Weg, um das Projekt zu sichern.

Zu Beginn des Projekts sollten Sie eine Erkundungsphase durchführen. Dies kann Workshops, Interviews mit Interessengruppen, Nutzerforschung und die Durchsicht vorhandener Unterlagen umfassen. Ziel ist es, die expliziten Anforderungen herauszuarbeiten (was genau muss getan werden) und auch alle impliziten Erwartungen, die nicht geäußert wurden, aufzudecken. Dokumentieren Sie alles - funktionale Anforderungen, Designpräferenzen, technische Beschränkungen, User Personas, Erfolgskriterien usw. Wenn Sie agil vorgehen, wird sich dies in einem gut gepflegten Product Backlog mit User Storys und Akzeptanzkriterien niederschlagen. Bei einem traditionellen Ansatz könnte es sich um eine detaillierte Spezifikation handeln. Dabei kommt es weniger auf das Format als auf die Klarheit an. Stellen Sie sicher, dass sich alle Beteiligten bei jeder wichtigen Funktion oder Seite darüber einig sind, was sie tun/wie sie aussehen soll. Oft ist es hilfreich, Beispiele oder Referenzen zu geben (z. B. "Der Kunde mag die Art und Weise, wie Website X Y macht"), um Unklarheiten zu vermeiden. Anstelle eines vagen Hinweises wie "moderne Galerie" können Sie zum Beispiel "eine durchsuchbare Fotogalerie, in der die Benutzer nach Kategorien filtern können" angeben. Wer im Vorfeld genau ist, spart später Zeit.

Worte können auf vielerlei Weise interpretiert werden, daher sollten Sie die schriftlichen Anforderungen durch Wireframes, Mockups oder Prototypen ergänzen. Ein grobes Layout oder ein Click-Through-Prototyp kann wichtiges Feedback auslösen - "Oh, ich dachte, die Anmeldung wäre auf der Homepage, nicht auf einer separaten Seite." Es ist viel einfacher, eine Skizze oder einen Prototyp anzupassen, als den Code zu überarbeiten. Außerdem erhält der Kunde auf diese Weise frühzeitig eine konkrete Vorstellung vom Endprodukt und kann seine Erwartungen mit dem Machbaren in Einklang bringen.

Lassen Sie keine Wochen ohne Interaktion zwischen Kunde und Team verstreichen. Vereinbaren Sie regelmäßige Treffen (wöchentliche Statusgespräche, Sprint-Demos usw.) und legen Sie Kontaktpunkte fest. Vielleicht schickt der Projektleiter wöchentlich eine E-Mail über den Projektfortschritt, oder der Kunde hat alle zwei Wochen einen Termin für eine Demo. Regelmäßige Kommunikation bietet die Möglichkeit, Unklarheiten zu beseitigen und das Verständnis zu verbessern. Auch der Kunde bleibt so involviert, sodass er rechtzeitig Feedback geben kann, bevor die Dinge aus dem Ruder laufen.

Führen Sie ein lebendiges Anforderungsdokument oder einen User Story Tracker. Wann immer eine Anforderung geklärt oder geändert wird, aktualisieren Sie die Dokumentation und informieren Sie alle Beteiligten. Wenn der Kunde z. B. während eines Sprint-Reviews sagt: "Eigentlich brauchen wir zwei Arten von Benutzerrollen, nicht eine", halten Sie dies in den Anforderungen fest. Auf diese Weise arbeitet das gesamte Team auf dem neuesten Stand der Dinge. Diese Dokumentation kann so einfach sein wie Sitzungsnotizen oder so strukturiert wie eine aktualisierte Spezifikation - wichtig ist nur, dass sie aufgeschrieben und weitergegeben wird. Mehr Kommunikation ist besser als zu wenig.

Techniker und Geschäftsleute sprechen oft unterschiedliche "Sprachen". Es ist wichtig, den Fachjargon in Geschäftsbegriffe zu übersetzen und umgekehrt. Wenn eine Anforderung in geschäftlichen Begriffen formuliert ist, sollte das Team sie in technischen Begriffen umformulieren, um das Verständnis zu bestätigen. Wenn Sie einem Kunden eine Einschränkung oder Alternative erklären, sollten Sie sie in einen Kontext stellen, der für den Kunden von Bedeutung ist (z. B. "Wenn wir X machen, könnte das die Website für Ihre Benutzer um Y % verlangsamen, also sollten wir vielleicht stattdessen Z in Betracht ziehen"). Eine klare, jargonfreie Kommunikation verhindert, dass Dinge in der Übersetzung verloren gehen.

Sorgen Sie für ein Umfeld, in dem Teammitglieder sich wohlfühlen, wenn sie "dumme Fragen" stellen. Wenn etwas unklar ist, muss es geklärt werden - gehen Sie nicht von Annahmen aus. Projektmanager sollten den Kunden aktiv fragen: "Wird hier genau erfasst, was Sie brauchen?" und Entwickler fragen: "Verstehen Sie, was der Kunde mit dieser Anforderung meint?" Ermutigen Sie den Kunden, ebenfalls Fragen zu stellen - vielleicht ist er mit einem Begriff wie "Taxonomie" in Drupal nicht vertraut; eine Klärung kann sicherstellen, dass er die richtigen Erwartungen setzt. Es ist viel besser, eine Unklarheit sofort zu beseitigen, als sie erst nach der Entwicklung zu entdecken. Wie das Sprichwort sagt: "Zweimal messen, einmal schneiden". Bei Anforderungen gilt: Zweimal klären (oder mehr), einmal programmieren.

Einigen Sie sich für jede Anforderung oder Benutzergeschichte darauf, wie ein zufriedenstellender Abschluss aussieht. Dies sind im Grunde genommen die Akzeptanzkriterien. Zum Beispiel: "Der Administrator muss in der Lage sein, eine CSV-Datei mit Produkten hochzuladen und diese innerhalb von 1 Minute auf der Seite "Produkte" aufzuführen. Mit solchen Angaben weiß der Entwickler genau, was er zu bauen hat, und der Kunde/Tester kann es leicht überprüfen. Dadurch wird die Interpretationslücke geschlossen, in der der Entwickler vielleicht sagt: "Es ist fertig", aber der Kunde sagt: "Das ist nicht das, was wir wollten." Alle arbeiten auf das gleiche, klare Ziel hin.

Formulieren Sie lange vor dem Start - idealerweise in der Findungsphase - eine Inhaltsstrategie. Bestimmen Sie den Zweck Ihrer Inhalte und wie sie den Bedürfnissen der Nutzer und den Unternehmenszielen entsprechen. Ermitteln Sie, welche Inhalte vorhanden sind, welche aktualisiert werden müssen und welche neuen Inhalte erforderlich sind. Wenn Sie z. B. einen neuen Bereich auf der Website einführen, wer wird diese Seiten schreiben? Haben Sie Richtlinien für die Markenbotschaft? Berücksichtigen Sie auch die Inhaltshierarchie und die Informationsarchitektur (IA) - Drupal eignet sich hervorragend für die Strukturierung von Inhalten mit Inhaltstypen, Kategorien, Tags usw., aber Sie müssen diese Strukturen um Ihre Inhaltsstrategie herum planen. Die Einbindung eines Content-Strategen oder Ihres Marketing-Teams zahlt sich hier aus. Sie können dazu beitragen, dass der Inhalt der Website benutzerorientiert, markengerecht und SEO-freundlich ist.

Wenn Sie eine bestehende Website haben, führen Sie eine Bestandsaufnahme der Inhalte durch. Listen Sie alle Seiten, Blogs, Dateien usw. auf. Beurteilen Sie, welche Inhalte migriert werden sollen, welche nicht mehr benötigt werden und welche neu geschrieben werden müssen. Dies verhindert spätere Überraschungen (z. B. die Entdeckung von Hunderten von Seiten, die Sie nicht berücksichtigt haben). Ein Content-Audit hilft Ihnen auch, Lücken zu erkennen - z. B.: "Wir haben Produktseiten, aber keine FAQs; für diesen Bereich brauchen wir neue Inhalte. Berücksichtigen Sie bei Drupal, wie vorhandene Inhalte in die neue Website-Struktur eingefügt werden. Zum Beispiel könnte eine alte News-Seite zu Drupal-Artikel-Inhaltstypen mit Feldern für Autor, Datum usw. werden. Diese Zuordnung ist für die Migration von entscheidender Bedeutun

Die Migration von Inhalten kann manuell, automatisiert oder in einem Mix erfolgen. Automatisierte Skripte können dabei helfen, große Mengen an strukturierten Inhalten zu verschieben (Drupal verfügt über Migrationsmodule und -tools), aber oft müssen die Inhalte bereinigt und umstrukturiert werden. Gehen Sie nicht davon aus, dass die Automatisierung alles automatisch erledigen wird. “Bei Vorschlägen zur Neugestaltung wird immer wieder davon ausgegangen, dass ‚Migration‘ automatische Migration bedeutet... Leider ist dies selten eine umfassende Option.” [14]
​
Ihre neue Drupal-Site verwendet möglicherweise neue Layouts und Felder, die nicht eins zu eins mit der alten Site übereinstimmen, was bedeutet, dass ein menschlicher Eingriff erforderlich ist. Entscheiden Sie sich für einen Ansatz: Werden die Entwickler Migrationsskripte schreiben? Werden die Redakteure die Inhalte manuell eingeben? Oft ist es eine Mischform (z. B. automatische Migration grundlegender Felder, dann manuelle Korrektur der Formatierung oder Hinzufügen von Metadaten). In jedem Fall sollten Sie ausreichend Zeit und Ressourcen einplanen. Es wird davor gewarnt, dass ein CMS-Projekt scheitern kann, wenn die Migration von Inhalten nicht geplant wird​ - Sie kann länger dauern als die Entwicklung selbst, wenn sie nicht geplant wird. Beginnen Sie möglichst früh mit der Migration, sogar auf einer Testseite, um den Aufwand abzuschätzen.

Inhalt besteht nicht nur aus Textabschnitten. Er umfasst auch all die "versteckten" Elemente, die für Suchmaschinen und die Zugänglichkeit wichtig sind: Meta-Titel, Meta-Beschreibungen, Alt-Tags für Bilder, URL-Umleitungen von alten auf neue URLs, Link-Querverweise, usw. Diese werden oft bis zum Schluss übersehen. In einem Artikel über die Migration von Inhalten wird darauf hingewiesen, dass die häufig vergessenen Punkte diejenigen sind, die "die Website für UX, SEO und ADA-Konformität optimieren” [14]  - Dinge wie optimierte Bilder, Alt-Text, Meta-Beschreibungen, richtige Überschriften. Machen Sie diese Punkte zu einem Teil der Checkliste für den Inhalt. Planen Sie für SEO auch eine Weiterleitungsstrategie: Wenn sich die URL-Struktur mit der neuen Drupal-Site ändert, bereiten Sie 301-Weiterleitungen vor, damit Ihre Google-Rankings und Benutzer-Lesezeichen übernommen werden.

Wenn Sie dies vernachlässigen, kann es zu einem starken Rückgang der Besucherzahlen nach dem Start kommen. Drupal verfügt über Module (wie Redirect), um dies zu verwalten, aber jemand muss sie mit den alten-zu-neuen URL-Zuordnungen konfigurieren.

Wenn neue Inhalte geschrieben oder bestehende Inhalte überarbeitet werden müssen, legen Sie die Zuständigkeiten und Fristen für diese Aufgaben fest. Oft ist das Team des Kunden für das Schreiben von Inhalten verantwortlich (da es sein Geschäft am besten kennt), aber es ist sich vielleicht nicht bewusst, wie lange gute Texte brauchen. Integrieren Sie inhaltliche Meilensteine in den Projektplan - zum Beispiel: "Entwurf aller Serviceseiten bis Datum X; Fertigstellung bis Datum Y". Behandeln Sie sie mit der gleichen Wichtigkeit wie Entwicklungsmeilensteine. Falls erforderlich, kann die Agentur beim Verfassen der Texte helfen oder empfehlen, einen professionellen Autor zu engagieren, um den Kunden zu entlasten. Das Wichtigste ist, das Schreiben von Inhalten nicht bis kurz vor dem Start aufzuschieben.

Verwenden Sie beim Aufbau der Drupal-Website so früh wie möglich echte oder repräsentative Inhalte. Dies hilft, das Design mit echtem Text/Bildern zu testen (anstelle von Lorem Ipsum) und gibt den Inhaltserstellern ein Gefühl dafür, wie viel Inhalt benötigt wird. Richten Sie eine Testseite ein, auf der Inhalte hinzugefügt und überarbeitet werden können. Die Flexibilität von Drupal bei Feldern und Vorlagen ist großartig, aber nur, wenn die Inhalte gut passen. Wenn Sie beim Staging feststellen, dass eine bestimmte Seite leer aussieht oder eine bestimmte Überschrift immer zu lang für das Design ist, können Sie entweder den Inhalt oder das Design entsprechend anpassen. Geben Sie den Autoren von Inhalten Vorlagen oder Richtlinien für jeden Inhaltstyp an die Hand (z. B. "Blog-Beiträge sollten einen Auszug von 150 Zeichen und ein Bild von 800 x 600 haben"). So wird sichergestellt, dass die Inhalte in einem Format erstellt werden, das mit dem Design und der Funktionalität der Website übereinstimmt.

Wie auch immer Sie Inhalte migrieren, planen Sie eine Qualitätssicherung für jede einzelne Seite der neuen Website ein. Oft muss jeder Inhalt noch einmal überarbeitet werden - vielleicht um die Formatierung zu korrigieren, ein Tag hinzuzufügen oder einfach nur, um sicherzustellen, dass er korrekt aussieht. Es ist üblich, dass “jede Seite vor dem Start zwei- oder dreimal - oder öfter - überprüft und bearbeitet werden muss.​” [14] Vielleicht migrieren Sie die Seite zuerst, dann formatieren Sie sie, und nach der Überprüfung nehmen Sie weitere Änderungen vor. Das ist normal, aber wenn Sie dafür keine Zeit eingeplant haben, wird es zu einer Krise. Seien Sie bei der Schätzung der benötigten Zeit konservativ (sogar pessimistisch). Wenn Sie früher fertig werden, ist das großartig - aber wenn nicht, werden Sie froh sein, dass Sie einen Puffer hatten. Wenn möglich, verteilen Sie das Laden der Inhalte auf ein Team von geschulten Redakteuren oder auf die Mitarbeiter des Kunden (mit Schulung, siehe nächste Stolperfalle).

Betrachten Sie UX nicht als etwas, das Sie am Ende hinzufügen. Beziehen Sie UX-Designer oder zumindest UX-Denken schon früh in das Projekt ein. Erstellen Sie in der Planungsphase User Journeys und Personas: Verstehen Sie, wer Ihre Nutzer sind und was sie auf der Website erreichen müssen. Auf dieser Grundlage können Sie Entscheidungen über die Navigationsstruktur, das Seitenlayout und die Funktionen treffen. Einfachheit und Klarheit sollten die Leitprinzipien sein. Verwenden Sie Wireframes und Prototypen, um den Benutzerfluss vor der eigentlichen Entwicklung zu testen. Führen Sie nach Möglichkeit Usability-Tests an Prototypen durch - selbst ein kurzer Flur- oder Remote-Usability-Test mit einigen wenigen Zielnutzern kann eklatante Probleme aufdecken (z. B. konnten sie die Seite "Kontakt" nicht finden oder nahmen an, dass ein Element anklickbar sei, was nicht der Fall war). Wenn Sie diese Probleme bei der Gestaltung berücksichtigen, ersparen Sie sich später die Frustration Ihrer echten Benutzer. Denken Sie daran, dass zufriedene Benutzer eher konvertieren, wiederkommen und Ihre Website weiterempfehlen - UX hat einen direkten ROI.

Ein wichtiger Teil der UX ist heute die Anpassung an mobile Nutzer. Stellen Sie sicher, dass Ihre Designs responsive und mobilfreundlich sind. Testen Sie die Website auf verschiedenen Geräten und Bildschirmgrößen. Ein häufiges Problem ist eine Website, die auf einem großen Bildschirm gut aussieht, aber auf einem Smartphone zu einem Labyrinth wird. Angesichts der Tatsache, dass der Großteil des Internetverkehrs heute über mobile Geräte abgewickelt wird, ist eine schlechte mobile UX der Todesstoß. Leistung ist ein weiterer UX-Faktor - optimieren Sie für schnelle Ladezeiten (langsame Seiten vergraulen die Nutzer). Drupal verfügt über Caching- und Optimierungsmodule; nutzen Sie diese und befolgen Sie die Best Practices (Optimierung von Bildern, Minimierung von Skripten).

Es gibt aus gutem Grund festgelegte Konventionen. Stellen Sie zum Beispiel sicher, dass die Navigation klar und konsistent ist, dass Schaltflächen wie Schaltflächen aussehen, dass Links unterscheidbar sind, dass Formulare ordnungsgemäß beschriftet sind und Fehlermeldungen enthalten, usw. Erfinden Sie das Rad nicht neu, es sei denn, Sie haben einen guten Grund - die Benutzer erwarten bestimmte Verhaltensweisen (Jakobs Gesetz in UX besagt, dass die Leute die meiste Zeit auf anderen Websites verbringen, also erwarten sie, dass Ihre Website wie andere funktioniert). Ein nutzerzentrierter Ansatz bedeutet, dass Sie sich an der Denkweise der Nutzer* orientieren, nicht an der Ihres internen Teams. Holen Sie während des gesamten Projekts Feedback zur UX ein; verlassen Sie sich nicht nur auf interne Meinungen.

Barrierefreiheit sollte eine Anforderung sein, kein Nice-to-have. Verwenden Sie die Web Content Accessibility Guidelines (WCAG) als Referenz - streben Sie mindestens die Einhaltung der WCAG 2.1 AA an. Dazu gehören Dinge wie: Sicherstellung eines ausreichenden Farbkontrasts für Text (für Menschen mit Sehschwäche oder Farbenblindheit), Bereitstellung von Textalternativen (Alt-Text) für Bilder, damit Bildschirmlesegeräte diese Informationen an blinde Benutzer weitergeben können, Sicherstellung, dass die Website nur über die Tastatur navigiert werden kann (für Benutzer, die keine Maus verwenden können), Hinzufügen von Untertiteln oder Transkriptionen für Multimedia (für gehörlose oder schwerhörige Benutzer) und semantische Strukturierung von HTML (Verwendung von richtigen Überschriften <h1>..<h6>, Listen usw., was Screenreadern und anderen Hilfsmitteln hilft). Drupal bietet eine gute Grundlage für die Zugänglichkeit - viele Drupal-Themes und -Module sind mit Blick auf die Zugänglichkeit entwickelt worden, aber es ist immer noch Aufgabe des Projektteams, sie korrekt zu verwenden und die Lücken mit geeigneten Inhalten und Code zu füllen. Testen Sie alle benutzerdefinierten Funktionen im Hinblick auf Barrierefreiheit.

Nutzen Sie während der gesamten Entwicklung Tools und Methoden zur Überprüfung der Zugänglichkeit. Automatisierte Prüfprogramme (wie WAVE, Axe oder Lighthouse) können viele Probleme aufdecken (fehlende Alt-Tags, geringer Kontrast, fehlende Formularbeschriftungen usw.). Führen Sie jedoch auch manuelle Tests durch: Versuchen Sie, die Website nur mit einer Tastatur (können Sie alle interaktiven Elemente erreichen und bedienen?) und mit einem Bildschirmlesegerät (wie NVDA oder VoiceOver) zu nutzen, um zu sehen, ob die Erfahrung sinnvoll ist. Es gibt auch Zugänglichkeits-Linters und -Module während der Entwicklung, um gute Praktiken durchzusetzen. Es ist einfacher, Probleme während der Entwicklung zu beheben, als eine fertige Website zu prüfen und Korrekturen nachzurüsten (obwohl Prüfungen ebenfalls hilfreich sind).

Jeder - Designer, Entwickler, Inhaltsersteller - sollte sich der grundlegenden Zugänglichkeits- und UX-Prinzipien bewusst sein. Inhaltsautoren sollten beispielsweise wissen, dass sie beschreibende Linktexte schreiben müssen ("Erfahren Sie mehr über unsere Dienstleistungen" statt nur "Klicken Sie hier"), und Designer sollten wissen, dass sie sich nicht nur auf Farben verlassen dürfen, um Informationen zu vermitteln ("Pflichtfelder in Rot" sollten auch ein Sternchen oder eine Kennzeichnung haben). Lassen Sie bei Bedarf einen Experten für Barrierefreiheit einen Workshop mit Ihrem Team veranstalten oder eine formelle UX-Überprüfung zu bestimmten Meilensteinen durchführen. Einfühlungsvermögen für die Nutzer (auch für Menschen mit Behinderungen) führt natürlich zu einem besseren Produkt. Berücksichtigen Sie Sonderfälle: Wie funktioniert dieses Formular für einen legasthenen Benutzer? Wird dieses Karussell für jemanden, der zur Reisekrankheit neigt, ein Problem darstellen? Diese Überlegungen führen zu integrativen Designentscheidungen.

Wenn möglich, sollten Sie vor dem Start eine Runde von Benutzertests oder zumindest eine heuristische Bewertung (eine Expertenbewertung der Benutzerfreundlichkeit) durchführen. Das Aufspüren und Beheben einiger größerer UX-Probleme, bevor die Öffentlichkeit die Website zu Gesicht bekommt, kann ihre Akzeptanz erheblich verbessern. Ziehen Sie auch eine Überprüfung der Zugänglichkeit durch Fachleute oder Mitglieder der Behindertengemeinschaft in Betracht. Sie könnten Probleme finden, die Sie nicht bemerkt haben. Beheben Sie so viele wie möglich. Selbst wenn Sie nicht jedes einzelne erweiterte WCAG-Kriterium erfüllen können, wird die Erfüllung der grundlegenden Kriterien die Zugänglichkeit Ihrer Website erheblich verbessern. Dokumentieren Sie alle bekannten Lücken und planen Sie, sie bei Bedarf nach dem Start zu beheben, anstatt sie auf unbestimmte Zeit zu vernachlässigen.

Beobachten Sie auch nach dem Start das Nutzerfeedback, die Analysen und alle Berichte zur Barrierefreiheit. UX-Arbeit ist nie wirklich "fertig" - es gibt immer Möglichkeiten, sie auf der Grundlage der tatsächlichen Nutzung zu verbessern. Vielleicht brechen alle Nutzer die Website auf einer bestimmten Seite ab - untersuchen Sie die Gründe dafür (vielleicht ist die Aufforderung zum Handeln nicht klar). Oder vielleicht meldet jemand Schwierigkeiten bei der Nutzung der Website mit einem Bildschirmlesegerät - beheben Sie das umgehend. Berücksichtigen Sie UX und Barrierefreiheit auch bei allen neuen Funktionen.

Das klingt offensichtlich, aber unter Zeitdruck ist es verlockend zu sagen: "Ich weiß, dass das nicht der sauberste Weg ist, aber lass es uns einfach tun. Machen Sie es sich zur Gewohnheit, auf die richtige Art und Weise zu kodieren (und zu thematisieren, und zu konfigurieren). In Bezug auf Drupal bedeutet dies, die APIs und Module von Drupal zu nutzen, anstatt Dinge zusammenzuhacken. Anstatt z.B. ein eigenes PHP-Skript zu schreiben, um etwas zu erledigen, was ein Regelmodul oder eine Kernfunktionalität erledigen könnte, sollten Sie das etablierte Tool verwenden (es sei denn, es gibt einen zwingenden Grund, dies nicht zu tun). Halten Sie sich an Coding-Standards und führen Sie Code-Reviews durch. Eine der Ursachen für technische Schulden ist, dass die Entwickler keine besseren Techniken kennen - geben Sie also Ihr Wissen innerhalb des Teams weiter. Wenn Sie sich nicht sicher sind, wie Sie eine Anforderung in Drupal elegant umsetzen können, fragen Sie die Community oder suchen Sie nach Beispielen; die Drupal-Community ist groß und die Chancen stehen gut, dass jemand ein ähnliches Problem gelöst hat, ohne auf Hacks zurückzugreifen. Indem Sie die Dinge beim ersten Mal richtig machen, vermeiden Sie die Notwendigkeit, "zurückzugehen und es später zu korrigieren", was oft erst dann geschieht, wenn es ein echtes Problem ist.

Denken Sie bei Architektur und Design an zukünftige Anwendungsfälle. Das bedeutet nicht, dass Sie zu viel entwickeln oder unnötige Komplexität hinzufügen müssen, "nur für den Fall", aber Sie sollten vernünftige Zukunftsszenarien in Betracht ziehen. Wenn der Kunde beispielsweise in einem Jahr auf mehrere Sprachen expandieren möchte, sollten Sie die mehrsprachige Unterstützung von Drupal jetzt einrichten, anstatt überall englische Inhalte zu kodieren. Wenn die Website später E-Commerce benötigt, wählen Sie eine Drupal-Distribution oder -Architektur, die dies unterstützt oder zumindest keine Konflikte verursacht. Wenn Sie ein Wachstum des Datenverkehrs erwarten, stellen Sie sicher, dass das Hosting und die Drupal-Caching-Strategien skalierbar sind (vielleicht verwenden Sie ein CDN usw.). Ein weiteres Beispiel: Verwenden Sie das in Drupal eingebaute Feld- und Entitätssystem für Inhalte anstelle von benutzerdefinierten Datenbanktabellen, damit Sie Inhaltstypen, Ansichten usw. später leichter erweitern können. Die Planung der Skalierbarkeit stellt sicher, dass Sie sich nicht in eine Ecke drängen lassen, die später eine Neuprogrammierung erfordert. Technische Schulden entstehen oft, wenn Entwürfe zu eng gefasst sind und dann über ihren Zweck hinaus ausgedehnt werden. Eine robuste Architektur kann neue Anforderungen bewältigen, ohne zusammenzubrechen.

Wenn ein Fehler oder ein Leistungsproblem gefunden wird, gibt es manchmal eine einfache Lösung, die das Problem sofort zu beheben scheint (z.B. direktes Bearbeiten des Codes eines beigesteuerten Moduls oder Hinzufügen von ein wenig JS, um ein Backend-Problem zu beheben). Dies sind rote Fahnen. Nehmen Sie sich stattdessen die Zeit, die Grundursache zu finden und sie richtig zu beheben. Wenn ein Contrib-Modul einen Fehler hat, sehen Sie nach, ob es ein Update oder einen Patch von der Community gibt; wenn nicht, überschreiben Sie es auf eine Art und Weise, die durch Updates nicht weggeweht wird (wie Formularänderungen oder die Erweiterung von Klassen in Drupal, anstatt den Core- oder Contrib-Code zu ändern). So schmerzhaft es im Moment auch sein mag, die Untersuchung und Lösung von Problemen auf die richtige Weise ist eine Investition in die zukünftige Stabilität des Projekts. Ein Hack kann jetzt eine Stunde sparen, aber später Dutzende kosten. Denken Sie daran, dass jeder Schnitzer "Zinsen" verursacht, die Ihr Team jedes Mal bezahlen muss, wenn die Codebasis erneut angefasst werden muss.

Eine Möglichkeit, Schulden zu verwalten und zu vermeiden, besteht darin, Probleme frühzeitig zu erkennen. Das Schreiben von automatisierten Tests (Unit-, Funktions- oder Behat-Tests für User Storys) kann als zusätzliche Arbeit erscheinen, aber es zahlt sich aus, denn es stellt sicher, dass Sie mit dem Wachstum des Projekts nicht versehentlich bestehende Funktionen zerstören. Tests wirken wie ein Sicherheitsnetz, das die Entwickler dazu ermutigt, den Code zu überarbeiten (um die Komplexität zu reduzieren), weil sie sicher sein können, dass ein Test den Fehler aufspürt, wenn etwas nicht funktioniert. Ohne Tests haben Teams oft Angst, unsauberen Code zu ändern ("wenn es funktioniert, lassen Sie die Finger davon"), was bedeutet, dass unsauberer Code unsauber bleibt - und die Schulden unbezahlt bleiben. Tools für die kontinuierliche Integration (Continuous Integration, CI) können Ihre Testsuite und andere Qualitätsprüfungen (Codierungsstandards usw.) bei jedem Commit ausführen und Probleme frühzeitig erkennen. Diese Qualitätskultur trägt dazu bei, dass schlampiger Code gar nicht erst in die Codebasis gelangt. Mit der Zeit erhalten Sie eine sauberere, modularere Codebasis, die leichter zu erweitern ist.

Kein Projekt ist völlig schuldenfrei. Manchmal müssen Sie eine Abkürzung nehmen, um eine Frist einzuhalten - das ist in Ordnung, wenn Sie es bewusst tun und planen, es "zurückzuzahlen". Erstellen Sie Tickets für Refactoring-Aufgaben und geben Sie ihnen in zukünftigen Sprints Priorität. Sie könnten z. B. sagen: "Wir haben Funktion X gehackt, um sie für die Messe zu demonstrieren; jetzt, wo die Frist verstrichen ist, sollten wir einen Tag damit verbringen, sie richtig neu zu schreiben." Lassen Sie nicht zu, dass das Refactoring immer aufgeschoben wird; machen Sie es zu einem Teil der Arbeit. Die Stakeholder sehen vielleicht nicht sofort den sichtbaren Wert, aber Sie können es wie bei der Wartung eines Autos erklären - wenn wir es nicht tun, wird das Auto kaputtgehen. Einige Teams weisen einen festen Anteil jedes Sprints (z. B. 10-20 %) für die Beseitigung technischer Schulden oder für Wartungsaufgaben zu. Dies gewährleistet eine kontinuierliche Verbesserung der Codebasis. Es ist viel einfacher, die Schulden in kleinen Schritten während des Projekts zu beseitigen, als später eine massive, systemische Umschreibung vorzunehmen.

Drupal entwickelt sich, wie jede Software, weiter. Halten Sie Ihren Drupal-Kern und Ihre Module während des Projekts auf dem neuesten Stand (in angemessenem Rahmen). Verschieben Sie nicht alle Aktualisierungen auf das Ende oder auf die Zeit nach dem Start, denn veraltete Software kann zu ihren eigenen technischen Schulden werden (Sicherheitslücken, veraltete Funktionen usw.). Vermeiden Sie bei der Aktualisierung jedoch schnelle Korrekturen wie das einfache Unterdrücken von Warnungen oder Fehlern, ohne sich mit der zugrunde liegenden Änderung zu befassen. Wenn beispielsweise eine neuere Version eines Moduls eine API ändert, sollten Sie Ihren benutzerdefinierten Code entsprechend anpassen, anstatt für immer an der alten Version festzuhalten oder etwas zu hacken. Stellen Sie sich auf die Wartung ein, während Sie arbeiten. Planen Sie die Website auch mit Blick auf den Upgrade-Pfad von Drupal. Bei Drupal 9 und 10 war es zum Beispiel einfacher, ein Upgrade durchzuführen, wenn Sie Ihren Code frei von veralteten Versionen hielten. Wenn Sie ein neues Projekt starten, sollten Sie mit der neuesten stabilen Drupal-Version beginnen, um die Langlebigkeit Ihrer Plattform zu verlängern. Technische Schulden können ebenso viel damit zu tun haben, dass man nicht mit der Plattform Schritt hält, wie mit der Codequalität.

Manchmal treffen Sie eine Entscheidung, die nicht ideal, aber notwendig ist (aufgrund einer Einschränkung). Dokumentieren Sie sie - in Code-Kommentaren oder in einem einfachen Entscheidungsprotokoll. Dies hilft zukünftigen Betreuern (oder Ihrem zukünftigen Ich), den Kontext zu verstehen und nicht versehentlich auf einem wackeligen Fundament zu bauen. Zum Beispiel: "TEMPORÄR: Verwendung der benutzerdefinierten Authentifizierung anstelle von SSO aufgrund der aktuellen Infrastrukturbeschränkungen. Wird ersetzt, wenn der SSO-Server verfügbar ist. Jetzt wissen Sie, dass dieses Codestück eine Schuld trägt, die einen Auslöser hat, um ersetzt zu werden. Ohne Dokumentation könnten Sie vergessen, dass es sich um eine Umgehungslösung handelt, und diese nie wieder aufgreifen.

Besprechen Sie während des Projekts (sogar schon bei den Vertragsverhandlungen), was nach der Inbetriebnahme geschieht. Wird die Agentur einen Supportzeitraum anbieten? Ist er inbegriffen oder wird er separat bezahlt? Wie wird der Kunde Probleme melden oder zukünftige Verbesserungen anfordern? Wenn Sie diese Fragen im Voraus klären, vermeiden Sie die "Support-Lücke", bei der der Kunde denkt, dass der Support auf unbestimmte Zeit inbegriffen ist, die Agentur das Projekt aber als abgeschlossen betrachtet. Viele Agenturen gewähren eine Garantiezeit (z. B. 30-90 Tage nach dem Start), in der sie alle Fehler beheben, die innerhalb des ursprünglichen Umfangs auftauchen. Darüber hinaus kann eine formelle Support-Vereinbarung oder ein Vorschuss in Kraft treten. Vergewissern Sie sich, dass der Kunde die Bedingungen versteht: Der Support könnte zum Beispiel eine bestimmte Anzahl von Stunden pro Monat umfassen oder eine Vereinbarung über eine Rufbereitschaft usw. Wenn der Kunde keinen laufenden Support wünscht, sollten Sie zumindest sicherstellen, dass er sich der Risiken bewusst ist und einen Plan für die Wartung hat (vielleicht eine interne IT-Abteilung oder ein anderer Anbieter). Wie ein Leitfaden für Freiberufler anmerkt, führt die Nichterfüllung dieser Erwartungen später zu frustrierten Kunden, wenn sie plötzlich eine E-Mail mit "dringender Hilfe" schicken und sich wundern, warum sie nicht abgedeckt ist. Es ist viel besser, dieses Gespräch in der Ruhe vor dem Start zu führen, als während eines Brandes nach dem Start.

Für die meisten Websites empfehlen wir dringend einen Wartungsplan - dieser könnte regelmäßige Drupal-Core-/Modul-Updates (da häufig Sicherheitsupdates herauskommen), Überwachung der Betriebszeit, Backups und ein paar Stunden für kleinere Optimierungen oder Beratung pro Monat beinhalten. Präsentieren Sie dies dem Kunden als Schutz seiner Investition (was es auch ist). Zum Beispiel ist die zeitnahe Anwendung von Sicherheits-Patches von entscheidender Bedeutung - Drupal-Releases, insbesondere Sicherheitsfixes, sollten angewendet werden, um Hacks zu vermeiden. Wenn das Team des Kunden dazu nicht in der Lage ist, ist der Support-Service der Agentur von unschätzbarem Wert. Dinge wie Server-Updates oder Leistungsoptimierungen im Laufe der Zeit fallen ebenfalls in diesen Bereich. Ein Support-Team sorgt dafür, dass die Website gesund bleibt. Ein Artikel über die Bedeutung des Supports drückt es gut aus: "Sie denken vielleicht, dass Sie den Support nicht auf der Kurzwahltaste behalten müssen, weil alles reibungslos läuft, aber Sie sollten seine Nummer noch nicht löschen... es wird immer eine Gelegenheit oder eine Situation geben, die Sie nicht erwartet haben.” [22]
Mit anderen Worten: Planen Sie das Unerwartete in einer Support-Vereinbarung ein.

Bevor Sie die Schlüssel übergeben, sollten Sie die Personen schulen, die das CMS tagtäglich nutzen werden. Schneiden Sie die Schulungen auf die jeweiligen Rollen zu: Redakteure erhalten z. B. Schulungen zur Erstellung/Bearbeitung von Inhalten, zur Verwaltung von Menüs und zum Hochladen von Dateien; Administratoren erhalten Schulungen zur Benutzerverwaltung, zur Verwendung von Ansichten oder zur Änderung von Taxonomien usw., je nach Bedarf. Drupal kann für neue Benutzer überwältigend sein, stellen Sie daher schriftliche Anleitungen oder Videoaufzeichnungen zur Verfügung, auf die sie sich beziehen können. Ermutigen Sie zu praktischen Übungen in einer Staging-Umgebung während der Schulung. Selbst wenn es sich um eine Neugestaltung handelt und der Kunde zuvor Drupal verwendet hat, sollten Sie nicht davon ausgehen, dass er die neue Einrichtung kennt - jede Website ist anders, und hinzugefügte Funktionen (wie ein neuer benutzerdefinierter Inhaltstyp) müssen erklärt werden. Wie ein Experte vorschlägt: "Schulung ist ein wichtiger Aspekt jedes Webprojekts. Selbst wenn Sie eine Website neu gestalten, sollten Sie mindestens 1 Stunde Schulung in die Projektkosten einplanen. Am besten ist es, die Schulung vor dem Start der Website zu planen, damit der Kunde sich sofort mit der Website vertraut macht.”
​Auf diese Weise ist das Team des Kunden am Tag des Starts zuversichtlich und nicht verwirrt.

Stellen Sie zusätzlich zu den Live-Schulungen eine Dokumentation zur Verfügung. Dies könnte eine einfache PDF-Datei oder ein Wiki mit Schritt-für-Schritt-Anleitungen für allgemeine Aufgaben sein ("Wie füge ich einen News-Artikel hinzu", "Wie aktualisiere ich das Homepage-Banner" usw.). Screenshots sind hilfreich. Die Dokumentation ist ein Sicherheitsnetz, wenn sich das Personal ändert oder jemand einen Teil der Schulung vergisst. Sie verringert auch den Aufwand für den Support, da sich der Kunde bei grundlegenden Fragen selbst helfen kann. Drupal-spezifische Besonderheiten für das Projekt sollten dokumentiert werden (z. B. "Unsere Website verwendet das Moderationsmodul, sodass Inhaltsaktualisierungen genehmigt werden müssen; so funktioniert der Arbeitsablauf..." oder "Wir haben einen benutzerdefinierten Block für die Fußzeile, bearbeiten Sie ihn unter Struktur > Blocklayout > Fußzeilenblock"). Diese Details geben dem Kunden mehr Möglichkeiten.

Lassen Sie das Team die Website gleich nach dem Start genau beobachten. Oft finden echte Benutzer schnell Probleme, die bei den Tests nicht erkannt wurden. Richten Sie Analysen und Fehlerüberwachung ein. Planen Sie nach ein paar Wochen ein Review-Meeting ein: Besprechen Sie, wie die Website funktioniert, welche Rückmeldungen Sie erhalten haben und welche schnellen Verbesserungen die UX oder die Leistung verbessern könnten. Dies zeigt dem Kunden, dass Sie immer noch in seinen Erfolg investieren und nicht nur die Ziellinie erreichen und dann verschwinden. Es ist auch ein guter Zeitpunkt, um kleinere Verbesserungen anzusprechen, die dem Kunden einfallen, nachdem er die Website "in echt" benutzt hat - kleine Verfeinerungen können die Kundenzufriedenheit erheblich steigern.

Aus geschäftlicher Sicht ist eine neue Website nicht das Ende der Kundenbeziehung - es ist eine neue Phase. Ermutigen Sie den Kunden, die Website als eine sich entwickelnde Plattform zu sehen. Vielleicht möchte er in 6 Monaten neue Funktionen, eine SEO-Kampagne oder eine Integration mit einem CRM. Indem Sie Ihre Agentur als langfristigen Partner positionieren, werden Sie zur Anlaufstelle für diese Bedürfnisse. Bei der Verwaltung von Inhalten benötigen Kunden oft Unterstützung, wenn sie neue Teammitglieder aufnehmen - bieten Sie vielleicht zusätzliche Schulungen an (ein Leitfaden schlägt vor, "zusätzliche bezahlte Schulungen anzubieten... z. B. ein Jahr nach dem Start, wenn der Kunde ein neues Teammitglied hat” [21]). Die Idee ist, den gesamten Lebenszyklus der Website zu begleiten. Wenn der Kunde mit seiner Drupal-Website erfolgreich und zufrieden ist, ist es wahrscheinlicher, dass er für künftige Projekte oder Erweiterungen wiederkommt.