Was zwischen Entscheidung und Veröffentlichung geschieht: Schritte der Website-Entwicklung

Der Vertrag ist unterschrieben, die Vorauszahlung ist geleistet, und dann tritt Stille ein. Das Unternehmen wartet darauf, dass die Website erscheint, der Entwickler wartet auf Texte und Fotografien, und keiner von beiden denkt, dass er genau dieselbe Woche wartet, deshalb sind nach einem Monat beide Seiten unzufrieden, und keine von ihnen hat etwas falsch gemacht; es hatte einfach niemand schriftlich festgehalten, wer was liefert und bis zu welchem Datum.

Dieser Artikel handelt davon, was zwischen der Entscheidung und der Veröffentlichung geschieht, und vor allem von der Arbeitsteilung zwischen den beiden Seiten, weil genau sie den Termin weit häufiger entscheidet als die Geschwindigkeit der Entwicklung oder die gewählte Technik. Über die Fehler, die Auftraggeber machen, haben wir gesondert geschrieben, im Artikel über zehn Fehler bei der Beauftragung einer Website, und hier wiederholen wir sie nicht. Ebenso gibt es hier weder Preise noch einen Vergleich zwischen dem Selbermachen und dem Beauftragen, weil beides Themen anderer Artikel sind; die Rede ist nur von der Reihenfolge und davon, was in welchem Schritt vorzubereiten ist.

Discovery ist nicht der Baubeginn

Fast jeder Entwicklungsprozess beginnt mit einer Phase, die Discovery oder Analyse genannt wird, und genau diese Phase wird am häufigsten falsch verstanden, weil der Auftraggeber sie als Formalie vor der eigentlichen Arbeit behandelt. Nielsen Norman Group, die den Begriff professionell verwendet, definiert ihn als eine Vorbereitungsphase, in der das Problem selbst und sein Zusammenhang untersucht werden, formuliert wird, was lösbar ist, und genug Belege gesammelt werden, um zu wissen, wie es weitergeht, und sie betont ausdrücklich, dass in der Discovery keine Lösungen geprüft werden.

Im öffentlichen Sektor ist dieser Gedanke noch strenger formalisiert, weil das Service Manual des britischen Government Digital Service fünf Phasen unterscheidet, nämlich Discovery, Alpha, Beta, Live und Retirement, und zur Discovery dort schlicht steht: in dieser Phase beginnt man nicht, den Dienst zu bauen. Am Ende der Phase entscheidet das Team, ob es weitergeht oder innehält, und das Manual selbst legt keine feste Dauer fest, merkt aber an, dass diese Phase in der Praxis gewöhnlich vier bis acht Wochen dauert.

Hier ist sogleich eine Einschränkung nötig, weil sonst ein falsches Bild entsteht: das genannte Manual beschreibt den Lebenszyklus eines staatlichen digitalen Dienstes, nicht eine Unternehmenswebsite von zehn Seiten, und seine Fristen auf ein gewöhnliches Entwicklungsprojekt zu übertragen wäre irreführend. Wertvoll daran ist das Prinzip, nicht der Kalender: vor dem Bauen gibt es eine Phase, deren Ziel es ist, den Auftrag zu verstehen, und das Ergebnis dieser Phase kann auch die Entscheidung sein, gar nicht zu bauen.

Im praktischen Projekt zeigt sich diese Phase gewöhnlich als ein Gespräch über Prozesse, Nutzerrollen und Umfang, und ihr Ergebnis ist ein schriftlicher Plan, keine Designskizze, auch wenn der Auftraggeber oft genau die zweite sehen möchte. Für den Auftraggeber folgen daraus zwei unmittelbare Konsequenzen, und die erste ist, dass ohne ein schriftliches Discovery-Ergebnis später schlicht nichts da ist, wogegen man das Gebaute halten könnte, sodass ein Streit über den Umfang für beide Seiten ohne Beleg bleibt. Die zweite ist, dass genau in dieser Phase ein Sinneswandel billig ist, während nach dem Baubeginn jede Änderung auch das kostet, was schon gebaut ist und erneut gemacht werden muss.

Der Prototyp ist die günstigste Stelle, um umzudenken

