Matthias, Jano und ich haben dafür mehrere Tage zuvor den Tagesablauf geplant und alle nötigen Vorbereitungen getroffen.

Da dies nicht unser erster Girls'Day war, konnten wir mit den bisher gesammelten Erfahrungen den Tag wie folgt strukturieren:

1. Ankommen und Ankoppeln
2. Front-End
3. Back-End
4. Mittagspause
5. Projektmanagement
6. Konzeption
7. Abschluss und Feedback

Jeden Bereich unserer Arbeit haben wir mit einer kurzen inhaltlichen Vorstellung begonnen, gefolgt von Phasen, in denen die Mädchen selber kreativ werden konnten.

Dabei wurden sie kurzerhand selber zu Front- und Back-End-Entwicklern und haben mit HTML-Elementen und CSS-Befehlen ihre eigene kleine Website gestaltet und in scratch.org die Welt der Programmierung kennengelernt. Gestärkt durchs Mittagessen mussten sie dann gemeinsam den Projektablauf eines neuen Schulrucksacks planen. Und zu guter Letzt: ihre eigene Website planen, gestalten und anschließend ihren Mitstreiterinnen vorstellen.

Einige Mädchen hatten sogar schon Vorkenntnisse im Bereich der Webentwicklung und haben beispielsweise in der Schule schon mit scratch.org gearbeitet. Somit konnten sie sich untereinander helfen und im Team arbeiten (ähnlich wie wir das auch machen ;-) ).

Insgesamt hatten nicht nur die Teilnehmerinnen, sondern auch wir viel Spaß am Girls'Day. Ich persönlich fand es sehr spannend zu sehen, welche tollen Websites in der Konzeptionsphase entstanden sind:

Die Webseite "KickBox" legt den Fokus auf den Sport des Kickboxens und bietet die Möglichkeit, passende Ausrüstung direkt über den integrierten Shop zu erwerben.

Die Webseite "LeCaLi" widmet sich dem Reitsport und bietet im Shop alles, was das Herz eines jeden Pferdeliebhabers begehrt. Durch den Angebotsbereich lassen sich auch richtige Schnapper ergattern.

Abschließend wurde der Tag noch in einer kleiner Feedback-Runde nach der "Fünf Finger"-Methode rekapituliert.

Wir freuen uns schon auf das nächste Jahr <3!

Die webfactory ist in vielen Projekten für öffentliche Auftraggeber tätig, teilweise seit über 20 Jahren. Öffentliche Auftraggeber sind verpflichtet, bei der Erteilung von Aufträgen das Vergaberecht zu beachten. Dieses sieht vor, dass Aufträge grundsätzlich öffentlich oder zumindest wettbewerblich ausgeschrieben werden müssen und dass Rahmenvereinbarungen auf 4 Jahre begrenzt sein müssen (§21 Abs. 6 VgV). Immer wieder stellt sich daher die Frage, inwiefern unsere Art und Weise der langfristigen Zusammenarbeit vom Vergaberecht gedeckt ist. Müssen Aufträge für Betrieb und Weiterentwicklung zeitlich begrenzt sein, mit der Möglichkeit, dass das System alle paar Jahre in die Hände eines anderen Auftragnehmers gegeben wird? Muss ein System gar alle paar Jahre neu programmiert werden?

Softwareentwicklung als Theoriebildung

Um diese Frage zu beantworten, sollte man sich zuerst bewusst machen, worum es bei Softwareentwicklung geht: ein Modell der Realität zur Lösung einer bestimmten Aufgabe.

Peter Naur hat bereits 1985 in seinem Aufsatz "Programming as Theory Building" dargelegt, wie eng eine Software an die Menschen gebunden ist, die sie entwickelt haben. Der Aufsatz wurde im 2006 erschienenen Buch "Agile Software Development: A Cooperative Game" von Alistair Cockburn nachgedruckt und ist auch heute noch aktuell.

Naur legt dar, dass Softwareentwicklung als eine Tätigkeit gesehen werden sollte, bei der die Programmierer Erkenntnisse gewinnen und eine Theorie des relevanten Ausschnitts der Welt entwickeln. Er stellt dies in Kontrast zu der Wahrnehmung, bei Softwareentwicklung ginge es in erster Linie um die Produktion eines Programms und weiterer begleitender Textdokumente. Die Theorie, die bei dieser Tätigkeit entsteht und auf der die Software basiert, ist untrennbar an Personen gebunden, es handelt sich um implizites Wissen.

Folgende Gründe nennt Naur dafür, dass das Wissen, das der Entwickler über die Software hat, über das in Form von Code und Dokumentation niedergeschriebene Wissen hinausgeht:

1. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, wie sich die Lösung zu dem Ausschnitt der Realität verhält, den sie zu handhaben hilft. Diese Erklärung erstreckt sich auch darauf, welche Dinge der realen Welt in welchem Detailgrad in der Software abgebildet sind. Er kann für jeden Teil der Software erklären, welchen Aspekt der Welt sie abdeckt, und umgekehrt für jeden Aspekt der Welt sagen, ob und wie er in der Software berücksichtigt ist. Die Frage, welche Aspekte der Welt in der Software abgebildet werden müssen, setzt eine fundierte Kenntnis dieser relevanten (Fach-) Welt voraus.
2. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, warum jeder Teil des Programms so geschrieben ist, wie er ist. Er kann also den Programmcode begründen.
3. Der Entwickler, der die Theorie hinter der Software kennt, kann konstruktiv auf Änderungsbedarfe reagieren. Die Entscheidung, wie eine Änderung am besten vorgenommen werden kann, und die Gestaltung dieser Änderung hängen davon ab, wie ähnlich der neue Bedarf zu den bereits in der Software vorhandenen Fähigkeiten ist. Die Beurteilung dieser Ähnlichkeit setzt das oben beschriebene Wissen sowohl über die Software als auch über die von ihr abgebildete Realität voraus, das nur der Entwickler hat.

Wird eine Software von Entwicklern ohne angemessenes Verständnis ihrer Theorie angepasst, degeneriert sie mit der Zeit. Denn es kommen stets verschiedene technische Lösungen für die Umsetzung neuer Anforderungen in Frage, die alle technisch korrekt funktionieren. Aber nur, wenn sie der Theorie entsprechen, entwickelt sich die Software in einem stimmigen Gesamtbild weiter. Wenn sie dagegen der Theorie widersprechen, wirkt die Software zunehmend wie ein Flickwerk, dessen Zerfaserung nur mit groben Nähten aufgehalten wird. All diese Nähte können das Verständnis der Software und damit ihren Betrieb und künftige Weiterentwicklungen erschweren. Nur Entwickler, die die Theorie hinter der Software kennen, sind in der Lage, die Lösungen dahingehend zu bewerten, ob sie dieser Theorie entsprechen oder widersprechen.

Daraus folgert Naur, dass eine Software nur als lebendig angesehen werden kann, solange ein Team, das die Theorie der Software besitzt, mit ihrer Weiterentwicklung betraut ist und die Kontrolle über alle Modifikationen hat. Eine Software stirbt demnach, wenn das Entwicklerteam, das die Theorie besitzt, aufgelöst wird. Eine solche tote Software kann zunächst weiter genutzt werden, aber der Tod wird sichtbar, wenn Weiterentwicklungsbedarfe nicht mehr intelligent umgesetzt werden können.

Die Theorie hinter der Software kann neuen Entwicklern vermittelt werden, indem diese intensiv und über längere Zeit mit den ursprünglichen Entwicklern zusammenarbeiten. Dadurch werden die neuen Entwickler vertraut mit dem Stellenwert der Software im Kontext verschiedener Situationen der realen Welt und bauen das Wissen auf, wie die Software funktioniert und wie außergewöhnliche Situationen und Änderungsanforderungen in ihrer Theorie abgebildet werden. Die Vermittlung einer solchen existierenden Theorie an neue Entwickler ist sehr ähnlich zur Vermittlung anderer Fähigkeiten, bei denen es mehr darum geht, zu lernen, wie etwas getan wird, als darum, sich Faktenwissen anzueignen. Solche Tätigkeiten sind zum Beispiel das Schreiben oder das Spielen eines Instruments. Naur hält fest, dass die wichtigste Lernaktivität bei solchen Fähigkeiten darin besteht, dass der Schüler relevante Tätigkeiten unter der Beobachtung und Anleitung seines Lehrers ausübt. Im Falle der Softwareentwicklung sollte diese Anleitung Diskussionen über das Verhältnis zwischen der Software und den relevanten Aspekten und Aktivitäten der realen Welt beinhalten, ebenso wie über die Grenzen der in der Software vorgenommenen Abbildung der Realität.

Eine tote Software könnte laut Naur theoretisch wiederbelebt werden, indem ein neues Team die Theorie zur existierenden Software erneut entwickelt. Das ist allerdings ohne Kontakt zu Personen, die die Theorie noch besitzen, aus seiner Sicht praktisch unmöglich und wird jedenfalls teurer sein, als die Software neu zu entwickeln.

Neuentwicklung statt Weiterentwicklung?

Man könnte nun versucht sein, zu fordern, dass Software folglich regelmäßig neu entwickelt werden müsste, wenn die Weiterentwicklung der Software ausgeschrieben werden muss und eine Arbeit mit dem existierenden Quellcode ohne die zugrundeliegende Theorie nicht möglich ist.

Das würde zum einen bedeuten, dass die komplette Investition, die in die Entwicklung der Software geflossen ist, erneut getätigt werden müsste. Es ist aus meiner Sicht zumindest fraglich, ob das mit dem Wirtschaftlichkeitsgebot aus dem Haushaltsrecht vereinbar ist (siehe hierzu Softwareentwicklung für öffentliche Auftraggeber).

Zum anderen würde das aber auch voraussetzen, dass es überhaupt möglich ist, die existierende Software neu zu entwickeln. Dies ist mit einem erheblichen Projektrisiko und einem hohen Zeitaufwand verbunden, der benötigt wird, um überhaupt nur den aktuellen Status Quo wiederherzustellen – ohne dass die benötigte Weiterentwicklung damit auch nur begonnen wäre. In den meisten Fällen wird die Weiterentwicklung schneller benötigt werden als eine komplette Neuentwicklung des Systems abgeschlossen werden könnte. Eine solche Neuentwicklung bringt zudem auch das Problem der Datenmigration von der alten in die neue Struktur mit sich.

Hinzu kommt, dass eine Neuentwicklung bestehender Lösungen knappe volkswirtschaftliche Ressourcen – Softwareentwickler – binden würde, die dann nicht für die Entwicklung innovativer Lösungen für noch ungelöste Probleme zur Verfügung stehen.

Die Neuentwicklung bestehender Systeme sollte daher die Ausnahme und nicht die Regel sein.

Das passende Vergabeverfahren

Wie oben gezeigt, ist es für die langfristige erfolgreiche Weiterentwicklung komplexer Systeme existenziell, dass ein Entwicklerteam, das die Theorie hinter der Software besitzt, diese Weiterentwicklung vornimmt. Das Team hat damit einzigartiges technisches Wissen über die Software.

Und hierfür wiederum kennt das Vergaberecht einen entsprechenden Tatbestand: Gemäß §14 Abs. 4 Nr. 2 der Vergabeverordnung kann der öffentliche Auftraggeber Aufträge im Verhandlungsverfahren ohne Teilnahmewettbewerb vergeben, wenn der Auftrag nur von einem bestimmten Unternehmen erbracht werden kann, weil aus technischen Gründen kein Wettbewerb vorhanden ist.

In jurisPK-Vergaberecht heißt es dazu:

Führt eine rechtmäßige Leistungsbestimmung dazu, dass die Leistung nur noch von einem Unternehmen zu erbringen ist, erfüllt dies zunächst den Tatbestand des technischen Alleinstellungsmerkmals. Es besteht daher ein von der deutschen Rechtsprechung geprägter direkter Zusammenhang zwischen dem Leistungsbestimmungsrecht des öffentlichen Auftraggebers und dem Verhandlungsverfahren ohne Teilnahmewettbewerb aufgrund technischen Alleinstellungsmerkmals. OLG Düsseldorf: „Sind die vergaberechtlichen Grenzen der Bestimmungsfreiheit des öffentlichen Auftraggebers indes eingehalten, sofern die Bestimmung durch den Auftragsgegenstand sachlich gerechtfertigt ist, vom Auftraggeber dafür nachvollziehbare objektive und auftragsbezogene Gründe angegeben worden sind und die Bestimmung folglich willkürfrei getroffen worden ist, solche Gründe tatsächlich vorhanden (festzustellen und notfalls erwiesen) sind und die Bestimmung andere Wirtschaftsteilnehmer nicht diskriminiert. Bewegt sich die Bestimmung in diesen Grenzen, gilt der Grundsatz der Wettbewerbsoffenheit der Beschaffung nicht mehr uneingeschränkt." (OLG Düsseldorf v. 01.08.2012 - Verg 10/12 und im Anschluss OLG Düsseldorf v. 12.02.2014 - VII-Verg 29/13, Verg 29/13 - juris.)

Ortner in: Heiermann/Zeiss/Summa, jurisPK-Vergaberecht, 6. Aufl., § 14 VgV (Stand: 15.09.2022)

Der Kommentar zur VgV/UVgO von Malte Müller-Wrede konkretisiert:

Dem Rückgriff auf § 14 Abs. 4 Nr. 2 VgV steht grundsätzlich nicht entgegen, dass das Vorliegen der Tatbestandsvoraussetzungen dem öffentlichen Auftraggeber zuzuschreiben ist. Im Falle des § 14 Abs. 4 Nr. 2 VgV übt der öffentliche Auftraggeber stets einen gewissen Einfluss auf das Vorliegen der Tatbestandsvoraussetzungen aus, denn er gibt die Leistungsanforderungen vor, die dann nur von einem Unternehmen erfüllt werden können. Aber auch das Zutun des öffentlichen Auftraggebers zum Erwerb der Monopolstellung durch ein Unternehmen ist im Rahmen des § 14 Abs. 4 Nr. 2 VgV unbeachtlich. So sind singuläre technische Fähigkeiten infolge einer vorangegangenen Beauftragung durch den öffentlichen Auftraggeber gerade typische Folge des Leistungswettbewerbs. Anderes könnte allenfalls dann diskutiert werden, wenn die vorangegangene Beauftragung und die hieraus folgende Monopolstellung unter Missachtung des Vergaberechts erlangt wurden. Jedoch kann die Rechtswidrigkeit der vorangegangenen Beauftragung nach hier vertretener Auffassung nicht auf das neue Vergabeverfahren durchwirken. Sie muss im jeweiligen Vergabeverfahren angegriffen werden.

Müller-Wrede in: Müller-Wrede, VgV / UVgO - Kommentar, 5. Aufl. 2017,§ 14 VgV Wahl der Verfahrensart

Mit dem Verständnis von Softwareentwicklung als Theoriebildung und im Hinblick auf die große Bedeutung impliziten Wissens für die erfolgreiche Weiterentwicklung scheint es eindeutig, dass § 14 Abs. 4 Nr. 2 VgV hier zum Tragen kommen muss.

Müller-Wrede betont auch, dass der öffentliche Auftraggeber darlegen muss, dass einer oder mehrere der in §14 Abs. 4 Nr. 2 VgV genannten Gründe zwingend die Vergabe an ein bestimmtes Unternehmen erfordern. Er weist des Weiteren darauf hin:

Gelingt dies, so ist ein Wettbewerb um den öffentlichen Auftrag tatsächlich unmöglich und die Durchführung eines wettbewerblichen Vergabeverfahrens obsolet. Eine dennoch erfolgende Bekanntmachung oder Aufforderung von Unternehmen zur Angebotsabgabe würde eine tatsächlich nicht bestehende Zuschlagschance suggerieren.

Gilt das für alle Unternehmen?

Wichtig scheint mir noch die Feststellung, dass die oben dargestellte Situation nicht in jedem Projekt und jedem Unternehmen gegeben sein muss – denn sie setzt voraus, dass das Team, das die Theorie hinter der weiterzuentwickelnden Software besitzt, auch für die Arbeit an dem Projekt zur Verfügung steht.

Bei uns in der webfactory ist das typischerweise der Fall. Da wir uns auf langlebige Softwareprodukte spezialisiert haben, legen wir großen Wert auf Kontinuität im Team und eine geringe Fluktuation. Neue Teammitglieder werden bei uns Schritt für Schritt in Weiterentwicklungsprojekte eingebunden und mit der Theorie hinter den Softwaresystemen vertraut gemacht.

