Planen und Priorisieren

Erfahren Sie, wie Sie Ziele für Ihre Plattformentwicklungsbemühungen identifizieren, gängige Szenarien durchlaufen und nach Möglichkeiten suchen, den Erfolg zu messen. Sie können den Erfolg messen, indem Sie Ihre Ziele auf Geschäftsziele festlegen.

Identifizieren von Zielen und wichtigen Szenarien

Als Leiter der Plattformtechnik sagte es einmal: "Ich tue nichts für plattformtechnische Entwicklung, bis ich etwas daraus gewinnen kann." – Peter, Platform Engineering Lead, Multinational Tech Company

Anstatt sich eine Checkliste mit Funktionen oder Features anzusehen, identifizieren Sie zunächst die Ziele Ihrer Plattformentwicklungsbemühungen. Sie können die Ziele im Laufe der Zeit kontinuierlich planen und aktualisieren. Wenn Sie sich jedoch darüber im Klaren sind, was Sie von der Investition in Ihre Plattformentwicklung gewinnen möchten, kann dies einen großen Beitrag zur Unterstützung der Organisation leisten.

Wenn Sie über Ihre Ziele nachdenken, können Sie sie auf Geschäftsziele im Zusammenhang mit Ihrem Plattformentwicklungsaufwand statt auf die Besonderheiten eines bestimmten Entwicklungsteams festlegen. Hier sind z. B. einige allgemeine Ziele für die Plattformentwicklung aufgeführt:

• Erhöhen Sie die Anwendungsqualität, reduzieren Sie Fehler und Probleme während der Veröffentlichung.
• Verbessern Sie die Sicherheit, verringern Sie die Anzahl von Sicherheitsvorfällen oder erkannten CVEs , die einmal in der Produktion vorhanden sind.
• Verringern Sie das Risiko durch bessere Compliance in Bereichen wie Lizenzierung, Barrierefreiheit, Datenschutz oder behördlichen Vorschriften.
• Beschleunigen Sie den Time-to-Business-Nutzen, indem Sie Komplexität und Mehraufwand reduzieren und die Codefreigabe durch interne Quellpraktiken fördern.
• Reduzieren Sie die Entwicklungs- oder Betriebskosten, minimieren Sie Duplizierungen und verbessern Sie die Automatisierung.

Obwohl alle diese Ziele langfristige Ziele sein können, ist die Auswahl Ihres obersten Ziels wichtig, da dies Ihre Meinung über Ihre Priorisierung bestimmt.

Noch besser: Die Vereinbarung von Zielen und Key Results (OKRs) mit Ihren Führungskräften und internen Partnern kann Ihnen helfen, messbare Ziele für die aktuelle Phase Ihrer Investitionen zu ermitteln. (Andere Planungsansätze haben ähnliche Konzepte, wenn Ihr organization etwas anderes verwendet.) Die besten OKRs sind diejenigen, die Sie basierend auf einem konkreten Measure festlegen können, da dadurch die Subjektivität entfernt wird.

Zu erledigende Szenarien und Aufträge

Nachdem Sie Ihre Ziele identifiziert haben, identifizieren Sie die wichtigsten Szenarien, die Sie verwenden werden, um Ihren Backlog und Ihre Roadmap zu entfernen. Sehen Sie sich z. B. diese Szenarien und zu erledigenden Aufträge an.

Szenario: Erstellen einer neuen Anwendung

• Grundlegendes und Anwenden bewährter Methoden und Richtlinien für Organisationen
• Erstellen eines neuen Repositorys
• Bereitstellen von Tools
• Bereitstellen einer allgemeinen Infrastruktur
• Gewähren des Zugriffs für Teammitglieder
• Einrichten von CI/CD-Pipelines
• Bereitstellen der Entwicklungsinfrastruktur
• Erste Bereitstellung zum Testen von "Pipes"

Szenario: Hinzufügen/Entfernen eines neuen Mitglieds zu einem vorhandenen Team

