Warum wir glauben, dass Senior-Entwickler ihre Zeit nicht mit Upgrade-Routine verbringen sollten

Vor einigen Jahren hätten wir diese Frage wahrscheinlich selbst anders beantwortet.

Natürlich braucht ein komplexes TYPO3-Upgrade erfahrene Entwickler. Wer schon einmal eine über viele Jahre gewachsene Enterprise-Plattform modernisiert hat, weiß, dass dabei ständig technische Entscheidungen getroffen werden müssen, die sich weder automatisieren noch in einer Checkliste vollständig abbilden lassen.

Heute würden wir diese Aussage trotzdem ergänzen.

Nicht jede Aufgabe innerhalb eines Upgrade-Projekts benötigt dieselbe Art von Erfahrung.

Und genau diese Unterscheidung verändert aus unserer Sicht die Art, wie Agenturen größere Modernisierungsprojekte organisieren sollten.

Erfahrung ist dort am wertvollsten, wo Entscheidungen getroffen werden

Wenn wir mit Agenturen zusammenarbeiten, erleben wir häufig sehr starke Entwicklungsteams. Viele verfügen über erfahrene TYPO3-Architekten, Senior-Entwickler und Technical Leads, die ihre Kunden seit Jahren begleiten und deren Geschäftsprozesse im Detail kennen.

Gerade diese Entwickler sind häufig der wichtigste Grund dafür, dass ein Projekt langfristig erfolgreich ist.

• Sie entwerfen Architekturen.
• Sie beraten Kunden.
• Sie diskutieren neue Anforderungen.
• Sie treffen Entscheidungen über zukünftige Erweiterungen.
• Sie erkennen technische Risiken oft schon lange bevor sie sichtbar werden.

All diese Aufgaben erzeugen unmittelbaren Mehrwert.

Ein Enterprise-Upgrade besteht jedoch nicht ausschließlich aus solchen Tätigkeiten.

Ein erheblicher Teil eines größeren Migrationsprojekts besteht aus Arbeiten, die zwar hohe technische Sorgfalt erfordern, deren Ablauf sich jedoch über viele Projekte hinweg erstaunlich ähnlich entwickelt.

Genau an dieser Stelle beginnt für uns die eigentliche Diskussion.

Ein Upgrade besteht aus sehr unterschiedlichen Aufgaben

Von außen betrachtet wirkt ein TYPO3-Upgrade häufig wie eine einzige technische Aufgabe.

In der Praxis handelt es sich jedoch eher um eine Sammlung sehr unterschiedlicher Disziplinen.

Da gibt es zunächst die eigentlichen Architekturentscheidungen.

• Welche Zielversion soll langfristig betrieben werden?
• Welche Extensions bleiben erhalten?
• Welche werden ersetzt?
• Wie verändert sich die Systemarchitektur?
• Welche Geschäftslogik sollte modernisiert werden?

Diese Fragen lassen sich nicht standardisieren.

Sie benötigen Erfahrung, technisches Verständnis und häufig auch intensive Gespräche mit dem Kunden.

Daneben existiert jedoch ein zweiter Bereich.

• Code muss migriert werden.
• Upgrade Wizards müssen vorbereitet werden.
• Deployment-Prozesse müssen reproduzierbar aufgebaut werden.
• Regressionstests müssen durchgeführt werden.
• Bekannte Migrationsmuster tauchen erneut auf.

Viele dieser Aufgaben sind keineswegs trivial.

Sie unterscheiden sich jedoch grundsätzlich von Architekturarbeit.

Je häufiger ein Team solche Projekte begleitet, desto stärker lassen sich genau diese Bereiche standardisieren und systematisieren.

Spezialisierung verändert die Wirtschaftlichkeit

Stellen wir uns zwei Agenturen vor.

Die erste entwickelt individuelle TYPO3-Projekte, begleitet Digitalisierungsinitiativen, entwickelt neue Features und führt gelegentlich größere Upgrades durch.

Die zweite konzentriert sich nahezu ausschließlich auf TYPO3-Upgrades und begleitet mehrere Migrationen parallel.

Beide beschäftigen hervorragende Entwickler.

Nach einigen Jahren werden sich ihre Kompetenzen dennoch unterscheiden.

Nicht, weil die Entwickler unterschiedlich talentiert wären, sondern weil Spezialisierung zwangsläufig den Prozess verändert.

Ein Team, das jede Woche Upgrade-Projekte begleitet, beginnt irgendwann nicht mehr nur Probleme zu lösen.

Es beginnt, Muster zu erkennen.

• Welche Deprecations treten regelmäßig auf?
• Welche Erweiterungen verursachen immer wieder dieselben Schwierigkeiten?
• Welche Testfälle fehlen in fast jedem Projekt?
• Welche Deployment-Schritte lassen sich standardisieren?

Aus diesen Beobachtungen entstehen Werkzeuge.

• Checklisten.
• Automatisierung.
• Interne Wissensdatenbanken.
• Eigene Rector-Regeln.

Und genau dadurch verändert sich die Wirtschaftlichkeit zukünftiger Projekte.

Warum wir nicht glauben, dass Erfahrung allein ausreicht

Es wäre einfach zu behaupten, dass erfahrene Entwickler automatisch bessere Upgrades durchführen.

Unsere Erfahrung zeigt jedoch, dass Erfahrung allein nicht skaliert.

