Den restlichen Tag über war damals die Stimmung im Büro etwas gedrückt – oder vielleicht kam es mir auch nur so vor. Ursprünglich hatten wir jedenfalls vorgehabt, um die Mittagszeit herum bereits nach Hause zu gehen, aber dann zogen sich die vorher noch zu erledigenden Arbeiten doch noch über den Tag – und fast schon schien es, als ob mindestens Einzelne nicht so richtig bereit waren, Abschied zu nehmen. Zu diesem Zeitpunkt war uns vermutlich allen schon bewusst, dass wir uns auf lange Sicht nicht mehr so persönlich begegnen würden, wie noch an diesem Tag. Das Wort „Monate“, schwebte auch da schon im Raum. 

Viel vorzubereiten hatten wir im Grunde genommen nicht. Wir machten uns Gedanken darüber, wie die Pflanzen in unserer Abwesenheit versorgt werden, dass wir unseren wöchentlich gelieferten Obstkorb abbestellen müssen und sprachen darüber, dass man zumindest ab und an irgendwie nach der Post sehen müsste. Wir legten einige grobe Regeln für die zukünftigen Arbeitstage fest: Dass sich jeder von uns bis 09:45 Uhr täglich via unserem Arbeits-Chat auf Slack melden würde, zum Beispiel. Dann richteten wir auf den Computern noch Möglichkeiten zum Screensharing ein und viel mehr war dann auch gar nicht mehr zu tun. 

Seit dem 10. März diesen Jahres haben wir uns also nicht mehr persönlich gesehen. Viele Wochen sind seitdem vergangen und somit ist es an der Zeit, einmal über unsere Erfahrungen zu berichten: Wie leicht gelang uns der Übergang von Präsenz- zu remote-Firma? Wie geht es uns insgesamt mit dieser neuen Arbeitssituation? Und: Wird dieses unfreiwillige Experiment unsere zukünftige Zusammenarbeit verändern?

Um ein genaueres Bild von der Stimmung und den Meinungen im Team zu bekommen, haben wir mittels Google Forms eine kleine Umfrage durchgeführt. Schauen wir uns die Daten doch nun einmal im Detail an:

In Abbildung 1 sehen wir, dass der Übergang ins Homeoffice einigen im Team gar keine Probleme bereitet hat („die Umstellung aufs Homeoffice ist mir schwer gefallen“), aber die Empfindungen diesbezüglich durchaus gemischter Natur waren. Dass uns als Firma insgesamt der Übergang gut gelungen ist, scheinen allerdings alle (antwortenden) Teammitglieder so zu sehen („die Umstellung aufs Homeoffice hat insgesamt für die Firma gut funktioniert“). Ebenso sehen wir hohe Zustimmungswerte bei „Im Homeoffice kann ich mich gut konzentrieren" (schlechtere Werte wurden vom Team teilweise durch die problematische Kinderbetreuungssituation begründet) und „Ich finde, die Kommunikation untereinander funktioniert auch von zu Hause aus gut“. 

Dennoch vermisst ein Großteil der Antwortenden den direkten Kontakt untereinander, wie Abbildung 2 zeigt („Ich vermisse den direkten Kontakt zu meinen KollegInnen“). Überraschend gespalten ist das Team bei dem (nicht ganz ernst gemeinten) Thema: „Ich vermisse die Kaffeemaschine im webfactory-Büro“. Auf Rückfrage erklärten sich einige damit, dass der Kaffee zuhause eben auch recht gut wäre. Na ok. Das können wir wohl so akzeptieren. Das Büro an sich wird dann scheinbar sogar noch weniger vermisst, als die Kaffeemaschine („Ich hoffe, dass wir bald alle wieder ins Büro zurückkehren werden“). Ein spannendes Ergebnis: Niemand scheint so richtig dringend wieder das Homeoffice verlassen zu wollen. Besonders toll auch: Das Vertrauen, dass wir ineinander haben, denn bei: „Ich vertraue meinen KollegInnen/MitarbeiterInnen, dass sie auch im Homeoffice gute Arbeit leisten“, erzielen wir durch die Bank sehr hohe Werte. 

Besonders auffällig: Bei fast allen haben sich im Homeoffice die Arbeitszeiten geändert (Abb. 3) und der Großteil von uns hat sogar die persönliche Meinung zum Thema „Arbeiten im Homeoffice“ geändert (Abb. 4). Auf Rückfrage erklärten manche Kollegen, dass sie nicht damit gerechnet hätten, dass es so gut laufen würde, oder dass sie sich im Homeoffice so gut würden konzentrieren können. Ein einzelner (ehemaliger) Homeoffice-Gegner hat seine ablehnende Haltung zum Thema sogar mittlerweile vollkommen revidiert. Positiv heben einige im Team hervor, dass sie sich ihre Arbeitszeit freier einteilen können. Somit fangen manche Eulen beispielsweise später an zu arbeiten (die obligatorische Meldung bis 09:45 Uhr im Teamchat hatte sich dann auch innerhalb von Tagen ganz automagisch erledigt), andere fangen früher an oder machen zwischendurch lange Pausen. Als Schattenseite davon merken Einzelne allerdings an, dass sich der Arbeitstag dadurch insgesamt in die Länge zieht und mindestens einem fällt es zumindest zeitweise schwer, einen Absprung zu finden. 

Insgesamt zeigt sich nach den letzten Wochen aber, dass wir erstaunlich gut mit der veränderten Situation zurechtkommen. Ich persönlich gehe davon aus, dass dieses Erlebnis unsere Arbeitsweise langfristig beeinflussen wird, auch wenn sich noch zeigen muss, wie unsere Zukunft im Detail aussehen wird. Manche Teammitglieder wünschen sich, zumindest ab und an, die Möglichkeit, die KollegInnen auch einmal wieder persönlich zu sehen oder ihre Arbeit im Büro zu verrichten. Andere träumen bereits davon, die Welt zu bereisen und von Unterwegs zu arbeiten oder haben für sich festgestellt, dass sie eigentlich gar nicht mehr so richtig ins Büro zurückkehren wollen und der eingesparte Pendelweg eine echte Erholung ist. Auch die Möglichkeit full-remote Kräfte einzustellen, scheint nun nicht mehr ganz fern jeglicher Vorstellung zu sein. Abbildung 5 zeigt allerdings, dass sich so ganz konkret doch niemand vollständig vom Büro distanzieren möchte. Entsprechend nicht ganz ernst gemeint, wurde sogar hier und da schon diskutiert, ob wir das Büro überhaupt noch brauchen. In guter Gesellschaft wären wir mit einer (optionalen) full-remote Firma zumindest: die bekannte social media Plattform Twitter hat bereits angekündigt, nicht mehr zu ihrer vorherigen Präsenzkultur zurückkehren zu wollen.

Diese Snapshots werden nach einer gewissen Zeit automatisch ausgedünnt, und zwar nach folgenden Regeln:

• Für 48 Stunden behalten wir alle Backups
• Zusätzlich für die letzten 7 Tage ein Backup pro Tag
• Zusätzlich für die letzten 4 Wochen ein Backup pro Woche
• und für die letzten 6 Monate ein Backup pro Monat

Eine ausführlichere (englische) Dokumentation der Löschregeln findet sich auf der Website des von uns genutzten Tools alestic/ec2-expire-snapshots (unsere Konfiguration: --keep-first-hourly 48 --keep-first-daily 7 --keep-first-weekly 4 --keep-first-monthly 6).

Bei der Kalkulation des Preismodells haben wir unverändert drei Hauptziele:

In erster Linie wollen wir die Kosten von Amazon Web Services möglichst genau abbilden. Einkaufs- und Verkaufspreise sollen in einem vernünftigen und nachvollziehbaren Verhältnis stehen.

Zusätzlich zu den Einkaufspreisen bei Amazon Web Services muss aber auch unser eigener Entwicklungs- und Pflegeaufwand für unsere Hostingarchitektur sowie der Administrationsaufwand für den Betrieb der Server und das Einspielen von Updates angemessen berücksichtigt werden.

Nicht zuletzt soll unsere Preisliste aber auch eine transparente und vorhersehbare Angebotsgestaltung ermöglichen und den Aufwand für die Abrechnung möglichst gering halten. Wir haben uns daher bemüht, Pakete zu schnüren, bei denen möglichst wenig individueller Abrechnungsaufwand entsteht.

Unsere aktuellen Hostingpreise

Alle genannten Preise verstehen sich netto zzgl. der gesetzlichen Umsatzsteuer.

Virtueller Webserver (auf gemeinsam genutztem System)

Eigene Instanzen

Für größere Projekte oder für Kunden, die viele Websites betreiben, bietet sich der Betrieb auf einem eigenen Server an. Wir beziehen dafür von Amazon Web Services individuelle Instanzen in verschiedenen, für das Webhosting optimierten Leistungsstufen. Instanz ist der Amazon-Begriff für einen virtuellen Root-Server.

Alle Instanztypen enthalten bei uns als Inklusivleistungen mehrmals tägliche Backups (Snapshots des Dateisystems), Administration und Betriebsüberwachung (Monitoring).

Zusatzangebote

Weitere Leistungen

