Projektarchitektur dient der Erreichung der Projektziele

Projektziele sind dabei natürlich in erster Linie inhaltliche Ziele wie eine technische Modernisierung oder ein gestalterischer Relaunch. Ein wichtiges Projektziel ist aber regelmäßig auch ein möglichst effizienter Ressourceneinsatz und in der Folge eine möglichst kostengünstige Umsetzung, möglichst viele Funktionalitäten bei einem vorgegebenen Budget oder allgemein möglichst wenig Verschwendung.

Dafür möchten wir einerseits möglichst wenige Ressourcen in eine detaillierte Planung und allgemein umfangreiches Projektmanagement stecken, aber zugleich auch Reibungsluste durch Missverständisse oder Konflikte vermeiden. Dafür kommt es auf vor allem auf erfolgreiche Kommunikation an. Dazu später mehr.

Agile Softwareentwicklung

Wir gehen bei allen Entwicklungsprojekten nach den Prinzipien der agilen Softwareentwicklung vor. Agil bedeutet reaktionsfähig und wendig, und es geht dabei insbesondere um die menschlichen, nicht-technischen Erfolgsfaktoren eines Projekts.

Einer dieser Faktoren ist, dass man während der Projektumsetzung unweigerlich zu neuen Erkenntnissen kommt – also alle Beteiligten im Projekt lernen – und man daher das Projekt so organisieren sollte, dass diese neuen Erkenntnisse ohne aufwändige Umplanung auch in der Umsetzung berücksichtigt werden können.

Ein weiterer wichtiger Aspekt ist, dass direkte und persönliche Kommunikation der beste Weg für die Vermittlung von komplexen Sachverhalten ist und daher die Auftraggeber eines Projekts auch regelmäßig in direktem Kontakt mit den Entwicklern stehen sollten. Darauf gehe ich gleich noch ein.

Flow-Orientierung und Kanban

In unseren Projekten hat sich eine flow-orientierte Vorgehensweise in kleinen Schritten besonders bewährt. Das bedeutet, dass wir die Entwicklungsaufgaben möglichst nacheinander angehen und so strukturieren, dass wir regelmäßig Zwischenschritte abschließen können. Je weniger Aufgaben gleichzeitig in Arbeit sind, desto flüssiger läuft das Projekt. Und umgekehrt: Je mehr Aufgaben parallel angegangen werden, desto leichter entsteht Durcheinander und desto weniger Fokus haben alle Projektbeteiligten.

Um das Projekt im Alltag zu steuern nutzen wir ein sogenanntes Kanban-Board, auf dem man zugleich auch jederzeit den Projektstatus sehen kann.

Auf einem Kanban-Board (Kanban ist japanisch und bedeutet soviel wie Karte, Tafel oder Beleg) werden alle Projektaufgaben als Karten dargestellt. Die Karten sind in Spalten organisiert, wobei jede Spalte für einen Zustand der Aufgabe steht. Es gibt mindestens eine Spalte für noch nicht begonnene Aufgaben (Todo), eine Spalte für Aufgaben, die angefangen sind (Doing) und eine Spalte für abgeschlossene Aufgaben (Done). Je nach den Anforderungen des einzelnen Projekts kann es noch eine Reihe weiterer Spalten geben. Für uns haben sich in den letzten Projekten z. B. Spalten für „Wartet auf Budgetfreigabe“ und „Wartet auf Abnahme“ bewährt.

In der Spalte „Wartet auf Abnahme“ liegen alle Aufgaben, die aus unserer Sicht fertig sind. Unser CI-System richtet für jede Aufgabe automatisch einen Testserver ein, den wir unseren Kunden dann schicken und auf dem sie sich die Website mit genau dieser Änderung anschauen können. Wenn es keine Änderungswünsche gibt, nimmt unsere Ansprechperson die Aufgabe ab und wir bringen sie per Knopfdruck auf den Liveserver. Anschließend wandert die Karte in „Done“.

Das Kanban-Board hilft uns bei der Fokussierung, denn es zeigt ganz klar, welche Aufgaben gerade in Arbeit sind. Die Grundregel ist, dass Aufgaben, die bereits angefangen sind, abgeschlossen werden sollten, bevor neue Aufgaben begonnen werden.

Kommunikationsstrukturen: Mischung aus persönlich und schriftlich

Vorhin habe die die Bedeutung guter Kommunikation für den Projekterfolg erwähnt. Daher möchte ich jetzt unsere Kommunikations-Strukturen für Projekte vorstellen.

Wie schon gesagt, legen wir Wert auf möglichst direkte Kommunikation zwischen unseren Entwickler:innen und unseren Kund:innen.

Aufgabe des Projektmanagements ist bei uns die Moderation der Kommunikation und die Steuerung des Projekts, aber nicht die Weitergabe von Informationen vom Entwicklungsteam zu Kunden und von Kunden zum Entwicklungsteam. Denn das führt leicht zu "Stille Post"-Effekten und nicht zu optimalen Lösungen.

Wir setzen sowohl auf schriftliche Kommunikation als auch auf persönliche Kommunikation in Videokonferenzen.

Soviel wie möglich versuchen wir schriftlich zu klären, denn das ist in vielen Fällen sehr effizient und vor allem asynchron – mit asynchron meinen wir, dass das Senden und Empfangen einer Nachricht nicht gleichzeitig passieren muss. Wir können also eine Nachricht zu einem beliebigen Zeitpunkt senden und unsere Ansprechpersonen können uns bei passender Gelegenheit antworten, ohne dass wir uns dafür verabreden müssen. Schriftliche Kommunikation ist zudem automatisch auch Dokumentation.

Jours Fixes für effiziente persönliche Abstimmungen

Gleichzeitig ist aber auch das Potenzial für Missverständnisse in der schriftlichen Kommunikation am größten und man bekommt zudem kein direktes Feedback, ob das Gegenüber die Nachricht verstanden hat. Daher vereinbaren wir in Projekten feste Termine für Videokonferenzen, um Themen zu besprechen, die von einem persönlichen Austausch profitieren. Ein typischer Jour Fixe-Termin wäre z. B. jede Woche Dienstags um 14:30 oder auch jeden Donnerstag um 10:30. Die festen Termine haben den Vorteil, dass wir Zeitaufwand und Verzögerungen verhindern, die sich ergeben, wenn jeder Abstimmungstermin einzeln abgestimmt werden muss. Die Regelmäßigkeit führt zudem dazu, dass die meisten Themen, für die es eine persönliche Abstimmung braucht, bis zum nächsten Termin warten können und keine Ad-Hoc-Besprechungen nötig sind.

An den Jours Fixes nimmt von unserer Seite der oder die Projektverantwortliche teil sowie der oder die Entwickler:innen, die an den Themen arbeiten, die im jeweiligen Termin besprochen werden sollen. Dadurch ist eine direkte Kommunikation zwischen Entwickler:innen und Auftraggeber:innen bei komplexen Themen sichergestellt. Auch von Auftraggeberseite sind alle Personen in den Jours Fixes willkommen, die Wissen zum Thema beisteuern können oder Interesse an der Entscheidung haben.

Was uns in dem Zusammenhang wichtig ist, ist, dass wir eine feste Ansprechperson auf Seiten der Auftraggeber haben, die hauptsächlich mit uns kommuniziert und regelmäßig bei den Jours Fixes anwesend ist. Unsere Ansprechperson sollte entscheidungs- und weisungsbefugt sein. Es sollte also in der Regel möglich sein, mit dieser Person in den Jours Fixes Aufgaben und Probleme zu besprechen und gemeinsam zu einer verlässlichen Entscheidung zu kommen.

Es spricht nichts dagegen, dass es auch mehr als eine Ansprechperson gibt, aber es sollte mindestens einen "Stabilitätsanker" geben.

Übrigens: In unserem Projektprozess gibt es keine Zwischenpräsentationen vor größeren Gremien wie zum Beispiel einem Lenkungsausschuss. Alle am Projekt Interessierten können sich den Stand auf dem Kanban-Board und auf den Testservern anschauen und gerne an Jours Fixes teilnehmen.

Schriftliche Kommunikation im Projekt über GitHub

Für die schriftliche Kommunikation in Projekten nutzen wir die Plattform GitHub. In GitHub wird der Quellcode des Systems verwaltet und es ist gleichzeitig eine Projektmanagement- und Kommunikationsplattform. Wir nutzen GitHub zur Strukturierung der Aufgaben, zur Abstimmung von Details und zur Freigabe fertiger Funktionalitäten durch unsere Kundinnen und Kunden – auch unsere Kanban-Boards leben in GitHub.

In GitHub haben alle Projektbeteiligten haben Einblick in die Kommunikation. Alle Entscheidungen und Entscheidungsgründe sind dort dann dokumentiert und nachvollziehbar.

Im folgenden Screenshot aus einem fiktiven Projekt sehen Sie, wie die Freigabe eines Features über GitHub erfolgt: Wir teilen unserer Kundin mit, dass der Projektschritt „Frontend-Basiseinrichtung inkl. Basislayout und Stilen“ bereit zur Abnahme ist, und nennen ihr eine Testserver-Adresse, auf der sie den Stand anschauen kann. Sie meldet sich daraufhin mit einem Änderungswunsch zurück, den wir auf einem neuen Testserver zeigen. Sie entscheidet sich schließlich für die geänderte Version und nimmt die Umsetzung ab.

Effiziente Prozesse durch Automatisierung

Ein wichtiger Aspekt in unserer Projektarchitektur ist auch die Nutzung von Automatisierung. Wie schon ein paar Mal angeklungen ist, wird für jede Änderung und jedes neue Feature ganz automatisch ein Testserver eingerichtet, auf dem die Website voll funktionsfähig und mit genau dieser Änderung zu sehen ist. Auf dieser Basis können sowohl Kolleg:innen als auch Auftraggeber:innen dann einfach beurteilen, ob aus ihrer Sicht alles korrekt umgesetzt ist.

Die automatische Einrichtung von Testservern hat eine ganze Reihe von Vorteilen:

• Wir sparen das Budget, das früher für die manuelle Einrichtung von Testservern nötig war.
• Durch die Automatisierung bekommen wir auch für kleine Änderungen jeweils eigene Testserver und können diese vor dem Launch perfekt mit unseren Kund:innen abstimmen. Das erleichtert die Kommunikation und verhindert Missverständnisse.
• Die Abstimmung erfolgt sehr fokussiert: Auf jedem Testserver ist genau ein Feature oder eine Änderung zu sehen und genau diese Änderung kann abgenommen werden (bei größeren Relaunches arbeiten wir zusätzlich mit einem Relaunch-Testserver, auf dem alle bereits abgenommenen Änderungen gesammelt zu sehen sind)

Darüber hinaus durchläuft jede Codeänderung auch verschiedene automatisierte Tests, über die wir sicherstellen, dass auch mit dem geänderten Code alles noch so funktioniert, wie es soll.