Zwischen dem Plan und dem Bauen liegt eine Phase, die Auftraggeber manchmal für eine überflüssige Ausgabe halten, und genau das ist die Phase, die am häufigsten Geld spart. Ein Prototyp ist eine klickbare Fassung der Website ohne den echten Code, in der man die wichtigsten Wege durchgehen und sehen kann, wo etwas fehlt, und sein einziges Ziel ist, das Umdenken zu erlauben, solange Umdenken noch billig ist.

Das britische Regierungsmanual sagt diesen Gedanken ungeschönt, wenn es zur Alpha-Phase schreibt, man müsse damit rechnen, dass der gesamte in dieser Phase geschriebene Code und ein großer Teil der geprüften Ideen am Ende der Phase weggeworfen wird, und das steht nicht im Widerspruch zu guter Arbeit, sondern ist ihr Sinn: einen Prototyp wegzuwerfen ist billig, ein gebautes System wegzuwerfen ist es nicht. Im Maßstab einer Unternehmenswebsite gilt dasselbe Prinzip in kleinerem Umfang, und genau deshalb bereiten wir den Prototyp vor der ersten Zeile Produktionscode vor.

Für den Auftraggeber folgt daraus eine praktische Anforderung, die sich auszusprechen lohnt: die Freigabe des Prototyps ist kein formales Abhaken, sondern der einzige Moment, in dem Änderungen nur Zeit kosten, deshalb lohnt es genau dann, die Menschen an den Tisch zu holen, die später sagen werden, niemand habe sie etwas gefragt. Nach der Freigabe des Prototyps kostet jedes solche Gespräch schon das Gebaute.

Das Zweite, das in dieser Phase lohnt, ist Inhalt im Entwurf, weil sich ein Prototyp mit Platzhaltertext leicht freigeben lässt und man danach feststellt, dass die echten Texte nicht hineinpassen oder dass ein Abschnitt, für den ein Absatz vorgesehen war, tatsächlich drei braucht. Sind die Texte noch nicht fertig, lohnt es, in den Prototyp wenigstens Entwürfe von ungefähr richtiger Länge zu setzen, weil die Länge das Layout stärker verändert als jede Farbe.

Die meiste Wartezeit entsteht auf Seiten des Auftraggebers

Den Termin eines Projekts bestimmt meist nicht die Geschwindigkeit der Entwicklung, sondern wie schnell der Auftraggeber Inhalte liefert, und in unserer Erfahrung ist das der häufigste Grund für Verzug. Dazu gibt es in der Branche keine unabhängige Untersuchung mit Methode und Datum, deshalb sagen wir es als unsere Erfahrung und tun nicht so, als stünden Prozente dahinter.

Hier lohnt noch eine Einschränkung, weil dieser Abschnitt sonst nach dem Abschieben der Schuld klingen würde: im öffentlichen Sektor ist das Erstellen von Inhalten ein eigener Beruf und eine Rolle im Team, und im Regierungsmanual ist der Content Designer unter den nötigen Fähigkeiten aufgeführt, aber daraus folgt nicht, dass in einem gewöhnlichen Entwicklungsprojekt der Entwickler die Texte schreibt. Wer sie schreibt, ist eine Frage der Vereinbarung, und die einzige falsche Antwort ist, dass das vor Arbeitsbeginn niemand geklärt hat.

Konkret liegen auf Seiten des Auftraggebers gewöhnlich fünf Lieferungen, und für jede von ihnen lohnt schon im Vertrag ein konkretes Datum, statt das auf der Ebene des Gesprächs zu lassen. Die erste sind die Texte, und sie sind die schwerste von allen, weil man sie nicht an einem Abend schreiben kann und sie gewöhnlich jemand schreibt, für den Schreiben nicht Teil der Hauptarbeit ist und der sie zwischen den übrigen Pflichten unterbringen muss. Die zweite sind Fotografien und Logos im Vektorformat, die dritte sind Zugänge zu bestehenden Systemen, wenn aus ihnen etwas übernommen werden muss, die vierte sind Freigaben an festgelegten Punkten des Projekts, und die fünfte, die kein Dokument ist, sondern ein Mensch, ist ein Freigeber, der im Namen des Unternehmens ja sagen darf.