Zusätzliche Leistungen bieten wir bei Bedarf individuell an.

Hierzu gehören z. B.

• Nutzung eines zentralen PDF-Servers
• Nutzung eines zentralen Solr-Suchservers
• Betrieb eines PDF-Servers auf eigener Instanz
• Betrieb eines Solr-Servers auf eigener Instanz
• Versand von E-Mail-Newslettern

Bei Fragen zum Preismodell können Sie uns jederzeit via info@webfactory.de kontaktieren.

Steile These

Doch bevor es ins Eingemachte geht, möchte ich erstmal eine These aufstellen: Ich glaube nämlich, ihr habt schon in so vielen Stellenanzeigen (oder Headhunter-Anfragen) von dem „netten und motivierten Team“, mit seinen „tollen Mitgestaltungsmöglichkeiten“, der „Kaffeeflatrate“ und der „mega Familienfreundlichkeit“ bei „super flexibler Arbeitszeit“ und natürlich „total spannenden Projekten“ gelesen, dass euch das nur noch anödet. Hat es eigentlich jemals irgendwen überrascht, dass da nirgendwo steht: „Arbeite in einem Team voller sozialphober Psychopathen an saudrögen Projekten in einem mittelcharmanten Bürogebäude mit schlechter Parksituation und häufigen Überstunden“? Nein? Eben!

Das Problem ist, jedes Mal, wenn ich versuche eine Stellenanzeige für uns zu erfinden, erwische ich mich dabei, wie ich die selben Floskeln zu Papier bringen will und mich darüber ärgere, dass sich das so doof anfühlt, obwohl ich gleichzeitig nunmal finde, dass das bei uns halt nun einmal keine Floskeln sind. Was nicht heißen soll, dass hier ausschließlich, alles immer Tutti-Frutti ist – aber es ist halt auch einfach echt viel echt gut. Schauen wir uns das doch mal im Detail an:

Mitgestaltungsmöglichkeit

Vielleicht ist es untypisch, mit diesem Aspekt einzusteigen, anstatt euch zu erzählen, wie technisch kompetent wir sind – aber dass wir nach 20 Jahren Firmengeschichte nicht total unfähig sind, was unser Fachgebiet angeht, könnt ihr uns an der Stelle vielleicht einfach mal glauben. Viel spannender finde ich aber eben sämtliche „Rahmenbedingungen“, die bei uns so herrschen und die uns meiner Ansicht nach von vielen anderen unterscheiden.

Es gibt irgendwie keine Tabuthemen.

Das Thema „Mitgestaltungsmöglichkeiten“ empfinde ich da für den „wf-spirit“ als ganz zentral. Bei uns kann man nämlich tatsächlich eigentlich alles mitgestalten, was man möchte – oder um es mit den Worten eines Kollegen zu sagen: „Es gibt irgendwie keine Tabuthemen.“ Die webfactory möchte ein Ort sein, an dem Menschen zufrieden und glücklich sind und das lebt sie nicht nur auf dem Papier aus. Es ist nun jedem selbst überlassen, ein Herzensthema aufzumachen bzw. bei einem bereits existierenden Thema „mitzumischen“ und das kann alles mögliche sein: Von technischen Fragestellungen ("Wie können wir unsere Tests verbessern?") über grundlegende Firmenprinzipien ("Wer bekommt wieviel Gehalt und wie entscheiden wir darüber?"), räumlichen Gegebenheiten ("Welche Farbe sollen die Rollos im Wintergarten bekommen?") bis hin zu ganz individuellen Wünschen ("Darf ich einen Hund mit zur Arbeit bringen?") – mir fällt wirklich kein Thema ein, das Tabu wäre, oder grundsätzlich hierarchisch „von oben“ entschieden werden würde. Schreib dir doch einfach mal auf, wie dein ideales Berufsumfeld aussähe oder was du dir alles von deinem Arbeitsplatz wünschen würdest und jetzt stell dir vor, du könntest wirklich versuchen all das zu realisieren. Vielleicht klappt nicht alles immer sofort und auf einmal – auf manche Ziele muss man sicherlich erst hinarbeiten – aber die webfactory versucht immer, alles irgendwie möglich zu machen. Toll, oder?

Handlungsfreiheit und Vertrauen

Gehört ein bisschen zum vorangegangenen Abschnitt dazu, verdient aber eine extra Erwähnung, wie ich finde. Die webfactory möchte nämlich auch ein Arbeitsplatz sein, an dem man vertrauensvoll miteinander umgeht und das geht sogar soweit, dass wir Mitarbeiter*innen frei über die Firmengelder verfügen können. In der Praxis bedeutet das: Grundsätzlich kann jede*r entscheiden, was auf Firmenkosten gekauft werden soll und wir haben vollen Zugriff auf die Kreditkarte, den Paypal-Account und Co. Wenn ich ein neues Buch kaufen möchte, ein tolles Küchengerät oder wenn ich eine Konferenz buchen will (oder zwei oder drei im Jahr…), dann kann ich das einfach tun und muss vorher niemanden um Erlaubnis fragen. Die Regel besagt lediglich, dass man sich selbst überlegen soll, eine andere Person hinzuzuziehen, wenn man das Gefühl hat, dass die geplante Anschaffung so teuer ist, dass man sich alleine mit einer Entscheidung unwohl fühlt. Natürlich funktioniert das Prinzip nur solange, wie wir auch alle verantwortungsbewusst mit dieser Freiheit umgehen – bisher haben wir aber nur positive Erfahrungen damit gemacht. 

Familienfreundlichkeit

Die webfactory ist nicht das erste Arbeitsumfeld, in dem ich mich persönlich bewege und natürlich habe ich mich schon oft mit Freunden aus den unterschiedlichsten Branchen über das Familienthema unterhalten. Ich habe schon selbst beobachtet, wie Verträge schwangerer Frauen rein zufällig nicht mehr verlängert wurden, oder Geschichten darüber gehört, was anderen von ihren Chefs so an den Kopf geknallt wird, wenn sie es wagen, Nachwuchs in die Welt zu setzen. Bei uns hier in der webfactory wiederum waren die beiden (männlichen) Chefs tatsächlich lange Zeit die einzigen mit Nachwuchs und entsprechend auch die einzigen, die aufgrund der Kinderbetreuungsthematik ihre Arbeitszeit reduziert (und ja: dabei auch auf Gehalt verzichtet) haben. Allein das fand ich schon immer bemerkenswert, denn der klassische (männliche) Chef, den man so vor seinem geistigen Auge hat, würde doch niemals weniger als Vollzeit (plus Überstunden, meine ich) arbeiten. Wenn ich also sage, dass die Chefs ihre Arbeitszeit reduziert haben, meine ich damit nicht etwa „von 60 auf 55 Stunden“, sondern eben irgendwo unterhalb ihrer vorherigen Vollzeitstelle. Letztes Jahr ist nun zum ersten Mal ein Mitarbeiter Vater geworden und die Firma hat es ihm sofort problemlos möglich gemacht, seine Arbeitszeit für ein volles Jahr von fünf auf zwei Tage die Woche zu reduzieren. Es ist bei uns auch ganz selbstverständlich, dass jemand früh nach Hause geht, oder spät kommt, oder spontan gar nicht kommt, wenn der Nachwuchs krank ist oder Kindergeburtstag hat, die Neffen und Nichten abgeholt werden müssen oder was-auch-immer. Im übrigen ist es genau so selbstverständlich möglich, der Firma fern zu bleiben, wenn der Hund krank ist – der Luxus beschränkt sich also nicht nur auf menschliche Familienmitglieder. 

Arbeitszeit und Home Office

Aktuell gilt eine 40-Stunden-Woche bei uns als Vollzeitstelle. Ich bin ganz ehrlich: Ich finde das ganz schön lang und nach hinten raus unproduktiv. On the bright side sind wir an dem Thema dran: Wir haben vor einigen Monaten die „Baustelle“ 30-Stunden-Woche-bei-vollem-Lohnausgleich-einführen“ aufgemacht (erwähnte ich schon, dass es bei uns keine Tabuthemen gibt?) und wollen alles dafür geben, diesen Traum zu verwirklichen – nicht nur, aber auch, weil wir uns davon erhoffen, attraktiver für neue Mitarbeiter*innen zu werden. Schon heute steht es jedenfalls jedem frei, seine Arbeitszeit bei gleichzeitigem Lohnverzicht zu reduzieren. Das ist natürlich – ganz klar – vor allem auch eine Frage der finanziellen Machbarkeit. Wiederum sehr positiv zu bewerten ist aber auch aktuell schon die Flexibilität, mit der wir unsere Arbeitszeit einteilen können. Es ist absolut gar kein Problem, wenn man zwischendurch mal einen Arzttermin hat oder zum Friseur geht, mittags ins Schwimmbad fährt oder eine Runde durch die Südstadt joggt (wir haben auch eine schicke, neue Dusche im Büro), mal später kommt, mal früher geht usw. Auch Überstunden sind bei uns tatsächlich praktisch kein Thema. Man munkelt, dass in manch anderer Agentur die Mitarbeiter*innen Extrastunden schieben müssen, wenn die Projektdeadline ins Wanken gerät oder das Budget zur Neige geht. Wir finden das nicht in Ordnung und suchen an dieser Stelle in aller Regel nach anderen Lösungen. Was wiederum Home Office und Remote Arbeit angeht, können wir uns meiner Einschätzung nach noch ein wenig verbessern. Aktuell sehen wir kein Problem darin, wenn jemand einen Home Office Tag pro Woche einlegt (es hat sich irgendwie so eingebürgert, dass das bei allen der Mittwoch ist) aber einige von uns wünschen sich da langfristig noch eine größere Flexibilität und auch die Möglichkeit, längere Zeit Remote zu arbeiten. Grundsätzlich sind wir dem Thema aber offen gegenüber eingestellt und wenn jemand mal wirklich ganz konkrete Bedürfnisse anmeldet, werden wir sicherlich darauf eingehen. Bisher war das im aktuellen Team wohl einfach noch nicht so relevant. 

