Wir sind ein technikaffines Unternehmen. Technische Neugier, Entdeckergeist und Offenheit für neue Herausforderungen sind Teil unseres Selbstverständnisses und unserer Unternehmenskultur. Wir empfinden Freude daran, neue Technologien zu verstehen und sinnvoll einzusetzen. Wir sind offen für Experimente und neue Lösungswege. Wir lernen durch Ausprobieren und kontinuierliche Verbesserung.

Daher möchten wir uns den Entwicklungen der KI nicht verschließen. Wir möchten die Möglichkeiten verstehen und herausfinden, wie sie sinnvoll, wertschöpfend und verantwortungsvoll eingesetzt werden können. Aber wir haben auch Sorgen, offene Fragen und zum Teil keine Antworten.

Frage nach Verantwortung

KI-basierende Anwendungen entstehen und werden schneller ausgerollt, als gesellschaftliche Diskussionen, rechtliche und ethische Rahmenbedingungen sich entwickeln können. Wir sehen grundsätzlich ungeklärte Fragen.

Das betrifft die Verantwortung der Unternehmen, die KI-Systeme entwickeln und verbreiten. Der Hunger nach immer umfassenderen und stets aktuellen Trainingsdaten führt dazu, dass kreative Werke Dritter häufig ohne explizite Zustimmung oder Vergütung genutzt werden, mitunter sogar gegen geltendes Recht. Nicht immer ist transparent, wie Inhalte aus der Interakt­ion mit KI-Anwendungen in zukünftige Trainingsprozesse einfließen. Der Schutz kreativer Arbeit, von Privatsphäre und Vertraulichkeit sowie eine faire Verteilung der Wertschöpfung bleiben große offene Herausforderungen.

Zumindest heute benötigen KI-Systeme erhebliche Energie- und Ressourcenmengen. Training und Betrieb großer Modelle haben messbare ökologische Auswirkungen. Nachhaltigkeit muss daher Teil der Bewertung sein. Kosten werden teilweise externalisiert — etwa wenn Online-Angebote durch massenhaftes automatisiertes Abrufen von Inhalten belastet werden, während menschliche Besucher zunehmend ausbleiben und damit Erlösmodelle der Anbieter unter Druck geraten. Auch Open Source Software leidet darunter, wenn Code und Dokumentation auf der einen Seite zum Training von Modellen verwendet werden, auf der anderen Seite aber die Arbeitsplätze der Menschen, die diese Projekte betreuen und voranbringen, Opfer KI-getriebener Rationalisierung werden.

Auch Unternehmen, die KI zur eigenen Aufgabenerfüllung einsetzen, müssen sich mit ihrer Verantwortung auseinandersetzen. Dazu gehören mögliche Auswirkungen auf Arbeitsmärkte, die Verantwortung für Fehlentscheidungen automatisierter Systeme sowie Sicherheitsaspekte KI-basierter Lösungen, die erst ansatzweise  verstanden werden. Funktionierende IT-Systeme sind für die Stabilität unserer Gesellschaft wesentlich. Es ist denkbar, dass sich durch den zunehmenden Einsatz von KI über die Zeit systemische Risiken in diesen Systemen entwickeln.

Nicht zuletzt berührt uns der Einsatz von KI auch menschlich. Für jede und jeden von uns stellt sich die Frage, wie sich die eigene Arbeit und fachliche Leistung, über die wir uns auch persönlich definieren, in den kommenden Jahren verändern wird. Aspekte unserer Arbeit werden verschwinden oder sich wandeln, gleichzeitig entstehen neue Möglichkeiten. Die damit verbundene Ungewissheit ist belastend.

Auf alle diese Fragen haben wir derzeit keine guten, schlüssigen Antworten. Wir sind zwiegespalten: Den Einsatz von und die Beschäftigung mit KI zurückzustellen, bis wir die Antworten haben, würde bedeuten, den Anschluss zu verlieren. Die Fragen zu ignorieren und KI durch ihren Einsatz zu legitimieren, fühlt sich ebenfalls nicht richtig an.

Perspektive für uns als Unternehmen

Unsere wirtschaftliche Existenz als Unternehmen basiert wesentlich auf Softwareentwicklungsleistungen. Was bedeutet es für uns, wenn sich das Versprechen einiger KI-Unternehmen erfüllt, Software zu einem jederzeit erzeugbaren, ubiquitären und kostengünstigen Produkt zu machen? Wenn KI-gestützte Werkzeuge zu erheblichen Effizienzgewinnen führen: Funktioniert dann ein Vergütungsmodell, das Zeit und nicht Ergebnisse vergütet, weiterhin? Welcher Wert würde denn alternativ den Ergebnissen noch zugeschrieben, wenn sie vermeintlich von KI erzeugt wurden?

In den mehr als 25 Jahren seit Unternehmensgründung waren wir immer davon überzeugt, dass Softwareentwicklung natürlich gute handwerkliche Arbeit erfordert. Ihr Erfolg hängt mindestens genauso vom Austausch zwischen Menschen ab: Vom Verständnis fachlicher Anforderungen, vom Einbeziehen der Bedürfnisse von Nutzerinnen und Nutzern, vom Erkennen technischer und organisatorischer Gestaltungsspielräume und vom vertrauensvollen Dialog aller Beteiligten.

Diese Aufgaben lassen sich nicht durch einen geschickten Prompt an ein KI-System delegieren. KI-gestützte „Vibe-Coding“-Ansätze können kurzfristig schnelle und scheinbar kostengünstige Ergebnisse liefern. Gleichzeitig erzeugen sie „kognitive Schulden“. Damit ist gemeint, dass eine tiefergehende, inhaltliche Auseinandersetzung mit Problemstellung, Kontext und Anforderungen ausbleibt. Es entstehen Lösungen auf Basis nur oberflächlich behandelter Annahmen, deren genaue Wirkungsweise und Zusammenhänge später kaum zu rekonstruieren sind.

