Wenn Sie eine Engineering-Organisation verantworten, kennen Sie die Kosten, die in keinem Bericht auftauchen: die Stunden, die eine Entwicklerin verliert, während sie eine Umgebung hochfährt, rät, wie das Projekt zu bauen ist, oder zwei Tage auf ein Review wartet. Für sich genommen wirkt jede harmlos; über ein ganzes Team hinweg ist Reibung in der täglichen Arbeit einer der teuersten und am wenigsten gemessenen Kostenblöcke eines Technologieunternehmens. Gute Developer Experience (DevEx) ist schlicht die Arbeit, diese Reibung zu beseitigen.
Aus unserer Erfahrung ist DevEx erstaunlich selten ein Talentproblem. Häufiger ist es eine Frage von Werkzeugen, Umgebungen und Standards, die nie jemand als Produkt behandelt hat. Wir gehen es anders an: Wir behandeln die interne Plattform und den Prozess als Produkt, dessen Nutzer die Ingenieurin ist. Und selbst wenn Sie kein eigenes Plattformteam haben, besetzen wir diese Rollen mit Kompetenzen aus DevOps und Platform Engineering.
Warum treibt Developer Experience Delivery-Geschwindigkeit und Bindung?
Der Grund ist schlicht: Eine produktive Ingenieurin verbringt die meiste Zeit damit, das fachliche Problem zu lösen, und nicht damit, gegen die Werkzeuge zu kämpfen. Wenn der Weg von der Idee in die Produktion kurz und planbar ist, liefert das Team schneller, ohne Heldentaten; ist er voller Hindernisse, sinkt das Tempo, und Ihre besten Leute schauen sich um.
Die Bindung ist hier der unterschätzte Teil. Eine erfahrene Entwicklerin geht selten wegen einer einzelnen Sache, aber kleine Frustrationen summieren sich: ein wackliger Build, eine Umgebung, die nur „auf meinem Rechner läuft”, ein Review ohne Ende. Gute DevEx ist deshalb nicht nur ein Hebel für Produktivität; sie ist ein echtes Argument dafür, die Menschen zu halten, deren Ersatz am teuersten ist.
Was ist Platform Engineering und eine interne Entwicklerplattform?
Platform Engineering ist die Disziplin, die die repetitiven, mühsamen Teile der Ingenieursarbeit in einsatzfertige Self-Service-Fähigkeiten verwandelt. Das Ergebnis ist eine interne Entwicklerplattform (IDP): eine Schicht, die es einer Entwicklerin erlaubt, einen neuen Dienst, eine Umgebung oder eine Pipeline zu starten, ohne ein Ticket an ein anderes Team zu stellen. Es geht nicht darum, ein einzelnes Werkzeug zu kaufen, sondern darum, aus Teilen, die Sie meist bereits haben, ein stimmiges Erlebnis zusammenzusetzen:
- Golden Paths, die befestigten, empfohlenen Wege, Dienste zu bauen und auszuliefern,
- ein Servicekatalog und Vorlagen, damit ein neues Projekt mit sinnvollen Voreinstellungen beginnt,
- Self-Service für Umgebungen, Secrets und Ressourcen, ohne manuelle Zwischenstellen,
- eine Observability-Schicht, standardmäßig verdrahtet und nicht am Ende angeflanscht.
Eine gute Plattform ist dünn, wo Teams Freiheit brauchen, und meinungsstark, wo ein Standard allen Zeit spart.
Welche Entwicklerwerkzeuge und Self-Service-Fähigkeiten bringen den größten Ertrag?
Am schnellsten zahlt sich aus, was eine Ingenieurin mehrmals pro Woche tut. Deshalb beginnen wir mit Self-Service-Fähigkeiten, die das Team aus der Ticket-Warteschlange anderer holen:
- Dienste und Umgebungen auf Abruf starten aus vordefinierten Vorlagen,
- CI/CD-Pipelines als Standard, statt sie in jedem Repository von vorn zu konfigurieren,
- Verwaltung von Secrets und Zugriffen, die sicher ist, aber nicht für jeden Schlüssel eine Anfrage verlangt,
- eine einheitliche Sicht auf den Zustand der Dienste (Logs, Metriken, Deployments) an einem Ort.
Es geht nicht um die Zahl der Werkzeuge, sondern darum, sie zu einem verständlichen Ganzen zu verbinden. Wir haben weit mehr Teams gesehen, die unter einem Wildwuchs uneinheitlicher Werkzeuge leiden, als unter deren Mangel; bevor wir etwas ergänzen, schauen wir deshalb, was sich vereinfachen und vereinheitlichen lässt.
Wie verkürzen Dokumentation und Onboarding-Pfade die Zeit bis zum ersten Commit?
Onboarding ist der gnadenloseste Test der Developer Experience. Braucht ein neuer Kollege eine Woche, um das Projekt zu bauen und in die Produktion zu kommen, ist das ein Signal, dass das ganze Team die Reibung ebenfalls spürt, nur hat es sich daran gewöhnt. Deshalb behandeln wir die Zeit bis zum ersten sinnvollen Commit als Kennzahl und nicht als Folklore.
Wir bevorzugen Dokumentation, die nah am Code lebt: eine README, mit der sich das Projekt wirklich bauen lässt, dokumentierte Golden Paths und Onboarding-Checklisten, die von denen aktuell gehalten werden, die sie gerade durchlaufen haben. Statt eines riesigen Dokuments, das niemand liest, legen wir kurze, aufgabenorientierte Pfade an: „wie führe ich es lokal aus”, „wie liefere ich aus”, „wie ergänze ich einen neuen Dienst”.
Wie sieht eine vernünftige Bereitstellung von Umgebungen für Teams aus?
Bei den Umgebungen bricht DevEx am häufigsten ein. Das klassische Problem „läuft auf meinem Rechner” rührt von Umgebungen her, die von Hand zusammengesetzt, auseinandergedriftet und nicht reproduzierbar sind. Wir gehen es über die Wiederholbarkeit an.
In der Praxis heißt das Infrastructure as Code (Terraform, Helm) und Containerisierung, sodass sich eine Umgebung mit einem einzigen Befehl wiederherstellen lässt statt aus dem Gedächtnis einer Person. Dazu ergänzen wir kurzlebige Umgebungen je Pull Request und Parität zwischen lokal, Test und Produktion, damit Überraschungen nicht bis zum Deployment warten. Das Ergebnis ist unspektakulär, aber messbar: weniger Zeit für „warum startet das nicht”, mehr für die eigentliche Arbeit.
Wie prägen Code-Standards und Review-Praxis die Developer Experience?
Standards werden manchmal für Bürokratie gehalten, dabei sind sie genau das Gegenteil: ein gut gewählter Standard bedeutet weniger Entscheidungen und weniger Streit im Review. Sind Formatierung, Linting, Konventionen und Qualitätstore automatisiert, hört das Review auf, ein Kampf um Stil zu sein, und dreht sich um das Wesentliche, die Logik und das Risiko.
Das Review selbst ist ein Stück DevEx, das leicht vergessen wird. Ein Pull Request, der zwei Tage hängt, ist nicht nur eine Verzögerung; er ist ein gebrochener Arbeitsfluss und wachsender Frust für die Autorin. Deshalb behandeln wir es als menschliche und als Prozessfrage:
- kleine, überprüfbare Änderungen statt unbeherrschbarer Mega-PRs,
- klare Erwartungen an die Durchlaufzeit eines Reviews,
- Automatisieren, was sich automatisieren lässt (Lint, Tests, Scans), damit Menschen auf die Bedeutung schauen,
- eine Feedback-Kultur, in der ein Review lehrt statt blockiert.
Wie messen Sie Developer Experience, damit Sie nicht raten?
Ohne Messung verkommt DevEx zu Meinungen. Wir verankern sie lieber in Signalen, die harte Daten mit dem verbinden, was Ingenieure tatsächlich empfinden. Wir schauen auf Flusskennzahlen im Geist von DORA (Deployment-Frequenz, Durchlaufzeit vom Commit in die Produktion, Fehlerrate von Änderungen, Zeit bis zur Wiederherstellung) und nutzen daneben leichtgewichtige Umfragen im Stil von DevEx und SPACE, denn manche Reibung ist nur von innen sichtbar.
Wichtig ist, Kennzahlen nicht in eine weitere Quelle von Druck zu verwandeln. Die Zahlen sollen auf Engpässe zeigen und keine Menschen benoten und Ihnen sagen, wo Sie zuerst ansetzen und ob die Maßnahme gewirkt hat.
Welche Kompetenzen aus DevOps und Platform Engineering stellen wir?
Das ist der Kern: Sie brauchen kein fertiges Plattformteam im Haus, um die Developer Experience zu heben. Auch wenn wir Ihre konkrete Plattform nicht gebaut haben, haben wir Menschen, die solche Dinge in Individualsoftware-Projekten und in unserer DevOps-Praxis tun. Unter anderem besetzen wir Rollen wie:
- einen Platform- bzw. DevOps-Engineer, der Self-Service, CI/CD und Infrastructure as Code baut,
- einen SRE, der Observability, Zuverlässigkeit und vernünftige Error Budgets verantwortet,
- einen Architekten, der Golden Paths, Standards und Verantwortungsgrenzen ordnet,
- einen Backend- bzw. Senior-Entwickler, der Qualitäts- und Review-Praktiken ins Produktteam selbst trägt.
Wir formen das Team um die konkrete Lücke und prüfen die Kompetenzen vor dem Start, nicht „auf Vorrat”. Wir liefern die Menschen, die es tun, und keine Folien darüber, wie es getan werden sollte.
Wie machen wir das bei RITS?
Wir tun das als Nearshore-Partner aus Polen, mit echter Erfahrung in DevOps, Platform Engineering und Individualsoftware-Projekten. Statt bei den Werkzeugen zu beginnen, beginnen wir dort, wo Ihr Team Zeit verliert, und entscheiden erst dann, was zu vereinfachen, zu automatisieren oder zu standardisieren ist:
- wir steigen in den bestehenden Prozess ein, statt eine fertige Schablone von außen zu verordnen,
- wir verbinden Werkzeuge, Umgebungen und Standards zu einem stimmigen Self-Service-Erlebnis,
- wir arbeiten in einer nahen Zeitzone, sodass wir ohne langen Anlauf in Ihren Review-Rhythmus und Ihre Termine finden,
- wir prüfen die Kompetenzen vor dem Start und stimmen die Rolle auf den realen Bedarf ab.
Am häufigsten liefern wir das als Team-Verstärkung oder dediziertes Team, denn DevEx ist fortlaufende Arbeit und kein einmaliger Rollout mit Enddatum.
Womit beginnen Sie bei der Verbesserung der Developer Experience?
Beginnen Sie damit, die schmerzhafteste einzelne Reibung zu messen: das Onboarding, die Wartezeit auf ein Review oder das Aufsetzen einer Umgebung. Eine zählbare Sache gibt Ihnen einen Ausgangswert und ein Ziel, statt Allgemeinplätze über „Engineering-Kultur”. Schließen Sie dann einen Golden Path durchgängig ab, und weiten Sie die Plattform erst von dort auf weitere Teams aus.
Wenn Sie abwägen, ob das Arbeit für eine Festanstellung, Team-Verstärkung oder ein dediziertes Team ist, haben wir die Unterschiede in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Wollen Sie die Developer Experience wirklich verbessern: Werkzeuge, Umgebungen und Standards? Sprechen wir darüber - wir stimmen Kompetenzen und Ansatz auf Ihr Team ab.