Total spannende Projekte

Unsere Projekte sind spannend – aber nicht immer. Oder: Es finden nicht immer alle jedes Projekt gleich toll. Ich denke, das ist ganz normal und keine große Überraschung. Was wir aber – glaube ich – alle ganz toll finden, ist die Tatsache, dass wir fast ausschließlich für Kunden aus dem sozialen und künstlerischen Bereich arbeiten (hinter dem Link verbirgt sich eine kleine Auswahl). Das bedeutet, dass wir Websites zu Themen erstellen, mit denen wir moralisch total im Reinen sind, die oft wenig mit der „bösen Welt des Kapitalismus“ zu tun haben und in denen es nicht darum geht, den Nutzer dazu zu bringen, auf möglichst viele Werbebanner zu klicken. Was vielleicht tatsächlich nicht jedem liegt, ist eben jene Form von Agenturarbeit, die wir abdecken. Wir arbeiten nunmal mit Kunden zusammen und nicht an unserem eigenen Produkt. Das heißt, dass wir mit unseren Kunden kommunizieren, interagieren und natürlich auch im alltäglichen Geschäft Support leisten. Unsere Arbeit kann sein, über Monate hinweg ein ganz neues Webprojekt von A bis Z aufzuziehen, aber es gehört auch dazu, das Impressum anzupassen, oder herauszufinden, warum irgendeine Anzeige kaputt ist. 

Das Team

Wir sind echt nett. Wirklich. Kann man nicht anders sagen. Ok, der ein oder andere hat einen wirklich unterirdischen Wortwitzhumor, beim Mittagessen diskutierten wir letztes Jahr überdurchschnittlich oft über den Brexit (ok, die Briten haben das letztes Jahr auch überdurchschnittlich oft versucht), es fällt mal der ein oder andere derbe Spruch (woran ich nicht ganz unschuldig bin) und natürlich merkt man schon, dass man hier mit einem Haufen Nerds (aber dafür ziemlich sozialkompetenten!) zusammenarbeitet. Hast du das jetzt irgendwie anders erwartet? Nee, oder?

Das Miteinander

Unsere Firma ist ein Ort, an dem die Menschen offen und respektvoll miteinander umgehen und auch auf zwischenmenschlicher Ebene zeigt sich, dass es keine Tabuthemen gibt. Wir wissen alle, dass es zum Mensch-sein dazugehört, dass man mal gute und schlechte Tage hat, nicht immer gesund ist und auch das Erleben im Privaten einen Einfluss darauf hat, wie wir uns auf der Arbeit geben und wie produktiv wir sind. Auch hier versucht die webfactory stets den Mensch mit all seinen Bedürfnissen mitzunehmen und soweit wie möglich dazu beizutragen, dass es allen gut geht. 

Kaffeeflatrate und andere Genüsse

Jaaa, wir haben natürlich auch eine Kaffeeflatrate. An dieser Stelle vielleicht tatsächlich erwähnenswert ist die superduper Siebträgermaschine, die wir vor ein paar Monaten gekauft haben (nachdem das ganze Team an einem Barista-Kurs teilgenommen hatte). Ohne Flachs: Ich kann jetzt in Bonn fast nirgends mehr Kaffee trinken, weil er einfach nirgendwo so gut schmeckt, wie in der webfactory. Nebenher bemerkt macht es vielen von uns großen Spaß, inklusive Latte Art so ganz professionell Kaffee zuzubereiten. Abgesehen davon gibt es bei uns Sprudelwasser per Knopfdruck aus der Leitung und wöchentlich einen neuen Obstkorb. Mittags kochen wir reihum im Team und essen gemeinsam – und wer darauf keinen Bock hat, versorgt sich halt anders. Vielleicht steckt auch in uns irgendwo ein kleiner Ökohipster, denn wir bereiten standardmäßig vegetarisches und glutenfreies Essen zu. Fleischesser werden aber dennoch nicht gedisst und insbesondere von den Hunden mit Freude aufgenommen!

Urlaub

Wir haben grundsätzlich 28 Tage bezahlten Urlaub im Jahr, aber on top noch „Sonderfrei“, was ich total toll finde. Das bedeutet, dass wir Rosenmontag (hier im Rheinland feiert man da Karneval) und die Tage von Heiligabend bis Silvester geschenkt bekommen. Unbezahlter Urlaub ist darüber hinaus verhandelbar und in der Vergangenheit auch ab und an schon vorgekommen. Wenn jemand Urlaub nehmen möchte, geht auch das total locker und unkompliziert: Im Prinzip ist jeder angehalten, sich selbst zu überlegen, ob harte Gründe gegen einen Urlaubswunsch sprechen und wenn man findet, dass das passt, kann man ruhigen Gewissens auch schon die Flüge (oder in Zeiten von FFF vielleicht die Zugtickets) buchen und im Nachhinein einfach das Team informieren. Selbst spontane Urlaube waren bisher nie ein Problem und selbst wenn sich herausgestellt hat, dass man bei der eigenen Urlaubsplanung etwas wichtiges übersehen hat („Ach Mist, da ist die Konferenz?“), dann haben wir den Urlaub dennoch immer irgendwie möglich gemacht.

Das Büro

Ist tatsächlich erwähnenswert, weil wir in einem schicken Altbau in der Bonner Südstadt arbeiten dürfen. Das sieht dann auch so aus, wie man sich das vorstellt: Stuck an den Wänden, hohe Decken, Kassettentüren, große Räume und ein wunderschöner Wintergarten. Wir sind erst im September 2019 eingezogen, das heißt, es ist sogar alles noch ganz frisch renoviert! Achja: Außerdem haben wir ein Bällebad!

Willst du auch mal bei uns baden? Dann schau in unsere aktuelle Stellenanzeige und bewirb dich einfach unter: info@webfactory.de 

Hast du noch Fragen? Dann schreib uns unter selbiger Adresse oder komm einfach mal auf einen Kaffee vorbei (eine kleine Vorwarnung wäre hierbei praktisch)!

Wir freuen uns auf dich!

Anlass war die Gehaltserhöhungsanfrage eines Kollegen: Er sei jetzt zwei Jahre im Team und hätte gerne eine Anpassung. Er habe gelernt, dass man regelmäßig fragen muss, weil man sonst gehaltsmäßig abgehängt wird. Wir waren in den 20 Jahren vorher in der komfortablen Situation, nicht häufig mit solchen Fragen konfrontiert worden zu sein. Und wenn doch, haben wir zwei Geschäftsführer über die Anfrage beraten und entschieden. Wir haben nie ein explizites Geheimnis aus Gehältern gemacht, aber sie auch nie aktiv offengelegt.

Zurück zur Gehaltsanfrage des Kollegen. Auch hier habe ich mich mit meinem Co-Geschäftsführer Matthias beraten. Dass wir das Gehalt erhöhen wollten, war schnell klar. Womit wir uns schwer taten, war die Wahrnehmung "wer nicht fragt, wird abgehängt". Das fanden wir nicht fair, zumal wir im Team mehrere Leute hatten, die auch für eine Erhöhung in Frage gekommen wären, aber nicht gefragt hatten. Wie sollten wir nun vorgehen?

• Nur wer fragt, bekommt eine Erhöhung? Das hatten wir schnell ausgeschlossen, es erschien uns unfair und hätte vermutlich dazu geführt, dass über kurz oder lang jeder Kollege regelmäßig nach einer Erhöhung gefragt hätte. Hierzu muss man wissen, dass Gehaltsverhandlungen zumindest bei mir, aber auch bei vielen meiner geschätzten Kolleg*innen weit unten auf der persönlichen Beliebtheitsskala rangieren.

• Wenn eine*r fragt, bekommen alle eine Erhöhung? Das wäre aus unserer Sicht fairer gewesen, denn zumindest hätte es nicht Teammitglieder, die fragen, gegenüber denjenigen bevorzugt, die nicht fragen. Richtig rund fanden wir aber auch diese Lösung nicht ;-)