Der Wert für unsere Kunden entsteht durch Verständnis, Verantwortung und Erfahrung. KI verändert unsere Werkzeuge und Arbeitsweisen. Sie ist so hoffentlich keine Bedrohung unserer Existenz, sondern verschiebt den Schwerpunkt von Umsetzung und Produktion hin zur Analyse und zur gemeinsamen Gestaltung möglicher Lösungen.

Der Bedarf an Verständnis, Verantwortung und Urteilsvermögen bleibt. Problemlösung erfordert weiterhin menschlichen Austausch und menschliche Perspektiven. Vertrauen, Qualitätsbewusstsein und Kontextverständnis bleiben relevant.

Bedeutung für unsere interne Arbeit

Wir möchten weiterhin neugierig und offen erkunden, wie KI-Werkzeuge eingesetzt werden können, um unsere Arbeit und ihre Ergebnisse zu verbessern. Vielleicht werden wir effizienter. Vielleicht erhöhen wir die Qualität unserer Ergebnisse.

Die Herausforderung besteht darin, in einem sich rasant entwickelnden Feld zu erkennen, welche Möglichkeiten tatsächlich bestehen. Was ist Hype — und was schafft echten Nutzen?

Wie erkennen wir funktionierende Ansätze, bewerten Erfahrungen systematisch und geben sie im Team weiter? Wie halten wir dieses Wissen aktuell in einem Umfeld, das sich innerhalb von Monaten, nicht Jahren, verändert?

Kontinuierliches Lernen war schon immer Teil der Arbeit in unserer Branche. Auch in diesem Fall möchten wir versuchen, das Lernen als gemeinsamen Prozess zu gestalten und Wissen zu teilen. Der technologische Fortschritt entsteht nicht durch die Tools, sondern durch ihren sinnvollen Einsatz – durch Menschen wie uns.

Beim Einsatz von KI-Werkzeugen wollen wir kritisch bleiben und nicht bequem werden. Der Wert für unsere Kunden und unser Selbstwert am Arbeitsplatz entstehen gleichermaßen aus der Überzeugung, sich angemessen mit den Problemen und möglichen Lösungen auseinandergesetzt zu haben. Wir wägen Optionen  ab, finden Kompromisse und streben die bestmöglichen, unter den gegebenen Umständen erreichbaren Ergebnisse an. Diese Aufgabe und damit verbundene Entscheidungen wollen wir nicht an Systeme delegieren, deren Funktionsweise und Ergebnisse nur zum Teil transparent, nachvollziehbar oder reproduzierbar sind.

KI-basierte Werkzeuge können uns helfen, bei bestimmten Aufgaben schneller ans Ziel zu kommen. Das Ziel zu definieren und dabei unsere Ansprüche zu wahren, bleibt unsere eigene und persönliche Aufgabe.

Bereits Ende 2024 ereilte uns eine spannende Anfrage von der Staatsoper Unter den Linden:

Können wir den Spielplan der Webseite auf Monitoren im Kassenbereich (im Foyer) sowie – zukünftig – auf Displays in unseren Außenvitrinen ausspielen?

Die Oper versprach sich hauptsächlich Synergieeffekte durch eine Vereinheitlichung der Datenquelle und Anzeigelogik. Damals wurden im Haus sowohl der aktuelle Spielplan als auch digitale Plakate für einzelne Produktionen mit hohem Aufwand als Grafiken vorbereitet und dann als zusammengesetztes Video für die Monitore (im folgenden „Infoscreens“) gerendert. Kurzfristige Änderungen von Besetzungen und Programmhinweisen oder der aktuellen Ticketverfügbarkeit konnten entweder nur mit erneut hohem Aufwand oder gar nicht berücksichtigt werden.

Unsere Antwort war ein optimistisch-enthusiastisches „Selbstverständlich!“, denn grundsätzlich spricht nichts dagegen, eine Website auf unterschiedlichen Bildschirmen oder Geräten anzuzeigen, solange das Gerät (z. B. ein Fernseher) über einen internetfähigen Browser verfügt. Und die Chance, „unsere“ Website abseits ihres natürlichen Habitats ins Foyer der Staatsoper zu bringen, wollten wir uns natürlich nicht entgehen lassen.

Von Anfang an war klar, dass es Unterschiede zur Website geben musste, da die Infoscreens nicht interaktiv sein würden, und entsprechend keine Hauptnavigation, Kategorie-Filter oder Ticket-Buttons gezeigt werden sollten. Das Hauptziel war und blieb allerdings, möglichst nah an der Ausgabe der Website zu bleiben, und neue Features oder visuelle Änderungen auch immer direkt für die Infoscreens verfügbar zu haben. Wir gingen daher mit der Annahme in die Planungsphase, dass wir nur einige Komponenten ausblenden oder geringfügig anders layouten müssten.

Das Projekt hatte dann aber doch ein paar Überraschungen parat.

1. Akt: Der Browser

Die Oper war unter anderem deswegen an uns herangetreten, weil im Rahmen eines Digitalisierungsprojekts gerade neue Monitore angeschafft worden waren. Wir waren optimistisch. Zu optimistisch? Nach etwas Wartezeit bekamen wir Details zum verbauten Mediaplayer und dem installierten Browser:

Die Engine ist nicht mehr ganz jung, aber es sollten alle Funktionen damit umsetzbar sein, allerdings muss das Template so angepasst werden, dass es auf einem Chrome Version 56 läuft.

Moment. „Nicht mehr ganz jung“? Google Chrome 56 war jung, als er herauskam – im Dezember 2016.