Wenn eine Änderung abgenommen ist, wird der neue Codestand auch automatisch und ohne manuellen Aufwand in den Livebetrieb übernommen.

Risiken aktiv steuern

Last but not least betreiben wir ein bewusstes Risikomanagement. Bei allen Planungsentscheidungen und insbesondere bei der Aufgabenpriorisierung berücksichtigen wir das Risiko für das Gesamtprojekt und den Zeitplan.

Wenn wir eine Aufgabe als besonders risikobehaftet ansehen, planen wir sie früh im Projekt ein, um noch einen möglichst großen Handlungsspielraum zu haben. Ein Risiko kann beispielsweise sein, dass der Umsetzungsaufwand schwer einzuschätzen ist. Oder aber die Machbarkeit ist gar nicht sicher, dann ist es wichtig, noch Zeit für Alternativpläne zu haben.

Als weitere Maßnahme des Risikomanagements nutzen wir Code Reviews und Pair Programming. Bei einem Code Review schaut sich eine zweite Entwicklerin den Code eines Entwicklers an, um zu prüfen, ob dieser gut verständlich und korrekt ist. Dadurch findet automatisch auch ein Wissenstransfer statt und das Wissen über den Code ist in zwei Köpfen. Gleiches gilt für das Pair Programming, bei dem zwei Entwickler:innen gemeinsam an einem Feature arbeiten. Häufig kommen zwei Köpfe gemeinsam zu besseren Lösungen als einer alleine und auch hier findet automatisch Wissenstransfer statt.

So ist sichergestellt, dass wir auch in Krankheitsfällen immer weiterarbeiten können.

Kontinuierliche Weiterentwicklung

Unsere Projektarchitektur entwickeln wir behutsam, aber kontinuierlich von Projekt zu Projekt weiter. Kanban setzen wir seit 2015 für die Projektsteuerung ein. 2017 haben wir begonnen, in Projekten regelmäßige Jour Fixes anstelle von Ad-Hoc-Anrufen zu etablieren. 2021 haben wir dann begonnen, unseren Kunden Zugriff auf ihr Quellcode-Repository bei GitHub zu geben und GitHub auch zur Verwaltung und Abstimmung von Aufgaben zu nutzen. In den Jahren darauf haben wir unsere teaminternen Arbeitsabläufe so angepasst, dass wir den großen Nutzen von Pull Requests in unseren Projekten realisieren konnten. Und schließlich haben wir dann in 2022 zunächst für alle Liveserver automatische Deployments eingerichtet und die Deployment-Automatisierung bis 2024 sukzessive auch auf Testserver-Deployments für Pull Requests erweitert.

Wir haben noch viele Ideen, wie wir unsere Projektarchitektur weiterentwickeln können – ich bin gespannt, welche wir als nächstes realisieren.

Auch wir bei der webfactory GmbH haben aktuell nur eine Frauenquote von 10%. Daher möchten wir unseren Beitrag leisten, um Mädchen und jungen Frauen die spannende Welt der Webentwicklung näherzubringen.

Der Girls’Day in der webfactory GmbH

Dieses Jahr haben sich Jano, Søren und ich bereit erklärt, alles vorzubereiten und die Mädchen durch den Tag zu begleiten. Besonders gefreut haben wir uns über die Unterstützung von Søren, der seit langem mal wieder beim Girls’ Day dabei war und so frischen Wind mitgebracht hat.

Durch die Erfahrungen der vergangenen Jahre konnten wir auf einen guten Tagesablauf zurückgreifen. Dieser erwies sich erneut als wertvoller Leitfaden:

Frontend

Nach einer kurzen Kennenlernphase und Roomtour durch unsere Büroräume ging es mit dem Thema Frontend-Entwicklung los. Mit einer Präsentation haben wir eine kurze Einführung in das Thema gegeben und es in den Gesamtkontext der Web-Entwicklung eingeordnet.

Doch besser als reines Zuhören ist bekanntlich Learning by Doing. Dafür haben wir im Vorfeld eine kleine Übungs-Website vorbereitet, an der die Mädchen selbstständig arbeiten konnten: Texte bearbeiten, neue HTML-Elemente einfügen, Schrift- und Hintergrundfarben per CSS anpassen, Bilder austauschen, etc.

Kurzgesagt: Sie konnten direkt in die Rolle einer Frontend-Entwicklerin schlüpfen und ihre Website nach Belieben gestalten.

Backend

Wo ein Frontend ist, ist ein Backend nicht fern!

Nun sollten die Mädchen noch einen Überblick über das Thema Backend-Entwicklung gewinnen. Dafür sind wir mit einem kurzen Exkurs in die Vergangenheit gestartet und haben Ada Lovelace – die erste Programmiererin der Welt – vorgestellt. Ihre visionäre Idee, Musik in Zahlen zu übersetzen und damit eine Maschine zur Komposition zu bringen, machte sie zu einer Pionierin der Informatik.

Danach sind wir auf scratch.org gegangen und haben dort gemeinsam kleine Programme geschrieben; z. B. haben wir logische Anweisungen programmiert, um Disney's Eisprinzessin Elsa bestimmte Figuren auf einer Eisfläche zu fahren zu lassen.

Projektmanagement

Frisch vom Mittagessen gestärkt, stand das Thema "Projektmanagement" auf dem Programm.

Wir zeigten den Mädchen unser Trello-Board und erklärten wie wir unsere Projekte planen, Aufgaben koordinieren und im Team zusammenarbeiten.

Natürlich durften sie auch hier wieder selbst ans Werk und bekamen die Aufgabe, eine Zeitplanung für den Weg von Entwurf über Prototyp und Test mit der Zielgruppe bis hin zur Produktion und Auslieferung eines neuen Schulranzenmodells erstellen.

„Die Musterranzen benötigen vier Tage zur Herstellung, können aber erst nach Fertigstellung des Briefings und der Abstimmung beginnen.“

„Die Schnittmuster müssen angepasst werden – das dauert einen Tag, kann aber erst nach dem Ergonomietest des Prototypen mit Schüler*innen erfolgen.“

Dabei kam es darauf an, Aufgaben parallel zu planen, Abhängigkeiten zu erkennen und mögliche Engpässe zu umgehen.

Søren hatte dabei eine große Freude daran, die Teilnehmerinnen vor weitere spontane Herausforderungen zu stellen:

„Der Kunde wünscht ein neues Ranzendesign – können wir die Deadline trotzdem halten?“

„Die Schüler*innen für den Ergonimietest können an dem geplanten Tag nicht, sie schreiben eine Klassenarbeit – an welchem Tag können wir sie erneut einladen? Was für ein Zeitfenster können wir nennen?“

„Unser Lieferant möchte seine neue Stickmaschine testen – gehen wir das Risiko ein?“

Aber auch diese Hürden wurden mit Bravour gemeistert.

Konzeption

Zu guter Letzt durften die Teilnehmerinnen in die Rolle einer Konzeptionistin schlüpfen und ihre eigenen Website konzipieren.

In zwei Gruppen entwickelten sie Website-Konzepte für ein Schmucklabel und eine Tierarztpraxis. Mit Stift, Zettel und viel Kreativität wurden Wireframes für die Websites gezeichnet. Danach präsentierten sie ihre Ideen vor einem strengen Komitee: ihren Mitstreiterinnen.

Abschluss

Um den Tag ausklingen zu lassen nutzten wir wieder die 5-Finger Feedback-Methode[^1].
Dabei zeigte sich, dass alle viel Spaß hatten und sie am liebsten noch länger an ihren eigenen Websites gearbeitet hätten.

Vier der sieben Mädchen können sich sogar vorstellen, später mal in der IT-Branche zu arbeiten – also ein voller Erfolg für den Girls'Day!

Nach dem Aufräumen ging auch für uns ein sehr schöner Tag zu Ende.

Wir freuen uns jedes Jahr aufs Neue auf den Girls’Day, da es einfach Freude macht, jungen Mädchen Einblicke in unsere Berufswelt zu geben. Gespannt und mit Vorfreude blicken wir schon jetzt auf den nächsten Girls’ Day!

[^1]: Die 5-Finger-Methode:
Daumen: Das fand ich gut
Zeigefinger: Darauf möchte ich hinweisen
Mittelfinger: Das fand ich nicht gut
Ringfinger: Das liegt mir am oder auf dem Herzen
Kleiner Finger: Das kam mir zu kurz

Dass die Schule in Deutschland bezogen auf die Schlafbedürfnisse von Jugendlichen eigentlich zu früh anfängt, hat sicherlich jeder mittlerweile schon einmal gelesen. Worüber jedoch bisher deutlich weniger prominent gesprochen wird ist die Tatsache, dass es auch für einen erheblichen Anteil der arbeitenden Bevölkerung Normalität ist, ins Bett zu gehen, ohne müde zu sein und sich von einem Wecker aus dem Schlaf reißen zu lassen, bevor der Körper wach werden möchte. Dabei ist die Organisation des gesellschaftlichen Alltags fest in der Hand der Lerchen, also jenen, die dem frühen Aufstehen und zeitigen Schlafengehen ganz freiwillig zugeneigt sind. Nicht nur Schüler sitzen morgens gegen acht Uhr bereits in der Schule, auch in vielen Büros, Behörden, Geschäften und Arztpraxen beginnt der Arbeitsalltag früh. Eigentlich überall. Der MDR spricht vor diesem Hintergrund gar von einer „Diktatur der Lerchen“. Dabei zeichnen die Zahlen ein anderes Bild. Zwar unterscheiden sich die konkreten Werte je nach Quelle, aber die Mehrheit der Bevölkerung stellen die Lerchen wohl keinesfalls. So schreibt die Zeit: „Von den Morgen- und Abendtypen gibt es jeweils etwa gleich viele. Das heißt aber auch: 60 Prozent sind in Wahrheit keines von beidem.“, während es beim WDR heißt: „Etwa 30 Prozent der Bevölkerung sind eher Morgenmenschen (Lerchen), 40 Prozent eher Abendtypen (Eulen). Die zwischen diesen beiden liegenden 'Normaltypen' bezeichnen Forschende in der Chronobiologie als Tauben.“

Eine Frage der Übung?