Diese fünfte fehlt am häufigsten, und ihr Fehlen kostet mehr als jede technische Schwierigkeit: ein Projekt, in dem die Freigabe ein Gremium erteilt, zieht sich nicht deshalb, weil jemand schlecht arbeitet, sondern weil jede Freigabe eine Sitzung verlangt, Sitzungen alle zwei Wochen stattfinden und dazwischen die Arbeit einfach steht. Gibt es im Unternehmen mehrere Beteiligte, ist die richtige Lösung nicht, sie auszuschließen, sondern zu vereinbaren, wer von ihnen die letzte Entscheidung trifft und in welcher Frist eine Antwort erwartet wird.

In Deutschland gibt es keine vergleichbare Vorschrift, die den Leiter einer Behörde namentlich zum Verantwortlichen für die Inhalte der Amtswebsite macht: das Behindertengleichstellungsgesetz und die BITV 2.0 legen die Pflicht auf die öffentliche Stelle, nicht auf einen benannten Behördenleiter. Für ein privates Unternehmen ist das ohnehin nicht verbindlich, aber der Gedanke ist derselbe und lässt sich freiwillig übernehmen: die Verantwortung für die Inhalte liegt beim Auftraggeber, und sie ist einem konkreten Menschen mit Namen zuzuweisen.

Bilder sind eine Rechtsfrage, keine Dateifrage

Fotografien sind die Stelle, an der Auftraggeber mit den besten Absichten trotzdem ein Risiko erzeugen, weil eine Datei, die auf dem Rechner liegt, als Datei gilt, die man verwenden darf. Nach dem Urheberrechtsgesetz sind Lichtbildwerke geschützte Werke, das Urheberrecht entsteht in dem Moment, in dem das Werk geschaffen ist, ohne jede Registrierung, und Urheber ist immer der Mensch, der die Aufnahme gemacht hat.

Daraus folgt eine Schlussfolgerung, die fast jedes Unternehmen überrascht: die Zahlung für ein Fotoshooting bedeutet für sich genommen nicht, dass der Auftraggeber das Urheberrecht erworben hat. Der Fotograf bleibt Urheber, das Urheberpersönlichkeitsrecht, darunter die Anerkennung der Urheberschaft, ist nicht übertragbar, und einräumbar sind nur Nutzungsrechte, nicht das Urheberrecht selbst; für ein Unternehmen, das die Fotografien auf der Website, in den sozialen Netzwerken und im Druck verwenden will, heißt das, dass die urheberrechtliche Lizenz oder die Einräumung der Nutzungsrechte genau diese Nutzungsarten nennen muss.

Bei Bildagenturen verhält es sich ebenso, nur sind die Bedingungen dort klar und öffentlich geschrieben, sodass man sie vor dem Kauf lesen kann: die Shutterstock Standard License gibt ein nicht ausschließliches und nicht übertragbares Recht, das Bild zu nutzen, einschließlich auf Websites, und auf derselben Seite steht, dass der Kunde weder Eigentum noch ausschließliche Rechte erwirbt. Dort stehen auch Beschränkungen, die man leicht versehentlich verletzt: das Bild darf nicht weitergegeben, nicht als Logo oder Marke verwendet werden, und Bilder, die nur für redaktionelle Zwecke gekennzeichnet sind, dürfen nicht kommerziell genutzt werden. Ein Unternehmen, das eine Standard License gekauft hat, hat das Recht erworben, das Bild auf der Website zu nutzen, nicht eine Datei, die es dem Entwickler als eigenes Gut übergeben könnte.

Es gibt noch einen Fall, der fast immer falsch verstanden wird. § 59 des Urheberrechtsgesetzes erlaubt, Werke, die sich bleibend an öffentlichen Wegen, Straßen oder Plätzen befinden, mit Mitteln der Malerei oder Graphik, durch Lichtbild oder durch Film zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben; bei Bauwerken erstrecken sich diese Befugnisse nur auf die äußere Ansicht. Eine Beschränkung auf die private Nutzung, auf Nachrichten oder auf nicht kommerzielle Zwecke enthält die Vorschrift nicht, deshalb ist die Fotografie der Außenansicht eines Gebäudes an einer öffentlichen Straße auf einer Unternehmenswebsite gedeckt, und ebenso andere Werke, die bleibend an einem öffentlichen Platz stehen. Die Innenansicht eines Gebäudes und Vervielfältigungen an einem Bauwerk bleiben draußen.