• Aktualisieren des Zugriffs auf Tools und Dienste
• Einrichten des Entwicklercomputers
• Einrichten eines Teammitglieds für Anwendungen
• Erstellen einer Anwendungssandkastenumgebung
• Erstellen und Überprüfen des ersten PR

Szenario: Hinzufügen/Aktualisieren der Infrastruktur für eine vorhandene Anwendung

• Grundlegendes zu bewährten Methoden der Organisation, verfügbare Optionen
• Aktualisieren/Hinzufügen der Infrastruktur als Codeartefakte
• Erstellen einer Anwendungssandkastenumgebung
• Überprüfen von Updates
• Rollout von Änderungen in anderen Umgebungen

Szenario: Hinzufügen/Aktualisieren des Tools für vorhandenes Team

• Grundlegendes zu bewährten Methoden der Organisation, verfügbare Optionen
• Anfordern der Verwendung des neuen Tools
• Aktualisieren des Zugriffs von Teammitgliedern auf Tools
• (Falls zutreffend) Integrieren des Tools in Clients oder CI/CD-Pipelines

Szenario: Suchen/Wiederverwenden vorhandener API, SDK oder Dienst

• Ermitteln verfügbarer APIs, SDK und Dienste
• Bewerten, ob die Anforderungen erfüllt werden
• Wenden Sie sich bei Fragen an das eigene Team.
• Für Anwendung einführen

Szenario: Reagieren auf einen Betriebsvorfall

• Benachrichtigung eines Problems
• Bewerten, ob App-Code oder Infrastruktur im Zusammenhang (oder beides)
• Erstellen einer Sandboxumgebung, die prod widerspiegelt (falls anders)
• Änderungen vornehmen, Testen, Out-of-Band-Release

Szenario: Schnelle Behebung von Sicherheitsvorfällen/ Hinweis zu allgemeinen Sicherheitsrisiken und Offenlegungen (CVE)

• Benachrichtigung eines Problems
• Bewerten der Bandbreite der Probleme (welche Systeme)
• Verstehen, ob Kunden direkt betroffen sind
• Erstellen einer Sandboxumgebung, die prod widerspiegelt (falls anders)
• Änderungen vornehmen, Testen, Out-of-Band-Release
• Kommunikation mit allen betroffenen Personen

Szenario: Veraltetes Tool

• Grundlegendes zur Toolverwendung
• Benachrichtigen von Benutzern über veraltete Daten
• (Optional) Koordination Migration von Benutzern zu einem neuen Tool

Szenario: Definieren/Rollout eines neuen App-Modells/einer neuen Architektur

• Vorgeschlagene Pilotarchitektur
• Anpassen basierend auf Pilotergebnissen
• Aktualisieren der Dokumentation zu bewährten Methoden
• Erstellen von Vorlagen, Aktualisieren von Automatisierung, Richtlinien, Governance

Überwachen der Anwendungskonformität (DSGVO, Barrierefreiheit, Infrastrukturstandards)

• Grundlegendes zu aktuellen Complianceregeln
• Überprüfen, ob die Anwendung Regeln erfüllt
• Festlegen einer Frist für Korrekturen für Abweichungen
• Änderungen vornehmen, testen, freigeben

Viele Szenarien gelten für mehr als eine Rolle. Daher sollten Sie auch über Metriken nachdenken, um zu verstehen, wie Sich Ihre Szenarien verbessern.

Von Problemen zu Konzepten

Als Nächstes wird empfohlen, die größten Probleme zu verstehen, die Ihre Entwickler und andere Rollen mit den von Ihnen identifizierten Szenarien und Aufträgen haben. Es kann verlockend sein, mit der Untersuchung neuer Produkte zu beginnen, um wahrgenommene Lücken zu schließen, aber wenn diese Produkte keine großen Probleme lösen, ist es unwahrscheinlich, dass sie angenommen oder geschätzt werden.