Die Behauptung, es wäre eine Frage von Disziplin, sich den frühen Rhythmus anzugewöhnen, hält sich hartnäckig. Wer von acht bis 16 Uhr arbeitet, gilt oft als organisiert und fleißig, wer hingegen von 14 bis 22 Uhr arbeitet, als undiszipliniert und faul. Dabei ergeben beide Zeiträume in der Summe acht Stunden. Margarete Stokowski nennt das im Spiegel „die dümmste Ideologie unserer Zeit“ und spricht von einer „Fetischisierung des frühen Aufstehens“. Mehrere Faktoren bestimmen maßgeblich über die eigene innere Uhr, dazu zählen die Gene, die Verfügbarkeit von Licht sowie Alter und Geschlecht. Für unsere eng mit der Natur lebenden Vorfahren hatte eine Population, die aus verschiedenen Chronotypen (also Lerchen, Eulen und sonstigen Typen) besteht, eventuell den Vorteil, dass Mitglieder einer Gruppe nicht gleichzeitig schliefen und somit immer jemand wach war und aufpasste. Ob sich der individuelle Rhythmus nun nachhaltig verändern lässt, ist fraglich. So schreibt zum Beispiel die AOK: „Es gibt nur einen Weg, die innere Uhr zumindest ein wenig zu verstellen. Denn neben den Genen ist das Licht der wichtigste Faktor für unseren Rhythmus. Licht beeinflusst Aktivität und Müdigkeit. Viel lässt sich an den Chronotypen aber nicht verändern – aus einer Eule wird auch durch mehr Licht keine Lerche." Beobachten kann man das mit dem Licht im Campingurlaub, in dem sich die Schlafgewohnheiten von Menschen in Ermangelung von Lichtquellen angleichen. Gleichzeitig ist da eben noch die Sache mit den angeborenen und biologischen Faktoren.

Als bekennende Eule kann ich bestätigen, dass eine Umstellung schwer ist. Ich kann mich zwar zwingen, meine Schlafgewohnheiten anzupassen, das funktioniert aber nicht immer und glücklich macht mich das nicht. Am Wochenende und im Urlaub dauert es meist nur zwei Tage, bis sich mein Wohlfühlrhythmus wieder einstellt. Beim Campen gehe ich zwar manchmal etwas früher ins Bett und stehe ein wenig früher auf – aber auch nicht immer, denn auch hier meldet sich mein Rhythmus zu Wort. „Viele Eulen werden hingegen gezwungen, gegen ihre innere Uhr zu leben. Das bedeutet für Betroffene bleierne Müdigkeit am Tage und schlechte Stimmung. Sie leben in einem dauerhaften "sozialen Jetlag", da sich ihre Schlafzeiten in der Woche stark von denen am Wochenende unterscheiden. Das permanente Leben gegen die innere Uhr kann zu psychischen Problemen, ungesunden Angewohnheiten wie Alkoholkonsum oder Rauchen, Stoffwechselstörungen und Krankheiten wie Diabetes führen. Zudem erhöht es einer Studie zufolge auch das Sterberisiko.“, schreibt N-TV. Ich denke, für eine Lerche wäre es ähnlich schwierig, noch um 23 Uhr beim Sport zu sein oder sich zu zwingen, bis zwölf Uhr mittags zu schlafen. Sie hat aber wohl den Vorteil, dass niemand eine Anpassung ihrer Schlafgewohnheiten fordert, sofern sie nicht gerade irgendwo im Schichtsystem arbeitet. Am einfachsten wäre es doch, wenn jeder seinen Rhythmus so leben könnte, wie es sich am besten anfühlt. Man kann allerdings davon ausgehen: Selbst wenn zwingende Umstände (wie die Notwendigkeit von Schichtdiensten) keine Rolle spielen würden, wird es für die meisten Arbeitnehmer wohl aufgrund von Konventionen, Vorurteilen und Sorgen um die Machbarkeit eine Utopie bleiben, sich ihre Arbeitszeiträume selbst auszusuchen. Dabei hätten zufriedene und ausgeschlafene Arbeitnehmer und Führungskräfte für alle Vorteile.

Ornithologie mal anders

Als wir uns 2021 mittels einer Teamumfrage angesehen haben, wie die verschiedenen Chronotypen bei uns verteilt sind, zeigte sich, wie erwartet, ein diverses Bild. Wir stellten die Frage: „Wenn es nur nach deinem Wohlbefinden geht und du frei von jeglicher Verpflichtung wärst, um wie viel Uhr würdest du ins Bett gehen und um wie viel Uhr aufstehen?“ (Abb. 1). Sechs von zehn Teammitgliedern beantworteten sie so, dass sie am liebsten ab neun Uhr morgens aufstehen. Der früheste Vogel gab an, um sechs Uhr aufstehen zu wollen, die späteste Eule um zwölf. Vier Teammitglieder wollten nach Mitternacht schlafen gehen. Müssten wir um acht Uhr morgens in einem externen Büro sitzen, würde das vermutlich nur für eine Person gut funktionieren. Eine zusätzliche Auswertung durch den Fragebogen zum Chronotyp (D-MEQ) der TU Dortmund erfasste in unserem Team vier „neutrale Typen“, zwei „moderate Abendtypen“ und zwei „definitive Abendtypen“.

Das aus diesen Angaben abgeleitete Schlafbedürfnis der Teammitglieder lag zwischen 8 und 10,5 Stunden pro Nacht, der tatsächlich erhaltene Schlaf an einem Arbeitstag laut Selbstauskunft ("Was würdest du sagen, wie viele Stunden du normalerweise vor einem Arbeitstag schläfst?") zwischen 6 und 9 Stunden. Die Antworten deuteten darauf hin, dass viele unter der Woche nicht so viel Schlaf bekamen, wie sie eigentlich brauchen. Die Diskrepanz könnte aber auch dadurch zustande kommen, dass bei den in Abb. 1 dargestellten Zeiträumen Ruhezeiten mit einbezogen wurden, in denen kein Schlaf stattfindet.

Die Frage: „Was würdest du sagen, um wie viel Uhr bzw. in welcher/n Zeitspanne(n) du geistig am leistungsfähigsten bist?“, beantworteten viele im Team mit der Nennung einer Periode, die irgendwo zwischen acht und 13 Uhr lag. Es gab aber auch drei Teammitglieder, die den Beginn ihrer frühesten, leistungsfähigsten Phase nach zwölf Uhr definierten, zwei davon sogar erst nach 17 Uhr und somit zu einer Zeit, zu der in Deutschland normalerweise Feierabend gemacht wird. Im Extremfall zog sich die leistungsfähige Periode laut Selbstauskunft bis zwei Uhr nachts (Abb. 2). In Einzelfällen gaben die Befragten unkonkrete Werte an (z. B. "mittags"). Hier wurden für die Auswertung Annahmen bezüglich des konkreten Zeitraums getroffen.

Dann schaffen wir eben das Daily Standup ab

Uns war spätestens mit Blick auf die Daten klar, dass wir etwas ändern wollten. Nicht nur für jedes einzelne Teammitglied, auch aus Firmensicht klingt es wenig sinnvoll, Menschen in Perioden zum Arbeiten zu zwingen, in denen sie sich selbst als leistungsschwach einschätzen. Und wir wollten kein übermüdetes, sondern ein erholtes Team sein. Es gab zwar ein paar Bedenken, was das hinsichtlich der Verfügbarkeit gegenüber Kunden oder in der Kommunikation untereinander bedeutet („Wenn alle unterschiedliche Arbeitszeiten haben, wie funktionieren dann Absprachen im Team?“), wir sind aber große Fans davon, Dinge in einem Experimentierzeitraum einfach mal auszuprobieren. So ein Experiment ermöglicht es, unterwegs zu schauen, ob es funktioniert, ob man Anpassungen vornehmen muss oder ob das Experiment gar gescheitert ist.

Zum Zeitpunkt der Umfrage hatten wir ein tägliches Standup-Meeting (bzw. montags eine Wochenplanung) um 09:45 Uhr, also zu einer Zeit, zu der einige noch schlafen wollten und andere vielleicht gerade erst aufgestanden waren. Am anderen Ende des Spektrums hatten wir einen Wochenrückblick, der freitags um 14:30 Uhr stattfand. Das war manchen im Team eigentlich zu spät und sie berichteten von Schwierigkeiten, sich am Nachmittag noch auf ein Meeting zu konzentrieren. Auf der Suche nach dem Slot, an dem alle möglichst schmerzfrei zusammenkommen können, warfen wir einen Blick auf die vom Team gewünschten Wachzeiten (Abb. 1), die leistungsstarken Zeiträume (Abb. 2) und auch auf die separat abgefragten Wunsch-Arbeitszeiten (nicht gezeigt, da viele Antworten keine konkreten Zeiträume nannten). Auf Basis dessen legten wir zwölf Uhr mittags als neue, tägliche Meetingzeit fest. Um diese Uhrzeit wollte niemand mehr schlafen. Die „Frühschicht“ bemerkte außerdem um die Mittagszeit einen Leistungsabfall und ein einsetzendes Bedürfnis nach Mittagessen. Das konzentrierte Arbeiten an einer Aufgabe wird ungefähr zu diesem Zeitpunkt also vermutlich sowieso beendet, womit wir weniger Gefahr laufen, Fokusphasen mit einem ungünstig gelegenen Meeting zu unterbrechen. Die „Spätschicht“ wollte so um den Dreh die Arbeit aufnehmen und konnte im Idealfall teilnehmen, bevor die Fokussierung auf eine Aufgabe begann.

Wie die Umstellung funktioniert hat

Es gab eine Phase, in der manche im Team das morgendliche Anknüpfen mit den anderen vermissten und sich auf freiwilliger Basis in einer Videokonferenz zum Stand-Up verabredeten. Eine Weile gab es als Alternative auch einen Chatraum, in dem zum individuellen Tagesbeginn ein schriftliches Stand-Up Meeting stattfinden konnte. Beide Modelle sind aber irgendwann ganz von alleine ausgelaufen und heute gibt es nur noch die Mittagsmeetings. Da sie keine Pflichtveranstaltung sind, stellt es auch kein Problem dar, wenn jemand an einem Tag andere Arbeitszeiten leben will. In der Realität sind Montags und Freitags (an diesen Tagen sind die Inhalte der Meetings etwas anders als Dienstag bis Donnerstag) alle anwesend – an den anderen Tagen gestaltet sich die Anwesenheit ganz unterschiedlich. Die Kommunikation untereinander oder mit Kunden hat sich als unproblematisch herausgestellt. Der Erfolg eines Modells ohne feste Arbeitszeiträume ist vermutlich auch abhängig von der Firmenkultur und dem Miteinander. In der webfactory fühlt sich jeder (mit)verantwortlich, die Zufriedenheit und das Zugehörigkeitsgefühl zur Firma ist hoch. Entsprechend ist es selbstverständlich, dass man natürlich auch mal zu Zeiten arbeitet, die individuell nicht ganz perfekt sind, wenn zum Beispiel ein Termin mit Kunden oder mit Kolleg*innen ansteht. Darüber hinaus kommunizieren wir sowieso so viel wie möglich schriftlich und asynchron, was bei einem Modell ohne Kernarbeitszeiten sicherlich von Vorteil ist. Und wenn man weiß, dass eine direkte Abstimmung im Team nötig ist oder man von jemandem gebraucht wird, dann kommt auch die euligste Eule nicht erst am späten Nachmittag an den Schreibtisch. Generell überschneiden wir uns sowieso noch relativ viel. Zwischen zwölf und 17 Uhr kann man eigentlich jeden im Team erreichen – wenn vielleicht auch nicht sofort, denn die Auflösung der Arbeitszeiten (sicherlich auch in Kombination mit der Einführung der 30-Stunden-Woche) hat bei vielen zu einem flexibleren Einschieben von privaten Terminen und bei einzelnen zu individuellen Anpassungen, wie einer extra langen Mittagspause, geführt. Insgesamt dürften wir regelmäßig eine Zeitspanne zwischen 09:30 Uhr und 19 Uhr abdecken, in der irgendjemand anwesend und für Kunden ansprechbar ist. Oft auch noch längere Zeiträume. Das ist somit deutlich mehr, als wenn wir alle dieselben sechs Stunden des Tages anwesend wäre. Es ist auf jeden Fall gut, dass es Personen im Team gibt, die vormittags arbeiten wollen. Für viele unserer Kunden beginnt der Arbeitstag zu klassischen Arbeitszeiten und es wird sicherlich erwartet, dass man uns vormittags erreichen kann. Wäre das nicht der Fall, hätte man hier vermutlich eine Lösung finden müssen. Auf der anderen Seite melden sich insbesondere unsere Theaterkunden aufgrund ihrer persönlichen Arbeitsabläufe häufig erst am späten Nachmittag und es wäre suboptimal, wenn dann niemand mehr da wäre. Die natürliche Verteilung der Arbeitszeiten im Team ist also durchaus von Vorteil.