Warum war das brisant? Wir legen beim Browser Support bereits sehr konservative Bemessungsmaßstäbe an und unterstützen alle gängigen Browserversionen auf etwa fünf Jahre rückwirkend, aber nicht neun Jahre. Tatsächlich war unter anderem das Layout der Website auf Basis von Techniken umgesetzt, die erst in späteren Chrome-Versionen verfügbar waren (CSS Grid Layout).

Ein Update des Browsers war nicht möglich:

[…] leider werden wir bei der Browser-Version hängen bleiben, da das an der Firmware des Players angedockt ist [...]

Ein Umstieg auf einen anderen Mediaplayer wie Chromecast/Google TV Streamer oder einen Raspberry Pi war ebenfalls keine Option für die Oper, weil das bestehende System weiterhin zur Verwaltung der ausgespielten Inhalte genutzt werden sollte. Die Website sollte neben Fotos und Videos nur ein Element unter mehreren in einer Gesamtpräsentation sein, die über den Mediaplayer auf den Infoscreens abgespielt würde.

Für uns bedeutete das: zumindest für den Zeitpunkt des Launches im September 2025 war davon auszugehen, dass die Umsetzung in Chrome 56 funktionieren müsste.

Zum Glück war unser Werkzeugkasten darauf einigermaßen vorbereitet. Wir nutzen in allen Projekten automatische Tools, die – basierend auf einer Konfiguration im Projekt sowie dem Abgleich mit global verfügbaren und stetig aktualisierten Datenbanken – unseren geschriebenen CSS- und JavaScript-Code je nach Bedarf modernisieren oder rückwärtskompatibel machen. Das ermöglicht uns einerseits, inzwischen unnötigen Quellcode in älteren Projekten nicht mehr auszuliefern, ohne jede Datei einzeln prüfen zu müssen. Andererseits können wir gefahrlos heute Code so schreiben, wie er in aktuellen Browserversionen  funktioniert oder sogar erst in zukünftigen funktionieren wird, und unsere Tools schreiben den Output rückwärtskompatibel um[^1].

Um den Code für Chrome 56 fit zu machen, waren daher letztendlich nur wenige Schritte notwendig:

• Aufnahme von Chrome 56 in die Browser-Support-Konfiguration unseres Toolings
• Durchsicht von CSS und JavaScript auf Funktionen, die nicht automatisch (oder „automagisch“?) rückwärtskompatibel gemacht werden konnten
• Manuelle Anpassungen: u. a. in CSS ein Fallback auf Flexbox Layout, da CSS Grid Support erst mit Chrome 57 (!) kam; in JavaScript die Ergänzung sogenannter „Polyfills“, d. h. Code-Schnipsel, die moderne Browser-Features in JavaScript für ältere Browser nachbauen

2. Akt: Der Fernseher

Mit der erfolgreich hergestellten Browser-Kompatibilität war es Zeit für die nächste Aufgabe. Parallel hatte die Oper erste Tests auf den Infoscreens ausgeführt und uns mit einem weiteren Detail überrascht:

Die Screens in der Kassenhalle sind hochkant gestellt, stellen aber automatisch auf orientation: landscape; die Templates müssten daher um 90° nach rechts gedreht werden.

Moment. „Um 90° nach rechts gedreht“? Sicherlich ließe sich die orientation , also die maschinenlesbare Ausrichtung des Geräts, leicht anpassen und eine Drehung der Website vermeiden?

Der Mediaplayer kann das Bild nicht drehen, da die anderen Inhalte wie Videos etc. sonst nicht in 4K ausgespielt werden können. Momentan läuft es dann nur in Full HD. Wir kommen also an der Drehung der Templates leider nicht vorbei.

Die Antwort war also: nein. Spannend! Zeit für den nächsten Blick in den Werkzeugkasten. Bei Aufgaben, für die es keine standardisierte Lösung gibt (unsere Lieblingsaufgaben!), beginnen wir mit einer explorativen Phase, in der wir zügig verschiedene Lösungsansätze skizzieren und prototypisch antesten.

Idee 1: CSS bietet über das Transforms Module unter anderem die Möglichkeit, Inhalte zu drehen – also genau das, was wir brauchen? Jein. Ein schneller Check ergab: grundsätzlich ist das ein möglicher Ansatz, aber eher dazu gedacht, einzelne Elemente zu drehen, und nicht die ganze Seite. Im Detail würde es knifflig, die Inhalte korrekt im Viewport zu positionieren und das korrekte Layout zu erreichen.

Idee 2: CSS bietet Writing Modes an, um Textausrichtung von links-nach-rechts (z. B. für Deutsch, Englisch und andere indogermanische Sprachen), von rechts-nach-links (z. B. Hebräisch oder Arabisch) oder vertikal (z. B. für asiatische Schriften) zu erlauben. Wäre das eine Option? Hm. CSS bietet außerdem Logical Properties an, um Layoutangaben für die Ausgabe in unterschiedlichen Textausrichtungen mit logischen anstelle von physischen Konzepten umzusetzen. In anderen Worten: statt naiv anzunehmen, dass eine CSS  width  immer eine physische Breite meinen wird, kann eine logische  inline-size  definiert werden, die (vereinfacht) von modernen Browsern als „Achse der Textausrichtung“ interpretiert wird. Für die senkrecht dazu verlaufende Achse existiert analog  block-size , und das Konzept der Inline- und Block-Achsen gibt es auch für Außen- und Innenabstände, Rahmen sowie ganze Layout-Module wie Flexbox.