Schließlich sind Menschen auf Fotografien eine Frage personenbezogener Daten, nicht bloß eine Frage der Höflichkeit: nach der Datenschutz-Grundverordnung ist die Fotografie einer identifizierbaren Person ein personenbezogenes Datum, und die Rechtsgrundlage kann die Einwilligung oder ein Vertrag sein; die Einwilligung muss freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich erteilt sein. Der praktisch wichtigste Punkt ist, dass die Einwilligung jederzeit widerrufen werden kann und die Bilder nach dem Widerruf aus der öffentlichen Umgebung zu entfernen sind, deshalb müssen Teamfotos auf der Website so eingerichtet sein, dass ein ausscheidender Mitarbeiter nicht zum Problem wird.

Die Staging-Umgebung und der Fehler, der in guter Absicht entsteht

Vor der Veröffentlichung findet die Arbeit in einer getrennten Umgebung statt, und das ist aus einem einfachen Grund nötig: der Auftraggeber muss eine echte Seite in einem echten Browser sehen, nicht ein Bild aus einem Designwerkzeug, und Fehler sind an einer Stelle zu fangen, an der Kunden sie nicht sehen. Die einzige Frage ist, wie man diese Umgebung abschließt, und genau hier wird ein Fehler gemacht, der richtig aussieht.

Die verbreitete Lösung ist, eine Sperre in die robots.txt-Datei zu schreiben, und sie tut nicht, was die Menschen denken, weil die Dokumentation von Google dazu direkt sagt: diese Datei teilt Crawlern mit, auf welche Adressen sie zugreifen dürfen, und sie dient vor allem dazu, die Website nicht mit Anfragen zu überlasten, ist aber kein Mechanismus, mit dem man eine Seite aus Google heraushält. Damit eine Seite nicht in den Suchergebnissen erscheint, ist eine noindex-Regel zu verwenden oder die Umgebung mit einem Passwort zu schützen.

Als Nächstes kommt die Einzelheit, derentwegen beide Methoden zusammen schlechter arbeiten als jede für sich. Eine noindex-Regel wirkt nur, wenn die Seite crawlbar ist, weil der Crawler sie lesen muss; ist die Seite in der robots.txt-Datei gesperrt, sieht der Crawler diese Regel nie, und die Seite kann trotzdem in den Ergebnissen erscheinen, etwa wenn von anderswoher Links auf sie führen; außerdem unterstützt Google eine noindex-Regel in der robots.txt-Datei überhaupt nicht.

Es gibt auch einen zweiten Grund, warum das keine theoretische Schwierigkeit ist, nämlich: enthält die Staging-Umgebung denselben Inhalt wie die fertige Website, dann kann die Suchmaschine genau sie für die Hauptfassung halten und sie in den Ergebnissen anstelle Ihrer Website zeigen, was bedeutet, dass ein Besucher auf einer unfertigen Seite mit Testdaten landet. Dieser Fehler ist schwer zu bemerken, weil die Website selbst einwandfrei läuft und das Problem nur in den Suchergebnissen sichtbar ist.

Die praktische Antwort ist deshalb einfach, und es lohnt, sie direkt zu verlangen: die Staging-Umgebung ist mit einem Passwort zu schützen. Das ist die einzige Lösung, die unabhängig vom Verhalten der Crawler sicherstellt, dass eine unfertige Website nirgendwo erscheint, und zugleich nimmt sie das zweite Risiko weg, an das seltener gedacht wird, nämlich dass eine Staging-Umgebung mit demselben Inhalt als Hauptfassung gelten und mit der echten Website konkurrieren kann.

Welche Entscheidungen nach dem Launch am teuersten sind