Es gibt mehrere Ansätze, die Ihnen bei dieser Art von Untersuchung helfen können. Einer davon ist das Framework für die Hypothesenprogression. Auch wenn Sie keinen formalisierten Prozess wie das Hypothesenprogressionsframework verwenden, können Sie viel davon gewinnen, Entwickler zu einer Aufgabe zu interviewen, die sie erledigen müssen, um die Diskussion zu bestimmen, und dann ihre größten Probleme bei der Durchführung ihrer Arbeit zu identifizieren. Sobald Sie ein gutes Gefühl dafür haben, was diese Probleme sind, können Sie mit der Erstellung von Konzepten für deren Lösung fortfahren. Dadurch wird sichergestellt, dass Sie Features erstellen, die Entwickler verwenden möchten.

Um diesen Prozess schnell wiederholen zu können, sollten Sie eine Person identifizieren, die die Stimme des Kunden direkt in Ihrem internen Entwicklerplattformteam darstellen kann. Diese Rolle wird in der Regel als Produktmanager bezeichnet (auch wenn sie eine andere Berufsbezeichnung haben), und mit zunehmender Kenntnis können sie Ergebnisse für kleinere Entscheidungen genau vorhersagen und bestimmen, wann Sie mehr Interviews durchführen müssen. Dies sorgt für eine höhere Agilität und gleichzeitig dafür, dass Sie sich darauf konzentrieren, Ihren internen Kunden einen Mehrwert zu bieten.

Machen Sie sich für Ihre anfangs getätigten Investitionen ein

Sobald Sie über eine Reihe überprüfter Probleme und Konzepte verfügen, sind Sie in einer guten Position, um ein Argument für investitionen zu machen. Beachten Sie jedoch, wie hoch die Investitionen im Vorfeld und die langfristige Wartung sind. Die Lösung mit dem geringsten Aufwand, die das Problem lösen kann, ist in der Regel die richtige Lösung für den Anfang, aber oft sind es die Wartungsarbeiten, die letztendlich entscheiden, ob Ihre Investition erfolgreich ist.

Anders ausgedrückt: Erstellen Sie keine Lösungen, die auf spätere Phasen Ihrer Reise abzielen, es sei denn, Dies ist wirklich erforderlich.

Nachdem Sie Ihre dünnste lebensfähige Plattform (TVP) ( ein MVP für Ihre Plattform) identifiziert haben, können Sie sie mit einer Reihe von Entwicklungsteams pilotieren, die bereit sind, Feedback zu geben. Wenn Ihre Pilotlösung Probleme löst, mit denen diese Teams konfrontiert sind, sollten Sie keine Probleme haben, jemanden zu finden, der daran interessiert ist.

Sie sollten einige wichtige Metriken erfassen, während Sie eine neue Funktion oder Änderungen testen, damit Sie messen können, ob das Konzept erfolgreich war, bevor Sie es bereitstellen.

Messen von Erfolg und Beweiswert

Unabhängig davon, ob Sie Ihre erste Investition tätigen oder nicht, ist das Messen, wie erfolgreich Sie sind, ein wichtiger Bestandteil einer Produktmentalität. Es hilft Ihnen nicht nur zu wissen, ob Sie Ihre Ziele erreicht haben, sondern auch kleine Erfolge mit bescheidenen Investitionen können die Grundlage für größere Investitionen schaffen, auf denen sie aufbauen können.

Beispielsweise kann es schwierig sein, Finanzierungen oder Buy-Ins für Compliance-Bemühungen zu sichern, da sie als Betriebssteuer für Entwicklungsteams wahrgenommen werden können, die einen geschäftlichen Wert liefern. Eine Produktmentalität kann diese Wahrnehmung ändern. Mit einer Produktmentalität versuchen Sie sicherzustellen, dass die Kunden für Ihre interne Entwicklerplattform zufrieden sind und dass die Geschäftsziele der Projektbeteiligten erreicht werden. Metriken versetzen Sie in die Lage, Fakten zu verwenden, um zu beweisen, dass Sie geschäftlichen Nutzen bieten. Das Festlegen von OKRs kann hilfreich sein, insbesondere wenn Sie über Metriken verfügen, mit denen Sie subjektive Verzerrungen entfernen können. Auch wenn Sie heute nichts Zutreffendes messen, können Sie ein Lern-OKR festlegen, um eine Baseline festzulegen, die Sie dann verfeinern, nachdem diese Baseline bekannt ist.