Auch wenn Idee 2 auf den ersten Blick komplizierter wirkt, fiel der erste prototypische Test positiv aus: Die bereits erwähnten automatischen Tools waren nicht nur in der Lage, logische Konzepte wie  inline-size  für Chrome 56 rückwärtskompatibel zu  width  zu übersetzen, sondern erlaubten eine Konfiguration der Textausrichtung. Wir konnten also die Ausgabe der speziellen CSS-Datei so erweitern, dass logische Angaben von „links-nach-rechts“ auf der Website zu „oben-nach-unten“ für die gedrehten Infoscreens transformiert wurden.

// Auszug aus der Konfiguration
postCssPresetEnv: {
    "logical": {
        "inlineDirection": "top-to-bottom",
        "blockDirection": "right-to-left"
    },
    browsers: [
        "Chrome 56"
    ],
}

Grundlage dafür war natürlich die Nutzung von logischen statt physischen Angaben im CSS-Quellcode der Website, aber wir hatten zum Glück schon vor langer Zeit begonnen, auf diese neue Praxis umzustellen.

Finale

Mit dem Plan in der Hand ging es an die Umsetzung. Wie in den meisten Softwareprojekten üblich, stießen wir gemeinsam mit unserem Kunden unterwegs noch auf weitere Anforderungen, die sich aber alle unter Einsatz von Standardtechniken erfüllen ließen:

• QR-Codes als einfacher Weg vom Infoscreen auf die entsprechende Seite der Website auf dem Mobiltelefon
• Einrichtung einer Pufferzone rund um die Inhalte, um visuelle Blenden vor den Fernsehern zu berücksichtigen
• Ausgabe von (ggf. gedrehten) Bildern und Videos auf den plakatartigen Produktionsseiten
• redaktionelle Tools, um eine für den begrenzten (nicht scrollbaren) Viewport auf dem Infoscreen optimierte Version von langen Informationen oder Besetzungslisten bereitzustellen
• unterschiedliche Layouts für die Darstellung auf den Außenvitrinen bzw. in der Kassenhalle

Epilog

Auch wenn es vielleicht skurril anmutet, im Jahr 2025 eine bestehende, moderne Website um 90° gedreht auf einem neun Jahre alten Browser auszugeben – wir haben dieses Projekt als eine spannende Herausforderung genommen und (meistens) mit großem Spaß an der Lösung gearbeitet. Es war auch toll, wieder einmal zu sehen, wie weit CSS gekommen ist, und welche Möglichkeiten es eröffnet.

Wir freuen uns jetzt schon auf das nächste konzeptionelle Puzzle!

Hier ist unser Ensemble:

• Der um 90° gedrehte Spielplan für die hochkant montierten Infoscreens im Foyer
• Das um 90° gedrehte digitale Plakat für die Wagner-Oper Lohengrin, ebenfalls für die Infoscreens im Foyer
• Das digitale Plakat von Lohengrin im Querformat für die Außenvitrinen
• Das digitale Plaket von Lohengrin auf English – denn was die Website kann, kann auch der Infoscreen

[^1]: Natürlich gilt das nur für Funktionen, die generell rückwärtskompatibel gemacht werden können, und ist kein Allheilmittel.

Automatisierte Tests als Grundlage der Qualitätssicherung

„Automatisiert“ bedeutet, dass das Testprogramm innerhalb weniger Minuten abläuft, ohne dass manuelle Schritte erforderlich sind. Nur so lassen sich die Tests häufig ausführen. Fehler können damit in der laufenden Entwicklung erkannt und korrigiert werden, nicht erst in einer späten Qualitätssicherungs- oder Abnahmephase.

Der Inhalt der Tests ist natürlich sehr projektspezifisch. Tests für einzelne, kleine Abschnitte der Software werden „Unit Tests“ genannt und oftmals direkt vom Entwicklungsteam parallel zum eigentlichen Anwendungscode geschrieben. In diesem Artikel geht es speziell um eine weitere Art von Tests, die auf der Idee des „Behaviour Driven Development“ (BDD) basieren.

Behaviour Driven Development

Das Ziel von BDD ist es, durch enge Zusammenarbeit zwischen dem Entwicklungsteam und der fachlichen Seite (z. B. dem Auftraggeber) ein gemeinsames Verständnis des gewünschten Verhaltens der Software zu erreichen. Der Fokus liegt dabei nicht auf den Details der technischen Umsetzung, sondern auf dem Verhalten der Anwendung aus fachlicher Sicht oder Sicht der Endnutzer.

Beschreibung von Anforderungen in „Gherkin“

Die Anforderungen werden dazu in einer einer halb-strukturierten Schreibweise formuliert, die „Gherkin“ genannt wird. Diese Notation lässt sich auch ohne technisches Hintergrundwissen lesen und verstehen.

Hier ein Beispiel aus der „TOY“-Datenbank des SALTO Youth-Netzwerks, in der Trainer berufliche Profile hinterlegen und sich miteinander vernetzen können.

Scenario: Reviewing pending connection requests on the dashboard
    Given my trainer profile was set up
    And another trainer was added and activated
    And they submitted a request to connect professionally with me
    And I am logged in
    When I go to my incoming connection requests page
    Then I should see the trainers name
    And I should see "Approve"
    And I should see "Refuse"

Typisch für die Beschreibungen ist die „given-when-then“-Struktur. Jedes Szenario definiert zuerst eine Ausgangsbasis oder die Voraussetzungen, die für ein bestimmtes Verhalten gegeben sein müssen. Die „when“-Phase beschreibt dann eine vom Benutzer, durch ein Ereignis o. ä. ausgelöste Aktion oder einen Ablauf. Das abschließende „then“ überprüft, ob die Veränderungen und Ergebnisse so eingetreten sind, wie sie gewünscht werden.

Behat interpretiert Szenarien als Drehbuch für einen Softwaretest