Bei größeren Unternehmen ist hingegen nicht unbedingt gesagt, dass eine Folgevergabe an das gleiche Unternehmen überhaupt dazu führt, dass die Entwicklung von einem Team durchgeführt wird, das die Theorie hinter dem System kennt. Wenn das aber nicht garantiert ist, ist eine Vergabe an ein solches Unternehmen auch nicht durch die obige Argumentation gerechtfertigt.

Und wenn alle Stricke reißen?

Natürlich kann es Situationen geben, in denen die Weiterentwicklung eines Systems durch das ursprüngliche Team nicht möglich ist und die Betreuung des Systems daher neu vergeben werden muss. In diesem Fall sollte aber, wenn die Software nicht komplett neu entwickelt werden soll, das ursprüngliche Team wenn möglich beratend bei der Entwicklung zur Seite stehen, damit das neue Team die Theorie hinter der Software lernen kann. Parallel zur Vergabe an den neuen Dienstleister sollte also der alte Dienstleister mit der Vermittlung des Wissens beauftragt werden. Die dadurch entstehenden Kosten sind durch die dadurch erreichte bessere Einarbeitung des neuen Teams, höhere Qualität der Weiterentwicklung und daraus resultierend ein längeres Leben der Software gerechtfertigt.

Im ersten Abschnitt des Buches werden phasenorientierte Methoden wie zum Beispiel das Wasserfallmodell sowie agile Methoden wie Scrum dargestellt. Der Schwerpunkt liegt dabei auf den agilen Methoden und Prinzipien.

Neben den Softwareentwicklungsmethoden werden auch die Grundlagen der Projektvergabe öffentlicher Auftraggeber dargestellt. Öffentliche Auftraggeber sind verpflichtet, das Vergaberecht zu beachten, das grundsätzlich eine öffentliche oder zumindest wettbewerbliche Ausschreibung von Aufträgen vorschreibt. Sie müssen Haushaltsmittel zudem wirtschaftlich und sparsam verwenden. Für die Vergabe gibt der Gesetzgeber in der Verordnung über die Vergabe öffentlicher Aufträge VgV (§14 Abs. 1) sowie in der Unterschwellenvergabeordnung UVgO (§9) verschiedene Verfahren vor. Diese unterscheiden sich im Bezug auf den Teilnehmerkreis sowie auf die Möglichkeit, während des Vergabeverfahrens beziehungsweise während der Projektlaufzeit über die konkrete Ausgestaltung der Auftragsinhalte zu verhandeln.

Ob die VgV oder die UVgO zu beachten sind, hängt vom Auftragswert ab. Überschreitet dieser einen Schwellenwert von 140.000 € bei obersten und oberen Bundesbehörden oder 215.000 € bei sonstigen öffentlichen Auftraggebern, sind die Aufträge gemäß VgV und damit EU-weit auszuschreiben (die Werte sind die 2022/2023 gültigen; im Buch sind noch alte Werte genannt). Der Auftragswert ist dabei ohne Umsatzsteuer, aber inklusive aller Folgeaufträge und Erweiterungen zu berechnen (UfAB S. 61). Viele agile Softwareprojekte werden über ihre Laufzeit gesehen im oberschwelligen Bereich liegen, weshalb das Buch den unterschwelligen Bereich ausklammert.

Generell sind öffentliche Auftraggeber gehalten, zwischen dem offenen und dem nicht-offenen Verfahren zu wählen, es sei denn, es stehen aufgrund der in §14 Abs. 3 oder 4 VgV genannten Gründe andere Verfahren wie das Verhandlungsverfahren, der wettbewerbliche Dialog oder die Innovationspartnerschaft offen.

Im letzten Abschnitt des Grundlagenteils werden die Rechtsvorschriften zur Preisgestaltung, insbesondere die Verordnung PR Nr. 30/53, dargestellt. Gemäß dieser Verordnung muss der Auftraggeber Marktpreisen den Vorzug vor Selbstkostenpreisen geben, feste Preise genießen Vorrang vor veränderlichen Preisen und es gilt das Höchstpreisprinzip: Die gemäß der Verordnung festgelegten Preise dürfen von keiner Partei überschritten, wohl aber unterschritten werden.

Möglichkeiten der Preisgestaltung agiler Entwicklungsprojekte

Im nächsten Kapitel werden Story Points als verbreitete Schätzmethode für agile Entwicklungsprojekte kurz umrissen. Es folgt eine vertragstypologische Einordnung von Softwareprojekten und eine Gegenüberstellung wesentlicher Eigenschaften von Werkvertrag und Dienstvertrag. Der Autor weist aber darauf hin, dass sich agile Softwareaufträge häufig nicht eindeutig zu einem der beiden Vertragstypen zuordnen lassen.

In den folgenden Abschnitten werden verschiedene mögliche Vergütungsarten für agile Entwicklungsprojekte ausführlich beschrieben.

• Der reguläre Festpreis ist das klassische Preismodell, lässt sich aber schwer mit agiler Entwicklung vereinbaren, da er strikte Planeinhaltung fordert. Auftraggeber, die ein Festpreisprojekt vergeben wollen, sollten die Kosten für Change Requests von vorne herein mit berücksichtigen.

• Der Aufwandspreis vermeidet die Probleme des Festpreises, verlagert aber das Risiko stark in Richtung Auftraggeber. Ein Aufwandspreis mit Obergrenze wiederum erlegt dem Auftragnehmer das Risiko bezüglich der Überschreitung des geplanten Aufwands auf, ohne ihn für eine Unterschreitung des Aufwands zu belohnen. Aufwandspreise setzen zudem keinen wirtschaftlichen Anreiz für möglichst gute Ergebnisse, sondern eher zur Produktion möglichst vieler Stunden.

• Eine nutzenabhängige Abrechnung ("Pay per use") setzt Anreize für die Entwicklung erfolgreicher Lösungen, aber der Auftragnehmer übernimmt ein erhebliches Risiko, da er bei geringem Nutzen eventuell keine kostendeckende Vergütung erhält. Allerdings sind auch Mischformen möglich wie zum Beispiel eine kostendeckende Basisvergütung und eine nutzenabhängige Erfolgskomponente.

• Schließlich wird der agile Festpreis dargestellt. In diesem Modell ist der Gesamtpreis fest und wird für einen bestimmten, in Story Points bemessenen Auftragsumfang vereinbart. Welche Funktionalität am Ende tatsächlich entwickelt wird, ist nicht von vorne herein festgelegt sondern kann im Projektverlauf verändert werden. Als Variante des agilen Festpreises wird ein Festpreis pro Iteration beschrieben.

Nach den Preismodellen geht der Autor auf weitere Möglichkeiten der agilen Vertragsgestaltung ein: die Option des Projektabbruchs und den Risk-Share-Ansatz.

Wenn beiden Vertragspartnern die Möglichkeit offensteht, das Projekt abzubrechen, ist dies ein starker Anreiz für eine gute Kooperation, sowohl für den öffentlichen Auftraggeber als auch für den Auftragnehmer.

Der Risk-Share-Ansatz sieht vor, dass Kostenüberschreitungen vom Auftragnehmer und Auftraggeber gemeinsam getragen werden. Der Auftragnehmer erhält somit auch für den erhöhten Aufwand eine Vergütung, aber da diese nur anteilig erfolgt (in Höhe des vom Auftraggeber übernommenen Risikoanteils) hat er keinen Anreiz, möglichst viele Stunden zu produzieren.

Abschließend werden die verschiedenen Ansätze vergleichend gewürdigt. Der agile Festpreis wird als das am besten zur agilen Softwareentwicklung passende Modell bezeichnet, wobei in Einzelfällen auch andere Preistypen oder eine Kombination davon sinnvoll sein können.

Deckung der Anforderungen öffentlicher Auftraggeber

In diesem Kapitel werden die zuvor beschriebenen Preis- und Vertragsmodelle mit den Anforderungen an die öffentliche Vergabe abgeglichen.

Zunächst erfolgt eine Analyse aus Sicht des Haushaltsrechts: Das Haushaltsrecht schreibt dem öffentlichen Auftraggeber die Beachtung des Wirtschaftlichkeitsprinzips vor. Ein gegebenes Ziel soll demnach mit möglichst geringem Mitteleinsatz erreicht werden (Minimalprinzip), umgekehrt soll mit den zur Verfügung gestellten Mitteln das bestmögliche Ergebnis erreicht werden (Maximalprinzip).

Es folgt eine aus meiner Sicht spannende Argumentation: Agile Methoden haben in den vergangenen Jahren ihre Vorteilhaftigkeit gegenüber herkömmlichen plangetriebenen Methoden unter Beweis gestellt (Orłowski et al. 2017, S. 525 f.), es würde dem Wirtschaftlichkeitsprinzip also widersprechen, ein anderes als das agile Vorgehen zu wählen. Allerdings ist einer der Grundsätze aus dem agilen Manifest, dass es Reaktion auf Veränderung für wichtiger hält als das Befolgen eines Plans. Ein starrer, vor Projektbeginn festgelegter Plan widerspricht also dem agilen Vorgehen. Damit kann das Minimalprinzip, das ein starres Ziel voraussetzt, nicht zur Anwendung kommen.

Besser passend ist das Maximalprinzip, das für einen gegebenen Mitteileinsatz den größtmöglichen Erfolg anstrebt. Allerdings gibt es keine Garantie dafür, dass die gegebenen Mittel zur Erreichung der Minimalanforderungen an die Software reichen werden; es kann vielmehr sein, dass mehr Mittel als ursprünglich geplant benötigt werden. Damit scheidet auch das Maximalprinzip aus, da es einen konstanten Mitteleinsatz vorsieht.

Der agile Festpreis scheint ein guter und dem allgemeinen Gebot der Wirtschaftlichkeit entsprechender Kompromiss zu sein. Das Buch verweist hier auf die Unterlage für die Ausschreibung und Bewertung von IT-Leistungen UfAB des Bundes, die zum Zeitpunkt der Erscheinung des Buches einen festen Preis mit variablem Leistungsumfang noch nicht vorsah. Inzwischen wurde die UfAB aber überarbeitet und beschreibt den agilen Festpreis verbunden mit einem Risk-Sharing-Ansatz ausdrücklich als in Betracht kommende Option (S. 88 UfAB 2018).

Abschließend weist der Autor noch darauf hin, dass nutzenbasierte Abrechnungen weder mit dem Maximal- noch mit dem Minimalprinzip vereinbar sind.

Es folgt eine Analyse aus Sicht des Vergaberechts. Sowohl das offene als auch das nicht-offene Verfahren, die beide eine vollständige Spezifikation vor der Vergabe vorsehen, sind mit einem agilen Vorgehen nur sehr begrenzt vereinbar. Insbesondere würde auf den wesentlichen Vorteil der agilen Vorgehensweisen, die intensive Kommunikation zwischen Auftraggeber und Auftragnehmer bei der Erarbeitung der konkreten Lösung, verzichtet.

Für agile Projekte geeignet sind hingegen das Verhandlungsverfahren sowie der wettbewerbliche Dialog. Der wesentliche Unterschied zwischen diesen beiden Verfahren liegt darin, dass im Verhandlungsverfahren der Auftraggeber in der Lage sein muss, die technischen Mittel anzugeben, mit denen die Projektziele erfüllt werden können. Im wettbewerblichen Dialog hingegen ist nur das Ziel vorgegeben, die technischen Mittel werden von den potenziellen Auftragnehmern (Bietern) vorgeschlagen. Mit diesen Verfahren sind auch sämtliche agilen Vergütungsmodelle vereinbar und können noch im Laufe des Vergabeverfahrens während der Verhandlungen zwischen Auftraggeber und Bieter festgelegt werden.

Auch die oben bereits erwähnte UfAB befasst sich inzwischen mit agilen Methoden und betont: "Als Vergabeverfahrensart wird das Verhandlungsverfahren / die Verhandlungsvergabe mit Teilnahmewettbewerb bei agilen Vorgehensmodellen regelmäßig zulässig, aber tatsächlich geboten sein, um vor Vertragsschluss mit den Bietern insbesondere über die Einzelheiten des Vorgehensmodells und die vertragliche Ausgestaltung verhandeln zu können" (S. 87 UfAB 2018). An anderer Stelle in der UfAB (S. 121 ff.) wird auch der wettbewerbliche Dialog als adäquates Verfahren beschreiben, wenn die Mittel zur Zielerreichung nicht vorab spezifiziert werden können.

Die Innovationspartnerschaft wiederum passt zwar vom Namen her sehr gut zur Natur von Softwareprojekten, sieht aber die Trennung in Forschung-/Entwicklungsphase und anschließende Produktionsphase eines innovativen Produkts vor. Da es in der Softwareentwicklung keine von der Entwicklung getrennte Produktionsphase gibt, hat die Innovationspartnerschaft keinen Mehrwert gegenüber dem wettbewerblichen Dialog (und ist ihm im Übrigen sehr ähnlich).

Schließlich erfolgt eine Analyse aus Sicht des Preisrechts. Grundsätzlich ist dem Marktpreis wie im Grundlagenkapitel beschrieben der Vorzug gegenüber Selbstkostenpreisen zu geben. Bei Sofwareentwicklungsprojekten, in denen kundenindividuelle Software entsteht, ist es aber schwierig, einen solchen Marktpreis zu bestimmen – zumal wenn diese Software nicht im Vorfeld abschließend spezifiziert werden kann und damit nicht verschiedene vergleichbare Angebote eingeholt werden können. Eine Lösung kann der Ansatz eines marktüblichen Tagessatzes für Entwickler als Marktpreis sein. Wenn aber die Anzahl benötiger Tage variabel ist, widerspricht das dem Grundsatz, dass festen Preisen der Vorzug vor veränderlichen Preisen gegeben werden sollte. Die ebenfalls denkbare Definition eines Marktpreises pro Story Point hingegen hat das Problem, dass Story Points ein sehr subjektives Maß für den Aufwand sind. Ein Preis pro Team und Iteration wiederum wäre ebenfalls ein flexibler Preis. Preisprüfer fordern, dass die Vergleichbarkeit der Marktpreise sich auf den gesamten Auftrag beziehen muss und es nicht ausreicht, dass Einzelpreise marktüblich sind (Preise und Preisprüfungen bei öffentlichen Aufträgen).

Sind Marktpreise nicht ermittelbar, müssen Selbstkostenpreise herangezogen werden, für die es in den Leitsätzen für die Preisermittlung auf Grund von Selbstkosten (PreisLS) detaillierte Vorschriften gibt. Allerdings sieht der Autor in der Heranziehung der Preisverordnung und der PreisLS keinen wesentlichen Mehrwert für den öffentlichen Auftraggeber gegenüber der Ermittlung und ggf. Nachverhandlung von Marktpreisen über einen Vergleich verschiedener Anbieter.

Insgesamt wird auch in der abschließenden Betrachtung der agile Festpreis als (vorkalkulatorischer) Selbstkostenfestpreis als die beste Option gesehen. Hinsichtlich des Vergabeverfahrens wird der wettbewerbliche Dialog als das gängigste Verfahren für Softwareentwicklungsprojekte dargestellt.

Bibliographische Angaben

Softwareentwicklung für öffentliche Auftraggeber. Agile Entwicklung und Preiskalkulation / Felix Hinkelmann, 1. Auflage 2018, Studylab München, 62 Seiten. Magisterarbeit der FernUniversität Hagen, erhältlich über https://www.grin.com/document/413391.

Weitere Literatur

Folgende Quellen stellen aus meiner Sicht eine gute Ergänzung zum hier besprochenen Buch dar:

• Unterlage für Ausschreibung und Bewertung von IT-Leistungen (UfAB): Die offizielle Handreichung des CIOs des Bundes für die mit der Ausschreibung von Software-/IT-Projekten befassten Beschaffer. Enthält umfassende Erläuterungen zur Planung und Durchführung von IT-Ausschreibungen der öffentlichen Hand.

• Der agile Festpreis : Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge (Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr, Carl Hanser Verlag München): Die detaillierte Beschreibung des im oben besprochenen Buch wie auch in der UfAB favorisierten Preismodells