Die meisten Entscheidungen in einem Website-Projekt sind auch nach dem Launch noch änderbar, und das lohnt klar zu sagen, weil Auftraggeber oft gerade über die Dinge nachdenken, die sich später am leichtesten ändern. Farben, Layout, Vorlage, Texte und sogar die Stellung der Seiten im Menü sind praktisch jederzeit änderbar, und das kostet nur Arbeitsstunden, keinen Umbau, aber zwei Dinge sind doch anders, und genau über die lohnt vor dem Launch nachzudenken, solange die Änderung noch nichts kostet.

Das Erste ist die Adressstruktur, und sie wird in dem Moment zur Entscheidung, in dem die Seiten indexiert sind und fremde Links auf sie führen, weil von da an eine Änderung der Adressen keine visuelle Wahl mehr ist, sondern eine Websitemigration, die Google als eigenes Verfahren mit eigenen Anforderungen beschreibt. Zu verwenden sind serverseitige permanente Weiterleitungen, und sie sind mindestens ein Jahr zu behalten; Google warnt außerdem davor, in einem Zug Adressen, Content-Management-System und Layout zu ändern, und für eine gewöhnliche Unternehmenswebsite empfiehlt es, alle Adressen auf einmal umzustellen, nicht stückweise. Dieselbe Seite hat außerdem eine nützliche Anmerkung, die die Sorge mindert: permanente Weiterleitungen führen für sich genommen nicht zu einem Verlust beim PageRank, auch wenn die Rankings eine Zeit lang schwanken können.

Das Zweite ist die Domain selbst, weil ein Domainwechsel dieselbe Websitemigration mit all ihren Anforderungen ist, nur in größerem Maßstab, und dazu kommt alles, was schon auf Visitenkarten und Briefbögen gedruckt ist. Darüber, auf wessen Namen die Domain registriert werden muss, haben wir im Artikel über zehn Fehler bei der Beauftragung einer Website geschrieben, und hier wiederholen wir das nicht; hier lohnt nur zu sagen, dass die Wahl der Domain eine der wenigen Entscheidungen ist, die später zu ändern mehr kostet, als sie gleich richtig zu treffen.

Es gibt eine Verfahrenseinzelheit, die man kennen sollte, um sie nicht ohne Bedarf zu verlangen: den Antrag auf Adressänderung in der Search Console stellt man nur, wenn sich die Domain oder die Subdomain ändert; für den Wechsel von einer unsicheren auf eine sichere Verbindung oder für die Wahl zwischen einer Adresse mit und ohne den Zusatz www in derselben Domain ist er nicht vorgesehen, und dort genügen die richtigen Weiterleitungen. Für ein Unternehmen heißt das, dass die meisten Änderungen serverseitig erledigt werden, nicht in einem Formular.

Praktisch folgt daraus eine Empfehlung vor dem Launch: wenn die alte Website schon existiert und Besucher aus Suchmaschinen hat, dann ist eine Liste der Adressen mit Weiterleitungen auf die neuen Adressen vor der Veröffentlichung vorzubereiten, nicht erst, nachdem jemand den Einbruch der Besuche bemerkt. Diese Liste ist auch eine der Arbeiten, die der Auftraggeber selbst vorbereiten kann und die, wenn sie niemand vorbereitet, nach dem Launch zu einer Woche Sucharbeit wird.

Barrierefreiheit: für wen sie Pflicht ist und für wen nicht

Für öffentliche Stellen ist Barrierefreiheit schon seit mehreren Jahren Pflicht; für ein privates Unternehmen nur dann, wenn es eine im Gesetz aufgezählte Dienstleistung erbringt, am häufigsten Dienstleistungen im elektronischen Geschäftsverkehr, und kein Kleinstunternehmen ist. Eine informative Unternehmenswebsite, die nichts verkauft, gehört nicht auf diese Liste. Am Markt werden diese beiden Regelungen oft verwechselt, und das ist ein Fehler, der kostet.

Die erste gilt für den öffentlichen Sektor und ist schon seit mehreren Jahren in Kraft, deshalb ist sie für Behörden keine Neuigkeit. In Deutschland setzen das Behindertengleichstellungsgesetz und die BITV 2.0 die Richtlinie der Europäischen Union über den barrierefreien Zugang zu den Websites öffentlicher Stellen um, und sie verlangen, dass die Angebote wahrnehmbar, bedienbar, verständlich und robust sind und dass eine gesonderte Erklärung zur Barrierefreiheit veröffentlicht wird. Diese Regelung bindet öffentliche Stellen und gilt nicht für ein privates Unternehmen, auch wenn sie am Markt manchmal als allgemeine Anforderung angeboten wird.