Die Formulierung ist strukturiert genug, um als „Drehbuch“ eines automatisierten Tests abgearbeitet zu werden. Für die Umsetzung mit der Programmiersprache PHP setzen wir das Tool „Behat“ ein. Behat fungiert als Bindeglied zwischen den in Gherkin geschriebenen Szenarien und der Ausführung von PHP-basiertem Anwendungs- und Testcode. Dazu werden Teilsätze oder „Schablonen“ mit dem Programmcode verknüpft, der dann – getrieben von der textlichen Spezifikation – abgearbeitet wird.

Idealerweise lassen sich Anforderungen so zumindest in Grundzügen bereits während der Konzeption eines Features festhalten. Während der Umsetzung wird dann auch die Ausführung als Test ermöglicht, womit unmittelbar die Ergebnisse validiert werden können. Dabei entwickelt sich sehr bald ein projektspezifisches Vokabular und ein Grundgerüst von (Halb-)sätzen. Es wird zunehmend einfacher, auch neue Szenarien und Anforderungen zu beschreiben.

Einsatz auf verschiedenen Ebenen der Software

Die Behat-Tests lassen sich in unterschiedlichen Ebenen der Software einsetzen. Hier ein Beispiel für einen Test des „Modells“ einer Software. Mit Modell werden die zentralen Komponenten eines Systems bezeichnet, in denen unmittelbar die relevanten, projektindividuellen Konzepte, Dinge und Umstände abgebildet werden.

Szenariogrundriss: Status eines Nutzenbewertungsverfahrens
    Angenommen es gibt ein Nutzenbewertungsverfahren
    Und das Nutzenbewertungsverfahren hat den Zustand ZUSTAND_AKTIV
    Und das Nutzenbewertungsverfahren beginnt das Stellungnahmeverfahren am <Beginn>
    Und das Nutzenbewertungsverfahren hat eine Frist zur Abgabe einer Stellungnahme bis zum <Ende>
    Dann sollte sich das Nutzenbewertungsverfahren im Status <Status> befinden
​
    Beispiele:
        | Beginn  | Ende    | Status                           |
        | gestern |         | STATUS_BEWERTUNG_GESTARTET       |
        | morgen  | +9 Tage | STATUS_BEWERTUNG_GESTARTET       |
        | gestern | morgen  | STATUS_STELLUNGNAHMEFRIST_LAEUFT |
        [...]

Wie man sieht, lassen sich Szenarien auch in deutscher Sprache formulieren, wenn das die bevorzugte Sprache aller Projektbeteiligten ist.

Szenarien können auch beschreiben, wie Benutzer:innen mit einer Webanwendung interagieren. Es können beispielsweise Eingaben in ein Formular gemacht oder Elemente der Bedienoberfläche angeklickt werden. So beschreibt das folgende Szenario, wie eine Projektleiterin in der Youthpass-Anwendung eine Nachricht an einen Projektteilnehmer schicken kann:

Scenario: Sending a message to a learner
    Given I am on the "Communications" page
    When I fill in "hello" into the "Your message" field
    And I press "Submit message"
    Then I should be on the "Communications" page
    And I should see "Your message was sent to the participant."
    And I should see "hello" in the "communication history" section

Es ist sogar möglich, zur Ausführung dieser Tests einen „ferngesteuerten“ Webbrowser zu verwenden. Damit werden „Ende-zu-Ende“-Tests möglich, bei denen auch die korrekte Funktionsweise solcher Teile mit überprüft werden kann, die im Browser des Benutzers ablaufen.

Dazu als letztes Beispiel die Spezifikation einer „Autocomplete“-Komponente, die auf dieser Seite eingesetzt wird. Sie ist in JavaScript geschrieben und schlägt direkt während der Eingabe der ersten Zeichen in ein Eingabefeld mögliche Suchworte vor.

Szenario: Filtern von Nutzenbewertungsverfahren über Suchworte
    Angenommen es gibt ein Nutzenbewertungsverfahren
    Und das Nutzenbewertungsverfahren hat als Handelsnamen "Quxdoo"
    Und das Nutzenbewertungsverfahren hat als Suchwort "Findolimod"
    Wenn ich die Listenseite der Nutzenbewertungsverfahren aufrufe
    Und ich gebe "Fin" in das Feld "Wirkstoff oder Handelsname" ein
    Und ich drücke "Filter anwenden"
    Dann sollte ich "Quxdoo" im Element "HTML: Auflistungstabelle" sehen

Wie viel Aufwand macht die Einrichtung von Behat-Tests?

Ohne Frage ist das Schreiben der Gherkin-Spezifikationen, der dazu notwendige Testcode und die erstmalige Einrichtung und Integration in die Test-Pipeline mit etwas zusätzlichem Entwicklungsaufwand verbunden.

Die Basiseinrichtung lässt sich in der Regel im Rahmen eines Personentags erledigen. Etwas mehr Aufwand stellt die tatsächliche Umsetzung der ersten Szenarien dar, weil zu Anfang ein „Grundvokabular“ für das Projekt aufgebaut werden muss. Je nach Umfang und Komplexität eines zu entwickelnden Features kann es dabei durchaus sein, dass zu Beginn 25% oder mehr der Entwicklungszeit für die Umsetzung des Test-spezifischen Codes benötigt werden.

Wir haben aber beobachtet, dass dieser Aufwand stark abnimmt, sobald eine gewisse sprachliche Basis die Szenarien etabliert wurde. Es wird zunehmend einfacher, Szenarien für neue oder geänderte Anforderungen zu formulieren, und der ergänzend zu schreibende Testcode wird immer geringer.

Dem Aufwand gegenüber steht der langfristige Nutzen, den ich abschließend zusammenfassen möchte.

Vorteile von Behat-Tests für die Zusammenarbeit und Ergebnisse im Projekt

Behat-basierte Tests sind für uns ein wertvoller Baustein, um die Qualität in den von uns entwickelten Anwendungen und Projekten zu verbessern.