• Es gibt regelmäßig automatisch Erhöhungen, ohne dass jemand fragen muss? Schon besser. Allerdings war uns klar, dass uns das regelmäßig mit der Frage konfrontieren würde, wer wie viel Erhöhung verdient hat. Und da hatten wir das starke Gefühl, dass wir als Geschäftsführer vielleicht gar nicht den vollen Überblick haben, wer wie viel leistet (z. B. wussten wir, dass es im Team auch Kollegen gab, die sehr geschätzt waren für ihre Hilfsbereitschaft, wenn andere Probleme hatten – sie haben also einen großen Beitrag geleistet, der für uns Geschäftsführer gar nicht direkt sicht- und fühlbar war.)

Der Teamworkshop

Wir haben uns daher entschieden, die Frage nicht alleine, sondern gemeinsam mit dem Team zu beantworten. Dazu haben wir einen ganztägigen Workshop zum Thema Gehälter einberufen.

Als Vorbereitung gab es die erste Gehaltszufriedenheitsumfrage in der Geschichte der webfactory. Über ein Online-Tool (Google Forms) haben wir allen Kollegen anonym folgende Fragen gestellt:

• Wie zufrieden bist du mit deinem aktuellen Gehalt? (1=sehr zufrieden—10=sehr unzufrieden)

• Hast du das Gefühl, dass die Gehälter bei der webfactory fair verteilt sind? (1-10)

• Wie zufrieden bist du mit dem Gehaltsprozess, also dem Weg, wie das Gehalt festgelegt wird? (1-10)

• Gibt es im Gehaltszusammenhang Dinge, die dich bei der webfactory stören?

• Gibt es im Gehaltszusammenhang Dinge, die du bei der webfactory besonders positiv findest?

• Sonstige Wünsche/Fragen/Anmerkungen?

Die Ergebnisse waren überraschend: Die Zufriedenheit mit dem eigenen Gehalt rangierte im Mittelfeld, wobei 2/3 der Antworten im eher positiven Bereich lagen (5 oder besser). In der Frage nach der Zufriedenheit mit dem Gehaltsprozess lagen schon 2/3 der Antworten im negativen Bereich (6 oder schlechter). Die Wahrnehmung der Fairness war sogar noch darunter – 5 von 6 Antworten waren im negativen Bereich. Gerade letzteres hat uns gewundert: Dass die Gehälter in der webfactory nicht hoch waren und die Kollegen damit vielleicht Grund zur Unzufriedenheit hatten, konnten wir uns vorstellen – aber warum wurden die Gehälter als unfair empfunden? Wohlgemerkt: Sie waren noch nicht transparent, d. h. zumindest offiziell wusste niemand, was die anderen verdienen.

Ein perfektes Thema für den Workshop, bei dem wir uns im Anschluss an die Präsentation der Umfrageergebnisse dann intensiv mit der Frage nach der Fairness von Gehältern auseinandergesetzt haben. Folgende Aussagen hatten in der Frage "Was ist fair" hohe Zustimmung im Team:

• Abhängig von der Leistung/dem Wert für die Firma/der Produktivität/der Schwierigkeit der Aufgaben (6x Zustimmung, 1 Gegenstimme)

• Keine Unterscheidung zwischen Ausbildung und Studium bei gleicher Leistung (6x Zustimmung, 1 Gegenstimme)

• Nachvollziehbar, wie das Gehalt festgelegt wird (7x Zustimmung, keine Gegenstimme)

• Nicht abhängig vom Verhandlungsgeschick (8x Zustimmung, keine Gegenstimme)

Die Aussage "Transparenz" als Fairnesskriterium rangierte im Mittelfeld mit 4 Zustimmungen und 2 besorgten Gegenstimmen.

Da die Frage nach der Transparenz der Gehälter eine wichtige Voraussetzung für die weitere Arbeit war und aus unserer Sicht nur im Team entschieden werden konnte, haben wir uns im nächsten Abschnitt des Workshops explizit damit befasst. Bei der Frage nach dem Pro und Contra von Gehaltstransparenz haben wir im Team folgende Punkte zusammengetragen:

• Transparenz könnte Rechtfertigungsdruck auf die Geschäftsführung aufbauen

• Transparenz könnte zu Neid und Frust führen

• Transparenz ermöglicht offene Diskussion

• Wir können ein sensibles, persönliches Thema nicht mehr einfach ignorieren (keiner hatte Lust auf Gehaltsdiskussionen, aber andererseits ist das Gehalt für jeden von uns ein Thema mit großen Auswirkungen)

• Müssen wir dann gleichzeitig auch einen "Prozess" haben?

• Und last but not least: Die Unzufriedenheit ist schon da, sie kann also nicht durch Transparenz erzeugt werden

Insbesondere der letzte Punkt, der ja durch die Zufriedenheitsumfrage belegt war, hat dann in meiner Erinnerung den Durchbruch gebracht: Es bestand plötzlich eine starke Tendenz bei allen, dass wir die Gehälter transparent machen sollten. Aufgrund der Tragweite der Entscheidung haben wir uns aber noch über das Wochenende Bedenkzeit gegeben (der Workshop war am Freitag) und haben am Montag in geheimer Abstimmung entschieden. Das Ergebnis: 7 Ja-Stimmen und eine Enthaltung. Die Gehaltstransparenz war damit besiegelt.

Offenlegung der Gehälter

Noch am Tag der Entscheidung habe ich die aktuellen Gehälter aller Teammitglieder (natürlich inklusive der Geschäftsführung) im webfactory-Wiki veröffentlicht. Mit Blick auf einen angedachten zukünftigen Gehaltsprozess bereits auf der Basis von Stufen anstelle von reinen Euro-Beträgen. Ausgehend von 2.000 € habe ich 15 Stufen berechnet, jede Stufe bedeutete eine ungefähr 9%ige Steigerung zur vorangegangen. Diesen Abstand hatte ich in einer Publikation zum Gehaltsmodell von it-agile als Empfehlung gefunden, einem Beratungsunternehmen, das selbst seit langem ein teamorientiertes Gehaltsmodell hat. Stufe 15 lag bei 6.700 €.

Die neue Wikiseite "Gehälter" enthielt die resultierende Tabelle mit den Gehaltsstufen und eine Zuordnung jedes Teammitglieds zu einer Stufe bzw. teilweise auch zwischen zwei Stufen auf Basis des aktuellen Gehalts. Unsere damaligen Gehälter lagen im Mittelfeld des Spektrums, weder die obersten noch die untersten Stufen waren besetzt.

Im Anschluss haben wir eine zweite Gehaltszufriedenheitsumfage gemacht, mit den gleichen Fragen wie oben, und einem erfreulichen Ergebnis: Die Zufriedenheit sowohl mit den Gehältern als auch mit der Fairness der Gehälter und dem Gehaltsprozess hatte sich insgesamt deutlich verbessert (50% fanden die Verteilung jetzt eher fair und 5/6 waren mit dem Prozess zufrieden) – und das, obwohl wir nichts anderes getan hatten als den Status Quo offenzulegen. Hier kam uns vermutlich zu Gute, dass wir uns auch vor der Transparenz immer schon bemüht hatten, eine faire Einstufung vorzunehmen und darauf zu achten, dass Teammitglieder mit vergleichbarer Leistung auch vergleichbare Gehälter bekamen.

Pendeldiplomatie

Nach der Veröffentlichung war es uns wichtig, mit allen Teammitgliedern Einzelgespräche zu führen, um eine offene Aussprache über wahrgenommene Ungerechtigkeiten und Anpassungsbedarf zu ermöglichen. Wir haben dann in der Geschäftsführung einen Entwurf für eine Korrektur der Einstufung auf Basis des Feedbacks erarbeitet, bei dem einige Kolleg*innen höher eingestuft wurden. Diesen Entwurf haben wir dann erneut mit jedem einzeln besprochen und auf Basis des Feedbacks noch einmal angepasst. Insgesamt war das eine recht zähe Pendeldiplomatie, aber immerhin: Nach zwei Tagen hatten wir eine neue Einstufungstabelle, die die Zustimmung aller Teammitglieder hatte. In einer dritten Umfrage im Anschluss an die Neueinstufung waren dann übrigens 5/6 mit ihrem Gehalt zufrieden und 2/3 fanden die Verteilung fair – 1/3 sogar mit der zweitbesten Note.

Uns war aber klar, dass das noch kein Modell für zukünftige Gehaltsanpassungen sein konnte: Die Beteiligung des Teams hatte den Entscheidungsprozess erstmal umständlicher statt leichter gemacht. Zudem hatten wir noch keine Kriterien für eine Einstufung – diese war rein Bauchgefühl-basiert.

Entwicklung eines Gehaltsmodells

In den folgenden Monaten haben wir uns Gedanken gemacht und recherchiert, wie ein Gehaltsmodell aussehen könnte. Wir brauchten einerseits nachvollziehbare Kriterien für die Einstufung, andererseits sollten diese hinreichend weich und offen sein, um nicht falsche Anreize zu setzen. Ein plastisches Beispiel hat mir Henning Wolf beschrieben, einer der Gründer und langjähriger Geschäftsführer von it-agile:

Wir hatten mal sowas wie einen Kriterienkatalog, z. B. konnte man eine damals „Senior-Berater" benannte Stufe nur erreichen, wenn man schon mal einen Konferenzvortrag gehalten hat. Das führt aber zu komischen „Checklisten“-Karrieren und nicht zu guten Vorträgen. Deshalb haben wir keine festen Kriterien, sondern Themenbereiche, in denen wir die Kollegen relativ zu einander bewerten. Am Ende geht es um sowas wie den „Wert oder Nutzen für das Unternehmen“ im Verhältnis zu anderen Kollegen.