• Software Estimation without Guessing (George Dinwiddie, O'Reilly 2019): Eine sehr gute Darstellung der Möglichkeiten und Grenzen von Aufwandsschätzungen in Softwareprojekten.

Was dem System bisher fehlte, war ein Verfahren, über das die Daten wieder aus der Datenbank gelöscht werden. Schließlich gibt es ein Recht auf Vergessenwerden und dem widerspricht es, wenn Daten von Projektteilnehmern ohne zeitliche Begrenzung gespeichert bleiben. Vor diesem Hintergrund trat unser Kunde mit der Bitte an uns heran, zukünftig Daten aus Projekten, die vor über 6 Jahren beendet wurden, automatisch aus dem System zu löschen. Das betraf direkt zu Beginn schon fast 600.000 Zertifikate, bei denen diese Frist bereits erreicht war. Schnell wurde klar, dass die Löschung an sich einfach ist, aber eine Reihe von umfangreichen Vorarbeiten erforderte.

Eine grundlegende Entscheidung: "Papierkorb" oder "Radiergummi"?

Die Anforderung unseres Kunden war, dass personenbezogene Daten aus der Datenbank gelöscht werden sollten. Dies umfasste z. B. die Namen, Geburtsdaten und Identifikationsnummern der Projektteilnehmer, aber auch die Informationen zu Dialogpartnern und Referenzgebern. Andere Daten sollten hingegen im System bleiben. Gemeinsam haben wir überlegt, wie wir hierbei am besten vorgehen können. Wir haben zwei grundsätzlich unterschiedliche Möglichkeiten gesehen, die wir "Radiergummi" und "Papierkorb" getauft haben.

Der "Radiergummi"-Ansatz bestand darin, in der Datenbank gezielt die Daten "auszuradieren", die personenbezogen waren, und alle anderen Daten unverändert zu erhalten. Vorteile, die wir in diesem Ansatz gesehen haben, waren:

• Es bleiben automatisch alle Daten im System erhalten, die nicht personenbezogen sind
• Es entsteht dementsprechend kein Entwicklungsaufwand, um nicht-personenbezogene Daten zu erhalten, die für andere Zwecke benötigt wurden (z. B. Statistiken, Verifizierung, Forschung)

Dem gegenüber standen auch einige Nachteile:

• Einige der personenbezogenen Daten sind in Pflichtfeldern gespeichert, z. B. der Name des Zertifikatsempfängers. Pflichtfelder können aber technisch nicht einfach auf "leer" gesetzt werden
• Benutzer des Youthpass-Systems finden in alten Projekten teilgelöschte Teilnehmerdaten vor und könnten ggf. auch Zertifikate für anonymisierte Personen generieren. Da das natürlich nicht sinnvoll ist und eventuell sogar zu Fehlern führen würde, muss die Anwendung entsprechend angepasst werden und den Zugriff auf die alten Daten sperren
• Alle Datensätze bleiben weiter dauerhaft im Produktivsystem, mit entsprechenden Anforderungen an die Performanz der Datenbank und mit dem Nachteil, dass alle Datenbankbereiche, die seit 2007 genutzt wurden, dauerhaft in Betrieb bleiben müssen.

Der "Papierkorb"-Ansatz sah vor, Datensätze, deren personenbezogene Daten entfernt werden sollen, komplett aus dem System zu löschen. Daten, die für andere Zwecke gebraucht werden, müssten vor der Löschung anonymisiert in dafür spezialisierte "Data stores" übertragen werden. Hierfür haben wir folgende Vorteile gesehen:

• Die Anwendung muss nicht mit teilgelöschten Daten umgehen; Projekte, die gelöscht wurden, sind einfach nicht mehr vorhanden
• Die Menge der im Produktivsystem vorhandenen Daten wächst langsamer
• Die Datenbankstruktur und der Programmcode für die Umsetzung früherer Versionen der Youthpass-Zertifikate (für alte Generationen der Förderprogramme) können gelöscht werden, sobald alle Projekte aus dieser Förderperiode gelöscht sind
• Die Daten, die für andere Zwecke aufgehoben werden, können in dafür optimierter Form gespeichert werden.

Folgende Nachteile hatten wir auf dem Schirm:

• Entwicklungsaufwand für die spezialisierten Data stores
• Die Struktur der aufgehobenen Daten könnte sich im Zeitverlauf ändern und wäre dann komplizierter zu analysieren (eine Nebenwirkung der größeren Freiheit bei der Weiterentwicklung der Datenstrukturen)

Nach Abwägung dieser Argumente haben wir uns gemeinsam mit JUGEND für Europa für den "Papierkorb"-Ansatz entschieden. Damit konnte die eigentliche Arbeit am Projekt beginnen.

Welche Daten sollen aufgehoben werden?

Da wir nun alle alten Datensätze komplett löschen wollten, musste vorher sicher gestellt sein, dass wir Daten, die wir weiter benötigen, vorher anderweitig sichern. Folgende Zwecke haben wir identifiziert:

• Statistiken: Das Youthpass-System bietet berechtigten Benutzern die Möglichkeit, statistische Daten über die generierten Zertifikate einzusehen. Und jeder Besucher der Website kann direkt auf der Startseite die Gesamtzahl der generierten Zertifikate sehen. Diese Informationen wurden bisher mehr oder weniger direkt aus der Produktivdatenbank ermittelt. Nach der Löschung wäre die ausgewiesene Gesamtzahl der Zertifikate damit um 600.000 gesunken.
• Verifizierung von Zertifikaten: Jedes Zertifikat trägt einen Identifikationscode, der online über die Website überprüft werden kann. Nach der Löschung der Daten wären die betroffenen Zertifikate nicht mehr als gültig erkannt worden.
• Forschungsdaten: Für zukünftige Forschung sollten insbesondere die auf den Zertifikaten vorhandenen Beschreibungen von Lernerfahrungen und erworbenen Kompetenzen möglichst erhalten bleiben, ebenso auch die anderen Angaben auf den Zertifikaten, die keiner Löschpflicht unterliegen.

Vollständige Statistiken trotz Löschung

Aus Performancegründen gab es in Youthpass bereits spezialisierte Datenbanktabellen mit den Statistikdaten. Diese Statistikdaten wurden allerdings bisher jede Nacht aus den Produktivdaten neu aggregiert – ein Vorgehen, das nach der Löschung von Produktivdaten natürlich nicht mehr möglich gewesen wäre, ohne die Daten der gelöschten Projekte auch in den Statistiken zu verlieren. Wir haben daher entschieden, die Statistikdaten direkt beim Generieren eines Zertifikats in die entsprechenden Datenbanktabellen zu schreiben. Beim Aktualisieren eines Zertifikats werden diese Statistikdaten ebenfalls aktualisiert, und ab der Löschung des Projekts bleiben sie eingefroren erhalten.

Was im Laufe des Projekts klar wurde: Nicht für alle Statistikabfragen wurden ausschließlich die spezialisierten Datenbanktabellen genutzt, sondern manche Abfragen nutzten auch Produktivdaten. Das betrifft sowohl das Statistik-Tool für die Youthpass-Benutzer, aber auch Ad-Hoc-Statistiken, die wir ab und zu im Auftrag unseres Kunden zusammengestellt haben. Wir mussten also analysieren, welche Daten wir für die unterschiedlichen Statistiken aufheben mussten. Anschließend haben wir die Statistiktabellen um diese Datenfelder erweitert.

Eine kleine Zusatzherausforderung war hier noch der Übergang von der alten in die neue Welt: Um vollständige Statistikdaten zu haben, haben wir zunächst das Skript für die nächtliche Aggregation der Daten so erweitert, dass die neuen Datenfelder mit befüllt wurden (auch wenn dieses Skript ja nicht mehr lange leben sollte). Anschließend konnten wir das Statistik-Tool so umstellen, dass die Abfragen ausschließlich über die Statistiktabellen liefen und keine Produktivdaten mehr nutzten. Im letzten Schritt haben wir dann die neue Lösung aktiviert, die die Statistikdaten direkt beim Generieren der Zertifikate schreibt, und das nächtliche Aggregationsskript in Rente geschickt.

Wie verifiziert man Namen, die man gelöscht hat?

Wie oben bereits erwähnt, bietet Youthpass eine Verifizierungsseite, über die jedes Zertifikat anhand seiner ID oder eines aufgedruckten QR-Codes auf Gültigkeit überprüft werden kann. Diese Überprüfung erfolgte, indem die ID in der Produktivdatenbank nachgeschlagen wurde. Daher hätte sie nach einer Datenlöschung für die gelöschten Zertifikate nicht mehr funktioniert. Mindestens die Zertifikats-ID musste also dauerhaft aufgehoben werden.

Die Verifizierungsfunktion prüft aber nicht nur, ob die ID gültig ist oder nicht, sondern sie zeigt auch an, in welcher Art von Projekt das Zertifikat ausgegeben wurde, welcher Zeitraum darauf angegeben ist und welchen Titel das Projekt hatte. Und, last but not least: Für welchen Teilnehmer das Zertifikat erstellt wurde. Diese Information ist wichtig, weil in einigen europäischen Ländern die Youthpass-Zertifikate für die Bewerbungen an Hochschulen genutzt werden können und entsprechend sicher sein müssen.

Grundsätzlich wählten wir für die Verifizierungsfunktion den gleichen Ansatz wie für die Statistiken: Die Daten, die wir für die Verifizierung benötigen, speichern wir in einer speziellen Datenbanktabelle.

Doch der Name der Teilnehmer stellte uns vor die besondere Herausforderung: Wie können wir Namen verifizieren, die wir gelöscht haben?

Wir entschieden uns dafür, die Namen unumkehrbar verschlüsselt in der Verifizierungsdatenbank zu speichern. Der gleiche Ansatz wird typischerweise bei Passwörtern verwendet: Websites, auf denen man sich einloggen kann, speichern aus Sicherheitsgründen nicht das Passwort selbst in der Datenbank, sondern einen daraus abgeleiteten Hash. Die Website kann die Korrektheit des Passworts prüfen, indem sie den Hash des beim Login eingegebenen Passworts mit dem in der Datenbank gespeicherten Hash des vom Benutzer gewählten Passworts vergleicht.

Mit diesem Ansatz können wir nicht mehr zu einer gegebenen Zertifikats-ID den Namen anzeigen (denn die Verschlüsselung ist ja nicht umkehrbar), aber wir können für einen vom Nutzer der Verifizierungsfunktion angegeben Namen prüfen, ob dieser tatsächlich auf dem Zertifikat stand. So weit so gut, doch eine zusätzliche Herausforderung kam noch auf uns zu: Was tun wir, wenn der Name nicht exakt so eingegeben wird, wie er in der Datenbank steht? Können wir das retten?

• Youthpass-Benutzer müssen im Formular Vorname und Nachname des Teilnehmers eingeben (heute würden wir vermutlich nur noch ein Namensfeld nutzen, aber das ist ein anderes Thema). Auf dem Zertifikat steht aber nicht, was der Vor- und was der Nachname ist – und auf ungarischen Zertifikaten wird die Reihenfolge sogar umgekehrt. Wir speichern daher sowohl den Hash für "Vorname Nachname" als auch den für "Nachname Vorname"
• Auf einigen Zertifikatsversionen wird der Name in VERSALIEN ausgegeben. In der Datenbank steht er aber in gemischter Schreibweise. Wir wollten, dass sowohl "MAX" als auch "Max" (und auch "max") als korrekt anerkannt werden. Zugleich wollten wir auch sichergehen, dass Akzente nicht zu Problemen führen (z. B. weil sie sich auf der Tastatur des Nutzers der Verifizierungsfunktion nicht eingeben lassen). Um diese Probleme zu lösen, speichern wir eine normalisierte Version des Namens (Kleinbuchstaben ohne Sonderzeichen) in der Verifizierungsdatenbank. Dafür nutzen wir die NFC-Normalisierung bzw., um ganz genau zu sein, "Any-Latin; Latin-ASCII; Lower".

Damit die Benutzer der Verifizierungsfunktion zukünftig möglichst wenig Aufwand haben, haben wir noch eine Vereinfachung vorgenommen: Der QR-Code, der auf den neueren Zertifikaten erscheint, enthält jetzt auch den Namen des Teilnehmers. Wenn man den QR-Code nutzt, um ein Zertifikat zu verifizieren, wird also bei neuen Zertifikaten nicht nur die ID, sondern auch der Name an den Youthpass-Server gesendet. Dieser kann dann den Namen mit dem gespeicherten Hash vergleichen und direkt anzeigen, dass dieser Name echt ist. Natürlich geht das nicht für Zertifikate, die bereits vor der Umstellung gedruckt wurden (der QR-Code kann sich ja nicht im Nachhinein ändern), weshalb die oben genannten Normalisierungen trotzdem wichtig sind.

Zugleich haben wir eine weitere Neuerung eingeführt: Wenn sich relevante Daten eines Zertifikats später einmal ändern, wird nun eine neue ID für dieses Zertifikat vergeben. Unter der alten ID können nach wie vor die alten Daten verifiziert werden, unter der neuen ID dann die neuen Daten.

Anonymisiertes Datenarchiv für Forschungszwecke

Für die Begleitforschung zu Youthpass und die Weiterentwicklung des Systems war es unserem Kunden wichtig, möglichst viele Daten aus den Youthpass-Zertifikaten anonymisiert zu speichern.

Wir haben verschiedene Lösungsmöglichkeiten evaluiert und uns schließlich dazu entschieden, die Daten in einem weit verbreiteten Format semistrukturiert zu speichern: JSON. Da derzeit noch keine konkreten Anforderungen für die Forschung bekannt sind, haben wir uns für die einfachstmögliche Form der Speicherung entschieden: In einer Datenbanktabelle. Es ist bei Bedarf aber auch jederzeit möglich (und vermutlich sinnvoll), die Daten in ein spezielles Datenanalysesystem zu übertragen.

Grundsätzlich ähnelt auch die Befüllung des Datenarchivs von der Einbindung her dem bereits beschriebenen Ansatz: Bei der Generierung von Zertifikaten werden die Forschungsdaten ins Archiv übertragen beziehungsweise aktualisiert.

Für den Aufbau des Datenarchivs haben wir als erstes für alle Datenklassen, aus denen sich ein Youthpass-Zertifikat zusammensetzt, Normalisierer konfiguriert, die diese Daten in JSON konvertieren. Teilweise sind das Normalisierer, die direkt aus dem Symfony-Framework kommen, teilweise mussten wir projektspezifische Normalisierer ergänzen. Auf diese Weise entsteht dann mit Hilfe der Symfony Serializer Component für jedes generierte Zertifikat ein JSON-Dokument mit allen seinen Daten in auswertbarer Form.

Eine Frage, über die wir uns länger den Kopf zerbrochen haben: Wie können wir sicherstellen, dass wir bei zukünftigen Veränderungen des Datenmodells nicht vergessen können, die Archivierungsregeln anzupassen? Wenn zum Beispiel ein neues Feld hinzugefügt ist, muss ja individuell beurteilt werden, ob dieses Feld ins Archiv eingeschlossen werden darf oder nicht. Ohne einen "Stolperstein" oder Alarm werden solche Dinge leicht vergessen, und so könnte dann entweder ein Feld im Archiv landen, das eine Identifikation von Personen ermöglicht, oder eines fehlen, das für die Forschung interessant gewesen wäre. Unsere Lösung besteht in funktionalen Tests über das Test-Framework Behat: In den Testspezifikationen wird in natürlicher Sprache konfiguriert, welche Daten im Archiv landen sollen und welche ausgespart werden. Die Tests gleichen das mit der Gesamtheit der vorhandenen Felder ab und schlagen fehl, sobald ein Feld existiert, für das keine Entscheidung getroffen ist.

Konkret sieht das dann so aus (Beispiel gekürzt):

Scenario: Normalizing certificate data contained in a multi-activity project (new data model)
    Given an organisation has been created and filled with data
    And a multi-activity project has been created and filled with data
    And an activity of type "Youth Exchange" has been added to the project and filled with data
    And a certificate comprising all activities has been created within the project
    When the certificate data is normalized
    Then the normalized data should contain the following fields:
        | fieldname                     | available |
        | publicCertificateId           | never     |
        | firstName                     | never     |
        | lastName                      | never     |
        | dateOfBirth                   | never     |
        | birthPlace                    | never     |
        | _birthCountry                 | never     |
        | email                         | never     |
        | certificateType               | always    |
        | languages                     | always    |
        | tasks                         | always    |
        | teamMemberRole                | always    |
        | trainingActivities            | always    |
        | lengthOfInvolvement           | always    |
        | activities                    | always    |
        | competences                   | always    |
        | learningOutcomes              | always    |
    And no other fields exist than given in this list

Damit waren wir fast am Ziel – doch eine Aufgabe blieb noch: Wie man in der obigen Definition sieht, werden die Felder tasks und competences ins Archiv aufgenommen, also Beschreibungen der Aufgaben und der Kompetenzentwicklung des Zertifikatsempfängers. In diesen Beschreibungen kann der Name des Zertifikatsempfängers vorkommen, wodurch die Zertifikate nicht mehr vollständig anonymisiert wären. Um dies zu verhindern, ersetzen wir in allen solchen Beschreibungsfeldern den Vor- und Nachnamen sowie die E-Mail-Adresse des Zertifikatsempfängers durch Platzhalter. Auch das sah auf den ersten Blick einfacher aus, als es tatsächlich war: Da Youthpass-Zertifikate mehrsprachig ausgestellt werden können und die Schreibweise des Namens von Sprache zu Sprache variieren kann (z. B. im Falle von griechischen Namen), müssen die Ersetzungen für alle Sprachversionen des Namens vorgenommen werden.

Und noch eine sprachliche Herausforderung begegnete uns: In vielen Sprachen werden die Namen dekliniert, aus Sebastian wird z. B. Sebastians (Aufgabe). Im Deutschen ist das noch relativ einfach, denn es gibt nur das Genitiv-s, das hinten angehängt wird. In anderen europäischen Sprachen gibt es Endungen mit mehreren Buchstaben, oder es fällt ein Buchstabe am Ende des Namens weg, bevor die Endung angehängt wird. Wir haben daher nach einigen Experimenten entschieden, den letzten Buchstaben des Namens zu entfernen und bis zu 4 Buchstaben für die Endung anzuhängen. Um im Fall von kurzen Namen wie Ly nicht jedes Wort, das mit L beginnt, zu ersetzen, wenden wir die Kürzung erst ab Namenslängen von 4 Buchstaben an.

Als wir mit dem "Research Archive" am Ziel waren, hatten wir eine schöne Erkenntnis: Ursprünglich ging es in dem Projekt ja darum, Daten der gelöschten Zertifikate zu Forschungszwecken zu retten. Da wir diese anonymisierten Datensätze jetzt aber schon direkt beim Generieren der Zertifikate erzeugen, können sie sofort für Recherchezwecke eingesehen und für die Weiterentwicklung herangezogen werden, was mit den vollständigen Zertifikaten aufgrund des Personenbezugs nicht möglich war.

Keine Löschung ohne Vorwarnung

Nun war also alles zur Löschung bereit – aber die Nutzer wussten noch nichts davon. Natürlich sollten nicht einfach hunderttausende Datensätze gelöscht werden, ohne die betroffenen Projektverantwortlichen vorher zu informieren. Eventuell wollte ja der ein oder andere auch ein altes Zertifikat noch einmal neu aushändigen.

Zu diesem Zweck zeigen wir jetzt zum einen bei den betroffenen Projekten das Datum der geplanten Löschung als kleinen Warnhinweis in der Projektübersicht an. Zum anderen sollten alle Projektverantwortlichen der zu löschenden Projekte mehrfach per Mail über die geplante Löschung informiert werden: Einmal drei Monate vor der geplanten Löschung, ein zweites Mal einen Monat vorher und ein letztes Mal eine Woche vor der Löschung.

Da wir für jede Vorwarnrunde ca. 50.000 Mails verschicken mussten, haben wir viel Liebe in die Formulierung des Mail-Subjects und des Vorschautexts der Mail gesteckt, um den Empfängern die Information möglichst prägnant zu vermitteln. Für das visuelle Design der Mails konnten wir die Templates einer anderen Benachrichtigungsfunktion, die wir vor einigen Jahren entwickelt haben, verallgemeinern und wiederverwenden.

Auch hier gab es eine noch eine späte Überraschung: Das System ist so aufgebaut, dass es die Mails für jedes Projekt einzeln verschickt. Bei einer Datenanalyse fiel aber auf, dass einige Youthpass-Benutzer weit über 100 Projekte hatten, die bereits zur Löschung anstanden. Es kam nicht in Frage, diesen Nutzern in jeder Vorwarnrunde 100 Mails zu senden. Unser Kunde hat daher die Mails allgemein formuliert, also ohne Bezug auf ein konkretes Projekt, und wir haben einen Mechanismus ergänzt, der E-Mail-Adressen, die vor kurzem bereits eine Benachrichtigung für ein Projekt erhalten haben, beim Versand weiterer Nachrichten der gleichen "Vorwarnstufe" überspringt.

Um das System möglichst robust zu gestalten, gibt es keine festen Zeitpunkte für den Versand der Mails oder die Löschung der Projekte. Nur der erste Mailversand orientiert sich am Enddatum des Projektes, jeder weitere am Datum des vorangegangenen Mailversandes für dieses Projekt. Und die eigentliche Datenlöschung ist an den Zeitpunkt der letzten Warnmail gekoppelt: Frühestens eine Woche, nachdem diese Mail in einem Projekt tatsächlich erfolgreich verschickt wurde, kann das Projekt gelöscht werden. Auf diese Weise ist sichergestellt, dass auch Systemstörungen nicht dazu führen können, dass Projekte ohne ausreichend Vorwarnung gelöscht werden. Das definierte Warnschema (erste, zweite, dritte Warnung mit entsprechenden Abständen) wird immer eingehalten und es kann höchstens zu Verschiebungen nach hinten kommen, was in diesem Fall als das geringste Übel erschien.

Im Zuge der Vorabinformation hat unser Kunde das Verfahren auch auf der Website beschrieben: https://www.youthpass.eu/en/help/deletion/

Zu guter Letzt: Marie Kondo-ing Youthpass!

Nach all dieser Vorarbeit war die eigentliche Löschung der Projekte schnell implementiert: Da wir bereits vor einigen Jahren durch die Einführung sogenannter Fremdschlüsselbeziehungen in der Datenbank definiert hatten, welche der unterschiedlichen Datensätze wie miteinander zusammenhängen, mussten nun nur noch die Projekte, die tatsächlich zur Löschung reif waren (also die vor mindestens einer Woche die dritte Warnmail erhalten hatten), aus der Datenbank gelöscht werden. Die zugehörigen Teilnehmer- und Generierungsinformationen wurden über die Fremdschlüssel automatisch mit entfernt. Außerdem musste das System noch die zugehörigen PDF-Dateien, die in einem Dateiablagesystem verwaltet werden, löschen. Das war eine Neuerung: In den Anfangsjahren von Youthpass war es eine ausdrückliche Anforderung, dass alle jemals generierten PDFs aus Gründen der Nachvollziehbarkeit und des Schutzes vor Missbrauchs dauerhaft aufbewahrt werden sollten. Das musste nun (aus heutiger Sicht erfreulicherweise) geändert werden, sodass nur noch PDFs aufgehoben werden, die noch benötigt werden.

Und schließlich war es soweit: Die Löschung konnte erfolgreich umgesetzt werden und auf dem Weg dahin hat Youthpass noch einige strukturelle Verbesserungen erfahren. Nicht nur wir sind zufrieden, auch unsere Kunden. Via GitHub schrieb uns Kundin Eda:

Yuhu! Great! Thanks for Marie Kondo-ing Youthpass :D

Der Verkehrsverbund hat uns kürzlich vor die Wahl gestellt, ob wir das alte JobTicket behalten wollen oder auf das Deutschlandticket wechseln. Eigentlich eine einfache Entscheidung, wären da nicht die Mitnahmeregelungen: Beim JobTicket konnte man täglich ab 15 Uhr 3 Kinder mitnehmen und Abends und am Wochenende zusätzlich noch einen Erwachsenen und ein Fahrrad. Beim Deutschlandticket fällt das alles weg.

Auf der Haben-Seite für das Deutschlandticket steht der günstige Preis: Für die Differenz von 36 € pro Monat kann man ganz schön viele Einzeltickets für Kinder und Partner kaufen – und schon fast ein zusätzliches Deutschlandticket. Und natürlich die deutschlandweite Gültigkeit: Nicht alleine für die inzwischen zwei Kollegen, die weit weg von Bonn wohnen, ist das Deutschlandticket natürlich viel attraktiver.

Wir haben daher in einem ersten Schritt im Team gefragt, wer die Mitnahmemöglichkeiten regelmäßig nutzt bzw. auf sie angewiesen ist. Das war nur bei zwei Kollegen der Fall und nicht so häufig, dass Einzeltickets keine Alternative wären.

Also haben wir entschieden, auf das Deutschlandticket zu wechseln (dessen Entwicklung und Einführung in Deutschland ich für eine enorme Leistung halte).

Blieb noch die Frage nach dem Preis: Für das alte JobTicket hat die webfactory einen Arbeitgeberanteil von 44 € übernommen, der Arbeitnehmer musste 36,50 € zuzahlen. Der neue Preis beträgt nur noch 46 €. Wem sollte also die Ersparnis zu Gute kommen?

Bei unverändertem Arbeitgeberzuschuss wäre das Ticket fast gratis gewesen. Wir haben daher auch mit dem Gedanken geliebäugelt, das Ticket gratis anzubieten. Auf der anderen Seite wollten wir auch einen Anreiz schaffen, das Ticket wirklich zu nutzen und es sich nicht einfach nur schenken zu lassen, weil es gratis ist. Daher wollten wir, dass man zumindest eine bewusste Entscheidung trifft und dafür einen mindestens symbolischen Eigenanteil erheben.

Und da schien uns dann ein Preis von 9 €, zu dem das Ticket ja im Sommer 2022 das erste Mal das Licht der Welt erblickt hat und großen Erfolg hatte, eine gute Lösung. Im Vergleich zum JobTicket hat dann der Ticketnutzer 27 € mehr im Portemonnaie, die er z. B. für Einzeltickets für Mitfahrer nutzen kann. Und die Firma spart auch noch 7 € pro Ticket.

Im Jahr 1995 gründeten Philipp Bosch, Matthias Pigulla und ich zusammen mit anderen eine Schülerzeitung am Clara-Schumann-Gymnasium in Bonn, die wir "Clarasil" nannten. Wir waren damals in der 10. Klasse, kurz vor den Sommerferien erschien unsere erste Ausgabe. Wenig später bekam Philipp sein erstes Modem und schaute sich in den Mailboxen der Region um. Von dort aus war es nicht weit bis zum World Wide Web, das damals in den Kinderschuhen steckte: erst 1993 war der erste Webbrowser auf den Markt gekommen. Philipp begann als Tüftler sofort damit, zu ergründen, wie man eine Website erstellt, und erstellte einen ersten Auftritt für Clarasil.

1996 startete "Schulen ans Netz", eine Initiative der Deutschen Telekom und des Bundesministeriums für Bildung und Forschung, die allen Schulen einen Internetzugang ermöglichen sollte. Auf einer großen Fachtagung in der Telekom-Zentrale in Bonn sollten sich Lehrer und andere Experten aus ganz Deutschland über die Möglichkeiten austauschen, das Internet in Schulen zu nutzen. Der damalige Pressereferent der Deutschen Telekom hatte die Idee, für die Fachtagung eine Online-Berichterstattung zu organisieren – und kontaktierte die Clarasil-Redaktion, da wir ja bereits Erfahrung mit dem Internet hatten. Für die Programmierung der Website hatte er eine Internetagentur aus Bremen gewonnen. Das kränkte uns natürlich in unserer Ehre und die Gestaltung der Website fanden wir langweilig. So kam es, dass unsere Redaktion am ersten Tag der Fachkonferenz nicht nur Artikel schrieb, sondern Philipp, Matthias und ich parallel bis in die Nacht hinein daran arbeiteten, ein neues Design für die Website zu entwickeln und umzusetzen. Als wir die neue Seite am nächsten Morgen den Verantwortlichen für die Fachtagung präsentierten, waren sie so begeistert, dass sie uns auf die Bühne baten, um uns den versammelten Teilnehmern der Konferenz vorzustellen. Schließlich verkörperten wir genau das, was der Verein erreichen wollte: Schüler, die Medienkompetenz für das Internet zeigten.

Die Konferenz hatte noch eine wesentliche Nachwirkung: Der Verein "Schulen ans Netz" kontaktierte uns im Anschluss mit der Anfrage, ob wir nicht auch die Vereinswebsite neu gestalten könnten. Wir sagten zu und vereinbarten einen Preis von 2500 DM (gut 1250 €). So hatten wir im Herbst 1996 unseren ersten kommerziellen Auftrag und beschlossen kurzerhand, dass wir eine Firma gründen müssten. Gesagt, getan: Im Dezember 1996 gingen wir zum Gewerbeamt der Stadt Bonn und meldeten eine GbR zur Entwicklung von Websites an. Matthias und ich waren gerade volljährig geworden, Philipp musste noch von seiner Mutter begleitet werden.

Die ersten Kunden

Nachdem die Website für Schulen ans Netz fertig war, hatten wir viele Anfragen aus dem engeren Familien- und Bekanntenkreis. So entwickelten wir eine Website für den Deutschen Juristinnenbund, dessen Geschäftsführerin Philipps Mutter war, und für die Junge Presse Nordrhein-Westfalen, deren Vorstandsmitglieder unser Schülerzeitungsseminar als Referenten betreut hatten. Und über die Junge Presse wiederum kamen wir in Kontakt mit dem Gründer eines Startups für Börsennachrichten, wallstreet:online. Kurz zuvor war die Deutsche Telekom an die Börse gegangen und hatte für ihre "Volksaktie" ein deutschlandweites Börsenfieber angeheizt – entsprechend groß war der Bedarf an Information und Austausch. So saßen wir tagsüber im Unterricht und programmierten nachmittags und manchmal nachts an einem Redaktionssystem für die Nachrichten, an einem Diskussionsforum für 300.000 Mitglieder, einem Live-Chat, Kursdiagrammen und vielem mehr, was wallstreet:online sich ausdachte. Gleichzeitig mussten wir den Serverbetrieb aufbauen und skalieren, denn die Website machte damals schon mehrere 100 GB Traffic pro Monat (und würde damit heute noch zu unseren größten Kunden gehören).

In diese Zeit fiel es auch, dass ein übermüdeter webfactorianer nach Mitternacht das Kommando rm -rf * ~ eingab und damit den kompletten Quellcode für die Benutzerverwaltung und das Diskussionsforum löschte. Eigentlich wollte er nur aufräumen und die beim Bearbeiten automatisch erstellten Kopien jeder Datei löschen, aber das unachtsam eingefügtes Leerzeichen hinter dem * führte dazu, dass der Befehl sich auf alle Dateien erstreckte. Ich weiß nicht mehr, wie wir es geschafft haben, das Diskussionsforum dann innerhalb von kurzer Zeit neu zu schreiben. Aber ich weiß, dass wir uns an diesem Tag geschworen haben, nie wieder ohne Backups zu arbeiten.

Abitur und Zivildienst

Im Sommer 1998 machten wir Abitur und waren froh, nicht weiter den halben Tag in der Schule sitzen zu müssen. Ein weiterer Kunde stieß über unsere Kontakte vom Schülerzeitungsseminar zu uns: Projekt PR, eine Bonner Agentur, die unter anderem die AIDS-Kampagne der Bundeszentrale für gesundheitliche Aufklärung und den Bundestagswahlkampf der Grünen betreut hatte und nun eine Website brauchte. Das sollte großen Einfluss auf unsere Entwicklung haben.

Wir waren eine Web-Agentur mit einem großen Kunden, der uns beachtliche Webhosting-Umsätze bescherte, und brauchten natürlich endlich ein Büro, denn wir wollten Kundentermine nicht weiter in unseren Kinderzimmern oder in Cafés wahrnehmen. Also hatten wir uns auf die Suche gemacht und von einer Dachetage über einer kleinen Autowerkstatt neben dem Rotlichtviertel bis hin zu einer repräsentativen Büroetage vis-a-vis des Poppelsdorfer Schlosses alle möglichen Büros angeschaut. Möglicherweise hätten wir die repräsentative Büroetage für damals 6000 DM Monatsmiete gemietet und es wäre unser Ruin gewesen – wenn nicht der Geschäftsführer von Projekt PR uns überzeugt hätte, in sein Büro mit einzuziehen. Die Agentur hatte sich gerade von 15 auf 3 Mitarbeiter verkleinert und hatte dementsprechend Platz übrig. Und sie hatte einen Kopierer, ein Sekretariat und eine Kaffeemaschine. So kamen wir an unser erstes Büro in der Lessingstraße 60 in der schönen Bonner Südstadt.

Im Spätsommer begannen wir drei dann unseren Zivildienst – weit verstreut: Philipp in einem Bildungswerk in der Eifel, Matthias in einer Bonner Klinik und ich in der invidivuellen Schwerstbehindertenbetreuung. Ich hatte die webfactory-freundlichsten Arbeitszeiten: Auf 4 Tage Dienst rund um die Uhr folgten 12 Tage frei, die ich natürlich nutzte, um das schöne Büro zu genießen. Während unserer Abwesenheit freuten wir uns über den Sekretariatsservice von Projekt PR, der uns auf ein ganz neues "Professionalitäts-Level" brachte.

In dieser Zeit besuchte uns auch ein Filmteam, um uns als Musterbeispiel für Erfolge des Programms Schulen ans Netz zu portraitieren. Für diesen Film mussten wir dann auch ganz schnell ein Firmenschild haben und entschieden uns, den Freiraum auf dem Schild von Projekt PR für einen webfactory-Aufkleber zu nutzen. Dieses Schild sollte dann für 10 Jahre so bleiben.

wfDynamic

Fast alle unserer frühen Kunden wollten Nachrichten auf ihrer Website veröffentlichen. Für jede Meldung immer eine handgebaute HTML-Seiten zu erstellen, war eine ziemlich zähe, langweilige, aber gleichzeitig zeitkritische Aufgabe. Da wir für für wallstreet:online bereits Erfahrungen mit Datenbanken gemacht hatten, entschieden wir, dass wir für alle unsere Kunden ein Redaktionssystem anbieten wollten, über das sie ihre Nachrichten selbst einpflegen könnten. Da jeder Kunde ein bisschen anders war, sollte es von Beginn an für individuelle Datenbankstrukturen anpassbar sein.

Projekt PR war dann der erste Kunde, der auf seiner Website nicht nur Textmeldungen veröffentlichen wollte, sondern Referenzen mit Bildern, z. B. von Plakatmotiven. Die Herausforderung nahmen wir an und lernten erst, wie man Dateien über ein Webformular hochlädt und in eine Datenbank speichert und dann, wie man diese Dateien automatisch in eine fürs Web passende Auflösung herunterrechnet.

Für den nächsten Kunden wollten wir dann noch Texte in eine Hierarchie bringen, also nicht nur eine Liste von Pressemitteilungen oder Referenzen pflegbar machen, sondern eine ganze Seitenstruktur.

Fertig war wfDynamic, ein Redaktionssystem, mit dem man die komplette Struktur der Seite anlegen und bearbeiten, Bilder hochladen und beliebige Inhaltstypen pflegen konnte. Und wfDynamic bescherte uns jede Menge Kunden.

Übrigens kam von Projekt PR schon damals die Idee, dass wir das System nicht gegen einen Einmalbetrag, sondern für eine Monatsmiete abgeben sollten. So ist die Finanzierung der Weiterentwicklung jederzeit gesichert. Und www.projekt-pr.de ist unsere dienstälteste, seit 1999 unverändert in Betrieb befindliche Website.

Studium und erste Mitarbeiter

Nach dem Zivildienst begannen zwei von uns ein Studium an der Universität Köln: Matthias in Wirtschaftsinformatik und ich in Betriebswirtschaftslehre. Philipp entschied sich, die Stellung im Bonner Büro zu halten.

Im Zuge der damals herrschenden Goldgräberstimmung am "Neuen Markt" der Deutschen Börse gewannen wir die auf Investor Relations spezialisierte Agentur Haubrok als Kunden. Für Haubrok realisierten wir nicht nur die Unternehmenswebsite, sondern auch eine Kontaktverwaltungslösung mit Newslettersystem, die wir wfContacts tauften und die inzwischen auf wfDynamic basiert. Haubrok brachte uns zudem in Kontakt mit verschiedenen Kunden, die im Zuge ihres Börsengangs neue Websites brauchten.

Ende 1999 fanden wir es an der Zeit, uns eine neue, "erwachsenere" Rechtsform zu geben, und gründeten zum 01.01.2000 die webfactory GmbH mit Philipp, Matthias und mir als gleichberechtigten Anteilseignern.

Im Jahr 2000 stellten wir dann unseren ersten Mitarbeiter ein, um unsere Arbeit auf mehr Schultern verteilen zu können. Leider lief die Zusammenarbeit nicht so gut, wie wir uns das vorgestellt hatten, sodass wir uns nach einem halben Jahr wieder trennten. Die Idee personeller Verstärkung ließ uns aber nicht los, und so stellten wir 2001 erneut einen Webentwickler ein, Christian, der uns für mehrere Jahre unterstützte und verschiedene bis heute aktive Websites mit entwickelte, darunter www.buechi-yachting.com.

JUGEND für Europa

Im Jahr 2001 beauftragte uns die Nationalagentur für das EU-Aktionsprogramm JUGEND mit der Entwicklung eines Online-Fortbildungskalenders für Fachkräfte der Jugendarbeit. Jeder, der eine entsprechende Fortbildung organisierte, sollte diese selbst eintragen können. JUGEND für Europa, die Nationalagentur, würde die Angebote dann prüfen und freischalten und Interessierte sollten sich online dafür anmelden können.

Aus dieser Zusammenarbeit entstand unsere bis heute intensivste Kundenbeziehung. Zunächst entwickelten wir 2003 eine Gruppe von mehreren unterschiedlich gestalteten Websites mit einheitlichem Content-Management-System für verschiedene Zielgruppen des Förderprogramms JUGEND. Eine davon war der Youthreporter, eine Blogplattform für jugendliche Teilnehmer des Förderprogramms hinzu, die 19 Jahre lang aktiv bleiben sollte und über die fast 13.500 Beiträge veröffentlicht wurden.

Später entwickelte JUGEND für Europa das Konzept für ein europaweites Instrument zur Anerkennung nicht-formalen Lernens: Den Youthpass. Youthpass beschreibt zum einen einen Prozess, wie Projekte der internationalen Jugendarbeit so organisiert werden können, dass die Teilnehmer sich ihrer eigenen Lernerfahrungen bewusst werden. Er bietet aber zugleich auch ein Zertifikat, über das diese Lernerfahrungen dokumentiert werden können. Hierfür entwickeln wir seit 2006 die technische Plattform auf www.youthpass.eu. Youthpass ist offizieller Bestandteil des Förderprogramms und jeder Teilnehmer hat das Recht auf ein Zertifikat. Bis heute sind fast 1,5 Millionen Youthpass-Zertifikate über das System erstellt worden. Seit 2020 befinden wir uns in einem intensiven Weiterentwicklungs- und Modernisierungsprozess.

2009 entwickelten wir für JUGEND für Europa zudem ein Online-Anmeldesystem für die Buchung der Begleitseminare, an denen Freiwillige im Europäischen Freiwilligendienst (heute Solidaritätskorps) teilnehmen. Organisationen, die einen Freiwilligen betreuen, können sich online in dem System registrieren und ihren Freiwilligen für die passenden Seminare anmelden. Dabei wird automatisch berücksichtigt, für welche Seminare noch Plätze frei sind. Die Seminarveranstalter können sich dann über wfDynamic fertige Teilnehmerlisten für ihre Seminare herunterladen. Bis heute wurden über 8000 Freiwillige über das System zu ihren Seminaren angemeldet.

Aus einer internationalisierten Version des Fortbildungskalenders entstand 2001 das Webportal SALTO-YOUTH.net, das die Zusammenarbeit und Vernetzung zwischen Fachkräften der Jugendarbeit in ganz europa unterstützt.

Ruhrtriennale

Über die Zusammenarbeit mit Haubrok kamen wir 2002 in Kontakt mit der prominenten Werbeagentur Boros, die für einen Kunden ein Content-Management-System suchte. Bei dem Kunden handelte es sich um die Ruhrtriennale, ein neu geschaffenes Kulturfestival, das Industriebrachen im Ruhrgebiet mit neuem Leben erfüllte. Boros entwickelte das Webdesign, wir die dahinterliegende Software. Die Ruhrtriennale betreuten wir über vier Intendanzen hinweg (Gerard Mortier, Jürgen Flimm, Willy Decker, Heiner Goebbels) bis 2015.

wfDynamic 3

Aufgrund von verschiedenen Kundenwünschen entschieden wir uns, wfDynamic von Grund auf neu zu entwickeln und mit professionellen Redaktionsfunktionen auszustatten. Die Ruhrtriennale sollte das erste Projekt werden, für das die Version 3 unseres Content-Management-Systems zum Einsatz kam. Kern des Systems war eine Hierarchie von Seiten, die in verschiedenen Versionen existieren konnten, mit einem Freigabeworkflow. Sämtliche Inhalte sollten in beliebig vielen Sprachen angelegt werden können. Dafür opferten wir die Flexibilität im Datenmodell. Es war durch die kompliziertere Datenbankstruktur wesentlich weniger einfach als in wfDynamic 2, neue Datentypen anzulegen. Zugleich war die Ausgabe der in wfDynamic erfassten Inhalte wesentlich umständlicher und rechenaufwändiger, da zum Beispiel für den Aufbau einer Seite mit einer Navigation und einer Liste von Terminen zunächst für eine große Zahl von Datensätzen die richtige, freigegebe Version in der richtigen Sprache geladen werden musste.

Letztendlich war die Entwicklung von Systemen auf Basis von wfDynamic 3 unverhältnismäßig viel teurer als auf Basis von wfDynamic 2, sodass wir nur wenige Kunden für das neue System gewinnen konnten. Schließlich entschieden wir uns, in Zukunft wieder auf Basis von wfDynamic 2 weiterzuentwickeln. Aus wfDynamic 3 übernahmen wir Innovationen, die sich bewährt hatten – unter anderem das bis heute aktuelle, fensterbasierte User Interface.

Azubis in der webfactory

2005 entschieden wir uns, unseren ersten Auszubildenden zum Fachinformatiker für Anwendungsentwicklung aufzunehmen. Matthias war fast fertig mit seinem Wirtschaftsinformatik-Studium und fühlte sich reif für die Weitergabe seines Wissens. Per war in Rekordzeit mit der Ausbildung fertig und legte Anfang Januar 2007 seine Abschlussprüfung ab. Die positive Erfahrung bestärkte uns darin, direkt im Sommer 2007 unseren zweiten Auszubildenden aufzunehmen. Diesmal entschieden wir uns gemeinsam mit Søren, dass er ein Mediengestalter für Digital- und Printmedien werden würde. Auch Søren war von Beginn an eine große Bereicherung des Teams, sodass wir direkt 2008 mit Herman einen weiteren Azubi zum Mediengestalter aufnahmen und 2010 dann parallel einen angehenden Fachinformatiker, Simon, und Jessica als angehende Mediengestalterin. 2011 legten wir nach mit Benjamin als weiterem Fachinformatiker und Marc als weiterem Mediengestalter. 2016 folge noch Konstantin, ein weiterer Fachinformatiker und 2018 kamen schließlich Jano als Fachinformatiker und Lukas als Mediengestalter, sodass wir bis heute 10 junge Menschen ausgebildet haben.

Der Gemeinsame Bundesausschuss

Im Jahr 2006 gewannen wir eine Ausschreibung für die technische Implementierung der Website des Gemeinsamen Bundesausschusses (G-BA). Der G-BA ist das Gremium, in dem Ärzte- und Krankenhausvertreter mit den Krankenkassen und Patientenvertretern über den Leistungskatalog der gesetzlichen Krankenversicherung in Deutschland entscheiden. Diese Entscheidungen sollten öffentlich auf der Website dokumentiert werden. Der G-BA war 2004 ins Leben gerufen worden und hatte schon einige hundert Entscheidungen getroffen, die alle manuell und ohne strukturierte Erfassung auf die Website hochgeladen worden waren. Dementsprechend hoch war der Veränderungsdruck. Die Agentur für Wissenschaftskommunikation Bosse und Meinhard hatte für die Website eine ausgeklügelte Informationsarchitektur entwickelt, die es nun technisch umzusetzen galt.

Bis heute basiert die Website www.g-ba.de auf dieser Informationsarchitektur und auf dem damals entwickelten Datenmodell und Programmcode, obwohl sie inzwischen gestalterisch mehrfach gerelauncht und erweitert wurde.

Für den G-BA entwickelten wir in den Folgejahren auch weitere Anwendungen, unter anderem ein Extranetsystem, das heute von 8 verschiedenen Abteilungen genutzt wird und den Versand von Tausenden von CD-ROMs an die Entscheidungsträger im Vorfeld der Gremiensitzungen einsparte. Auch weitere Websites und Anwendungen entstanden für den G-BA, unter anderem ein Online-Tool für Krankenhäuser zur Erfassung der Meldebögen für die Festlegung des sogenannten Systemzuschlags (systemzuschlag.g-ba.de), ein Online-Bestellsystem für Druckerzeugnisse (druckerzeugnisse.g-ba.de) und die Website des Innovationsausschusses beim G-BA (innovationsfonds.g-ba.de).

Umbau in Bonn und Standort Berlin

Im Jahr 2007 stellten wir fest, dass unser unser Teppichboden inzwischen zu fleckig war, und beschlossen, zu renovieren. Und wenn man Teppiche tauscht, muss man nicht nur das ganze Büro leer räumen, sondern wird automatisch mit der Frage konfrontiert, ob man anschließend die gleichen Möbel wieder an ihre alten Stellen stellen möchte. Und so wurde daraus unser bis dahin größtes internes Projekt: Das neue webfactory-Büro, das wir 2008 mit einer großen "11 Jahre"-Party einweihten.

Kurze Zeit später entschied sich unser Gründungsmitglied Philipp Bosch, seinen Lebensmittelpunkt nach Berlin zu verlegen und wir eröffneten dort eine kleine Ein-Mann-Dependance. Leider stellte sich das nicht als dauerhaft zufriedenstellende Lösung heraus, eine Person in Berlin und 5 Kollegen in Bonn, und Philipp entschied sich schweren Herzens, die webfactory zu verlassen.

Webanwendung "Sicherer IT-Betrieb"

2010 gewannen wir den Auftrag, für das Informatikzentrum der Sparkassenorganisation eine Webanwendung zu entwickeln, über die Sicherheitsaudits in Banken durchgeführt werden sollten. Ein großes Projekt mit einem hohen Anspruch, für das wir uns mächtig ins Zeug legten. Wir entwickelten eine Anwendung, über die hunderte Fragen, die eine Bank im Rahmen der Auditierung beantworten musste, über mehrere Stufen an denjenigen Sachbearbeiter delegiert werden konnten, der sie am besten beantworten konnte. Hatte der seine Antwort fertiggestellt, reichte er sie bei der Person ein, die die Frage an ihn delegiert hatte, und diese dann wiederum bei ihrem Vorgesetzten – die ganze Delegationskette entlang bis zum Leiter des Audits. Das Webbasierte Audit sahen wir als unser Meisterstück der Webentwicklung.

Personelle Veränderungen

2011 überschritten wir dank unserer vielen Azubis erstmalig die Schwelle von 10 Mitarbeitern. Wir brauchten zum einen mehr Platz, zum anderen mussten wir uns besser koordinieren. Wir stellten daher im Laufe des Jahres zwei Projektmanager ein. Und wir nutzten die Gelegenheit, dass die Weinhandlung gegenüber umzog, zur Erweiterung unserer Räumlichkeiten: Das webfactory-Lab war geboren.

2013 verließ uns unser erster Auszubildender Per nach 8 Jahren toller Zusammenarbeit, um sich neuen Herausforderungen zu stellen. Immerhin nicht ohne uns direkt zwei neue Mitarbeiter zu vermitteln, die er beim "Code and Coffee" kennengelernt hatte. Einer der beiden war Malte, der erste Diplom-Informatiker im webfactory-Team.

2014 verließ uns dann auch unser zweiter Auszubildender Søren, um auf Wanderschaft zu gehen. Nach Stationen bei Sapient Nitro (heute PublicisSapient) und Chefkoch konnten wir ihn 2017 überzeugen, zu uns zurückzukehren – bereichert um jede Menge Erfahrungen aus unterschiedlichsten Großprojekten.

Kurz nach Sørens Weggang konnten wir Stefan als neuen Frontend-Entwickler gewinnen, der unser Team seitdem verstärkt.

2014 war insgesamt ein turbulentes Jahr, in dem wir kurzzeitig Angst um unsere Existenz hatten (verschiedene Kunden hatten Aufträge zurückgestellt) und uns im Sommer daher schweren Herzens entschieden, zwei betriebsbedingte Kündigungen auszusprechen. Damit uns das nie wieder passiert, haben wir uns entschieden, Rücklagen aufzubauen, um Durststrecken überwinden zu können. Und hierfür vor allem besser und realistischer zu kalkulieren und abzurechnen als vorher. Es entstand unser T-Shirt-Größen-Verfahren für die Aufwandsschätzung.

Vorträge und Meetups

Seit 2013 geben wir unser Wissen nicht nur in Form von betrieblicher Ausbildung weiter, sondern halten auch Vorträge auf Meetups und Konferenzen. Den Anfang machte Matthias mit seinem Vortrag Marry Me...? über die schrittweise Migration von Altcode auf Symfony 2. Dieser erste Vortrag bei der Symfony User Group Köln machte gleich in doppelter Hinsicht Lust auf mehr: Wir beschlossen, dass wir Meetups toll finden und selbst in unserem neuen Lab welche hosten würden. Im Laufe der Jahre hatten wir die BonnAgile bei uns zu Gast, den Scrumtisch Bonn und mehrmals die UXBN und das Bonn Data Science Meetup. Und Matthias beschloss, dass es ihm Spaß macht, Vorträge zu halten.

2017 folgte Matthias' erster Vortrag auf einer großen Konferenz, der Symfony Live, mit einer Fallstudie über die Nutzung des Specification-Patterns in der Website der Staatsoper Berlin. 2018 legte er nach und präsentierte das Paketmanagement mit Composer auf der Symfony Live im Phantasialand, und 2019 bei der SymfonyCon Amsterdam über das HTTP Caching in Symfony. Malte übernahm den Staffelstab und hat inzwischen diverse Vorträge auf der FrOSCon in Sankt Augustin und der SymfonyWorld Online gehalten, unter anderem Extraktion von Microservices aus einer monolithischen Webanwendung, PHP-Anwendungen toolgestützt aktualisieren, Tools for Upgrading Symfony Applications und Mit Pull Requests arbeiten. Der bislang einzige Kollege, der je einen Vortrag auf einer von der webfactory ausgerichteten Veranstaltung gehalten hat, ist Søren – und das nicht nur einmal: Auf der UXBN im Dezember 2017 sprach er über Performance als Usability-Ziel und im April 2019 über Usability bei Web-Formularen.

Unternehmenswert Mensch

Ein schwelender Konflikt und schlechte Stimmung im Team brachten uns 2016 in Kontakt mit der Psychologin und Prozessberaterin Lucie Lewandowski und diese wiederum mit dem Förderprogramm "Unternehmenswert Mensch", das zum Ziel hat, Unternehmen dabei zu unterstützen, mitarbeiterorientierte und wertschätzende Führung zu etablieren. Natürlich waren wir vorher schon davon überzeugt, dass die webfactory super mitarbeiterorientiert wäre – aber die Prozessberatung, im Rahmen derer wir uns über mehrere Monate regelmäßig mit "unserer Psychologin" trafen, hat uns rückblickend extrem weitergebracht und uns für vieles die Augen geöffnet. Zum Beispiel dafür, dass es Unterschiede zwischen Geschäftsführern und dem Rest des Teams gibt, die nicht einfach weggehen, indem man sagt "wir sind hier alle gleich". Oder, dass man nicht allein dadurch ein diverses Team hat, dass man sagt, dass jeder machen kann, was er will und sein kann, wie er will. Oder, dass man auch bei internen Prozessen dafür sorgen muss, dass sie nicht ergebnislos im Sand verlaufen. Die bis heute prägendsten Ergebnisse der Beratung sind die soziokratische Entscheidungsfindung, die explizite Ermächtigung des Teams, dass jeder alles kaufen darf, was er braucht (mehr zu den beiden Punkten im Artikel über unsere Unternehmenskultur) und unser monatliches "Interne Baustellen"-Meeting (hierzu mehr in "Unser Besprechungs-Stundenplan"). Und, nicht zu vergessen: dass wir zu Beginn jeder Besprechung "ankoppeln", also jeder kurz berichtet, wie es ihm geht.

Staatsoper Berlin und Staatstheater Darmstadt

Kaum schließt sich eine Tür im Leben, öffnet sich eine neue: Das Marketing-Team der Ruhrtriennale hatte Ende 2014 nach über 13 Jahren Zusammenarbeit entschieden, sich einen neuen Partner für die Betreuung der Website zu suchen. Doch wir hatten nicht lange Zeit, den Verlust unseres Kultur-Kunden zu betrauern: im Frühjahr 2015 meldete sich die Staatsoper Berlin bei uns. Deren Marketingleiterin war dem Intendanten Jürgen Flimm von der Ruhrtriennale an die Staatsoper gefolgt und hatte die Zusammenarbeit mit uns in bester Erinnerung. Und so kamen wir zu der Ehre, zunächst eine Website für die Staatskapelle Berlin unter Daniel Barenboim zu entwickeln (pünktlich zu deren 450-jährigem Jubiläum) und anschließend die Website der Staatsoper Berlin auf das für die Staatskapelle konzipierte Content-Management-System auf der Basis von wfDynamic umzustellen.

Noch bevor die Website der Staatsoper online ging, entschied sich auch das Staatstheater Darmstadt zu einem Relaunch seiner Website auf Basis von Symfony und wfDynamic. Da wir nun drei Theaterwebsites entwickeln mussten, entschieden wir uns, hierfür ein wiederverwendbares Softwarepaket zu entwickeln: Es entstand das "Bacchus-Bundle", das die Kernfunktionalität für eine Theaterwebsite bündelt. Die Pflege von Produktionen und Terminen sowie Spielstätten, Künstlern und Besetzungen und die Generierung von Spielplänen muss nun nicht mehr für jedes Theater individuell programmiert werden, sondern steht über das Paket zur Verfügung. Auch Schnittstellen zu verschiedenen Ticketsystemen (Eventim Inhouse und Bilettix) sowie der Dispositionssoftware Theasoft haben wir inzwischen für die Theater realisiert und pflegen mit beiden Häusern eine intensive Zusammenarbeit bei der Weiterentwicklung der Onlineangebote. Das schöne am Bacchus-Bundle ist, dass diese Weiterentwicklungen allen zu Gute kommen.

Kaffee-Sponsoring auf Konferenzen

Die Projektlage Anfang 2017 war somit sehr erfreulich – leider verließen uns im ersten Halbjahr drei Mitarbeiter, und das, nachdem bereits im Sommer 2016 ein Entwickler aus Bonn weggezogen war und daher den Arbeitgeber wechseln musste (es war vor Corona und 100% remote arbeiten war damals bei der webfactory noch unvorstellbar). Vor diesem Hintergrund entschieden wir, dass unsere gerade neu angeworbene Kollegin Eva, die ihre Promotion in Biologie zu Gunsten der webfactory aufgegeben hatte, erst einmal intensiv um neue Mitarbeiter werben sollte. Ihr erstes Projekt war die Organisation eines Kaffeestandes auf der FrOSCon 2017, einer renommierten Open Source-Software-Konferenz in Sankt Augustin bei Bonn. Hierfür arbeiteten wir mit Ruth Außenhofer zusammen, die einen exzellenten Baristaservice betreibt. Und natürlich musste es stilvoll zugehen, daher ließen wir in Italien Cappuccinotassen mit webfactory- und FrOSCon-Logo produzieren.

Da die Zusammenarbeit uns sehr viel Spaß gemacht hatte, entschieden wir uns, im Frühjahr 2018 einen Schritt weiterzugehen und auch den Kaffeestand auf der Symfony Live zu übernehmen, die damals im Phantasialand stattfand, einem großen Freizeitpark zwischen Bonn und Köln. Leider fand die Symfony Live danach nicht mehr im Rheinland statt sondern zog nach Berlin – für uns ein Grund abzuspringen, denn der Organisationsaufwand war ohnehin eigentlich zu hoch für eine kleine Firma wie uns, und auch Ruth wäre mit ihrer Kaffeemaschine vermutlich nicht nach Berlin gereist.

Citylight-Werbung um neue Mitarbeiter

Für die Mitarbeitergewinnung hat sich ein anderes Instrument besser bewährt: Anfang 2018 schalteten wir sogenannte Citylight-Poster an Bonner Bus- und Bahnhaltestellen. Unter anderem am Uni-Hauptgebäude, am Bonner Hauptbahnhof und am Konrad-Adenauer-Platz in Beuel. Und siehe da: Das Plakat in Beuel war der letzte Schubs, den ein Mitschüler unseres ehemaligen Auszubildenden Benjamin brauchte, um sich endlich bei uns zu bewerben. Wenige Wochen später durften wir Martin als neuen Softwareentwickler im Team begrüßen.

Ganz ohne Werbung, sondern durch reines Vitamin B, kamen zwei andere geschätzte Kollegen zu uns ins Team: Ich hatte zum 100-jährigen Jubiläum meiner früheren Schule, des Bonner Clara-Schumann-Gymnasiums, angefangen, im Schulchor mitzusingen. Dort sang ich mit Jano zusammen im Tenor. Und in der Mittagspause eines Probenwochenendes kamen wir darauf zu sprechen, dass er plante, Informatik zu studieren und schon jede Menge Erfahrung mit PHP und Linux hatte. Ich erzählte natürlich, dass ich in einer Webagentur arbeite, die auf PHP spezialisiert ist, und wir händeringend neue Kollegen suchen. Es dauerte nicht lange, bis Jano als Werksstudent bei uns anfing und sich schließlich sogar entschied, sein Studium aufzugeben zugunsten einer Ausbildung bei uns.

Lukas hingegen erwähnte gegenüber dem Freund seines Vaters, dass er sich für Gestaltung interessierte – und der Freund seines Vaters war ein guter Freund unseres Teammitglieds Stefan. So kam es dazu, dass Lukas nach der Schule ein Praktikum bei uns machte (mehr dazu im seinem spannenden Praktikumsbericht) und sich schließlich entschied, eine Ausbildung zum Mediengestalter bei uns zu absolvieren. Dafür nahm er nach reiflicher Überlegung sogar eine Fernbeziehung in Kauf. Glücklicherweise hat die Beziehung die räumliche Trennung gut überstanden und Lukas lebt inzwischen dank Homeoffice wieder mit seiner Freundin zusammen im Sauerland.

Das neue webfactory-Büro

Da auch Søren inzwischen zur webfactory zurückgekehrt war, war uns unser Büro nun langsam zu klein. Und auch hier half uns das Schicksal, unsere Trägheit zu überwinden: Das Haus in der Lessingstraße 60 wurde an einen neuen Eigentümer verkauft, der nicht nur sehr genaue Vorstellungen mitbrachte, was wir in unseren Kellerräumen lagern dürften und was nicht, sondern kurze Zeit später auch unsere Miete drastisch erhöhen wollte. Daher begannen wir, uns auf Immobilienbörsen nach anderen Mietobjekten in der Nähe umzuschauen – und wurden in der Heinrich-von-Kleist-Straße fündig. Das neue Büro, lustigerweise direkt neben meinem früheren Kindergarten gelegen, war gerade frisch saniert und schlug Matthias und mich direkt bei der ersten Besichtigung in seinen Bann. Es war mit 220qm fast doppelt so groß wie das alte Büro und sollte somit genug Platz für die weitere Entwicklung bieten.

Kurzerhand  unterschrieben wir den Mietvertrag, aktivierten unsere Lieblingshandwerker Mark Hesterbrink und Michael Schuh, damit sie möglichst viele Möbel sowie die lieb gewonnene Beleuchtung aus dem alten ins neue Büro transferieren konnten, und zogen im September 2019 um.

Ab nach Hause!

Der Umzug war gerade rechtzeitig abgeschlossen, um uns noch einige Monate im neuen Büro zu lassen, bevor es im März 2020 hieß: Ab nach Hause! Die Corona-Infektionszahlen gingen gerade durch die Decke und die Bundesregierung rief dazu auf, soweit irgend möglich im Homeoffice zu arbeiten. Wir fanden uns zu einer Teambesprechung zusammen, entschieden, dass wir das möglich machen wollten, und meldeten am 10. März via Twitter:

Wir haben entschieden, Verantwortung zu übernehmen und ab heute geschlossen im Home Office zu bleiben. Die COVID-19 Gefahr für jeden Einzelnen von uns ist gering aber jeder kann dafür Sorge tragen, nicht zum Spreader zu werden: Für unsere (älteren) Mitbürger, Freunde, Familien!

Nach einer kurzen Umgewöhnung stellten wir fest, dass wir im Homeoffice als Team extrem produktiv sein können, und fanden in Form von täglichen Google Meet-Videokonferenzen auch einen guten Weg, intensiven Kontakt zu halten. Eine Nebenwirkung: Alle Kunden hatten plötzlich auch Videokonferenz-Ausrüstung, sodass wir uns so oft sehen konnten wie nie zuvor. Telefonkonferenzen gehören seitdem der Vergangenheit an – warum auch telefonieren, wenn man sich stattdessen per Video in die Augen sehen kann?

Erfahrungen mit Arbeitskräftemigration

Da wir nun schon seit Jahren personelle Verstärkung suchten, entschieden wir uns Anfang 2020 für ein besonderes Experiment: Über private Beziehungen hatten wir Kontakt zu Amitay, einem kubanischen Informatiker, der in Mexiko arbeitete und Interesse hatte, nach Deutschland zu kommen. Auch wenn er kein Deutsch sprach und keine Erfahrungen mit unserem Technologie-Stack hatte, entschieden wir uns, ihn anzusprechen. Was man nicht kann, kann man lernen, dachten wir – und Amitay war Feuer und Flamme, es auszuprobieren.

Nun stand zunächst ein intensiver Meinungsbildungsprozess in der webfactory an. Schließlich hatten wir noch nie jemanden im Team gehabt, der kein Deutsch sprach, und es gab unterschiedliche Meinungen dazu, wie gut unsere Teammeetings unter diesen Voraussetzungen funktionieren würden. Wir entschieden uns, es zu versuchen. Bezüglich der Sprache überlegten wir uns die Regelung, dass wir die ersten 8 Wochen ausschließlich Englisch sprechen würden und dann Woche für Woche ein Teammitglied auf Deutsch wechseln würde, sodass nach einigen Monaten wieder jeder in seiner Sprache sprechen könnte und Amitay, dem wir parallel Deutschkurse finanzierten, einen weichen Übergang haben würde. Fachliche Besprechungen in Projekten würden wir natürlich weiterhin auf Englisch machen und in anderen Besprechungen bei Bedarf übersetzen.

Wir lernten, dass es im Prinzip dank des "Blue Card"-Programms der EU nicht schwer ist, für Arbeitskräfte ein Visum für die Einreise nach Deutschland zu bekommen. Es gab noch ein paar kleinere Stolpersteine auf dem Weg, aber trotz der Reisebeschränkungen und eingeschränkter Öffnungszeiten der Botschaften mitten im ersten Corona-Jahr konnten wir Amitay im Januar 2021 am Flughafen Frankfurt in Empfang nehmen.

Leider ist er inzwischen nicht mehr in unserem Team, sondern hat sich entschieden, zu einer anderen Bonner Firma zu wechseln, in der er wieder in seiner gewohnten Programmierumgebung (C#/.net) entwickeln kann. Aus meiner Sicht haben wir die Sprachbarriere gut gemeistert, auch wenn ich es als überraschend schwierig empfunden habe, Software-Entwurfsfragen auf Englisch zu diskutieren – und das, obwohl wir uns täglich auch mit Kunden auf Englisch abstimmen. Auch die technische Einarbeitung in PHP und Symfony hat gut funktioniert. Trotzdem habe ich das Gefühl, dass das zu viel Fremdheit auf einmal war. Ein fremdes Land und eine fremde Sprache sind schon eine ganz schön große Umgewöhnung, man sollte das vielleicht nicht auch noch mit einem fachlichen Sprung ins kalte Wasser verbinden.

Open Source Software veröffentlichen zahlt sich aus

2012 hatten wir im Rahmen unserer Bemühungen, für alle unsere Bestandskunden eine Weiterentwicklung ihrer Produkte auf Basis von Symfony zu ermöglichen, das Legacy Integration Bundle als Open Source-Software veröffentlicht (mehr dazu auf der Leistungsseite "Langlebige Softwareprodukte"). 8 Jahre später erhielten wir eine Bewerbung eines begeisterten Nutzers. Fabian plante seinen Umzug nach Bonn und war fest entschlossen: "Wenn ich mal in Bonn arbeite, möchte ich zur webfactory". Er hatte das Legacy Integration Bundle bei seinem früheren Arbeitgeber kennengelernt und offenbar einen guten Eindruck von uns gewonnen.

Gut war auch unser Eindruck von Fabian und so zögerten wir nicht lange, ihn ins Team aufzunehmen.

Kinder in der webfactory

Stand heute sind 5 Kinder von webfactory-Kollegen zur Welt gekommen: Felix, Florentine, Lasse, Timo und Aino. Wir freuen uns sehr, sie im erweiterten Team zu haben. Dank dieser Kinder haben wir jede Menge Arbeitszeitmodelle ausprobiert: Mein Geschäftsführer-Kollege Matthias teilte sich die Elternzeit zu gleichen Anteilen mit seiner Frau und reduzierte seine Wochenarbeitszeit für mehrere Jahre auf 50%. Ich selbst nahm mir einen Tag pro Woche frei und kam auf 80%. Stefan übernahm den größeren Anteil der Betreuung seiner Tochter und reduzierte auf 40%. All das ließ sich gut einrichten und ich freue mich, dass wir so viel Zeit mit unseren Kindern verbringen konnten.

Schade nur, dass wir noch keine Frauen mit Kindern im Team haben. Aber was nicht ist, kann ja vielleicht noch werden!

Weitere Kunden

Abschließend möchte ich noch einige Kunden erwähnen, die bisher keinen Platz in diesem geschichtlichen Abriss hatten, aber trotzdem zu wichtig sind, um den Artikel schon an dieser Stelle zu beenden.

Zum einen ist da die Agentur Euro-Informationen, für die wir seit dem Jahr 2000 verschiedene Websites entwickelt haben, die teilweise durch Fördermittel, teilweise durch Werbung oder Provisionen finanziert wurden. Die größte davon ist www.krankenkassen.de. Eine Website, die über 10 Jahre lang aus technischer Perspektive einfach nur vor sich hin funktionierte und Anzeigenerlöse generierte, bis wir einen Online-Wechselservice umsetzten. Seitdem kann man über die Website die Krankenkasse wechseln und die Abhängigkeit von Werbeerlösen ist weggefallen. Der Wechselservice ist so erfolgreich, dass er inzwischen um API-Schnittstellen zu großen Krankenkassen erweitert wurde, über die die Wechselanträge direkt ins IT-System der Krankenkasse übertragen werden, sowie um eine Lösung, mit der man die Anträge direkt online unterschreiben kann.

Dann wäre da noch der Deutsch-Südafrikanische Reisedienst (DSAR), ein kleiner Bonner Reiseveranstalter, der uns im Frühjahr 2017 kontaktierte. Die Firma war ausgelastet und die Kunden zufrieden mit dem Webangebot, aber der Inhaber wollte die Website technisch und gestalterisch modernisieren und das umfangreiche Wissen der Firma über das südliche Afrika ins Netz bringen. In der Anfrage hieß es:

Meine Idealvorstellung ist eine contentbasierende Plattform, in der wir all das Wissen erfassen können, welches wir über unser Zielgebiet (das südliche Afrika) haben. Also keine Infohäppchen, sondern eher eine wie ein Wiki vernetzte Struktur, in der der potentielle Kunde sich fundiert über Individualreisen durch das südliche Afrika informieren kann. Trotzdem soll es optisch inspirieren und muss am Ende natürlich einen Teil der Besucher davon überzeugen, eine Reise bei uns zu buchen.

Im Grunde nicht anders als in der Open Source Entwicklung: Ich präsentiere unser Wissen um das Zielgebiet (also den Source Code) und verdiene an den Kunden, die keine Zeit haben, sich die Reise selber zusammen zu stellen. Zumal wir mehr Erfahrung und die besseren Tools haben.

Diese Philosophie war uns natürlich ausgesprochen sympathisch. Spannend war auch, dass der DSAR bereits eine ganze Reihe an internen Softwaretools entwickelt hatte, darunter einen Reiseplaner, in dem alle Unterkunftsdaten hinterlegt waren und über den individuelle Reiseverläufe visualisiert werden können. Die Touren aus diesem System kann der DSAR nun über eine Schnittstelle direkt auf der Website veröffentlichen und sie werden dort in einem Zeitstrahl präsentiert (ein Beispiel: die zweiwöchige Namibia-Rundreise). Da wir 2017 beim besten Willen keine Zeit hatten, haben wir den DSAR gebeten zu warten. Und im Januar 2018 konnte es dann endlich losgehen. Der DSAR ist insofern besonders, als er einer unserer wenigen Kunden ist, die über ihre Website tatsächlich unmittelbar Geld verdienen müssen – und das als Kleinunternehmen, für das ein solches Projekt eine beachtliche Investition ist. Und er ist auch besonders dadurch, dass er als Reiseveranstalter durch Corona massiv betroffen war und das komplette Geschäft pausieren musste. Glücklicherweise hat der DSAR die Pandemie gut überstanden und freut sich, jetzt wieder Reisegäste nach Afrika bringen zu können. Last but not least: der DSAR ist der erste Kunde, dem wir Zugriff auf sein GitHub-Repository gegeben haben (mehr zum Hintergrund auf der Seite "Offene und vertrauensvolle Zusammenarbeit"). Ursprünglich vor allem, damit der technisch bewanderte Kunde die im Code hinterlegten logischen Regeln selbst einsehen und über den Pull-Request-Mechanismus von GitHub Änderungen vorschlagen konnte, doch diese Art der Zusammenarbeit hat sich so gut angefühlt, dass wir sie inzwischen allen Kunden nahelegen.

Schließlich gibt es da unter unseren Kunden noch die Nationale Leitstelle Ladeinfrastruktur. Sie übernimmt im Auftrag der Bundesregierung die wissenschaftliche Begleitforschung für den Ausbau der Ladeinfrastruktur für Elektro-Autos. Das Forscherteam hatte uns gefunden über eine Suche nach den Stichworten "Agil" und "Symfony" und sich bereits auf unserer Website informiert. Als dann die Anfrage kam, waren wir natürlich direkt auf einer Wellenlänge. Und das Projekt brauchte auch tatsächlich einen sehr agilen Prozess: Es musste eine komplett neue Software entwickelt werden und der Projektzeitraum war auf knapp 6 Monate begrenzt. Auch die Aufgabenstellung war spannend: Die Forschungsarbeit sollte unter anderem auf der Auswertung der Ladedaten an einer großen Zahl von Ladestationen unterschiedlichster Betreiber basieren. Die Betreiber erhielten staatliche Förderung für den Aufbau der Ladestationen und waren im Gegenzug verpflichtet, jedes halbe Jahr die Ladedaten zu übermitteln. In der ersten Runde war das per Mail erfolgt, die Leitstelle hatte also hunderte Excel-Dateien mit teilweise unterschiedlichen Strukturen erhalten, die sich nur mit enormem personellen Aufwand zusammenführen ließen. Die Aufgabe bestand nun darin, einen Online-Prozess für den Upload der Excel-Dateien umzusetzen und die Daten dabei in eine Datenbank zu übernehmen, auf deren Basis die Forschung stattfinden konnte. Zusätzlich werden für jede Ladestation auch noch über 60 Stammdaten erhoben (zum Beispiel, wie der Stellplatz markiert ist und welche Bezahlverfahren unterstützt werden). Ein Projekt genau nach unserem Geschmack, und eine extrem fokussierte und konstruktive Zusammenarbeit. Einen Namen für das System dachte sich mein Kollege Matthias aus: OBELIS, kurzform für Online-Berichterstattung Ladeinfrastruktur (inzwischen als OBELIS öffentlich Teil einer Familie von Angeboten). Zum Abschluss des Projekts gab es eine große Überraschung: Eine OBELIS-Torte für die webfactory!

Die webfactory ist ein kundenorientiertes Unternehmen, und ein mitarbeiterorientiertes Unternehmen obendrein. Oder andersherum? Mitarbeiter- und Kundenorientierung ist uns gleichermaßen wichtig. Ich glaube, wenn man den Begriff menschenorientiert verwendet, trifft das die Sache ganz gut. Für mich bedeutet es, dass wir sowohl unseren Mitarbeitern als auch unseren Kunden jeden Wunsch erfüllen – solange es sich möglich machen lässt, ohne jemanden zu beeinträchtigen.

Ein Beispiel: Anfang 2020 haben wir in unserer Mitarbeiterzufriedenheitsumfrage herausgefunden, dass unsere Arbeitszeiten nicht für jeden im Team gut mit seinem persönlichen Biorhythmus vereinbar sind. Eigentlich hatten wir bereits volle Flexibilität bei der Arbeitszeit – nur dummerweise ein freiwilliges tägliches Standup-Meeting um 9:45 Uhr. Die Eulen unter uns stellte das aber vor die Wahl, entweder ihre Kollegen nicht regelmäßig zu sehen oder zu einer Zeit mit der Arbeit zu beginnen, zu der sie am liebsten schlafen würden. Was aber hat eine Firma für einen Vorteil davon, wenn ihre Mitarbeiter zu Zeiten arbeiten, zu denen sie nicht ihre optimale Leistung bringen können? In einem internen Projekt haben wir dann einen neuen Besprechungsrhythmus erarbeitet, evaluiert und umgesetzt. Unsere morgendlichen Standups sind einem Daily Café zur Mittagszeit gewichen. Da ist jeder wach. Und Kundentermine hatten wir zu dieser Zeit ohnehin selten.

Ein weiteres Beispiel: Am 10. November 2022 (einen Tag vor Beginn der Karnevalssaison hier im Rheinland) hatten wir ein erstes Gespräch mit unserem Kunden über eine Website für neue Fördermöglichkeiten der EU. Die erste Antragsfrist für den Erhalt der Förderung stand fest, es war der 23. Februar 2023. Damit die potenziellen Antragsteller sich vorher noch über das Programm informieren konnten, war es für unseren Kunden wichtig, die Website möglichst schon im Januar zu veröffentlichen. Es blieben also ungefähr 8 Wochen Zeit. Das Design sollte von der Corporate Design-Agentur des Kunden beigesteuert werden. Allerdings hatte die noch gar nicht mit der Arbeit begonnen. Dank der eingespielten Zusammenarbeit mit unserem Kunden und seiner Designagentur ist es gelungen, die Website www.erasmusplus-sport.de pünktlich am 17.01.2023 zu launchen – und das trotz Krankheiten und ohne, dass einer von uns die traditionell freie Zeit zwischen Weihnachten und Neujahr opfern musste. Unser Kunde schreibt:

[...] danke für die großartige Umsetzung des Designs ins Web. Danke fürs Einrichten des Backends mit all den damit verbundenen Neuerungen im CMS. Danke für den Kampf mit diversen Endgegnern (z.B. Hero-Gestaltung [...]) und vor allem Dank dafür, dass ihr kein einziges Mal gesagt habt: „Das geht zeitlich nicht.“ (Also, ich hätte es verstanden…) ;-)

Soziokratische Entscheidungen

Fast alles, was die webfactory betrifft, entscheidet bei uns das Team gemeinsam – von Arbeitszeiten und Besprechungsterminen über die Einrichtung der Büroräume bis hin zum Gehaltsmodell. Dass wir dafür nicht wochenlange basisdemokratische Diskussionen führen müssen, ermöglicht uns ein ausgeklügelter Entscheidungsprozess: Beim soziokratischen Konsent wird über eine Entscheidungsvorlage in einem strukturierten Prozess beraten und jede Meinung wird gehört. Wenn es Einwände gibt, versuchen wir, einen verbesserten Vorschlag zu entwickeln. Die Entscheidungsvorlage ist angenommen, sobald es keinen schwerwiegenden Einwand gibt. Vorteil davon: Jeder im Team hat de facto ein Vetorecht und nichts kann über seinen Kopf hinweg entschieden werden. Es muss aber auch keine demokratische Mehrheit gefunden werden, sondern das Design des Prozesses ist "fortschrittsorientiert".

Anschaffungen? Fortbildungen? Entscheide selbst!

Nicht alles braucht einen Teamentscheid. Über Anschaffungen entscheidet grundsätzlich jedes Teammitglied eigenverantwortlich, ebenso über den Besuch von Fortbildungen. Hierbei gibt es kein Budgetlimit. Warum? Weil es keinen Vorteil hat, teure Arbeitszeit der Geschäftsführung oder gar des gesamten Teams dafür zu verwenden, zu entscheiden, ob A sich einen neuen Bürostuhl anschaffen darf (und welches der beste wäre) oder B einen neuen Kopfhörer. Wir sparen also jede Menge Zeit und mentale Energie und ermöglichen gleichzeitig jedem und jeder, mit den Tools zu arbeiten, die sie für sich am besten finden. Übrigens hat noch niemand diese weitreichende Teamermächtigung ausgenutzt und sich z. B. einen Porsche auf Firmenkosten angeschafft. Oder ein Alpaka.

Pull-Prinzip für die Aufgabenverteilung

Bei uns gibt es niemanden, der anderen Aufgaben zuweist. Stattdessen machen wir, hauptsächlich über ein sogenanntes Kanban-Board, für alle transparent, welche Aufgaben zu erledigen sind. Jeder zieht sich dann nach Fertigstellung einer Aufgabe eine neue Aufgabe aus der Warteschlange.

Dieses Prinzip unterstützt aus meiner Sicht eine Zusammenarbeit auf Augenhöhe, denn es gibt nicht mehr denjenigen, der Aufgaben verteilt, und denjenigen, der Aufgaben empfängt. Es verhindert auch, dass einzelne Mitarbeiter überlastet werden, weil sie mit zu vielen Aufgaben betraut werden. Durch die hohe Transparenz verhindert es zugleich, dass Aufgaben "verhungern", also nicht erledigt werden. Und natürlich verhindert es auch, dass Mitarbeiter nichts zu tun haben, weil niemand ihnen Aufgaben zuweist.

Ergänzend zum Pull-Prinzip beraten wir bei größeren Projekten, die für einige Zeit mehrere dezidierte Kollegen brauchen, im Team, wer dieses Projekt am besten übernehmen kann und möchte.

Urlaub? Sag' einfach Bescheid

Schon viel länger als die oben erwähnte Ermächtigung für Kaufentscheidungen gibt es bei uns die Freiheit, Urlaub zu nehmen, wann man möchte. Der Urlaubsprozess ist einfach: Überlege, wann du Urlaub machen willst, welche Dinge dem entgegenstehen könnten (z. B. ob du schon die Fertigstellung eines Projekts zugesagt hast, dessen Launchtermin mitten im Urlaubszeitraum liegt) und schreib dann eine Mail ans Team, von wann bis wann du weg bist.

Diesen Prozess haben wir schon seit Jahrzehnten und er hat noch nie zu Problemen geführt. Schließlich sind wir ein Team von 10 Kollegen, (fast) jeder kann (fast) jedes Projekt betreuen und an Tagen, wo drei Viertel des webfactory-Teams freinehmen, gibt es in der Regel auch nicht viele Kundenanfragen.

Qualität

Ein großer Aspekt unserer Unternehmenskultur ist der Qualitätsanspruch. Wir reden immer eher mit unseren Kunden über höhere Budgets oder das Weglassen weniger wichtiger Features, als aus Budget- oder Termingründen qualitativ schwache Lösungen zu akzeptieren. Das zahlt sich nicht nur für das Produkt aus (siehe "Langlebige Softwareprodukte"), sondern es ist auch ein wichtiges Signal an das gesamte Team: Jeder wird darin bestärkt, sein Bestes zu geben. Und wenn man interne Tools, unsere Open Source-Pakete oder die Dokumentation in unserem Wiki verbessert, gibt es dafür Lob von den Kollegen.

Aus Fehlern wird man klug

Wir reden offen über Fehler und Probleme. Niemand wird für Fehler angegriffen oder zurechtgewiesen. Schließlich ist es am besten, wenn nicht nur man selbst aus seinen eigenen Fehlern lernen kann, sondern direkt das ganze Team. Meist hat dann auch noch jemand eine Idee, was man verändern könnte, um diese Art von Fehler für die Zukunft unwahrscheinlicher zu machen.

Wertschätzende und gewaltfreie Kommunikation

Dumme Fragen gibt es bei uns nicht. Jeder hat andere Stärken und jeder steht auch irgendwann mal auf dem Schlauch. Wir helfen uns gegenseitig und gehen immer davon aus, dass der andere das Beste wollte. Das hilft uns, uns nicht mit internen Spannungen aufzuhalten, sondern uns ganz auf unser gemeinsames Ziel zu konzentrieren: Die besten Softwareprodukte zu entwickeln und dabei jeden Tag Freude an der Arbeit zu haben.

Flexible Arbeitszeiten und -umfänge

Jede und jeder arbeitet, wann es für sie oder ihn am besten passt. Wir haben keine Regeln, die das einschränken, stattdessen haben wir Prozesse, die asynchron, also ohne gleichzeitige Anwesenheit funktionieren. Dazu gehören z. B. ein Teamchat und die Kommunikation über GitHub Pull Requests. Wir haben auch intensiv daran gearbeitet, mit unseren Kunden andere Kontaktwege als Telefonanrufe zu etablieren – zum Beispiel, in dem wir versprechen, dass E-Mails genau so schnell und zuverlässig bearbeitet werden wie Anrufe. Da nun nicht mehr die Erwartung besteht, einen bestimmten Ansprechpartner in einem bestimmten Zeitfenster telefonisch erreichen zu können, sind wir mit der Arbeitszeit sehr flexibel. Und die Tatsache, dass die Kolleg:innen diese Flexibilität auch nutzen, führt sogar dazu, dass die Erreichbarkeit sich auf Unternehmensebene verbessert hat: Denn auch eine E-Mail, die am Wochenende oder spät Abends eingeht, bekommt so gelegentlich noch eine schnelle Antwort.

Generell sind unsere Arbeitszeiten meist noch klassisch auf Montag bis Freitag gleichverteilt, es gab aber auch schon persönliche Experimente mit einem "Weekend Wednesday", also dem Tausch von Mittwoch gegen Samstag.

Die Flexibilität gilt auch für die gewünschte Wochenarbeitszeit: Jeder Mitarbeiter kann über diese frei entscheiden. Wir hatten in der Vergangenheit Kollegen, die Elternzeit genommen und dafür auf 2 Tage pro Woche reduziert haben, ebenso wie Musiker, die gerne eine 3-Tage-Woche arbeiten wollten. Unsere Geschäftsführer arbeiten übrigens in Teilzeit mit 80% bzw. 90%.

Remote First

Wir waren immer der Ansicht, dass wir vor Ort am besten zusammenarbeiten können und Homeoffice auf einen Tag pro Woche beschränkt bleiben sollte. Dann kam Corona und wir haben uns angepasst. Seit März 2020 arbeitet unser Team fast vollständig von zu Hause aus, und die Zusammenarbeit läuft besser denn je. Unser schönes, gerade 2019 frisch bezogenes Büro steht trotzdem zur Verfügung – für alle, die einen Tapetenwechsel zwischen Wohnen und Arbeiten bevorzugen.

Unsere Prozesse sind aber seit Corona "Remote First", das bedeutet für uns, dass wir Kollegen, die nicht vor Ort im Büro sind, keinesfalls benachteiligen wollen. Daher finden zum Beispiel alle Teammeetings als Videokonferenz statt, egal wie viele Kollegen im Büro sind.

Damit ermöglichen wir auch ganz neue Arbeitsmodelle: 2022 hat zum Beispiel der erste Kollege sein Büro spontan für zwei Wochen in ein Ferienhaus in Griechenland mit Blick aufs Meer verlegt.

30-Stunden-Woche

Wir haben lange über dieses Thema nachgedacht. Es gibt verschiedene Studien, die nahelegen, dass der Mensch nicht in der Lage ist, mehr als 6 Stunden am Tag konzentriert zu arbeiten (eher sogar deutlich weniger). Und dennoch fühlte es sich radikal an, die logische Konsequenz daraus zu ziehen und die tägliche Arbeitszeit auf 6 Stunden zu reduzieren. Verliert man da nicht möglicherweise 25% der Arbeitsleistung? Der Umzug ins Homeoffice während der Corona-Pandemie hat dann den entscheidenden Impuls gegeben, denn plötzlich verlor die Unterscheidung zwischen Anwesenheitszeit und dokumentierter Arbeitszeit ihren Sinn. Wir hatten vorher die Regel, dass man beim Kommen und Gehen seine Arbeits- und Pausenzeit erfasst und dass man einen möglichst hohen Anteil der Anwesenheitszeit, mindestens aber 70%, auf konkrete Tätigkeiten nachweist. Nur diese nachgewiesene Arbeitszeit konnten wir Kunden in Rechnung stellen. Im eigenen Zuhause fühlte es sich aber sinnlos an, zu entscheiden, wann man "auf der Arbeit" ankommt und wann man geht. Nachdem wir das ein gutes Dreivierteljahr gemacht hatten und es uns allen auf die Nerven gegangen war, haben wir entschieden, die Erfassung der Anwesenheitszeit abzuschaffen und die Quote der nachzuweisenden Arbeitszeit auf 75% zu erhöhen. Und plötzlich hatten wir unsere 30-Stunden-Woche.

Man könnte das nun als Augenwischerei abtun – aber dagegen sprechen die Zahlen aus unserer Evaluation: ein Dreivierteljahr nach der Umstellung fühlten sich 80% der Mitarbeiter erholter als früher, 90% fühlten sich produktiver, ebenfalls 90% bejahten die Frage, ob es sich auch tatsächlich so anfühlte, als ob sie weniger arbeiten als früher. Nur 10% (eine Person) hatte das Gefühl, dass es nach der Umstellung länger dauert, ein Projekt fertigzustellen. 80% des Teams bestätigten, nach Feierabend mehr Energie zu haben als früher – andererseits hatten nur 40% das Gefühl, wenn sie Feierabend machen, könnten sie häufig auch noch produktiv weiterarbeiten. Und unter dem Strich waren 90% sehr zufrieden mit der reduzierten Arbeitszeit (Bewertung von 5 oder 6 auf einer Skala von 0-6).

Und mit nunmehr 2 Jahren Erfahrung kann ich auch aus Geschäftsführer-Sicht sagen, dass das Modell ein voller Erfolg ist. Sowohl die Qualität unserer Produkte und der Zusammenarbeit mit unseren Kunden als auch das Klima im Team haben sich in dieser Zeit aus meiner Sicht hervorragend entwickelt.

Gehaltstransparenz

Seit 2017 sind alle unsere Gehälter im Team transparent. Das ist für uns schon so selbstverständlich, dass ich fast vergessen hätte, es zu erwähnen – aber immerhin haben wir die ersten 20 Jahre unserer Firmenlebens die Gehälter vor dem Team "geheim gehalten" (und ich wage die Vermutung, dass das in den meisten Firmen auch heute noch so gehandhabt wird).

Die Gehaltstransparenz hat zunächst einmal dazu geführt, dass unsere Gehaltsverteilung als fairer wahrgenommen wurde. Die Unterschiede waren offensichtlich deutlich geringer, als einige im Team gedacht hatten. Sie hat außerdem ermöglicht, dass wir im Team über die Gehaltshöhe reden und darüber, wovon das Gehalt abhängen sollte. Als nächsten Schritt nach der Veröffentlichung der Gehälter haben wir Anfang 2018 ein Gehaltsmodell und einen Gehaltserhöhungsprozess entwickelt.

Automatische Gehaltserhöhungen

Im Laufe der Jahre hat sich gezeigt, dass das Gehaltsmodell einige Schwachstellen hatte, insbesondere für sehr erfahrene Entwickler und langjährige Teammitglieder. Ende 2021 hat daher eine Arbeitsgruppe damit begonnen, ein neues Gehaltsmodell zu entwickeln. Ein Ziel der Arbeitsgruppe war, mit einem Mindestmaß an Einstufungs- und Bewertungsrunden auszukommen, denn diese haben sich als schwierig zu realisieren und häufig frustrierend herausgestellt.

Wir konnten uns bis heute noch nicht auf ein vollständiges neues Gehaltsmodell einigen, haben aber zum 1.1.2023 das alte Modell abgeschafft und jährliche automatische Gehaltserhöhungen für alle eingeführt, deren Höhe es unseren jüngsten Kollegen in Aussicht stellt, im Laufe ihrer Karriere auf das Niveu ihrer heutigen erfahrensten Kollegen zu kommen. Ich bin gespannt, wann wir hier im Blog unser fertiges neues Modell vorstellen können.

Was sonst noch war

• Einen Einblick in unsere Teamkultur gibt auch Eva in ihrem Artikel wfLeaks: Eine Mitarbeiterin packt aus!
• Bis 2020 hatten wir die Tradition, im Team reihum zu kochen und jeden Mittag gemeinsam zu essen. Und natürlich hatten wir ein ausgeklügeltes System, um Fairness beim Kochen zu garantieren. Der Artikel Wenn die Küchenglocke ruft ist eine Erinnerung.

Besonders freuen wir uns, wenn unsere Kunden uns berichten, wie zufrieden sie mit wfDynamic sind.

Hier nun das Feedback von Laura:

Wir nutzen wfDynamic für fünf Anwendungsfälle:

• Support der NutzerInnen unserer Online-Plattform für die Berichterstattung zu geförderten Ladesäulen (wir nennen es unsere „Wartungsklappe“)
• Versenden von Erinnerungs-Emails zur Berichterstattung an die NutzerInnen
• Export ausgewählter Felder unserer Datenbank per Knopfdruck als CSV-Dateien für unser Reporting
• Erweiterung von Auswahllisten für verschiedene Drop-Down-Felder unserer Online-Plattform
• Anpassung/Erweiterung der Regeln zur Verifizierung von zugelassenen Förderkennzeichen

Seit März 2019 nutzen wir wfDynamic mittlerweile schon und unser Fazit ist:

• guter Überblick: Durch wfDynamic können wir uns immer schnell einen Überblick verschaffen, was der aktuelle Stand bei der Berichterstattung ist (z.B. wie viele Accounts angelegt wurden, bei wie vielen NutzerInnen die Daten bereits vollständig eingetragen wurden etc.).
• Support leisten geht schnell und easy: Wenn eine Nutzer sich bei einem Problem mit seiner Berichterstattung bei uns meldet, können wir seine Angaben einsehen und somit schnell die Ursache seiner Schwierigkeiten identifizieren. Man kann auch notwendigen Anpassungen der Angaben (z.B. bei Feldern, die der Nutzer nach einmaliger Eingabe selbst nicht mehr anpassen kann) schnell und einfach vornehmen, ohne ein SQL- oder Datenbank-Profi sein zu müssen.
• effizienter und flexibler E-Mail-Versand: Für die E-Mails, die wir regelmäßig an die NutzerInnen versenden, können wir die Vorlagen und Verteiler immer wieder nutzen, aber auch flexibel anpassen. Man kann den E-Mail-Entwurf auch direkt in wfDynamic zwischenspeichern, falls er im Team noch abgestimmt werden soll.

Uns erleichtert wfDynamic tagtäglich die Arbeit, da die Funktionalitäten genau unseren Anforderungen entsprechen. Das Interface ist auch sehr übersichtlich und leicht in der Handhabe. Daher klare Empfehlung an alle Administratoren von Datenbanken!"

In diesem Zuge wollen wir uns nochmal für das Vertrauen und die nette Zusammenarbeit bedanken!

Assume we have a macro that simplifies some output task. For the sake of simplicity, let‘s have it print a list.

{% macro list(items) %}  
<ul>  
  {% for item in items %}  
    <li>{{ item }}</li>  
  {% endfor %}  
</ul>  
{% endmacro %}{{ _self.list([book.title, book.author])}}

So far, everything is fine.

Thanks to Twig‘s autoescape feature, this code is protected from XSS attacks: Even when an attacker can supply arbitrary values for book.title or book.author , Twig will make sure the htmlspecialchars() function is applied to make the values safe for use in HTML.

You can try the example in a Twig fiddle.

Adding HTML with Good Intentions™

Now, assume we‘re tasked to make the author‘s name editable. We add functionality somewhere to do that, and we‘d like to allow the user to jump to that edit from right from our list.

We might change the macro invocation to look like this:

{{ _self.list([
    book.title,
    book.author ~ '<a href="#">edit</a>'
])}}

We give it a shot by reloading the page in the browser, or by looking at the updated fiddle.

We immediately recognize our mistake, since the <a href="#">...</a> link is printed as-is in the page. Right, that autoescape feature! What do we need to do?

Let‘s update our macro, since we know we want to include HTML in the output.

{% macro list(items) %}
<ul>
  {% for item in items %}
    {# Use |raw for HTML passthrough #}
    <li>{{ item | raw }}</li>
  {% endfor %}
</ul>
{% endmacro %}

Another quick refresh (fiddle) shows us that now it‘s working as expected. Let‘s commit and we‘re done.

What just happened

By applying the |raw filter in our macro, we have declared that whatever value the item variable contains, it is safe to use as-is in the current context. It will turn off Twig‘s autoescaping at the point where the list items are printed.

We have shifted responsibility for proper escaping from Twig to the developer using our macro. And that not only affects the item where we add the HTML link, which might be fixed like so:

{{ _self.list([
    book.title,
    book.author|e ~ '<a href="#">edit</a>'
])}}

Note I‘ve added |e , the shorthand for the escape  filter, to do HTML escaping before concatenating the author name with the HTML markup.

This, of course, falls short, since we need not only escape the book.author item, but also book.title .

Even worse, when our macro is a re-used component being called from various places, we‘d need to have this escaping applied to all inputs supplied to the macro, which might be a lot of work to find and update.

You probably would take a step back and find some other way to solve your current task without doing such a change. Maybe you‘d just stop using the macro in the current situation and duplicate the code in this one spot. If… you are aware of it.

You ain‘t gonna notice (in time)

The challenge, in my opinion, is that you are likely not going to notice the problem you just created. It takes a lot of awareness to understand the subtle implications of the change.

This is may not only be an issue for less experienced developers or template designers. Imagine the template not being as simple as in the above example, but a bit more cluttered. For example, the list macro might need to also deal with array keys and blend in CSS classes (maybe taken from a second parameter) as well. That gives a lot of distraction also for more experienced Twig users and you might easily miss the important point.

Also, since Twig – and proably other template engines as well – do a great job at producing „safe“ output most of the time nowadays, when it comes to HTML and XSS we have become a bit more negligent or less well trained than some of us might have been a decade ago.

To make matters worse, nothing will point you to the problem in the short run. Whilst the initial HTML that you added showed up in the output and immediately reminded you of „fixing“ it, the XSS loophole is lurking in your template with no indications of a problem. The „lorem ipsum“ style data you will typically use during development and also during automated tests (functional or acceptance) is most likely not suited to find XSS exploits like this.

Here is a fiddle where an author attended a creative writing course and changed their name afterwards, to better illustrate the problem. Imagine an admin user of your online book shop visiting a page where the above macro is used: You‘re not seeing anything – no „funny looking“ author name. Yet, JavaScript is executed in the background in the context of your admin‘s session.

A more robust pattern

Here is another way how you could have written the previous change in Twig.

{% set author_with_link %}
    {{ book.author }} <a href="#">edit</a>
{% endset %}
{{ _self.list([book.title, author_with_link])}}

The interesting thing about this is that you can keep the list macro as-is, without adding |raw in it.

When Twig processes the {% set … %}...{% endset %} section, it will apply autoescaping as usual. The book.author value will have HTML escaping applied before being printed, and literal HTML markup in templates is safe by default.

Now, the author_with_link variable does not contain a simple string, but an instance of a special class in Twig. It will feel like a string for most purposes, so you can pass it around, concatenate it with other strings or pass it through filters.

As long as you use it unchanged, Twig will „remember“ that output escaping has been applied to this piece of HTML already. You can verify in this fiddle that in fact, the HTML link is printed as plain HTML, whereas HTML markup in the book.author data is escaped.

Conclusion

Be careful when you apply the |raw filter in Twig. It shifts the responsibilty for applying appropriate output encoding from Twig to you, the template developer.

When using |raw , especially in centralized places like includes or macros, make sure everyone passing in data is aware of their obligation to apply appropriate escaping. This may be a break in backwards compatibility for the include/macro.

Glitches in output escaping are likely to go unnoticed for a long time, since you don‘t typically test with the necessary inputs, unless doing security audits.

Doing string concatenation operations with HTML snippets in Twig may be a sign of danger. Even tough it may take a few more lines of code to write and variable names to come up with, writing markup in Twig and capturing it with {% set … %} may help you to stay on the safe side, especially when passing data along afterwards.

Wir haben die bei uns davon betroffenen Systeme inzwischen auf neue Softwarestände aktualisiert, mit denen das Problem gelöst ist. Die Aktualisierung erfolgte auf bekannte, saubere Systemzustände.

Anzeichen für ein tatsächliches Ausnutzen der Schwachstelle auf unseren Systemen liegen nicht vor. Allerdings hat unser Monitoring-System einige entsprechende "Scans" dokumentiert.

Sollten sich weitere für unsere Kunden relevante Informationen ergeben, werden wir diesen Blog-Eintrag aktualisieren.

Update 17.12.2021

Inzwischen ist eine weiteres Advisory unter der Nummer CVE-2021-45046 publiziert worden: Unter bestimmten Umständen und Konfigurationen waren die Korrekturen, die zur Beseitigung der 1. Schwachstelle veröffentlicht wurden, nicht ausreichend bzw. konnten erneut umgangen werden.

Unsere Systeme sind von dieser zweiten Lücke nicht betroffen.