Im Folgenden finden Sie Beispiele für bekannte Metriken, die Sie messen können, um zu bestimmen, ob die Teams, mit denen Sie arbeiten, einen Wert aus dem nutzen, was Sie erstellen. Lassen Sie sich von denen abbringen, mit denen Sie messen können, ob Sie und Ihre Entwicklungsteamkunden Ihre Ziele erreichen. Im Folgenden finden Sie beispielsweise eine Reihe von Metriken, mit denen Sie bewerten können, ob Ihre Plattform zu einem effektiven engineering-organization beiträgt:

• Geschwindigkeit/Zeit bis zum Geschäftswert: Mediantage bis zum Abschluss des ersten Pull Requests (Onboarding), Medianminuten für Build- und Testprozesse (Beispiel: CI), Medianzeit bis zum Zusammenführen von Pull Request.
• Softwarequalität: Incidents (Issues), die pro Monat pro Dev erstellt werden (anzahl normalisiert auf anzahl der Entwickler), mean time to remediate (MTTR), mean time to investigate and remediate security issues.
• Benutzerfreundlichkeit der Plattform: Net User Satisfaction (NSAT)
• Blühendes Ökosystem: Durchschnittliche Bewertung für jede der folgenden befragten Fragen: "Ich bin befähigt, meine beste Arbeit zu tun", "die meisten Tage, an denen ich energiegeladen bin durch die Arbeit, die ich verarbeite", "die Arbeit, die ich verarbeite, ist für mich von Bedeutung."

Anschließend können Sie diese Metriken nach organization, Team oder Projekt aufschlüsseln. Zunächst müssen Sie einige Baselines messen, aber Sie können dann watch sich diese Metriken ändern, wenn Sie Ihre Plattform verbessern.

Weitere Metriken, die Sie oder Ihre Sponsoren messen möchten, sind:

Bereich	Beispielmetriken
Leistung der Softwarebereitstellung	DevOps Research and Assessment (DORA): Vorlaufzeit, Bereitstellungshäufigkeit, Änderungsfehlerrate, Zeit bis zur Wiederherstellung des Diensts (MTTR)
Vorgänge	DORA (MTTR), mean time between failure (MTBF), average time to acknowledge, end-customer availability, latency, throughput metrics, cost per team, cost per deployment
Metriken zur Einführung von Plattformfunktionen	Anzahl der Teams oder Entwickler, die ein Tool oder Feature im Laufe der Zeit verwenden, Prozentsatz der Repositorys, die die Plattform verwenden, die beliebtesten Vorlagen, Pipelines usw.

Das Sammeln von Metriken erfordert Zeit und Aufwand, daher ist es wichtig, sich auf kritische Metriken für die von Ihnen identifizierten Kernziele zu konzentrieren – insbesondere auf diejenigen, die Ihre OKRs unterstützen. OpenTelemetry-basierte Produkte wie Application Insights können hilfreich sein. Unabhängig davon sollten Sie die Benutzerfreundlichkeit der Plattform messen und regelmäßig überprüfen, ob Sie über ein florierendes Ökosystem verfügen. Diese Metriken werden für interne Systeme häufig übersehen und sind ein Frühindikator dafür, ob Sie Ihre umfassenderen Geschäftsziele erreichen, da eine engagierte Beteiligung entscheidend für den Erfolg ist. Es hilft Ihnen auch zu wissen, ob es an der Zeit ist, weitere Kundenentwicklung zu unternehmen, um zu verstehen, wohin sie als Nächstes gehen.

Weitere Tipps

Beachten Sie unabhängig davon, wie Sie beginnen, die folgenden Richtlinien.

Planen von Änderungen