In einem weiteren Teamworkshop haben wir daher gemeinsam Themenbereiche gesammelt, die man für einen Vergleich zweier Kollegen untereinander heranziehen kann. Diese Liste ist eine Art Brainstorming-Ergebnis, wir haben im Grunde alle genannten Punkte aufgenommen. Die Liste ist aber auch nicht abschließend – sie soll vor allem Anhaltspunkte geben. Sie enthält folgende Punkte:

• Kundenorientierung

• Verantwortungsübernahme

• Erfolg und Wertschöpfung

• Technisches Know-How/Skills

• Schwierigkeit der Aufgaben

• Motivation und Einsatz

• Teamfähigkeit, soziale Kompetenz

• Pragmatismus und "Dinge-auf-die-Straße-bringen"

• Vielseitigkeit

• Marktwert

• Formale Qualifikationen

Auf Basis dieser Liste wäre es nun also möglich, zu sagen: Kollege B bekommt ein um eine Stufe höheres Gehalt als Kollegin A, weil beide in den meisten Kriterien gleich abschneiden, aber B eine deutlich höhere Kundenorientierung hat. Oder: A und B sind auf der gleichen Stufe, weil B zwar eine höhere Kundenorientierung hat, aber A schwierigere Aufgaben übernimmt.

Gehaltserhöhungen

Die Vergleichskriterien schienen uns sinnvoll, ließen aber eine Frage unbeantwortet: Wie berücksichtigen wir, dass jedes Teammitglied sich weiterentwickelt? Wie reduzieren wir langfristig Anpassungsbedarf in der Einstufung? Anlass für unseren Einstieg in das Gehaltsprojekt war ja der berechtigte Wunsch eines Kollegen nach einer Gehaltserhöhung nach 2 Jahren Betriebszugehörigkeit. Unsere Sorge war: wenn wir einfach nur bei der Stufentabelle und dem Kriterienkatalog bleiben, wird es regelmäßig ein Wettrennen um Neueinstufungen geben – in einem als fair empfundenen Ausgangsgefüge reicht es, wenn ein Teammitglied sagt, dass es eine Erhöhung möchte, um einen Anpassungsbedarf bei allen anderen zu erzeugen, bis jede*r eine Stufe höher geklettert ist.