Insgesamt lässt sich sagen, dass uns die Umstellung ziemlich mühelos gelungen ist. Wir sind mit dem Ergebnis sehr zufrieden und sehen viele Vorteile für jeden Einzelnen und die Firma im Gesamten. Auch der Chronobiologe Professor Achim Kramer von der Charité Berlin empfiehlt im Interview mit N-TV: „‚Man sollte versuchen, die unterschiedlichen Chronotypen der Belegschaft zu kennen und dann die Schichtpläne so zu machen, dass die Belastungen möglichst gering sind‘ Dies bedeute, dass Eulen häufiger in Spätschichten und Lerchen öfter in Frühschichten eingesetzt werden sollten. Zudem ließen sich viele Berufsunfälle sowie diverse Fehler im Job durch unkonzentriertes Arbeiten dank Berücksichtigung der biologischen Uhr vermeiden.“ Wir empfehlen, vielleicht einfach mal eine eigene Umfrage zu starten und in einem Experiment zu testen, was passiert, wenn ein Team ohne feste Arbeitszeiträume agiert. Wenn es dann doch schiefgeht, dann hat man immerhin was gelernt und vielleicht wenigstens für ein paar Tage ausgeschlafene Kolleg*innen.

In einem meiner Lieblingsartikel in der brand eins (Paywall) sagt Georg Vobruba, Professor für Soziologie an der Universität Leipzig:

Der Abbau von Vertrauen geht schneller als sein Aufbau [...] es entsteht aus komplizierten und immer wieder fragilen Abstimmungen.“  Misstrauen hingegen lässt sich schnell und einfach herstellen. Es habe  „Sogwirkung“, und man könne „sich ihm kaum entziehen. Misstrauen ist selbstverstärkend.“

Vertrauen ist auch die Basis für internationale Arbeitsteilung und damit für den enormen technischen Fortschritt der letzten Jahre, vom iPhone bis zum Corona-Impfstoff, wie die New York Times kürzlich noch einmal plastisch herausgestellt hat.

Misstrauen hingegen verursacht zum einen hohe Kontrollkosten, zum anderen verhindert es auch erfolgreiches Zusammenleben – denn wer Vertrauen erhält, revanchiert sich normalerweise mit positivem Verhalten. Wer hingegen zu Unrecht Misstrauen erfährt, wird frustriert.

Im Vorfeld der anstehenden Bundestagswahl machen viele Parteien einen Wahlkampf des Misstrauens – je nach politischem Lager gegen Reiche und Konzerne oder gegen Bürgergeldempfänger und Einwanderer. Nach meiner Überzeugung sind die großen und komplexen Probleme der Gegenwart nur mit Vertrauen und Zusammenarbeit zu lösen, und zwar gemeinsam mit allen gesellschaftlichen Gruppen.

Ich wünsche mir eine neue Bundesregierung, die diese Werte teilt.

Daher meine Wahlempfehlung:

1. wählen gehen (sonst entscheiden andere über unsere Zukunft)
2. eine Partei wählen, die es wahrscheinlich in den Bundestag schafft (sonst ist das Ergebnis das gleiche, wie wenn man nicht wählt)
3. eine Partei wählen, die für Vertrauen, Kooperation und Offenheit steht, statt im Wahlkampf Misstrauen zu schüren.

Weiterführende Links

• Strategisches Wählen? Was das bei der Bundestagswahl bringt
• Migration steigert laut Studie nicht die Kriminalität
• Zum Thema Bürgergeld: "Die Menschen wollen arbeiten"
• Die Unternehmenskultur der webfactory

Andere Browser (Chrome, Edge, Safari) schienen nicht betroffen zu sein. Wie konnte das sein?

Vertikale Font Metriken

Dazu muss man etwas weiter ausholen. Jede Schriftdatei enthält eine Menge von Metadaten, darunter auch solche, die die vertikale Ausrichtung von Text beeinflussen. Aus historischen Gründen gibt es nicht weniger als drei Gruppen von Werten, die sich mit vertikalen Metriken befassen. Sie sind bekannt als hhea , typo (auch bekannt als sTypo oder OS/2 ) und win (oder usWin ). Je nachdem, welche Kombination von Betriebssystem und Anwendung die Schrift gerade anzeigen soll, wird eine andere Gruppe für die Darstellung der Schrift auf dem Bildschirm verwendet. Das (englische) Tutorial Vertical metrics des Schriftarten-Editors Glyphs bietet exzellente Hintergrundinformationen zu diesem Thema.

Für uns ist vor allem relevant, wie sich Browser verhalten. Die Chrome Developer Dokumentation hat dafür eine gute Tabelle[^1]​:

Die Metadaten lassen sich auf mehreren Wegen aus einer Schriftdatei auslesen[^2], eine sehr einfache Option beschreibt Simon Hearne in seinem umfassenden Artikel:

1. Schriftdatei auf https://fontdrop.info/ hochladen
2. Das Tab "Data" öffnen
3. Werte unter „hhea – Horizontal Header Table“ sowie „OS/2 – OS/2 and Windows Metrics Table“ auslesen

In unserem Fall finden wir für die neuen Dateien der Avenir Next heraus:

hhea – Horizontal Header Table

ascender: 978
descender: -250
lineGap: 0
unitsPerEm: 1000

OS/2 – OS/2 and Windows Metrics Table

sTypoAscender: 758
sTypoDescender: -242
sTypoLineGap: 200
usWinAscent: 978
usWinDescent: 250

Die Werte geben einen ersten Hinweis: die abweichenden sTypo* -Werte könnten erklären, warum sich Firefox anders verhält. Leider ist genau der Wert USE_TYPO_METRICS nicht in den von fontdrop.info gelieferten Daten enthalten. Visuell ist der Unterschied in einem reduzierten Test aber deutlich erkennbar:

MacOS Firefox	MacOS Chrome

Die Lösung: Modernes CSS!

Das CSS Fonts Module Level 4 erlaubt das Überschreiben bestimmter Metriken aus der Schriftdatei. Inbesondere stehen uns für unser Problem ascent-override, descent-override und line-gap-override zur Verfügung. Die Spezifikation adressiert hauptsächlich Probleme beim Wechsel von einer Fallback-Font zur gewünschten Web Font; mit den genannten Eigenschaften kann eine Fallback-Font so an die Web Font angeglichen werden, dass kein sog. "flash of unstyled text" (FOUT) zu einem Layout Shift mit Abzügen im Core Web Vital "cumulative layout shift" (CLS) führt.

Die Metriken können aber eben auch als Progressive Enhancement für cross-browser-Ausgleiche einer Web Font eingesetzt werden. Progressive Enhancement deshalb, weil sie zwar nicht von allen Browsern unterstützt werden (Safari bildet hier die Ausnahme, alle anderen Hersteller haben zwischen 2020 und 2021 Versionen mit Support herausgebracht), ein Browser ohne Support aber einfach weiterhin die Werte aus der Schriftdatei nutzt.

Mit den CSS-Metriken können wir also bei der @font-face -Einbindung der Schriftdatei dafür sorgen, dass diese Werte von uns normalisiert werden. Wir nutzen dazu die ursprünglichen hhea -Werte[^3]. Die Werte von ascent-override und descent-override werden in CSS in Prozent angegeben, negative Werte sind dabei nicht zulässig. Wir können aber den absoluten Wert des Descenders ohne Vorzeichen verwenden; bei unitsPerEm: 1000 ergeben sich der Formel[^4] ascent-override = ascender/unitsPerEm entsprechend 978/1000 * 100% , also ascent-override: 97.8% und analog descent-override: 25% . Für line-gap-override: 0 ist keine Umrechnung nötig, sonst käme die gleiche Formel zum Einsatz.

Nach dem Eintragen der CSS-Metriken sieht unser Test so aus:

MacOS Firefox	MacOS Chrome

Et voilà!

[^1]: https://developer.chrome.com/blog/font-fallbacks#understanding_font_tables

[^2]: https://developer.chrome.com/blog/font-fallbacks#reading_font_tables

[^3]: Wenn wir für unser CSS genau die Werte als Ausgangsbasis verwenden, die Safari aus der Schriftdatei heranzieht, erreichen wir trotz fehlendem Support in Safari die gleiche Darstellung in allen Browsern. Safari unter Windows greift auf die Werte aus der Tabelle OS2/Win zu, die bei unseren Dateien genau den hhea -Werten entsprechen (siehe oben).

[^4]: https://developer.chrome.com/blog/font-fallbacks#calculating_font_metric_overrides

Was führte zum European Accessibility Act und dem Barrierefreiheitsstärkungsgesetz?

Der European Accessibility Act, der 2019 von der Europäischen Union verabschiedet wurde, ist das Ergebnis jahrelanger Bemühungen, die Rechte von Menschen mit Behinderungen zu stärken. Mehrere Faktoren haben zu seiner Entstehung beigetragen:

1. Die Ratifizierung der UN-Behindertenrechtskonvention durch die EU-Mitgliedstaaten schuf eine völkerrechtliche Verpflichtung zur Verbesserung der Barrierefreiheit.
2. Der demografische Wandel in Europa führte zu einem wachsenden Bewusstsein für die Bedürfnisse einer alternden Gesellschaft.
3. Die fortschreitende Digitalisierung machte deutlich, dass ohne gezielte Maßnahmen eine digitale Kluft entstehen könnte, die bestimmte Bevölkerungsgruppen ausschließt.
4. Es wurde erkannt, dass barrierefreie Produkte und Dienstleistungen nicht nur sozial wichtig sind, sondern auch wirtschaftliche Chancen bieten.