Sie liegen in einer Form vor, die ohne größere Schwierigkeiten auch von den Projektbeteiligten der fachlichen Seite verstanden und nachvollzogen werden kann. Unsere Auftraggeber können so das korrekte Verständnis der Anforderungen besser beurteilen.

Gleichzeitig bekommen sie ein besseres Verständnis vom Umfang der Tests. Das wiederum kann dabei helfen, in QS- und Abnahmephasen die Aufmerksamkeit auf die Dinge zu lenken, die eventuell nicht oder nur aufwendig automatisiert getestet werden können. Durch die automatisierte Ausführung wird die Qualitätssicherung langfristig von repetitiven, manuellen Arbeiten entlastet.

Ziel: Gemeinsame Diskussion und Verständnis

Die in Gherkin geschriebenen Szenarien sind eine gute Grundlage für eine detaillierte Diskussion oder einen strukturierten Review der Anforderungen. In verschiedenen Projekten hat es bereits funktioniert, dass wir zusammen mit den fachlichen Projektbeteiligten die Anforderungen im Detail anhand dieser Spezifikationen diskutiert haben. Bereits nach kurzer Zeit haben unsere fachlichen Ansprechpartner auf Kundenseite eigene Vorschläge für weitere Tests gemacht. Sie haben fachlich irrelevante Szenarien gestrichen und Vorschläge zur besseren Formulierung der Szenarien gemacht. Und last but not least: Sie haben falsch verstandene Anforderungen anhand der Testspezifikation erkannt und korrigiert.

Diese Zusammenarbeit war durch Reviews und Kommentare auf der Plattform GitHub möglich, die schon in unserem Artikel zur Projektarchitektur beschrieben ist. Alle Projektbeteiligten konnten so mit einer gemeinsamen Sprache unmittelbar am tatsächlichen Testcode arbeiten. Wir sind überzeugt, dass das insgesamt zur Verbesserung der Kommunikation sowie einem besseren und detaillierteren Verständnis der Anforderungen auf beiden Seiten beiträgt.

Behat-Tests als lebendige Spezifikation

Die einmal erarbeiteten Ergebnisse der Spezifikation bleiben langfristig erhalten. Und zwar nicht als „tote Dokumentation“, sondern als lebendige Beschreibung der Anforderungen, die bei jeder Änderung am System überprüft und ggf. angepasst werden kann.

Im besten Fall sind die Ergebnisse sogar übertragbar, falls die Software einmal vollständig neu oder in einer anderen Programmiersprache implementiert werden müsste: Gherkin an sich ist nicht an eine bestimmte Sprache gebunden. Die Testszenarien könnten daher zumindest prinzipiell auf eine neue Codebasis übertragen werden, sofern nicht auch die Anforderungen grundsätzlich geändert werden.

Alle Teilnehmer:innen tragen dazu bei, diese Meetings möglichst wertvoll zu gestalten. Als Moderator trage ich aber oft eine besondere Verantwortung dafür. Für mich bedeutet das zum einen, dass wir aus Unternehmenssicht wichtige Informationen und Aufgaben abstimmen. Und zum anderen, dass die Teilnehmer:innen das Gefühl haben, dass sie ihre Zeit wertgeschätzt, sinnvoll und möglichst angenehm aufwenden.

Bei beidem hilft es unterm Strich, wenn möglichst viele Teilnehmer:innen ihre Kamera eingeschaltet haben.

Der Vorteil eingeschalteter Kameras: Nonverbale Kommunikation

Bewusst gegebene nonverbale Signale

Durch Gestik und Mimik können Teilnehmer:innen schon während jemand anderes spricht Signale geben: Nicken für Zustimmung, Kopfschütteln für Ablehnung, eine Grimasse für Klärungsbedarf, eine hochgehaltene Kaffeetasse als ELMO-Signal ("Enough, let's move on") und so weiter:

Redner:innen bekommen so unmittelbares Feedback und können darauf reagieren. Sie müssen nicht “auf Verdacht” in die Leere ausgeschalteter Kameras sprechen (was sich für viele sehr merkwürdig anfühlt und Wortmeldungen sogar verhindern kann). Und sie müssen nicht explizit um Feedback bitten, was Meetings anstrengend und langwierig machen kann.

Zum Vergleich:

In welcher Situation würdest Du Dich als Sprecher:in wohler fühlen?

Eingeschaltete Kameras zeigen aber noch mehr als die bewusst gegebenen nonverbalen Signale, nämlich:

Unbewusst gegebene nonverbale Signale

Das herzliche Lachen über einen gelungenen Scherz, das kurze gequälte Grinsen nach einem schlechten Scherz - oder die Ungläubigkeit, Betroffenheit und Verärgerung nach einem richtig fies daneben gegangenen Scherz: Das ist spontanes, nicht bewusst gesteuertes, körpersprachliches Feedback, das die Meetings menschlicher macht und allen Teilnehmer:innen hilft, die Stimmung wahrzunehmen und entsprechend zu reagieren.

In meiner Moderator-Rolle suche ich laufend nach weiteren unbewusst gegebenen Signalen, um das Meeting dynamisch zu steuern:

• Schaut jemand verwirrt? Dann kann ich ihm Gelegenheit für eine Frage geben.
• Zögert jemand, sich zu melden? Dann kann ich mir das merken und bei günstiger Gelegenheit nachfragen, ob da noch etwas offen ist.
• Kommt jemand mit seiner Wortmeldung wiederholt nicht durch? Dann kann ich ihm explizit Redezeit einräumen.
• Sehen manche Teilnehmer erschöpft oder genervt aus? Dann kann ich eine Pause anregen.

Selbst neutrale Gesichter sind für mich als Moderator hilfreich:

• Falls alle Zuhörer:innen aufnahmebereit schienen und auf eine Information nicht z.B. mit Verwirrung oder Ablehnung reagiert haben, kann ich davon ausgehen, dass die Information verteilt und angenommen wurde.
• Wenn ich keinen Redebedarf mehr erkenne, kann ich ein Thema schließen und zum nächsten Tagesordnungspunkt übergehen, ohne langwierig bei allen Teilnehmer:innen einzeln die Zustimmung zu holen.
• Falls die Gesichter zu lange neutral bleiben, kann ich mich fragen, ob das Meeting zu passiv geworden ist und es durch Interaktion auflockern.
• Falls eine einzelne Person länger ein neutrales Gesicht behält und sich nicht zu Wort meldet, kann ich gezielt im oder nach dem Meeting nachfragen, ob sie vielleicht gar nicht in diesem Meeting (bzw. weiteren dieser Art) sein möchte.

Und sogar, wenn das Kamerabild nur einen leeren Stuhl zeigt, hilft mir das als Moderator mehr, als gar keine Bildübertragung zu haben. Denn dann wissen alle Teilnehmer:innen, dass jemand das Gespräch gerade nicht mitbekommt oder zumindest nicht reagieren kann - und wann die Person zurückkommt.

Wenn eingeschaltete Kameras so viele Vorteile haben: Sollten Teilnehmer:innen ihre Kameras dann einfach immer einschalten?

Nein. Denn eingeschaltete Kameras haben auch Nachteile. Und die wollen wir nur in Kauf nehmen, wenn die Vorteile überwiegen. Das ist keine triviale Abwägung, zumal hier eine persönliche Komponente drinsteckt. Deshalb haben wir uns darüber ausgetauscht, was für uns gute und schlechte Gründe für ausgeschaltete Kameras sind.

Gute Gründe für ausgeschaltete Kameras

Kleingruppen

Wenn die Anzahl der Teilnehmer:innen klein genug ist, kann es ihnen ausreichen, ihr Mikrofon laufend ein- und die Kamera ausgeschaltet zu lassen. Bei zwei Teilnehmer:innen ist das wie in einem klassischen Telefonat, in dem sie beispielsweise durch Geräusche wie “hm” je nach Intonation verschiedene Signale senden können.

(Ab etwa 4 Personen lassen wir zur Vermeidung von Störgeräuschen das Mikrofon oft aus bzw. schalten es nur für unsere Redezeit ein. Ab diesem Zeitpunkt wird es für die nonverbale Kommunikation dann wichtig, die Kameras einzuschalten.)

Screensharing-Themen

Wir haben häufiger Meetings zur Arbeit an konkreten technischen Problemen, beispielsweise beim Pair Programming. Da ist uns Screensharing dann wichtiger als Mimik und Gestik. Die kann sogar ablenken und stören, weil der Bildschirmplatz und vor allem unsere Aufmerksamkeit und Konzentration begrenzt sind.

Im Gegensatz dazu empfiehlt Adrian Bolboacă in seinem Buch “Practical Remote Pair Programming” ein Setup mit mehreren Monitoren inklusive Video-Feed. Vielleicht fühlt sich das für uns nicht wichtig an, weil wir schon ein eingespieltes Team sind.

Ablenkende Bewegungen

Irgendwas müssen wir in unseren Meetings richtig machen: Denn obwohl sie nicht verpflichtend sind, nehmen manche von uns gelegentlich sogar von unterwegs teil.

Wenn sie oder der Hintergrund sich in ihrem Kamerabild zu stark bewegen und dadurch andere Teilnehmer:innen ablenken würden, schalten sie ihre Kamera nur während ihrer Redezeit ein - wenn überhaupt.

[video id="10265" caption="Ein unruhiger Hintergrund kann leicht ablenken" aspect-ratio="9/16" autoplay="true" loop="true"]

Zoom Fatigue

Insbesondere lange Videokonferenzen können uns belasten, geistig und körperlich erschöpfen: die sogenannte Zoom Fatigue. Jeremy Bailenson bietet interessante mögliche Erklärungen für die Ursachen - und legt Ideen nah, mit denen wir uns davor schützen können. Ein paar davon greife ich hier auf und ergänze sie um unsere Erfahrungen.

Zum Ersten könnten wir den Stress der konstanten Selbstbewertung reduzieren, indem wir das eigene Bild im Meeting ausblenden. Wobei mir persönlich diese Idee nicht hilft: Denn ich empfinde das Ausblenden des eigenen Bildes eher als stressigen Kontrollverlust. Tatsächlich mochte sich niemand in unserem Team mit der Idee anfreunden - aber es mag Menschen geben, denen das hilft.

Zum Zweiten müssen wir uns nicht selbst im frustum einsperren. Das Wort musste ich erst nachschlagen: englisch für Kegel- oder Pyramidenstumpf. Hier meint es den von der Kamera erfassten 3D-Ausschnitt, in dem man sich aufhalten muss, um das Bild nicht zu verlassen. Hat etymologisch also nichts mit Frust zu tun, aber als Eselsbrücke reicht's: Sperren wir uns nicht selbst im Frustraum ein.

Bewegen wir uns ein bisschen! Ich habe nachgefragt: Keine:n von uns stört es, wenn jemand anderes in unseren internen Meetings beispielsweise die Arme hinter dem Kopf verschränkt, sich auf einer Couch lümmelt oder mal die Füße hochlegt und sie dabei in die Kamera hält.

Ebenso wenig stört uns ein bisschen geistige Bewegung. So, wie wir in vor-Ort-Gesprächen den Blick mal schweifen lassen oder etwas kritzeln, können wir das auch in remote Team-Meetings tun. Mein Lieblings-Blickfang ist mein Hund, den ich auch zwischendurch gerne streichle, um die Gedanken kurz zu lösen.