Um diesen Effekt und die erwarteten unangenehmen Diskussionen zu vermeiden, haben wir eine automatische Anpassung in unser Gehaltsmodell integriert: Einen prozentualen Aufschlag für die Dauer der Betriebszugehörigkeit. Nach unseren Erfahrungen steigt der Wert einer Mitarbeiterin für die Firma mit der Zeit stark an – zum einen, weil sie sich selbst fachlich und persönlich weiterentwickelt, zum anderen, weil sie die Firma und ihre Kunden und Projekte besser kennenlernt. Unsere Inspiration war hier Buffer, ein Startup, das jedem Mitarbeiter 5% Aufschlag für jedes Jahr Betriebszugehörigkeit zahlt (https://open.buffer.com/transparent-salaries/). Wir sind etwas niedriger eingestiegen, zumal wir den Loyalitätsbonus natürlich auch für die bestehenden Kollegen einführen wollten. Und da Matthias und ich bereits 20 Jahre im Unternehmen waren, hätten wir 100% Aufschlag nicht als fair empfunden und es hätte uns auch finanziell überfordert. Unser Modell sieht 4% Gehaltssteigerung für die ersten 5 Jahre vor, 2% mehr für jedes weitere Jahr bis zum 10. Jahr, und 1% pro Jahr darüber hinaus.

Dennoch gibt es natürlich ab und zu auch das Bedürfnis nach einer Neueinstufung – alleine schon bei neuen Teammitgliedern, mit denen wir während der Probezeit lieber eine vorsichtige Einstufung vereinbaren, die dann am Ende der Probezeit überprüft wird.

Der Prozess für Neueinstufungen

Für uns war klar, dass der Prozess für Neueinstufungen teambasiert sein muss – sonst hätte es potenziell bei jeder Einstufungsänderung Unzufriedenheit oder Diskussionen im Anschluss gegeben. Daher setzen wir folgendes Verfahren ein:

Wenn ein Teammitglied auf eine neue Gehaltsstufe wechseln möchte, stellt es bis zum Ende der ersten vollen Arbeitswoche des Jahres einen "Antrag" – konkret eine Mail an die Geschäftsführer mit der gewünschten neuen Stufe und einer Begründung auf Basis des Gehaltsmodells. Diese Begründung wird, wieder in Form einer anonymen Online-Umfrage, an das Team weitergegeben. Hierzu stellen wir folgende Fragen:

• Ich bin für folgende Einstufung (Auswahlliste mit allen Gehaltsstufen)

• Anmerkung/Begründung dazu

• Gibt es sonstige Personen, die aus meiner Sicht höhergestuft werden müssten?

• Gibt es Personen, die aus meiner Sicht zu hoch eingestuft sind?

• Ist das resultierende Gehaltsgefüge (wenn die Entscheidungen in meinem Sinne fallen) insgesamt fair? Wenn nicht, was müsste sich ändern?

• Was ich sonst noch sagen wollte (freies Bemerkungsfeld)

Wichtig ist uns dabei, dass mit jeder Neueinstufung auch noch einmal mit dem gesamten Team die Fairness des Gesamtgefüges abgestimmt wird.

Auf der Basis der Umfrage entscheidet dann die Geschäftsführung über die Einstufung. Aus unserer Sicht kann die Entscheidung auch an andere Personen delegiert werden (ein "Gehaltschecker"-Gremium), aber das ist vielleicht eine zukünftige Ausbaustufe.

Berufserfahrung: eine offene Flanke

Wir haben das Gehaltsmodell bewusst so konstruiert, dass wir regelmäßige Gehaltserhöhungsanfragen unnötig machen. Das erreichen wir wie beschrieben über den Betriebszugehörigkeitsbonus, der den Zuwachs an Produktivität sowohl durch hinzugewonnene Berufserfahrung und Fachwissen als auch durch bessere Kenntnis der Fima und ihrer Kunden abbilden soll.

Eine Schwierigkeit besteht aus meiner Sicht noch darin, dass Berufserfahrung, die innerhalb der webfactory gesammelt wird, damit anders bewertet wird als Berufserfahrung, die vorher gesammelt wurde (die muss folglich durch die Gehaltsstufe abgebildet sein). Nehmen wir an, ein Entwickler mit Uniabschluss steigt mit 2 Jahren Berufserfahrung in der webfactory auf Stufe 8 ein. Nach 5 Jahren bei uns hat er auf der gleichen Stufe einen Betriebszugehörigkeitsbonus von 20%, also das Äquivalent von zwei Gehaltsstufen mehr als beim Einstieg. Wenn eine Kommilitonin von ihm, die gleichzeitig ihren Abschluss gemacht und in den 5 Jahren woanders gearbeitet hat, zur webfactory wechselt, müsste sie auf Stufe 10 einsteigen, wenn sie annähernd das gleiche Gehalt bekommen sollte (tatsächlich wären es dann sogar noch 30 € weniger). Mein Eindruck ist aber, dass die Gehaltsstufen unweigerlich auch mit Rang- oder Wertigkeitsstufen assoziiert werden. Selbst wenn die neue Kollegin "nur" auf Stufe 9 einsteigen würde und damit ein um knapp 9% geringeres Gehalt akzeptieren würde als ihr Kommilitone, würde es für ihn doch leicht so aussehen, als sei er mit Stufe 8 weniger wert als sie.

Hier glaube ich, dass vielleicht noch ein Baustein fehlt, der dieses Problem vermeiden hilft.

Mein Fazit

Die Gehaltstransparenz hat sich seit Tag 1 richtig angefühlt. Ich glaube, niemand von uns kann sich mehr vorstellen, die Gehälter wieder geheim zu halten. Insbesondere die offenen Gespräche über faire Gehälter wären ohne Transparenz nicht möglich.

Das Gehaltsmodell mit der Kombination aus automatischen und anlassbezogenen Erhöhungen hat sich seit nunmehr drei Jahren in allen Situationen bewährt. Durch seine Offenheit und das Fehlen von harten Kriterien ist die Einstufung zwar manchmal schwierig und natürlich subjektiv, aber da das ganze Team gehört wird, nicht willkürlich. Gerade diese Flexibilität ermöglicht es uns auch, jedem Einzelfall gerecht zu werden.

Insgesamt ist es recht ruhig um das Thema, was für mich auch bedeutet, dass das Modell hinreichend gut funktioniert und wir uns anderen Baustellen widmen können.

Gerade letzte Woche haben wir übrigens zum ersten Mal seit der Einführung des Modells die Gehaltsstufen inflationsbasiert angepasst, was für jeden eine zusätzliche Gehaltserhöhung von 4,78% bedeutete.

When staging a project to run tests or build a Docker image, you might need to fetch additional dependencies (libraries or "vendors") from private repositories. However, GitHub Actions are limited to accessing the repository they run for.

To solve this, you can create an additional SSH key with sufficient access privileges. Store that key in the secrets storage which is in the "Settings" area of your repository. The secret content is the private SSH key, as you will find it in the id_rsa file.

For the following example, the name of the secret should be SSH_PRIVATE_KEY.  Then, have a look at the following workflow definition:

# .github/workflows/my-workflow.yml
# ... other config here
jobs:
    build:
        runs-on: ubuntu-18.04
        steps:
            -   uses: actions/checkout@v1

            -   name: Setup SSH Keys and known_hosts
                env:
                    SSH_AUTH_SOCK: /tmp/ssh_agent.sock
                run: |
                    mkdir -p ~/.ssh
                    ssh-keyscan github.com >> ~/.ssh/known_hosts
                    ssh-agent -a $SSH_AUTH_SOCK > /dev/null
                    ssh-add - <<< "${{ secrets.SSH_PRIVATE_KEY }}"

            -   name: Some task that fetches dependencies
                env:
                    SSH_AUTH_SOCK: /tmp/ssh_agent.sock
                run: ./fetch-deps.sh

We first run ssh-keyscan to detect GitHub's SSH host keys. This for sure could be improved if worker nodes had these keys already set up. We then start the ssh-agent , binding it to a predictable socket location, and finally import the SSH private key into the agent. The nice thing about the way this happens is that the private key is never written to disk.

After the setup step has run, the SSH agent will still be running and can be used by other processes. To make this happen, set the SSH_AUTH_SOCK environment variable. Commands like git run ssh under the hood and will make use of the key stored in the agent when they authenticate to other hosts.

Right now, you will have to set the environment variable for every step that needs it, but it looks as if an improvement for this is already underway. 

Where to register the public SSH key part?

To actually grant the SSH key access, you can – on GitHub – use at least two ways:

• Deploy keys can be added to individual GitHub repositories. They can give read and/or write access to the particular repository. When pulling a lot of dependencies, however, you'll end up adding the key in many places. Rotating the key probably becomes difficult.
• A machine user can be used for more fine-grained permissions management and have access to multiple repositories with just one instance of the key being registered. It will, however, count against your number of users on paid GitHub plans.

class Order
{
    const PRIORITY_NORMAL = 'normal';
    const PRIORITY_HIGH = 'high';

    // ...
}

A method accepting one of these constants usually looks like this:

class Order
{
    /**
     * Create a new order instance
     */ 
    public static function place(ItemList $items, string $priority): self
    { ... }
}

Problems with the scalar-typed approach

Although there are two special string values defined as the two constant values in the above example, clients of this method may pass in literal string values (a plain  'normal'  or  'high' ) directly. For example, this may happen if they are taking the value directly from request parameters, which obviously is a risky practice.

In general, as the  Order::place()  method above accepts a string, nothing prevents you from passing in arbitrary string values.

Another possible mistake is that parameter order is messed up and arbitrary values are passed in places where constant values are expected.

To make your software design robust, defensive and fail-fast, in the above example you should check that the  $priority is indeed one of the available priorities.

As you can imagine, this can quickly get impractical when the constant values are used a lot and passed on between methods, as each method would need to check them again and again. Adding a new constant value would also require you to update all those checks.

When working with  int  constants ( 0, 1, 2, ... ), the mistake of messing up the parameter ordering might be so subtle that you cannot catch it by checking the parameter value.

Constant value objects

So, here is another way how we can design this. I will be building upon two OOD concepts:

• Value objects describes the approach of modelling plain values as objects.

• Often, it is benefical as well to design such objects as being immutable.

You can find valuable chapters on both ideas in Eric Evans' book "Domain Driven Design".

Bringing both together, we can come up with an  OrderPriorty  class as follows. Let's call this a constant value class:

class OrderPriority
{
    private const NORMAL = 'normal';
    private const HIGH = 'high';

    private $priority;

    public static function NORMAL(): self
    {
        return new self(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return new self(self::HIGH);
    }

    private function __construct($priority)
    {
        $this->priority = $priority;
    }
}

As the  OrderPriority  constructor is private, the only way of creating  OrderPriority  instances is through the static construction methods  OrderPriority::NORMAL()  and  OrderPriority::HIGH() .

We can now write our method as

class Order
{
    public static function place(ItemList $items, OrderPriority $priority): self
    { ... }
}

Since PHP is type-checking the  $priority  parameter, you can now be sure you're dealing with some kind of  OrderPriority . Without further checks or safeguards, the  place(...)  method can now be sure that  $priority  is one of the valid priority levels.

There is one required change for clients passing in one of these values: Instead of writing  Order::PRIORITY_NORMAL  or  Order::PRIORITY_HIGH , we will now use  OrderPriority::NORMAL()  or  OrderPriority::HIGH() . This is necessary to create the instances of our constant value class.

Note that I chose to name these methods all caps to resemble the convention of constant identifier naming.

Checking for constant values

When checking a parameter like  $priority  for one of the constant values, we can write the check as  $priority == OrderPriority::HIGH() . This already works for the  ==  loose comparison since the values of both constant class instances – the one in  $priority  and the one created on the fly – are the same.

As a cautious programmer, however, you're probably using the strict comparison operator  ===  whenever possible. With a constant value class as shown above, this will not work, since this operator also checks for object identity and we're using two different object instances.

So, let's fix that.

Using flyweights

The Flyweight is a structural pattern from the classic "Gang of Four" book. Part of the pattern is the idea to re-use object instances when they don't differ in state, which is perfect for our immutable constant values.

Also described in the pattern is the need to have some kind of factory to obtain flyweight object instances without creating them again and again.

So, let's add a new method to our class that takes care of this. We'll call it  constant()  since it returns the constant value object instance for a given value.

This method will be  private  as well, so clients still have to use the construction methods ( OrderPriority::NORMAL()  and  OrderPriority::HIGH() ) as before.

class OrderPriority
{
    private const NORMAL = 'normal';
    private const HIGH = 'high';

    private static $instances = [];

    private $priority;

    public static function NORMAL(): self
    {
        return self::constant(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return self::constant(self::HIGH);
    }

    private static function constant($value)
    {
        return self::$instances[$value] ?? self::$instances[$value] = new self($value);
    }

    private function __construct($priority)
    {
        $this->priority = $priority;
    }
}

Now, for every different constant value, only one single object instance will be created. The same instance will be returned for every call to methods like  OrderPriority::NORMAL() . And since there is only one instance per value, the  === strict comparison now works.

Constant definitions in interfaces

One tiny drawback of the approach shown above is that you cannot put such constant definitions into interfaces. The approach is based on object instances, which are a runtime concept. Interfaces, however, do not contain implementation code and thus cannot provide the necessary methods.

You can, of course, have a "constant value class" to provide the allowed values and then have your interface use it, for example as part of method signatures.

A nice trait

In our current draft of the  OrderPriority  class, everything besides the actual two constant values and the construction methods is pretty much boilerplate and would be the same for every "constant value class". So, let's move that to a reusable trait:

trait ConstantClassTrait
{
    private static $instances = [];

    private $value;

    final private function __construct($value)
    {
        $this->value = $value;
    }

    private static function constant($value)
    {
        return self::$instances[$value] ?? self::$instances[$value] = new self($value);
    }
}

With this,  OrderPriority  becomes:

class OrderPriority
{
    use ConstantClassTrait;

    private const NORMAL = 'normal';
    private const HIGH = 'high';

    public static function NORMAL(): self
    {
        return self::constant(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return self::constant(self::HIGH);
    }
}

Casting to and from strings

Sooner or later, you might find yourself in a situation where you need to render an HTML form with something like a select list or radio button for an  OrderPriority . Or, you need to accept the  OrderPriorty  from a form or the command line as input.

Since we're now dealing with the  OrderPriority  class, we now have a perfect place to keep such additional methods:

class OrderPriority
{
    // Omitted trait and construction methods (like before)
    
    public static function fromString(string $value): self
    {
        if ($value !== self::NORMAL && $value !== self::HIGH) {
            throw new InvalidArgumentException();
        }
        
        return self::constant($value);
    }
    
    public function __toString()
    {
        return $this->value;
    }
}

You can now easily cast an  OrderPriority  instance to a string, for example when using it as the  <input value="..."> .

Now assume your task is to write the code that accepts a new  Order  from a web request or the command line. At your UI/code boundary, the order priority will clearly be available as a string. The  Order::create()  method, however, needs an  OrderPriority  instance.

Even somebody new to your project will quickly figure out that there are only a few ways to actually create  OrderPriority instances. They will probably find the  OrderPriority::fromString()  method and write code like this:

    // Somehow obtain $itemList
    $order = Order::place($itemList, OrderPriority::fromString($_REQUEST['priority']));
    // ... 

The bottom line is that the way we have written our  Order  and  OrderPriority  classes here makes it almost impossible to use them in a wrong way or to forget checking our inputs.

Even more value object perks

For a moment, assume your business comes up with a requirement to add a new  expedited  priority class. This service level is above the  normal  level, but does not yet make a  high  priority order.

I'll leave it to you as an exercise to add the  EXPEDITED  constant definition, a creation method and to update the  fromString()  method in our  OrderPriority  class.

What is more interesting is that we can now add an additional method to compare two priorities:

class OrderPriority 
{
    // ... as before

    public function atLeast(OrderPriority $other): bool
    {
        // Return true if $this->value is a priority equal to or above $other->value.
    }
}

With this, our new business rule might be something along the lines of

class ShippingFeeCalculator 
{
    public function computeShippingFees(Order $order): Money
    {
        // ...

        if ($order->getPriority()->atLeast(OrderPriority::EXPEDITED()) {
            // ... do what business requested
        }
    }
}

Being a value object, the  OrderPriority  class is a nice place to keep such additional comparison and computation methods which make it even more expressive.

Summary

This article described how simple class constants can be replaced with instances of a "constant value class". Methods that accept such constants can use type hints to make sure only valid constant values can be passed, without having to perform any additional checks. By reusing object instances, comparisons of constant values can also be written using the  ===  strict syntax check, with only minimal changes to code being necessary.

In addition to that, the constant value objects are a great place for keeping a particular kind of business logic.

Eine Anfrage wie diese löst oft widersprüchliche Gefühle aus. Einerseits macht es Spaß, eher obskuren Bugs auf die Schliche zu kommen, andererseits seufzt man innerlich ob der ungewöhnlichen Problematik.

Zum Glück konnten wir das Problem zügig eingrenzen: "Mit deaktiviertem Javascript funktioniert es", schrieb Stefan nach zehn Minuten. Einige Zeit später war klar, dass es an Hyphenopoly, einem Javascipt-basierten Polyfill für Silbentrennung lag. 

Silbentrennung – ein gelöstes Problem?

Wir setzen Hyphenopoly in Projekten ein, in denen Wert auf ordentlichen Flattersatz mit Silbentrennung in allen Browsern gelegt wird. Eigentlich unterstützen mittlerweile fast alle Browser Silbentrennung über eigene Wörterbücher und Regelwerke, die natürlich für jede Sprache unterschiedlich sind. Der Support für Deutsch ist insgesamt geringer als der für Englisch, aber Mozilla Firefox, Apple Safari, Google Chrome und demnächst Microsoft Edge haben Silbentrennung für die deutsche Sprache umgesetzt. Die große Ausnahme ist hier leider der Microsoft Internet Explorer (IE) in allen Versionen. Für Deutschland gibt StatCounter zwischen Mai und August 2019 zwar "nur" noch einen Anteil von ca. 7% für IE 11 an, beim Gemeinsamen Bundesausschuss liegt dieser aber deutlich höher: hier sehen wir in unseren Daten für IE 11 eine Quote von 25% für den gleichen Zeitraum. Diese Zahlen sowie der (Kunden-)Wunsch nach visueller Einheitlichkeit sind der Hauptgrund für unseren Einsatz von Hyphenopoly.

Hyphenopoly bringt von Haus aus eine sogenannte feature detection mit: zunächst wird nur ein kleines Skript geladen, das beim Aufruf der Website für ein konfiguriertes Testwort testet, ob der Browser eine erwartete Silbentrennung vornehmen würde. Nur wenn das Ergebnis negativ ausfällt, lädt Hyphenopoly das eigentliche Skript sowie die für die aktuelle Sprache nötigen Wörterbücher nach.

Regression in Firefox

Zurück zu unserem Problem. Die Tatsache, dass Hyphenopoly scheinbar verhindert, dass Verknüpfungen mit kopiert werden können, ist unschön, aber vielleicht nicht die Stelle, an der wir zuerst ansetzen sollten.

Was uns vor allem verwundert hat: Firefox unterstützt Silbentrennung für Deutsch, Hyphenopoly hätte also gar nicht in Aktion treten sollen! Ein kleiner Testcase bestätigte unseren Verdacht – tatsächlich schlug die Silbentrennung in Firefox fehl. 

Eine schnelle Suche im Bugtracker von Firefox blieb ohne Erfolg  – scheinbar hatte noch niemand ein Ticket erstellt. Kein Problem, wir hatten ja bereits einen Testcase. Zusätzlich konnten wir beweisen, dass die Silbentrennung in einer der letzten Versionen von Firefox noch korrekt funktioniert hatte. Genug Informationen für einen hoffentlich aussagekräftigen Bugreport.

Die Antwort traf nur wenige Stunden später ein: es war doch ein bereits bekannter Fehler, der in der folgenden Browserversion bereits behoben war. Mit einem Großbuchstaben beginnende Worte wurden nicht korrekt getrennt! Die gleichen Worte, komplett in Kleinbuchstaben, verhielten sich einwandfrei. Auch das konnten wir in unserem Testcase sofort nachvollziehen.

Abschließend konnten wir daher unser Hyphenopoly-Testwort anpassen (nur Kleinbuchstaben), das unnötige Laden des Polyfills auch in der aktuellen Version von Firefox verhindern und unsere Ansprechpartnerin informieren, dass sie ab sofort wieder Links von der Website kopieren und samt Verknüpfung in Word einfügen kann.

Eine kuriose Fehler-Kaskade aus dem Alltag in der Webentwicklung.
 

Ich weiß noch ganz genau, wie trocken und uninteressant ich den Bereich Webentwicklung fand. Vor zwei Jahren kam ich zum ersten mal mit HTML und CSS in Berührung. In einem stickigen Klassenzimmer wurde mir träge im Unterricht die ersten Basics der Sprachen vermittelt. Es wurde mit Fremdwörtern im Schwall geredet und in wirren Strukturen gezeichnet. Meine Verwirrung wurde dabei immer größer. In diesem Moment beschloss ich damals, dass ich den Bereich Webentwicklung nie wieder in meinem Leben betreten wollte.

Aber: Sag niemals nie!

Der Wurf

Nach dem Abschluss meiner Ausbildung zur gestaltungstechnischen Assistentin in Grafik und Objektdesign bewarb ich mich im Bereich Print für die duale Ausbildung als Mediengestalterin. Ich bekam einen Ausbildungsplatz und absolvierte mein erstes Lehrjahr im Printbereich. Was ich vorher nicht wusste: Mediengestalter, die im Bereich Digital ausgebildet werden, sind ebenfalls in meiner Berufsschulklasse. So kam es dazu, dass mich wieder HTML und CSS in der Schule verfolgten. Wieder durfte ich stupide die Sprachen lernen. 

Diese Mal ging der Lehrer aber mehr auf das Verständnis der Schüler einz. Ich verstand die ersten Basics, konnte mich aber mit dem Coden nicht anfreunden. Mit meinen ersten Kenntnissen versuchte ich, eine Website zu erstellen. Ich würde heute rückblickend sagen, dass es auf jeden fall keine Website war, welche ich da gebaut habe.

Das erste Schuljahr beugte sich dem Ende und mein Lehrer quälte mich durch das trockene Schulfach. Dann kam meine Ausbildungsstätte auf den interessanten Gedanken, dass ich in den Sommerferien ein fünfwöchiges Praktikum absolvieren könnte. Die einzige Bedingung war, dass ich das Praktikum im Bereich "Frontend-Entwicklung" absolvieren sollte. Ich gab mich den Gedanken hin und fasste den Entschluss, der Webentwicklung nochmals eine Chance zu geben. Und das, obwohl ich mir wirklich nicht vorstellen konnte, dass immer mehr Menschen Coden möchten, wenn es doch so trocken ist.

In meiner Berufsschulklasse sah ich einige Mitschüler, welche wirklich gute Websiten bauten. Das gab mir den Impuls, das Webentwicklung vielleicht doch nicht trocken sein konnte. Also bewarb ich mich bei der webfactory in Bonn. Meine Vorfreude wuchs,  da ich gespannt war, ob sich meine schlechten Erfahrungen mit Webentwicklung bestätigen würden, oder ob das Frontend doch interessanter ist, als gedacht.

Treibende Strömung

Ich bekam nach einem netten Telefonat den Praktikumsplatz. Am ersten Tag wurde ich von einem netten Team und zwei süßen Hunden begrüßt. Mit einem Online-Workshop, der zwei Tage ging, ratterte ich die Basics von HTML und CSS runter. Ich war wieder an einem Punkt, wo meine schlechten Erfahrungen sich bestätigen wollten. Das Webentwicklung tatsächlich nichts für mich ist.

Doch dann kam die Wendung. Als würde ein Regenschauer vorbei ziehen und die Sonne zwischen den Wolken durchscheinen, machte ich die ersten richtig interessanten Erfahrungen. Ich baute mit meinem Wissen aus dem Workshop eine erste Website. Ich verstand wirklich, was ich da schrieb! Ich war an einem Punkt angelangt, wo ich es nicht glauben konnte, dass ich zum ersten mal so etwas wie Freude fühlen konnte, während ich die Elemente und Styles in CodePen eintippte.

Ich konnte mit CodePen direkt sehen, wie sich der eingetippte Code verhielt. Besonders das Gerüst einer Website konnte ich nun sehen und anwenden. Nach den ersten Übungen kam Lukas auf mich zu und zeigte mir ein Spiel, das die Funktionen von Flexbox erklärt. Flexbox ist ein Weblayoutmodell, mit dem man Content auf der Website ausrichten kann. Danach zeigte er mir noch das Version Control System (VCS) Git. Mit Git führt man ein Protokoll über die Veränderungen des Codes, damit man nach längerer Zeit nachvollziehen kann, was man an bestimmten Stellen im Code geändert hat. So können auch andere Mitarbeiter an dem Code weiter arbeiten und Änderungen direkt nachvollziehen. Außerdem kann man aus einem beliebigen Stand auf den Code zurückspringen, falls man ungewünschte Änderungen zurücksetzten möchte.

Richtung wählen

In der zweiten Woche meines Praktikums fing ich an, ein Konzept für meine eigene Website zu entwickeln. Mir war schnell klar, dass ich ein Portfolio erstellen wollte, da ich in meiner Freizeit Designprojekte erstelle und diese präsentieren möchte. Auf der Seite sollten also meine Projekte zu sehen sein, und dazu Texte mit Einblicken in meine kreativen Prozesse.

Ich tüftelte das Konzept eine ganze Woche lang aus. Dabei wurde ich in ein Programm namens Sketch eingeführt, welches zur Visualisierung von Website-Layouts dient. Ich bekam immer wieder Feedback von Stefan, der mir half, mehr Verständnis für die Anforderungen von Webseiten und Userinterfaces zu erlangen.

Nach mehreren Entwürfen entschied ich mich nun für einen. Mir wurde immer wieder bewusst, dass die Ausbildung "Mediengestalter Digital und Print" genannt wird, aber zwischen den Bereichen Welten liegen. Nach Erstellung des Konzepts und meinen ersten Entwürfen fing ich mit dem Code Editor Visual Studio Code an, meine erste richtige Website zu bauen. Die ersten Basics funktionierten gut. Bis ich Flexbox anwenden musste. Ich übte gefühlt mehr als eine Woche, bis ich wirklich verstand, wie Flexbox funktioniert. 

Mit immer neuen Befehlen baute ich meine Website und mein Wissen aus. Dann kam der Tag, an dem mir Søren mitteilte, das meine Website auch mobil funktionieren muss. 

Responsive Design. Die Kopfschmerzen bahnten sich langsam an. Wie sollte das gehen? 

Ich las Bücher und googelte mehr als zuvor, um die mobile Ansicht zu optimieren. Doch die Navigation war mein Endgegner. Ich schrieb einen komplizierten Code, der nach viel Kopfzerbrechen am Ende mit wenigen einfachen Befehlen und Flexbox gelöst werden sollte:

.navigation {
    display: flex;
    justify-content: space-evenly;
    align-items: center;
}

Da verstand ich die Schwierigkeit, Code simpel zu schreiben. Media Queries halfen mir, den Anforderungen der verschiedenen Displays und dem Design gerecht zu werden, da man mit ihnen bestimmen kann, dass für verschiedene Displaygrößen unterschiedliche Befehle gelten dürfen.

Erkenntnis

Im Laufe der Umsetzung in HTML und CSS bemerkte ich eine zunehmende Unzufriedenheit mit meinem Design. Eva eilte mir zu Hilfe und gab mir wertvolle Tipps, wie ich mein Design optimieren könnte. Ich fing an, meine ersten Entwürfe komplett zu verwerfen und hielt mich an anderen Farbwelten und Typografien fest. Ich wollte, dass meine Persönlichkeit sich in dieser Website widerspiegelte.

Der letzte große Baustein folgte noch: Ich wollte zur Präsentation meiner Projekte eine Galerie haben. Der Begriff „Overlay“ viel zum ersten Mal. Eine Ansicht, die jeder schon mal gesehen hat: Die Website verdunkelt sich und Content wird in einen Präsentationsmodus gebracht. Mit JavaScript und npm bauten Lukas und ich ein Overlay in meine Website ein.

Während des ganzen Praktikums geriet ich immer wieder in Sackgassen beim Coden, aber mir wurde immer wieder durch Bücher und Teamwork geholfen. Manchmal half es auch einfach, erst am nächsten Tag das Problem in Angriff zu nehmen. Die positive Kritik, die mir immer weiterhalf führte dazu, dass ich meine Kreativität immer mehr herausholte und mein ganzes Herzblut in dieses Projekt steckte.

Dann kam der Zeitpunkt, an dem ich meine eigene Domain kaufte, mein Git Repository mit einem Webserver verknüpfte und meine Webseite endlich online war. Hier findest du sie: lisaheidenreich.de

Mir wurde bewusst, dass ich mir vor einem Monat nicht mal ansatzweise vorstellen konnte, dass es Spaß machen würde, Webseiten zu designen. Ich kann jetzt nachvollziehen, warum Webentwicklung eine tolle und wirklich aufregende Welt ist. Jeden Tag kommen neue Befehle dazu. Es ändern sich täglich neue Dinge, weshalb man nie auslernt. Vor allem die vielen Möglichkeiten reizten mich. Da begriff ich, dass Print und Digital doch mehr Gemeinsamkeiten haben, als gedacht, und trotzdem Unterschiede wie Tag und Nacht besitzen.

Das Praktikum bei der webfactory hat mir geholfen zu verstehen, dass Webentwicklung kein Einhorn (etwas Undefinierbares) ist, sondern ein logisches, cooles, nervenaufreibendes, komplexes Designen von Webseiten und Webanwendungen sein kann.

An meinem letzten Tag des Praktikums präsentierte ich meine Ergebnisse dem Team. Hier findest du meine Präsentation: Abschluss Präsentation

Lisa Marie Heidenreich

Symfony is open source. That means everyone may use it for free. You can read the source code, which gives you a better understanding of how things work. You are free to change and adapt the code to make it fit your needs. And everyone can contribute: By fixing bugs, adding new features and giving these changes back to the project itself.

For us at webfactory, building on top of Symfony has been a strategic choice we made back in 2011 and did not regret ever since. Symfony has grown over the years, also when it comes to strategic decision-making, policies and processes. There is a clearly defined release cycle, and Symfony delivered over a dozen of releases in time.

The Hackathon idea

I was very excited when I got the invitation for a "Hackathon" event in Brussels. Funding was provided by EU-FOSSA 2, the "EU-Free and Open Source Software Auditing project". This programme is managed by the European Commission's Directorate-General for Informatics (DIGIT). It provides a systematic approach for the EU institutions to ensure that widely used critical software can be trusted.

The Hackathon was invite-only and brought together about 50 contributors and "core team members" in a single venue. Most of them were from EU countries, but some also arrived from the US, Cuba, Morocco, Russia or Switzerland. The organizers did a great job, creating an environment where all attendees could work together to bring the Symfony project forward. We planned to work on strategic initiatives like Diversity and Inclusion, fix security problems and reduce the number of open support or change request tickets in general.

This weekend was different

Usually, open source projects work by using online tools for collaboration. Discussions and decisions take place in online forums, public chats or on mailing lists. This "asynchronous" way of working makes it possible for anyone to join. But sometimes it can be hard as well, since written communication lacks the richness of personal interaction.

The venue was an extraordinary place. These photos might give you an idea:

We had plenty of space to come together in groups, discuss things, to work on desks right next to each other or to retreat in cosy, quite places to help concentration.

Never before have so many contributors and members of the core team been together in one place. That gave an incredible boost to everyone and set free lots of energy and enthusiam. Talking to each other, getting advice from senior contributors or directions from the project leads themselves was always just a matter of walking a few steps.

Around that, we had a lot of occasions to get to know each other, to connect, trade stories and share experiences. For me, it was the first time to meet about a dozen of people that I had worked with before online without ever having seen their faces. In most cases, I knew their GitHub usernames better than their real names.

Some numbers and figures

Speaking of GitHub: On that platform, developers open so-called "pull requests". Basically, these are proposals to perform a particular change in the code. These pull requests are then reviewed and discussed. More than often, the initial idea undergoes many rounds of changes, fixes and improvements before it finally gets "merged". In addition to that, "issues" are created for reporting bugs, discussing new ideas and features even before having code for it.

The GitHub statistics for this weekend are impressive, even though the second day hasn't even finished yet:

The Symfony documentation team, which works in a separate GitHub area, did equally well:

Fabien Potencier, the project lead, estimated that on this weekend the work of two months of regular activity has been done. In this filtered issue tracker list, you will find that more than 230 issues have been addressed or even resolved.

The most impressive figure, in my opinion, comes from the "Continuous Integration" system. For every single change suggested, this system will run a suite of several thousand automated software tests to make sure nothing breaks. If you look at the following chart of how many test runs have been triggered during the past 30 days, it gives you a good idea of how much activity there was.

After more than 12 hours of focused work on the first day, we're now on Sunday afternoon and preparing for a closing session. All the groups will get an opportunity to tell the others about their work and results. We're also looking forward to some closing remarks from the project leads as well as the EU-FOSSA 2 team.

Although exhausted, I think most of us will return home with a feeling of satisfaction. For sure we've all learned a lot at the same time as bringing the Symfony project and related open source projects a leap forward.

Thanks – and hope to see you all soon again at one of the Symfony conferences or user groups!