Die zweite ist jünger, und genau sie erzeugt den größten Teil der Missverständnisse, weil das Datum des Inkrafttretens weit bekannt gemacht wurde, der Anwendungsbereich aber nicht: in Deutschland gilt seit dem 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz, das die Richtlinie (EU) 2019/882 umsetzt, zusammen mit der Barrierefreiheitsstärkungsverordnung. Das heißt nicht, dass ab diesem Datum jede Unternehmenswebsite einem Barrierefreiheitsstandard genügen muss, und genau diese zu weite Behauptung wird am Markt am häufigsten wiederholt, manchmal zusammen mit dem Angebot, sie zu beheben.

Das Gesetz gilt für eine bestimmte Liste von Dienstleistungen, nicht für jede Website, und dazu gehören Telekommunikationsdienste, bestimmte Elemente von Personenbeförderungsdiensten im Luft-, Bus-, Schienen- und Schiffsverkehr, Bankdienstleistungen für Verbraucher, E-Books und die dafür bestimmte Software sowie Dienstleistungen im elektronischen Geschäftsverkehr. Eine informative Unternehmenswebsite, die nichts verkauft und keine Bank, kein Verkehrsunternehmen und keine E-Book-Plattform ist, gehört nicht auf diese Liste.

Es gibt auch eine Ausnahme für Kleinstunternehmen, und die muss genau formuliert werden, weil sie oft zu weit nacherzählt wird. Ein Unternehmen, das weniger als zehn Personen beschäftigt und das entweder einen Jahresumsatz von höchstens zwei Millionen Euro erzielt oder dessen Jahresbilanzsumme sich auf höchstens zwei Millionen Euro beläuft und das eine Dienstleistung im Anwendungsbereich des Gesetzes erbringt, ist von der Pflicht befreit, die Barrierefreiheitsanforderungen für Dienstleistungen einzuhalten. Die Ausnahme gilt für Dienstleistungen; die mit Produkten verbundenen Pflichten sind für Kleinstunternehmen leichter, aber nicht aufgehoben, deshalb ist der Satz, Kleinstunternehmen seien vom Gesetz befreit, nicht richtig.

Die praktische Folgerung für den Auftraggeber ist kurz: wenn Sie einen Onlineshop bauen und kein Kleinstunternehmen sind, dann gehören die Barrierefreiheitsanforderungen schon in die technische Spezifikation, weil sie später einen Umbau bedeuten. Wenn Sie eine informative Website bauen, dann besteht nach dem Barrierefreiheitsstärkungsgesetz wahrscheinlich keine rechtliche Pflicht, aber das bleibt ein Argument dafür, dass die Seite mit der Tastatur bedienbar und mit einem Screenreader lesbar ist, weil ein Teil Ihrer Kunden das unabhängig vom Gesetz nutzt.

Wie lange das alles dauert

Die Frage nach dem Termin ist die, auf die der Auftraggeber zuerst eine Antwort will, und sie ist auch die, auf die eine ehrliche Antwort am schwersten zu geben ist. Die in der Branche veröffentlichten Fristen kommen fast immer von den eigenen Seiten der Entwickler, wo sie als Versprechen über die Geschwindigkeit dienen, deshalb kann man sie nicht als unabhängigen Datenpunkt verwenden, und eine unabhängige Untersuchung mit Methode haben wir nicht gefunden.

Deshalb ist es richtiger, darüber zu sprechen, was den Termin bestimmt, als nach einer Durchschnittszahl zu suchen, die für kein konkretes Projekt taugt: den Termin bestimmen der Umfang, die Geschwindigkeit der Freigaben und wie weit die Inhalte fertig sind, und bei den letzten zwei dieser drei liegt der entscheidende Einfluss auf Seiten des Auftraggebers. Ein Projekt, in dem die Texte vor dem Beginn fertig sind und die Entscheidungen ein Mensch trifft, läuft deutlich schneller als ein Projekt desselben Umfangs ohne diese beiden Bedingungen, und das ist ein Unterschied, den man in Wochen messen kann.