Wenn ein Projekt erfolgreich ist, weil ein einzelner Senior-Entwickler sich an hundert kleine Details erinnert, dann besitzt das Unternehmen zwar einen hervorragenden Mitarbeiter, aber noch keinen reproduzierbaren Prozess.

Genau deshalb versuchen wir, möglichst viele wiederkehrende Erkenntnisse aus einzelnen Projekten dauerhaft in unsere Arbeitsweise zu übernehmen.

Unsere interne Upgrade-Checkliste ist dafür ein gutes Beispiel.

Sie entstand nicht am Whiteboard, sondern aus vielen Projekten.

Jeder zusätzliche Prüfschritt existiert, weil irgendwann einmal genau an dieser Stelle ein Problem aufgetreten ist.

Dasselbe gilt für unsere Wissensdatenbank, unsere Deployment-Skripte oder den Legacy Updater.

Sie alle verfolgen dasselbe Ziel.

Erfahrung soll nicht ausschließlich im Kopf einzelner Entwickler bleiben. Sie soll Teil des Engineering-Prozesses werden.

Was Agenturen dadurch gewinnen

Wenn wir mit Agenturen zusammenarbeiten, verstehen wir uns deshalb nicht als Ersatz für ihre Entwickler.

Das wäre auch kaum sinnvoll.

Die Menschen, die den Kunden seit Jahren begleiten, kennen dessen Anforderungen wesentlich besser als wir.

Unser Ziel besteht vielmehr darin, diese Entwickler dort zu entlasten, wo Spezialisierung den größten Unterschied macht.

Während unser Team sich auf den eigentlichen Upgrade-Prozess konzentriert, können sich Architekten und Technical Leads weiterhin den Themen widmen, bei denen ihr Wissen den größten Einfluss auf den Projekterfolg hat.

• Neue Funktionen.
• Architekturentscheidungen.
• Workshops.
• Beratung.
• Strategische Weiterentwicklung der Plattform.

Aus unserer Sicht entsteht genau hier der eigentliche Mehrwert einer White-Label-Zusammenarbeit.

Nicht dadurch, dass Aufgaben ausgelagert werden, sondern dadurch, dass beide Teams das tun, worin sie den größten Beitrag leisten können.

Warum das nichts mit Geschwindigkeit zu tun hat

Manchmal entsteht der Eindruck, Spezialisierung sei in erster Linie eine Frage der Geschwindigkeit.

Natürlich profitieren Projekte häufig davon, wenn ein Team ähnliche Aufgaben regelmäßig bearbeitet.

Das eigentliche Ziel ist jedoch ein anderes.

Wir möchten Unsicherheit reduzieren.

Je mehr wiederkehrende Aufgaben standardisiert sind, desto besser lassen sich Aufwand, Qualität und Risiken einschätzen.

Genau deshalb investieren wir so viel Zeit in Prozesse, Werkzeuge und interne Standards.

Nicht weil sie spektakulär wären, sondern weil sie dafür sorgen, dass sich unsere Entwickler auf die wenigen Aufgaben konzentrieren können, die sich eben nicht standardisieren lassen.

Die eigentliche Aufgabe erfahrener Entwickler

Wenn wir heute auf größere Enterprise-Upgrades zurückblicken, fällt uns immer wieder auf, dass die schwierigsten Entscheidungen selten technischer Natur waren.

Es ging nicht darum, welche API ersetzt werden musste oder welche Extension aktualisiert werden sollte.

Die eigentlichen Herausforderungen lagen fast immer dort, wo technische Möglichkeiten und geschäftliche Anforderungen zusammenkamen.

• Soll eine bestehende Funktion erhalten bleiben, obwohl sie in einer aktuellen Third-Party-Extension nicht mehr existiert?
• Lohnt sich eine individuelle Erweiterung langfristig?
• Ist ein bestimmter Prozess heute überhaupt noch sinnvoll?

Genau dort entsteht aus unserer Sicht der größte Wert erfahrener Entwickler.

Nicht beim wiederholten Abarbeiten bekannter Migrationsschritte, sondern bei Entscheidungen, die den zukünftigen Charakter einer Plattform bestimmen.

Was wir daraus gelernt haben

Vielleicht lautet die wichtigste Erkenntnis der vergangenen Jahre deshalb nicht, dass TYPO3-Upgrades Spezialwissen erfordern.

Das tun sie ohne Zweifel.

Die eigentliche Erkenntnis ist vielmehr, dass sich dieses Spezialwissen sehr unterschiedlich einsetzen lässt.

Ein Teil davon gehört in Architekturentscheidungen. Ein Teil gehört in Gespräche mit Kunden. Und ein überraschend großer Teil lässt sich im Laufe vieler Projekte in Prozesse, Werkzeuge und gemeinsame Standards überführen.

Genau dort sehen wir heute den eigentlichen Wert von Spezialisierung.

Nicht darin, dass ein Team schneller programmiert, sondern darin, dass es mit jedem abgeschlossenen Projekt den gesamten Engineering-Prozess verbessert.

Denn am Ende profitieren davon nicht nur zukünftige Upgrade-Projekte.

Davon profitieren vor allem die Entwickler, deren Zeit wieder für die Aufgaben frei wird, bei denen Erfahrung tatsächlich den größten Unterschied macht.