EU-Richtlinien wie der European Accessibility Act müssen von den Mitgliedsstaaten in ihre nationale Gesetzgebung überführt werden. Zwei Jahre später, im Juli 2021, wurde daher das Barrierefreiheitsstärkungsgesetz (mit vollem Namen "Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheits­anforderungen für Produkte und Dienstleistungen") als Bundesgesetz erlassen. Es tritt am 28. Juni 2025 in Kraft.

Der European Accessibility Act und das daraus resultierende Barrierefreiheitsstärkungsgesetz sind mehr als nur gesetzliche Vorgaben. Sie repräsentieren einen gesellschaftlichen Wandel hin zu mehr Inklusion und Gleichberechtigung: Letztendlich geht es darum, eine Welt zu schaffen, in der digitale Technologien allen Menschen gleichermaßen zugänglich sind.

Wer ist vom European Accessibility Act und Barrierefreiheitsstärkungsgesetz betroffen?

Der European Accessibility Act – und damit das Barrierefreiheitsstärkungsgesetz – gehen weit über bisherige Regelungen zur Barrierefreiheit hinaus. Erstmals sind nicht nur öffentliche Einrichtungen, sondern auch der private Sektor betroffen. Besonders bemerkenswert ist, dass die Anforderungen für alle Unternehmen gelten, die Produkte oder Dienstleistungen an Kunden in EU-Mitgliedstaaten verkaufen, unabhängig vom Standort des Unternehmens. Dies hat weitreichende Folgen für den globalen Handel und die Produktentwicklung.

Das Gesetz richtet sich an Hersteller, Händler und Importeure bestimmter Produkte sowie Anbieter spezifischer Dienstleistungen.

Zu den betroffenen Produkten zählen unter anderem:

• Computer, Smartphones, Tablets
• Selbstbedienungsterminals (z.B. Geldautomaten und Ticketautomaten)
• Smart-TVs
• E-Book-Reader

Im Dienstleistungsbereich sind beispielsweise betroffen:

• Telekommunikationsdienste (Telefonie, Messenger-Apps)
• Bankdienstleistungen
• Personenbeförderungsdienste (Websites, Apps oder Ticketdienste)
• E-Book-Software
• Dienstleistungen im elektronischen Geschäftsverkehr mit Verbrauchern

Besonders hervorhebenswert ist der letzte Punkt, Dienstleistungen im elektronischen Geschäftsverkehr: Hier geht es um den gesamten Online-Handel, also E-Commerce-Angebote wie Online-Shops und Apps, über die Produkte erworben werden können. Darüber hinaus sind aber auch alle anderen Online-Dienstleistungen betroffen, die auf den Abschluss von Verbraucherverträgen abzielen, z.B. die Buchung von Konzertbesuchen, Hotelurlauben oder Arztterminen.

Ausgenommen sind Anbieter von Dienstleistungen mit weniger als 10 Mitarbeitern und einem Jahresumsatz oder einer Jahresbilanzsumme von maximal 2 Millionen Euro (sog. "Kleinstunternehmen"). Für Produkthersteller gilt diese Ausnahme jedoch nicht.

Was sind konkrete Anforderungen an Unternehmen?

Die Anforderungen an Barrierefreiheit sind vielfältig und reichen von der Gestaltung von Benutzeroberflächen über die Bereitstellung von Informationen in verschiedenen sensorischen Kanälen bis hin zur physischen Zugänglichkeit von Produkten und Dienstleistungen.

Zur Erleichterung enthält das Barrierefreiheitsstärkungsgesetz Konformitätsvermutungen (siehe § 4 und 5 BFSG): Werden bestimmte technische Normen, EU-harmonisierte Normen oder DIN- oder ISO-Standards (technische Spezifikationen), erfüllt, wird die Einhaltung der Barrierefreiheits­anforderungen vermutet, wenn die Normen und Standards selbst die Barrierefreiheits­anforderungen erfüllen.

Die Bundesfachstelle Barrierefreiheit hat bisher keine Zuordnung von Produkten und Dienstleistungen zu bestimmten Normen und Spezifikationen veröffentlicht, gibt aber folgenden Hinweis​[^1] für Websites und Apps, die Dienstleistungen anbieten, die unter das Barrierefreiheitsstärkungsgesetz fallen:

In Bezug auf digitale Barrierefreiheit lässt sich bereits auf die EN 301 549 verweisen (für Websites öffentlicher Stellen des Bundes ist sie gemäß BITV 2.0 bereits maßgeblich), da sich eine Aktualisierung dieser EN explizit mit Blick auf die Anforderungen der Barrierefreiheit von Produkten und Dienstleistungen im Kontext der EU-Richtlinie 2019/882 in Planung befindet.

Es geht also um die Einhaltung der harmonisierten Norm EN 301 549, die bereits für öffentliche Stellen im Rahmen der Barrierefreie-Informationstechnik-Verordnung (BITV) Anwendung findet. Die EN 301 549 wiederum basiert auf den international anerkannten Web Content Accessibility Guidelines (WCAG). Konkret bedeutet dies, dass ab dem 28. Juni 2025 betroffene Unternehmen ihre Dienstleistungen gemäß den in der BITV festgelegten Standards gestalten müssen, die im Wesentlichen den WCAG 2.1 auf Konformitätsstufe AA entsprechen. Die BITV geht dabei in einigen Bereichen sogar über die WCAG hinaus und enthält zusätzliche, spezifisch deutsche Anforderungen z.B. für Gebärdensprachvideos und Informationen in Leichter Sprache.

Für viele Unternehmen bedeutet das Barrierefreiheitsstärkungsgesetz also eine erhebliche Umstellung. Sie müssen:

1. Ihre bestehenden Produkte und Dienstleistungen auf Barrierefreiheit überprüfen und gegebenenfalls anpassen.
2. Barrierefreiheit von Anfang an in den Entwicklungsprozess neuer Angebote integrieren.
3. Mitarbeiter schulen und für das Thema Barrierefreiheit sensibilisieren.
4. Konformitätsbewertungsverfahren durchführen und dokumentieren.

Was sind mögliche Konsequenzen bei Verstößen gegen das Barrierefreiheitsstärkungsgesetz?

Die Sicherstellung der Barrierefreiheit obliegt prinzipiell den Anbietern von Produkten und Dienstleistungen.

Neu eingerichtete Markt­über­wachungs­behörden werden die Einhaltung der Anforderungen nach Inkrafttreten des Barrierefreiheitsstärkungsgesetz sowohl ohne Anlass stichprobenhaft als auch anlassbezogen (z.B. aufgrund konkreter Beschwerden von Verbrauchern) überprüfen. Bei Nichteinhaltung drohen Bußgelder bis zu 100.000 Euro und es besteht das Risiko, dass betroffene Produkte und Dienstleistungen zurückgerufen bzw. eingestellt werden müssen.

Mitbewerber können außerdem mittels einer wettbewerbsrechtlichen Abmahnung gegen Verstöße vorgehen.

Was ist zu tun?

Mit der Frist zur Umsetzung des Barrierefreiheitsstärkungsgesetz am 28. Juni 2025 bleibt Unternehmen nicht mehr viel Zeit, sich vorzubereiten. Es ist dringend ratsam, jetzt zu handeln:

1. Machen Sie sich mit den Anforderungen des BFSG vertraut.
2. Führen Sie eine Bestandsaufnahme Ihrer Produkte und Dienstleistungen durch.
3. Entwickeln Sie einen Aktionsplan zur Implementierung der Barrierefreiheitsanforderungen.
4. Investieren Sie in Schulungen und Bewusstseinsbildung in Ihrem Unternehmen.
5. Ziehen Sie gegebenenfalls externe Experten hinzu.

Eine gute erste Anlaufstelle ist die Sammlung häufiger Fragen und Antworten zum Barrierefreiheitsstärkungsgesetz (BFSG) der Bundesfachstelle Barrierefreiheit.

Wenn Sie mit digitalen Dienstleistungen unter den Anwendungsbereich des Barrierefreiheitsstärkungsgesetz fallen sollten, unterstützen wir Sie gerne. Wir stehen seit vielen Jahren Kunden aus dem öffentlichen Sektor mit unserer Erfahrung und Expertise beim Thema Barrierefreiheit zur Seite und freuen uns, wenn wir auch Ihnen mit einer Beratung weiterhelfen können.

[^1]: Siehe "Welche Normen und anderen technischen Standards sind maßgeblich für die Umsetzung des BFSG?", Bundesfachstelle Barrierefreiheit (zuletzt abgerufen 30. Oktober 2024)

Die meisten von uns entwickelten Websites und Webanwendungen (im Folgenden einheitlich als "System" bezeichnet) basieren heute auf dem Open-Source-Framework Symfony. Symfony stellt eine Vielzahl von Komponenten zur vereinfachten Entwicklung von Websites und Webapplikationen zur Verfügung. Dazu gehören Komponenten zur Verarbeitung von Formulareingaben, Entwicklung von HTML-Templates oder zum Aufbau einer Loginfunktion mit differenzierten Benutzerrechten.

Das Symfony-Framework wird laufend weiterentwickelt. Diese Weiterentwicklungen werden seit über 10 Jahren nach einem festen, planbaren Rhythmus veröffentlicht. Im Detail haben wir das in unserem Blogpost "Up-to-date bleiben" beschrieben.

Alle zwei Jahre im November erscheint eine neue Major-Version, danach jedes halbe Jahr eine Minor-Version.

Die Minor-Versionen fügen neue Features und Funktionalitäten hinzu, sind aber vollständig kompatibel mit der Vorversion. Sie können also einfach installiert werden, ohne dass Anpassungen im Quellcode Ihres eigenen Symfony-basierten Systems erforderlich sind. Der Aufwand für diese Updates ist daher sehr gering.

Anders sieht es bei den Major-Versionen aus: Hier werden größere Neuerungen eingeführt, durch die entsprechender Anpassungsbedarf in Ihrem System entsteht.

Wenn wir Ihr System auf eine neue Major-Version von Symfony aktualisieren, umfasst das nicht nur Aktualisierungen von Symfony selbst. Zusätzlich aktualisieren wir auch viele andere eingebundene Softwaremodule, "Bibliotheken" (libraries) oder "Abhängigkeiten" (dependencies) genannt. Auch hierfür kann es erforderlich werden, dass Ihr System an einigen Stellen angepasst wird.

Alle nötigen Anpassungen nehmen wir im Rahmen des Updates für Sie vor. Es kann sich dabei um Anpassungen der Konfiguration handeln oder Anpassungen im Quellcode selbst.

Zum Beispiel mussten spätestens für das Update von Symfony 6 auf Symfony 7 alle Anweisungen, die bisher über eine Technik namens "Annotations" vorgenommen wurden, auf eine neue Technik namens "Attributes" umgestellt werden. Im Ergebnis tun beide Techniken das Gleiche: mit ihrer Hilfe können Konfigurationsanweisungen direkt im Quellcode hinterlegt werden.