Unsere eigene veröffentlichte Frist auf der Seite zur WordPress-Entwicklung beträgt vier bis zehn Wochen, und das gilt für eine gewöhnliche Unternehmenswebsite, während sie für komplexere Projekte länger ist und für den Onlineshop noch länger, aber für ein konkretes Projekt ist die einzige nützliche Frist die, die aus dem Umfang folgt, nicht aus einem Durchschnitt.

Es gibt noch eine andere Art, auf diese Frage zu schauen, und die ist für den Auftraggeber gewöhnlich nützlicher als jede Zahl: Fragen Sie den Entwickler nicht, wie lange es dauern wird, sondern welche Wochen von Ihnen abhängen und welche von ihm. Die Antwort auf diese Frage ist prüfbar, und sie zeigt sogleich, wie viel vom Termin Sie selbst steuern.

Und noch eine Sache, die den Termin stärker beeinflusst, als es aussieht, ist das Wachsen des Umfangs im Lauf der Arbeit: jeder neue Vorschlag ist für sich klein und begründet, aber zusammen verschieben sie das Übergabedatum, und das geschieht unbemerkt, weil keiner von ihnen je nach einer Entscheidung aussieht, das Projekt zu verlängern. Das Einzige, was dagegen hilft, ist die Vereinbarung, dass Änderungen außerhalb des ursprünglichen Umfangs gesondert festgehalten werden, zusammen mit ihrer Wirkung auf den Termin, statt sie stillschweigend aufzunehmen.

Was Sie klären sollten, bevor die Arbeit beginnt

Vor der ersten Rechnungszeile lohnt es, einen Inhaltsplan mit Daten durchzusprechen und festzuhalten: wer die Texte schreibt, bis zu welchem Datum sie in den Händen des Entwicklers sind und was geschieht, wenn sie sich verspäten, weil ohne diesen Punkt der Verzug immer nach der Schuld des Entwicklers aussieht.

Das Zweite ist die Herkunft der Bilder und die Rechte, nämlich woher die Fotografien kommen, welche Lizenz sie haben, ob in der Lizenz die Nutzung gerade auf der Website genannt ist und ob die Menschen auf den Bildern eine Einwilligung gegeben haben, die sie später widerrufen können. Das Dritte ist ein Freigeber mit Vor- und Nachnamen und eine Vereinbarung darüber, in wie vielen Arbeitstagen eine Antwort auf eine Freigabeanfrage erwartet wird, weil eine Freigabe ohne Frist keine planbare Größe ist.

Das Vierte ist eine Staging-Umgebung, die mit einem Passwort geschützt ist, nicht mit einer Sperre in der robots.txt-Datei, und das Fünfte ist eine Liste der Weiterleitungen von den alten Adressen auf die neuen, wenn die alte Website schon existiert und Besucher hat. Das Sechste ist die Frage der Barrierefreiheit, deren Antwort davon abhängt, was Ihre Website tut, und die viel billiger in dem Moment zu stellen ist, in dem die technische Spezifikation geschrieben wird, als nach der Übergabe.

Diese Liste lohnt es, in einem Gespräch durchzugehen, nicht stückweise, weil sie genau zusammen zeigt, wie groß der Anteil des Projekts ist, der vom Auftraggeber abhängt, und das ist gewöhnlich größer, als der Auftraggeber erwartet hat. Keine dieser Anforderungen ist teuer, und keine von ihnen verlangt technisches Wissen; sie verlangen nur, dass sie jemand vor Arbeitsbeginn stellt.

Und das Siebte, das nicht technisch ist, aber mehr entscheidet als die anderen sechs: eine Vereinbarung darüber, was der Mindestumfang ist, mit dem die Website veröffentlicht werden kann. Ein Projekt, in dem erst veröffentlicht wird, wenn alles fertig ist, wird oft nie veröffentlicht, während ein Projekt mit klarem Mindestumfang rechtzeitig veröffentlicht wird und danach wächst. Wenn Sie möchten, dass wir dieses Gespräch mit Ihnen führen, schreiben Sie uns.