Ihre Zielanwendungsplattform wird sich im Laufe der Zeit weiterentwickeln, und Möglicherweise können Sie nicht alle vorhandenen Investitionen gleichzeitig migrieren. Sie sollten sich wahrscheinlich überlegen, wie Sie mehrere Variationen im Laufe der Zeit unterstützen und Änderungen planen können.

Überprüfen von Ideen mit neueren Anwendungen

Es ist im Allgemeinen am besten, mit neuen Anwendungen einer angemessenen Größe zu beginnen, wenn Sie Ihre neue Plattform oder Plattformfunktionen pilotieren. Dies gibt Ihnen auch Erfahrung mit der Verwaltung Ihrer Plattform als Produkt. Scheuen Sie sich vor der Neuplattformierung von Projekten, da Sie lernen werden, wie Sie gehen, und große vorhandene Anwendungen haben oft einzigartige Anforderungen, die erst während der Umplattformierung selbst aufgedeckt werden. Aus diesem Gründen kann die Kopplung Ihres Erfolgs mit diesen Arten von Bemühungen zu Erwartungskonflikten oder späten Breaking-Problemen führen. Wenn Sie mit etwas neuerem beginnen, können Sie den Wert, den es bietet, vertrauen, in Ihre Richtung. Dies verringert das Risiko, dass diese größeren Anstrengungen angegangen werden. Anders ausgedrückt: Wenn Sie sicher sind, dass die Leute richtig anfangen und richtig bleiben können, dann ist es einfacher, mit dem, was Sie aus Erfahrung gelernt haben, eine get right-Kampagne zu fahren. Wenn dieser Ansatz nicht möglich ist, sollten Sie sorgfältig analysieren, Erwartungen festlegen und inkrementell einsteigen, anstatt zu versuchen, alles auf einmal zu ändern.

Konzentrieren Sie sich auf vorhandene Schwerpunkte für Benutzeroberflächen, bevor Sie neue erstellen

Entwickler werden neue Funktionen eher übernehmen und beibehalten, wenn sie in etwas angezeigt werden, das sie bereits mögen und verwenden. Während Sie Konzepte zur Bereitstellung neuer Funktionen evaluieren, sollten Sie optionen untersuchen, die vorhandene "Schwerpunkte" erweitern. Beispielsweise können Editoren/IDEs (Visual Studio, VS Code), DevOps-Suites (GitHub, Azure DevOps), vorhandene CLIs oder ein vorhandenes internes Portal effektiver sein als ein völlig neues Portal oder eine andere Benutzeroberfläche. Weitere Informationen finden Sie unter Benutzeroberflächen .

Nehmen Sie das Prinzip der geringsten Rechte an.

Angenommen, Entwickler haben eingeschränkten Zugriff auf Downstreamsysteme für Dinge wie die Bereitstellungsinfrastruktur. Sie benötigen eine kontrollierte Methode, um diesen Zugriff für Self-Service-Umgebungen zu aktivieren.

Planen von kontrollierten Experimenten

Experimentieren Sie vor dem Rollout wichtiger oder riskanter Änderungen. Nicht alles muss für den Start vollständig automatisiert werden. Ein automatisch ausgelöster manueller Workflow kann eine hervorragende Möglichkeit sein, Ideen zu testen.

Minimieren der Anpassung der App-Plattform

Versuchen Sie, die benutzerdefinierte Erstellung von Anwendungsplattformfunktionen zu vermeiden, die von Funktionen, die von Softwareherstellern im Laufe der Zeit veröffentlicht werden können, verfinstert werden könnten. Beispielsweise Laufzeithosting, Dienstgitter, Identitätssysteme usw. Wenn Sie einen dringenden Bedarf in einem Bereich feststellen, von dem Sie vermuten, dass es sich um eine solche Handelt, sollten Sie mehrere Implementierungsoptionen planen, da die langfristige Wartung wahrscheinlich dazu führt, dass Sie im Laufe der Zeit wechseln.

Anwenden von Softwareentwicklungssystemen