Ein Beispiel für eine Annotation:

/**
 * @Route("/path", name="action")
 */

Und die gleiche Anweisung als Attribute:

#[Route('/path', name: 'action')]

Annotations brauchen zum Funktionieren eine zusätzliche Bibliothek, die diese Konfigurationsanweisungen aus dem Quellcode extrahiert. Attributes hingegen sind eine Funktion, die in die Programmiersprache PHP seit Version 8 fest integriert ist (ein language feature). Daher sind sie wesentlich schneller. Codestellen wie das obige Beispiel existieren in einem System in sehr großer Zahl, entsprechend umfangreich sind die Anpassungen – und die Umstellung kann nur teilweise automatisiert werden. Dafür steigt die Geschwindigkeit des Systems und die zusätzliche Bibliothek kann entfallen, was den zukünftigen Wartungsaufwand verringert.

Auf der Website von Symfony finden Sie, wenn Sie sich für die technischen Details bei einem Symfony-Update interessieren, eine allgemeine Empfehlung zur Vorgehensweise bei Updates (Englisch).

Im Anschluss an die eigentlichen Updates führen wir noch eine umfangreiche Qualitätssicherung durch, z. B. einen vollständigen Vorher-Nachher-Vergleich der gesamten Website, um sicherzugehen, dass durch den Umstieg auf die neue Symfony-Version keine Fehler im System auftreten.

Welche Vorteile bringen neue Symfony-Versionen?

Der wichtigste Vorteil, den Sie durch ein Symfony-Update gewinnen, ist die Gewährleistung der Betriebssicherheit: Das Symfony-Entwicklungsteam sorgt für fünf Jahre ab Erscheinen einer neuen Major-Version für Bugfixes auf dieser Versionslinie. Noch ein Jahr länger, also insgesamt sechs Jahre lang, werden Updates zur Schließung von Sicherheitslücken bereitgestellt. In diesem Zeitraum wird auch die Kompatibilität mit neuen PHP-Versionen gewährleistet.

Neue Symfony-Versionen bringen häufig auch Performanceverbesserungen mit sich, wodurch die Seitenabrufe schneller werden oder mit weniger Rechenleistung auskommen.

Last but not least kommen in neuen Symfony-Versionen zusätzliche Funktionalitäten hinzu, zum Beispiel neue Module, mit denen bestimmte Aufgaben effizienter und schneller als früher umgesetzt werden können. In der aktuellen Major-Version Symfony 7 waren das beispielsweise

• Eine Scheduler-Komponente, die Ereignisse auf Basis eines vordefinierten Zeitplans auslösen kann

• Die Komponenten Webhook und RemoteEvent, mit denen man Webhooks anbieten kann und die Reaktionen auf Ereignisse in anderen Systemen steuern. (Ein Webhook ist eine Art webbasierte Benachrichtigungsfunktion, mit der Ihr System andere Systeme von bestimmten Ereignissen informieren kann – zum Beispiel, dass ein neuer Beitrag veröffentlicht wurde oder dass eine neue Nutzerin oder ein neuer Nutzer sich registriert hat. Ein RemoteEvent ist das technische Gegenstück zum Webhook auf der anderen Seite, also im empfangenden System.)

• Ein HtmlSanitizer, der dabei unterstützt, validen und sicheren HTML-Quellcode zu erzeugen

• Eine Uhr-Komponente, mit deren Hilfe man zeitabhängigen Code besser automatisiert testen kann.

Auf diese neuen Komponenten können wir dann bei der Weiterentwicklung Ihres Systems zurückgreifen.

Kann ich auf die Updates auch verzichten?

Ein Verzicht ist eine gewisse Zeit lang möglich. Für jede Hauptversion von Symfony gibt es als letzte Minor-Version ein "Long Term Support"-Release, das drei Jahre lang Bugfixes bekommt und vier Jahre lang Fixes für Sicherheitslücken. Nach Ablauf dieser Zeit würden Sicherheitslücken, die im Framework entdeckt werden, nicht mehr behoben und wären schlimmstenfalls ein Einfallstor für Hackerangriffe.

Zudem ist jede Symfony-Version auch nur mit bestimmten Versionen der zugrundeliegenden Programmiersprache PHP kompatibel. Jede PHP-Version wird aber nur eine bestimmte Zeit lang durch aktuelle Versionen des Server-Betriebssystems Linux unterstützt. Wenn im Rahmen des Hostings eine Aktualisierung des Server-Betriebssystems und damit ein Wechsel der PHP-Version erfolgt, können Websites und Webanwendungen, die nicht mit der neuen PHP-Version kompatibel sind, nicht weiter betrieben werden.

Warum ist es sinnvoll, möglichst früh auf neue Versionen von Symfony zu aktualisieren?

Wir empfehlen, jeweils so früh wie möglich auf neueste Major-Version und die darauf folgenden Minor-Versionen zu aktualisieren.

Dadurch steht der Nutzen der neuen Version – in Form der oben beschriebenen Vorteile – früher zur Verfügung.

Ein weiterer wichtiger Aspekt: Teilweise werden in neuen Minor-Versionen Änderungen vorgenommen, die unerwartete Kompatibilitätsprobleme mit Ihrem System aufweisen. In solchen Fällen ist es uns häufig gelungen, beim Symfony-Entwicklungsteam zu erreichen, dass diese Änderungen zurückgenommen werden, weil sie das Kompatibilitätsversprechen brechen. Wenn diese Kompatiblitätsprobleme hingegen erst spät auffallen, ist eine Rücknahme in Symfony nicht mehr möglich, sondern es bleibt nur die Möglichkeit, aufwändig den Quellcode Ihres Systems anzupassen, um die Kompatibilität wieder herzustellen.

Kann man mehrere Versionssprünge zu einem Update kombinieren?

Häufig werden wir gefragt, ob man direkt mehrere Versionssprünge in einem Update machen kann, also z. B. von Version 5 auf Version 7 springen, und dadurch Kosten sparen.

Das ist nicht der Fall, da die Änderungen, die im Code erforderlich sind, sich aufaddieren. Es müssen also die Änderungen des Sprungs von 5 auf 6 vorgenommen werden und dann zusätzlich die Änderungen von 6 auf 7. Da in zwei Versionen nie die gleichen Änderungen nötig sind, kann man durch die Zusammenfassung nicht abkürzen, sondern muss alle Änderungen einzeln erledigen.

Lediglich bei der abschließenden Qualitätssicherung bietet sich eine Einsparmöglichkeit, wenn diese nur einmal für das Doppelupdate erfolgt. Das bringt allerdings einen Nachteil mit sich: Wenn wir in dieser Phase Fehler entdecken, wissen wir nicht, aus welchem Versionssprung diese stammen, und müssen entsprechend länger nach der Ursache suchen.

Wieso sind frühe Updates kostengünstiger?

Wenn Symfony-Updates also grundsätzlich sequenziell abgearbeitet werden müssen und eine Zusammenfassung mehrerer Versionssprünge keinen Kostenvorteil bringt, sind im Umkehrschluss getrennte Updates für jede Major-Version nicht teurer als zusammengefasste.

Vor diesem Hintergrund ergibt sich ein klarer Kostenvorteil früher Updates aus der frühen Entdeckung der oben beschriebenen unerwarteten Kompatibilitätsprobleme: Können diese noch im Symfony-Framework behoben werden, reduziert das den Aufwand für die Herstellung der Kompatibilität mitunter erheblich.

Eine weitere Ersparnis ergibt sich aus der Verfügbarkeit der neuen Features. Häufig können bestimmte Anforderungen mithilfe der in einer neuen Symfony-Version hinzugefügten Komponenten leichter und damit kostengünstiger realisiert werden als in früheren Symfony-Versionen.

Last but not least: Das Wissen in unserem Team über die genaue Vorgehensweise, die Fallstricke und Lösungsmöglichkeiten bei einem bestimmten Versionssprung ist bei einem frühen Wechsel auf die neue Symfony-Version noch frisch. Eine sechs Jahre alte Symfony-Version auf eine vier Jahre alte Version zu aktualisieren, erfordert eine neue Einarbeitung in die Besonderheiten dieses Updates und ist damit automatisch teurer, als wenn das Update vor vier Jahren erfolgt wäre.

Was muss ich tun, um regelmäßige Symfony-Updates zu bekommen?

Wenn Ihre Website oder Webanwendung bereits durch die webfactory als Agentur betreut wird, behalten wir gerne für Sie im Blick, wann ein Symfony-Update ansteht, und informieren Sie entsprechend. Auf Wunsch können wir die Updates auch im Rahmen einer Aktualitätsgarantie regelmäßig unaufgefordert für Sie vornehmen. Wenn Sie daran Interesse haben, sprechen Sie uns gerne an.

Übrigens: Welche Symfony-Versionen gerade aktuell sind und wann die nächste Version erscheint, erfahren Sie stets aktuell auf symfony.com/releases.

Sie sind noch kein webfactory-Kunde und interessieren sich für unsere Arbeit? Erfahren Sie mehr über unsere Leistungen als Symfony Agentur.

Wir erläutern, wie die Anbindung an die Datenbank funktioniert und was Sie dabei im Vorfeld unbedingt beachten sollten.

Was ist Theasoft?

Theasoft ist eine umfassende Software-Suite, die Theatern, Opernhäusern und Orchestern die Koordination ihrer Betriebsabläufe erleichtert. Die enthaltenen Software-Module decken unter anderem folgende Bereiche ab:

• Künstlerische Planung und Disposition
• Finanz- und Trägerstrukturen
• Personalmanagement
• Tarif- und Arbeitsrecht
• Marketing und Publikumsentwicklung

Alle Theasoft-Module greifen auf dieselbe zentrale Datenbank zu. Änderungen sind damit sofort für alle Nutzer:innen sichtbar, wodurch Dubletten und widersprüchliche Dateneingaben vermieden werden. Zugriffsrechte lassen sich granulär verwalten.

Nicht zuletzt aufgrund der nunmehr 30-jährigen Erfahrung des Entwicklungsteams und der Vielfalt an Prozessen, die in Theasoft abgebildet werden können, ist die Software-Suite für Theater, Opernhäuser und Orchester in Deutschland marktführend. Alternativen mit einem geringeren Funktionsumfang sind etwa KOKOS.event und evis.

Theasoft-Module

Die Theasoft-Software-Suite umfasst zahlreiche Module, die verschiedenste Aspekte der Betriebsabläufe von Theatern und anderen Veranstaltern digital abbilden. Im Folgenden stellen wir die einzelnen Module kurz vor.

Thea.dispo

Das wichtigste Modul und Kernstück von Theasoft, das die Spielplandaten für alle anderen Module bereitstellt. Funktionen zur Überschneidungsprüfung sorgen für eine fehlerfreie Erstellung von Plänen mittels grafischer Anwendungsoberfläche.

