Wie Sie Ihre interne Entwicklerplattform messen und weiterentwickeln
Einige Monate nach dem Start Ihrer internen Entwicklerplattform stellen Sie etwas Beunruhigendes fest. Die Akzeptanzzahlen stagnieren. Teams richten ihre eigenen Pipelines weiterhin manuell ein. Neue Dienste werden durch Kopieren alter Repositories erstellt, anstatt Ihre Vorlagen zu verwenden. Das von Ihnen gebaute Portal bleibt weitgehend ungenutzt.
Diese Geschichte ist nicht ungewöhnlich. Eine Plattform zu bauen ist schwer, sie aber relevant zu halten, ist noch schwerer. Plattformen, die nicht gemessen und weiterentwickelt werden, verstauben. Entwickler fallen in alte Gewohnheiten zurück, und die Investition in die Plattform verpufft.
Beginnen Sie mit der Akzeptanz, aber hören Sie nicht dort auf
Die offensichtlichste Metrik ist die Akzeptanz. Wie viele Teams nutzen die Standard-Pipelines? Wie viele neue Dienste werden über die Portalvorlagen erstellt? Niedrige Akzeptanzzahlen sagen Ihnen, dass etwas nicht stimmt, aber nicht, was.
Bevor Sie schlussfolgern, dass die Plattform schlecht ist, sprechen Sie mit den Teams. Vielleicht wissen sie nicht, wie man sie nutzt. Vielleicht ist die Dokumentation unklar. Vielleicht sind die Vorlagen zu starr für ihren Anwendungsfall. Oder vielleicht haben sie bereits ein eigenes Setup, das für sie besser funktioniert.
Akzeptanz ist ein Signal, keine Diagnose. Nutzen Sie es, um Gespräche zu beginnen, nicht um Annahmen zu treffen.
Messen Sie die Wartezeit der Entwickler
Eine Plattform existiert, um Reibung zu reduzieren. Der beste Weg, Reibung zu messen, ist zu betrachten, wie lange Entwickler auf Dinge warten müssen.
Betrachten Sie diese Wartezeiten:
- Wie lange dauert es, einen neuen Dienst von Grund auf bis zu einer funktionierenden Entwicklungsumgebung zu erstellen?
- Wie lange dauert es, bis Code nach einem Pull-Request-Merge in die Produktion gelangt?
- Wie viel Zeit wird mit Warten auf manuelle Freigaben verbracht?
- Wie oft warten Entwickler, weil Testumgebungen nicht bereit sind?
Eine gute Plattform sollte diese Wartezeiten deutlich verkürzen. Wenn Entwickler immer noch Tage auf eine Entwicklungsumgebung warten, löst die Plattform nicht die richtigen Probleme.
Schaffen Sie Feedbackschleifen, die tatsächlich funktionieren
Plattformteams benötigen klare Kanäle, damit Entwickler Probleme melden, Verbesserungen vorschlagen oder sich einfach beschweren können. Dies könnte ein internes Forum, regelmäßige Umfragen oder wiederkehrende Diskussionen zwischen Plattform- und Produktteams sein.
Wichtig ist nicht die Menge des Feedbacks. Entscheidend ist, wie Sie darauf reagieren. Wenn ein Entwickler meldet, dass der Spring-Boot-Vorlage die Standard-Logging-Konfiguration fehlt, beheben Sie es schnell. Werden solche Meldungen ignoriert, verlieren Entwickler das Vertrauen und beginnen wieder, eigene Lösungen zu bauen.
Feedbackschleifen funktionieren, wenn sie zu sichtbaren Änderungen führen. Entwickler müssen sehen, dass ihr Input zählt.
Entwickeln Sie basierend auf Daten und Anfragen weiter
Sobald Sie Akzeptanzdaten, Wartezeitmessungen und Feedback haben, können Sie die Plattform gezielt weiterentwickeln.
Zum Beispiel könnten mehrere Teams um Unterstützung für eine Programmiersprache bitten, die noch nicht in Ihrem Golden Path ist. Bewerten Sie die Anfrage:
- Kommt sie von einem Team oder mehreren Teams?
- Ist die Sprache stabil und für den Produktionseinsatz sicher?
- Kann das Plattformteam sie unterstützen, ohne sich zu übernehmen?
Fallen die Antworten positiv aus, fügen Sie die Sprache als Option hinzu. Zwingen Sie sie niemandem auf, aber machen Sie sie für diejenigen verfügbar, die sie benötigen.
Ein weiteres Beispiel: Entwickler beschweren sich, dass Pipelines zu langsam sind, weil sie bei jedem Commit alle Tests ausführen. Das Plattformteam kann reagieren, indem es eine intelligentere Testauswahl einführt und nur die Tests ausführt, die für den geänderten Code relevant sind.
Passen Sie Leitplanken im Laufe der Zeit an
Plattformen beginnen normalerweise mit strengen Leitplanken. Vielleicht erfordert jede Bereitstellung eine manuelle Freigabe durch das Plattformteam. Nach einigen Monaten stellen Sie möglicherweise fest, dass die Produktteams reif sind und selten Fehler machen. Die Leitplanken können gelockert werden: Manuelle Freigabe wird zur automatischen Freigabe, solange alle Sicherheitschecks bestanden sind.
Wenn andererseits Vorfälle zunehmen, weil Entwickler Regeln umgehen, ziehen Sie die Leitplanken wieder an.
Leitplanken sollten dem Reifegrad der Teams entsprechen, die die Plattform nutzen. Sie sind keine dauerhaften Regeln. Sie sind anpassbare Grenzen, die sich weiterentwickeln, während die Organisation lernt.
Was passiert, wenn Sie nicht messen
Eine Plattform, die nie gemessen und nie verändert wird, wird obsolet. Entwickler hören auf, sie zu nutzen. Sie finden Workarounds. Sie bauen eigene Skripte und Tools. Die Plattform wird zu einem aufgegebenen Projekt, das alle ignorieren.
Das Plattformteam muss sich ständig fragen:
- Löst die Plattform noch echte Probleme?
- Werden Entwickler noch unterstützt?
- Wenn die Antwort unsicher wird, ist es Zeit zu evaluieren und anzupassen.
Praktische Checkliste für die Plattformentwicklung
- Erfassen Sie monatlich die Akzeptanzraten für Pipelines und Vorlagen
- Messen Sie die Zeit von Pull-Request-Merge bis zur Produktionsbereitstellung
- Führen Sie vierteljährlich eine Entwicklerzufriedenheitsumfrage durch
- Halten Sie monatliche Feedback-Sitzungen zwischen Plattform- und Produktteams ab
- Überprüfen Sie Leitplanken alle drei Monate und passen Sie sie basierend auf Vorfallsdaten an
- Protokollieren Sie jede Funktionsanfrage und prüfen Sie sie auf teamübergreifende Nachfrage
- Entfernen Sie ungenutzte Plattformfunktionen, um den Wartungsaufwand zu reduzieren
Das Fazit
Eine Plattform ist kein einmaliger Bau. Sie ist ein Produkt, das kontinuierliche Aufmerksamkeit erfordert. Messen Sie die Akzeptanz, reduzieren Sie Wartezeiten, hören Sie auf Feedback und passen Sie Leitplanken an, während Teams reifen. Wenn Sie die Plattform als lebendiges Produkt behandeln, werden Entwickler sie tatsächlich nutzen wollen.