Manche von uns haben gefühlt 90% der Zeit an der Kamera vorbei geschaut: Sie haben die Laptop-Kamera zur Aufnahme benutzt, die Videos der anderen aber auf einem externen, größeren Monitor im Blick behalten. Auch solche hohen an-der-Kamera-vorbei-schauen-Anteile haben uns nicht unmittelbar gestört. Seitdem wir darüber gesprochen haben, haben sich aber schon mehrere Kollegen externe Kameras gekauft und auf ihrem externen Monitor platziert, um leichter Blickkontakt halten zu können. (Solche Käufe sind bei uns zum Glück ganz unbürokratisch - jeder kann einfach die Firmenkreditkarte nutzen.)

Zum Dritten können wir bei unserer Meeting-Kultur ansetzen. Wir können die Anzahl, Dauer und den Teilnehmerkreis der Meetings gering halten, in dem wir:

• möglichst viel asynchron regeln
• möglichst viel im kleinen Kreis (gegebenenfalls zu zweit) regeln
• Team-Meetings freiwillig machen
• Team-Meetings gut vorbereiten - vor allem die Agenda im Vorfeld bekanntgeben, so dass jede:r Gelegenheit hat, sich inhaltlich vorzubereiten. Ich habe den Eindruck, dass sich jede Minute zur Vorbereitung vielfach im Meeting auszahlt.
• regelmäßige Pausen während der Team-Meetings einlegen. Wenn wir erwarten, dass ein Meeting insgesamt länger als eine Stunde dauert und wir aktuell noch mehr als zwanzig Minuten vor uns haben, legen wir oft alle 25-30 Minuten eine 5-minütige Pause ein. Selbst, wenn sich das manchmal wie eine Zwangspause anfühlt und man doch eigentlich noch weiter reden könnte, hilft es, in der Pause aufzustehen und sich ein bisschen zu bewegen, um mit frischem Kopf weitermachen zu können.
• darüber reden, wenn etwas an der Meeting-Kultur für uns nicht passt, und nachsteuern.

Individuelle Gründe

Wenn sich jemand unwohl fühlt und nur noch kurz etwas übergeben oder sich vom Team ins Krankenbett verabschieden möchte, braucht er oder sie sich dafür natürlich nicht vor der Kamera zu präsentieren.

Es gibt sicher noch weitere gute individuelle Gründe, Videokameras auszuschalten. Beispielsweise können neurodivergente Personen Videokonferenzen als Reizüberflutung wahrnehmen und dadurch beeinträchtigt werden. Ich versuche gar nicht erst, eine Liste der guten individuellen Gründe zu erstellen. Ich versuche lieber, im Zweifelsfall zuzuhören und ins Gespräch zu kommen.

Schlechte Gründe für ausgeschaltete Kameras

In unserem Austausch zu den Gründen ausgeschalteter Kameras haben wir nur einen “schlechten” Grund ausgemacht: Der Kollege nutzte seinen Laptop zugeklappt und hatte nur die darin eingebaute Kamera zur Verfügung. Ihm war gar nicht bewusst, dass wir sein Bild häufiger vermissten - und hat dann gleich angeboten, seinen Laptop häufiger aufzuklappen oder eine externe Kamera zu verwenden.

Wenn jemand die Kamera ausgeschaltet hat…

… begrüßen wir es, wenn die Person auch außerhalb ihrer Redezeiten Signale gibt, beispielsweise durch:

• die Melden-Funktion
• Emoji-Reaktionen
• kurze Chat-Nachrichten:
  • “+1” für Zustimmung
  • “-1” für Ablehnung
  • “/” für Gleichgültigkeit
  • “?” für Fragen
  • “brb” für “be right back”
  • “re” für “returned”
  • ...

Schlussgedanken

Wir haben alle schon im Vorfeld ein ganz gutes Gefühl dafür, wie wichtig die visuelle nonverbale Kommunikation für ein Team-Meeting wird. Wenn wir über soziale Themen oder auf konzeptueller Ebene in größerer Runde miteinander sprechen wollen, ist “Kamera an” unser Default. Wenn wir zu zweit oder dritt oder über ein Screensharing-Thema sprechen wollen: “Kamera aus”.

Für die “Kamera an”-Team-Meetings nutzen wir Google Meet, für die “Kamera aus”-Meetings Slacks Huddle als Konferenztool. Wenn wir auf einer dieser beiden Plattformen zu einem Meeting einladen, kommunizieren wir also implizit schon eine Erwartung an die Kameras. Wenn sich im Laufe eines Meetings das gewählte Tool nicht mehr richtig anfühlt, wechseln wir einfach auf das andere.

Als wir das Thema für uns aufgearbeitet haben, stand die Frage im Raum, ob wir uns Regeln für die Nutzung der Kameras geben wollen. Ich selbst hatte eingangs damit geliebäugelt, mich dann aber vom Gegenteil überzeugen lassen und am Ende lautete die einhellige Antwort “Nein”. Wir glauben nicht, dass starre Regeln hier sinnvoll sind.

Schon durch die Besprechung der Problematik haben wir unser Bewusstsein dafür geschärft, unser gegenseitiges Verständnis ausgebaut und sind aufeinander zugegangen. Auch das ist für mich Teil unserer Gesprächskultur - und damit ein Grund, weshalb wir immer noch gerne remote, erfolgreich und vor allem gerne zusammen arbeiten.
 

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 2014 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.

Weitere Blogbeiträge zum Thema Projektorganisation

• Agile Softwareentwicklung in kleinen Projekten
• Wie wir Behat-Tests zur Spezifikation und Qualitätssicherung in Projekten einsetzen
• Kamera an oder aus in remote Team-Meetings? Kommt drauf an!

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)