Thea.orchester

Planungs- und Abrechnungssystem für Orchester. Ermöglicht das Erstellen von Dienstplänen, automatische Abrechnungen, Hochrechnungen zur Auslastung und die Integration von Mitarbeiterdaten.

Thea.perso

Planungs- und Abrechnungssystem für technische Abteilungen. Erleichtert die Personalplanung, erstellt automatisch Dienstpläne und Rapportzettel und ermöglicht die Einplanung wiederkehrender technischer Arbeiten als sogenannte Countdowns.

Thea.chor

Planungs- und Abrechnungssystem für Chöre. Ordnet entstehende Kosten automatisch den entsprechenden Kostenträgern zu und erleichtert die Erstellung monatlicher Abrechnungsberichte.

Thea.project

Planungs-Tool für den künstlerischen und technischen Bereich. Die grafische Oberfläche visualisiert alle Produktionen einer Spielzeit mittels Gantt- und Zeitleistendiagrammen. Hochrechnungen der verfügbaren Stunden pro Abteilung vereinfachen die langfristige Planung und vermeiden Personalengpässe.

Thea.kontakt

Adressverwaltungs-Tool mit Such- und Filterfunktionen, das die Zuordnung von Sekundärkontakten und das Hinterlegen von Gesprächsnotizen ermöglicht. Die eingebauten Mailing-Funktionen eignen sich für die Öffentlichkeitsarbeit und das Customer-Relationship-Management.

Thea.staff

Modul für die Organisation von Maßnahmen wie Schulungen oder betriebsärztlichen Untersuchungen. Dank diverser Einstellungsmöglichkeiten lassen sich bestimmte Maßnahmetypen priorisieren und Intervalle für bestimmte Personengruppen festlegen.

Thea.fundus

Verwaltungs-Software für den Kostümfundus mit eingebautem Ausgabe- und Verleihsystem. Bietet einen Überblick über die derzeitigen Lagerorte der Kostüme und welche davon gerade in Produktionen verwendet werden. Für jedes Kostüm lassen sich verschiedenste Daten wie Farbe, Zustand oder Größe erfassen.

Theasoft-Add-ons

Die einzelnen Theasoft-Module lassen sich durch Add-ons in ihrem Funktionsumfang erweitern. Derzeit sind folgende Add-ons verfügbar:

• Thea.contract: Vertragsverwaltungs-Funktion, die Vertrags- und Besetzungsdaten kontinuerlich abgleicht und Abweichungen meldet.
• Thea.travel: Add-on für die Buchung von Reisen, Hotels und Theaterwohnungen für Gastkünstler:innen.
• Thea.transfer: Ermöglicht die Erstellung von Abrechnungen für künstlerisches und technisches Personal auf Basis der aktuellen Einplanungen sowie deren Export, etwa im CSV-Format.
• Thea.works: Add-on für die bedarfsgenaue Einplanung von Mitarbeitenden mittels Balkendiagramm-Visualisierung.
• Thea.budget: Tool für die Budget-Planung des künstlerischen Bereichs auf Basis der Spielplandaten aus thea.dispo.
• Thea.export: Ermöglicht den Export von Spielplan- und Besetzungsdaten auf den eigenen Web-Server.
• Thea.web-info: Add-on für den Zugriff auf Spielplan- und Arbeitsinformationen über den Web-Browser.
• Thea.library: Tool für die Verwaltung von Noten und Klavierauszügen.

Dank der Vielzahl von Modulen und Add-ons lassen sich mit Theasoft nahezu alle Prozesse in Theater- und Opernhäusern abbilden. Über die Export-Funktionen können Sie als Veranstalter zudem Informationen aus der Datenbank auf Ihrer Website darstellen. So halten Sie auch Ihre Besucher:innen stets auf dem neuesten Stand.

Darum lohnt sich die Verknüpfung von Theasoft mit Ihrer Website

Indem Sie Ihre Theasoft-Datenbank als zentrale Informationsquelle auch für Ihre Website nutzen, profitieren Sie von folgenden Vorteilen:

• Konsistente Datenqualität: Meist haben die von den Mitarbeitenden gepflegten Dispositionsdaten eine hohe Qualität. Diese leidet jedoch häufig bei der manuellen Übertragung auf die Website. Indem Sie Ihre Website an Theasoft anbinden, beugen Sie dem vor und vermeiden zudem zeitliche Verzögerungen bei der Aktualisierung der Datensätze.
• Zeit- und Kosteneinsparungen: Anstelle von zwei Datenbanken müssen Ihre Mitarbeitenden nach der Theasoft-Anbindung nur noch eine pflegen. Das setzt Kapazitäten frei und vermeidet kostspielige Irrtümer aufgrund von uneinheitlichen Datensätzen. Gerade bei kurzfristigen Ausfällen ist die automatische Übertragung der Änderungen auf Ihre Website eine enorme Hilfe.
• Klare Rollenverteilung: Durch die granuläre Vergabe von Lese- und Schreibrechten in Theasoft können Sie sicherstellen, dass die Verantwortlichkeiten für die Pflege Ihrer Datensätze klar geregelt sind. Da alle Abteilungen auf dieselbe Datenbank zugreifen, können sie sich gegenseitig bei der Pflege unterstützen und Fehler frühzeitig erkennen.

Anbindung Ihrer Theasoft-Datenbank: Das sollten Sie beachten

Wenn Sie als Theater oder Opernhaus bereits Theasoft nutzen, bietet es sich an, die zentrale Datenbank auch als Quelle für die Informationen auf Ihrer Website zu nutzen – so entfällt die fehleranfällige manuelle Übertragung der Daten in Ihr Content-Management-System (CMS).

Bevor die Anbindung erfolgen kann, sollten Sie jedoch einige wichtige Fragen klären.

Projektorganisatorische Fragen

• Relevante Daten: Welche Informationen möchten Sie automatisch aus Theasoft beziehen und welche sollten manuell im CMS gepflegt werden?
• Vollständigkeit der Daten: Sind alle Daten, die Sie auf Ihrer Website darstellen möchten, in Theasoft vorhanden? Falls nicht, möchten Sie diese in Zukunft dort verwalten oder lieber händisch einpflegen? Und nicht zuletzt: Sind alle Datensätze einer Datenart, z. B. Termine, Künstler und Besetzungen, vollständig?
• Datenqualität: Reicht die Qualität der in Theasoft verwalteten Daten aus, um sie ungeprüft auf Ihrer Website darzustellen? Wenn nicht, wie kann Ihr Team die erforderliche Datenqualität erreichen?
• Abteilungsverantwortlichkeiten: Welche Ihrer Abteilungen (Marketing, Künstlerisches Betriebsbüro, Kasse etc.) pflegen die für Ihre Website relevanten Daten und sollten daher ins Projekt miteinbezogen werden?
• Zuständigkeit für Korrekturen: Wer wird sich zukünftig um die Bereinigung von Fehlern in der Datenbank kümmern? Kann das Künstlerische Betriebsbüro kurzfristig reagieren? Sollte das Kommunikations- und Marketing-Team Schreibrechte in Theasoft erhalten?
• Zeitpunkt für die Inbetriebnahme: Wann wollen Sie auf die Theasoft-Anbindung umschalten? Planen Sie hier genügend Zeit für die Behebung von etwaigen Fehlern ein, die auch bei einer intensiven Testphase mitunter erst im Live-Betrieb auffallen.

Technische Fragen

• Aktualisierungsfrequenz: In welchen Abständen möchten Sie den Datenbestand auf Ihrer Website mit dem in Theasoft synchronisieren? Je kürzer die Frequenz, desto aktueller die Daten – und umso höher das Risiko, dass Sie Eingabefehler nicht rechtzeitig korrigieren können, bevor sie auf Ihrer Website sichtbar werden.
• Zu exportierende Zeiträume: Wie weit im Voraus möchten Sie damit beginnen, für einzelne Website-Einträge Daten aus Theasoft zu übertragen? Wie lange sollen diese im Nachhinein noch synchronisiert werden? In der Praxis hat es sich bewährt, die Synchronisation auf die aktuell laufende und die darauf folgende Spielzeit zu begrenzen.
• Termin-Veröffentlichung: Ab welchem Planungsstatus sollen in Theasoft verwaltete Termine auf Ihrer Website sichtbar werden? Gibt es neben dem Haken bei "Im Web veröffentlichen" weitere Kriterien, die erfüllt sein müssen, damit der Termin auf der Website angezeigt wird?
• Bearbeitung im CMS: Möchten Sie Ihrem Website-Team die Möglichkeit geben, Daten aus Theasoft nachträglich im CMS zu bearbeiten? Oder sollen Fehler ausschließlich an der Quelle, sprich in Theasoft, behoben werden?
• Umgang mit nicht mehr exportierten Daten: Wie möchten Sie mit Datensätzen umgehen, die in Theasoft nicht mehr exportiert werden? Sollen sie auf der Website unsichtbar geschaltet, gelöscht oder beibehalten werden?

So bringen wir Ihre Theasoft-Daten auf Ihre Website

Damit die Anbindung Ihrer Website an Ihre Theasoft-Datenbank so reibungslos wie möglich verläuft, gehen wir wie folgt vor:

1. In einem vorbereitenden Workshop mit Ihren Digitalisierungs- oder Projekt-Manager:innen definieren wir die Anforderungen und den groben Ablauf des Anbindungsprojekts. Zudem einigen wir uns auf feste Ansprechpartner:innen im Künstlerischen Betriebsbüro und in Ihren Kommunikations-, Marketing- und IT-Abteilungen.
2. In einem virtuellen oder persönlichen Gespräch lernen uns die Ansprechpartner:innen kennen. Hier können sie uns von ihren Erfahrungen und Bedenken berichten und eigene Ideen in das Projekt einbringen.
3. Mit Ihrem Kommunikations- und Marketing-Team definieren wir die aus der Theasoft-Datenbank zu exportierenden Entitäten und Felder und halten diese für das Künstlerische Betriebsbüro schriftlich fest. Parallel erfolgt die initiale technische Einrichtung in Abstimmung mit Ihrer IT-Abteilung.
4. Nun erfolgt die schrittweise Abbildung der Theasoft-Einträge auf Ihrer Website. Wir kontrollieren fortlaufend die Ergebnisse und klären etwaige Unstimmigkeiten im wöchentlichen Austausch mit Ihrem Team.
5. Im letzten Schritt führen wir die Website- und Theasoft-Datenbestände zusammen und bereiten die Inbetriebnahme vor. Wir empfehlen als Zeitpunkt für die Inbetriebnahme die Pressekonferenz für die kommende Spielzeit, da hier erfahrungsgemäß am wenigsten zusätzlicher Arbeitsaufwand für Ihr Team entsteht und es seltener zu Verzögerungen kommt.

Von nun an bezieht Ihre Website automatisch Datenbestände aus Theasoft und ist somit stets auf dem aktuellen Stand.

Sprechen Sie uns an

Brauchen Sie Unterstützung bei der Anbindung Ihrer Website an Ihre Theasoft-Datenbank? Dann sprechen Sie uns gerne an! Gemeinsam erarbeiten wir ein passendes Konzept für Ihr Veranstaltungshaus, um einen reibungslosen Übergang zu gewährleisten. Gerne stellen wir Ihnen auch unser spezialisiertes Content-Management-System für Theater-Websites vor und unterstützen Sie, wenn Sie eine neue Theater-Website entwickeln möchten.

Das Problem: 450 Termine, 1 Browser

Gerade zu Bekanntgabe des Programms für die nächste Spielzeit ist der Spielplan prall gefüllt mit allen zukünftigen Terminen der kommenden Monate. Im Mai 2024 standen wir genau vor dieser Situation mit 450 Terminen von Opern, Konzerten, Ballettaufführungen und weiteren Veranstaltungen. Zu diesem Zeitpunkt wurde der Spielplan noch auf dem Server berechnet und als ein großes HTML-Dokument mit der kompletten Liste von Terminen an den Browser geschickt. Dieses Vorgehen ermöglichte zwar eine Filterung nach Sparte oder Zeitraum mit JavaScript, bedeutete aber auch, dass der Browser eine große Menge von Daten laden und verarbeiten musste. Insbesondere der für die Filterung nötige JavaScript-Code schlug hier stark ins Gewicht.

Für mobile Endgeräte, deren Leistung eher in der Mittelklasse angesiedelt ist, kann eine Website mit vielen Elementen oder einer großen Menge an JavaScript-Code eine Verzögerung von Anzeige und Nutzbarkeit im Sekundenbereich bedeuten. Da die Wechselwirkung von Website-Performance und -Erfolg ("Konversionsrate") gut belegt ist, hatten wir gemeinsam mit der Staatsoper Berlin ein strategisches Ziel ausgerufen: Wir wollten die Zeit bis zur Anzeige und Interaktivität des Spielplans deutlich verringern. Um den Erfolg zu überprüfen, würden wir gängige Messwerte wie Googles Core Web Vitals und Serien von Screenshots nutzen, die alle 0,1 Sekunden während des Ladevorgangs aufgenommen werden.

Unsere Lösung: Paginierung und Infinite Scrolling

Das Projekt war klar umrissen: Wir wollten die Größe des HTML-Dokuments verkleinern und die Menge an rechenintensivem JavaScript-Code möglichst gering halten. Frei nach „Divide et impera“ ist die Lösung für die erste Teilaufgabe, die lange Liste aller Termine nicht auf einer einzigen Seite zu rendern, sondern auf viele Seiten verteilt. Mit einer paginierten Darstellung von 10 Terminen pro Seite würden wir bei durchschnittlich 1-3 Vorstellungen am Tag etwa 5-6 Tage abdecken.

Die Aufteilung bedeutet aber, dass eine Nutzerinteraktion nötig ist, um auf die nächste Seite zu navigieren. Zusätzliche Klicks würden das Durchstöbern des Spielplans stören und sich negativ auf die Nutzerbindung auswirken. Wir haben daher mit „Infinite Scrolling“ ein Muster implementiert, das von sozialen Netzwerken und anderen großen Plattformen bekannt ist. Statt per Klick auf die nächste Seite navigieren zu müssen, werden die nächsten Termine im Hintergrund schrittweise nachgeladen, wenn Nutzerinnen und Nutzer nach unten scrollen. Damit ändert sich an der Art der Bedienung nichts, die Ladezeit des ersten Pakets von nur noch 10 Terminen verkürzt sich aber dramatisch.

Das konnten wir uns bei der zweiten Teilaufgabe zu Nutze machen. Um möglichst viel JavaScript-Code entfernen zu können, stellten wir die Filterung des Spielplans auf eine serverseitige Lösung um. Wo eine Eingrenzung auf eine Sparte oder einen Zeitraum zuvor zu Verzögerungen führte, während das JavaScript die Filterung vornahm, würden wir zukünftig eine neue Anfrage an den Server ausführen, der ein neues HTML-Dokument zurückliefert. Das braucht deutlich weniger JavaScript-Code und wir konnten die Dateigröße von 136 kB auf 9 kB reduzieren. Die Dateigröße steht hier nur stellvertretend für die letztendlich eingesparte Rechenzeit, denn weniger Code ist auf allen Geräten schneller ausgeführt.

Das Ergebnis: Eine halbe Sekunde kürzere Ladezeiten

Bereits kurz nachdem wir den Spielplan Mitte Mai 2024 auf die neue Implementierung umgestellt hatten, wurden bei Googles Core Web Vitals im Chrome UX Report (echte Nutzerdaten, letzte 28 Tage) Verbesserungen sichtbar – und das, obwohl die Umstellung nur für die Hälfte des Messzeitraums aktiv war. Auch synthetische Tests zeichneten ein erfolgreiches Bild: In Messungen mit dem Tool WebPageTest zeigte sich für ein simuliertes iPhone X über eine 4G-Verbindung eine Verbesserung der Ladezeit von 2,2 s auf 1,7 s – eine halbe Sekunde schneller!

Schön ist auch zu sehen, dass die Belastung des Browsers (und des Prozessors des Endgeräts) stark zurückgegangen ist: Durch die Reduktion von HTML-Elementen und JavaScript-Code gibt es keine Blockaden des Main Threads (erster Screenshot, zweite Zeile von unten, sehr hohe Auslastung) durch Long Tasks (erster Screenshot, unterste Zeile, drei rote Blöcke) mehr:

Auch in Googles PageSpeed Insights ist die Verbesserung signifikant: im Bereich Performance für mobile Geräte erreicht die Spielplan-Seite 88 von 100 möglichen Punkten, was im Vergleich zu vorher (47 von 100 Punkten) beinahe eine Verdopplung ist. Für die Kategorie „Desktop“ erreicht der neue Spielplan sogar 99 Punkte. Das freut uns sehr, zeigt aber auch, dass es vor allem bei mobilen Geräten noch weiteres Verbesserungspotenzial gibt. Performanceoptimierung ist ein Prozess, der immer weiter geht – und wir nehmen die Herausforderung gerne an.

Update 14.06.2024: optimierte Ladereihenfolge kritischer Ressourcen

Diese Woche haben wir den Prozess weiter voran getrieben und die Ladereihenfolge der für gute Performance kritischen Ressourcen optimiert. Hier geht es um Fragen wie:

• Was soll zuerst geladen werden? JavaScript, CSS oder doch lieber die Web Fonts?
• Welche einzelnen Ressourcen sind vielleicht nicht kritisch und können ans Ende der Warteschlange gesetzt werden?
• Wie sollen die Ressourcen geladen werden? Müssen andere Prozesse warten, bis eine bestimmte Ressource verfügbar ist, oder sind die Ressourcen unabhängig voneinander und können asynchron angefordert werden?
• Wie gehen wir mit den Schriftarten um – zeigen wir eine weiße Seite, bis die Web Fonts geladen sind, oder erst eine generische Ersatzschrift vom Gerät der Website-Besucher*innen?

Mit Hilfe von Harry Roberts' Empfehlungen zur Ladereihenfolge, die er seit Jahren kontinuierlich weiterentwickelt, haben wir unsere Antworten gefunden und umgesetzt. Und die Seite wieder ein bisschen schneller gemacht: Google Pagespeed belohnt uns für die Seite des Spielplans mit nunmehr 93 von 100 Punkten (mobile Geräte).

Da unser Girls’Day 2023 ein voller Erfolg war, sprach aus unserer Sicht nichts dagegen, das damals entwickelte Konzept auch in diesem Jahr wieder einzusetzen.

Für den Girls’Day haben wir die Berufsfelder unserer Firma grob auf vier Bereiche heruntergebrochen: Frontend, Backend, Projektmanagement und Konzeption.
Nach einer Einführung durch uns in die jeweiligen Bereiche, konnten die Mädchen selbst in die Jobs schlüpfen:

In der Rolle der Frontend-Entwicklerin erstellten die Mädchen auf Basis der von uns bereitgestellten Vorlagen ihre eigene Portfolio-Website.

Auf scratch.org konnten sie in der Rolle der Backend-Entwicklerin per Drag&Drop ihr eigenes Online-Spiel programmieren und zum Beispiel „Flappy Bird“ nachbauen.

Den Produktionsweg eines Schulranzens durften sie dann gemeinsam als Projektmanagerinnen planen und mussten unterwegs Zeitprobleme lösen und Deadlines einhalten. „Die Herstellung des Schnittmusters verzögert sich um 2 Tage. Können wir dennoch unsere Deadline einhalten?“

Zu guter Letzt teilten sich die vier Mädchen in zwei Gruppen auf, konzipierten ihre eigene Website auf Papier und am Whiteboard und präsentieren sie anschließend im Stil von „Die Höhle der Löwen“.

In der Konzeptionsphase wurden zwei ähnliche Websites für Innenausstattung und Raumdesign entwickelt:
„Home Zone“ und „7, 8, 9 - Designtime“.

Die Ideen der Mädchen: Auf beiden Websites kann man sich neue Inspirationen für die eigenen vier Wände holen, oder Termine für eine Umgestaltung buchen. Durch die Verwendung von großformatigen Bilder sollen Besucher*innen inspiriert werden und die Möglichkeit erhalten, über ein Formular Kontakt herzustellen.

Auf „Home Zone“ gibt es sogar einen integrierten Webshop, sodass man Deko-Objekte direkt nach Hause bestellen kann. „7, 8, 9 - Designtime“ bietet hingegen die Umgestaltung von ganzen Häusern oder Gärten und besitzt einen eigenen Blog, über den sich neue Kunden und Fans auf dem Laufenden halten können.

Der Tag wurde abschließend in einer Feedback-Runde mit der 5-Finger-Methode[^1] reflektiert.

Dabei stellte sich heraus, dass sie viel Spaß hatten, in die verschiedenen Bereiche zu schnuppern und zwei der Mädchen sich sogar vorstellen können, später in der IT-Branche zu arbeiten.

Schon beim Rundgang durch das Büro ist den Mädchen das „Bällebad“ ins Auge gefallen. Nach der Feedback-Runde wurde dann die Wartezeit auf den Bus mit einem Fotoshooting in der umfunktionierten Badewanne überbrückt.

Für uns war der Tag wieder ein voller Erfolg und auch wir hatten viel Spaß den Mädchen einen Einblick in unsere Berufe und in die Firma zu ermöglichen. Wir freuen uns schon auf den nächsten Girls'Day!

[^1]: Die 5-Finger-Methode:
Daumen: Das fand ich gut
Zeigefinger: Darauf möchte ich hinweisen
Mittelfinger: Das fand ich nicht gut
Ringfinger: Das liegt mir am oder auf dem Herzen
Kleiner Finger: Das kam mir zu kurz