Planen und Priorisieren
Erfahren Sie, wie Sie Ziele für Ihre Plattform-Engineering-Bemühungen basierend auf dem Platform Engineering Capability Model identifizieren, allgemeine Szenarien durchgehen und nach Möglichkeiten suchen, um den Erfolg zu messen. Messen Sie den Erfolg, indem Sie Ihre Ziele auf Geschäftsziele festlegen.
Identifizieren von Zielen und wichtigen Szenarien
Um zu beginnen, bewerten Sie zunächst, wo Sich Ihre Organisation heute mit dem Platform Engineering Capability Model befindet. Verwenden Sie das Modell, um zu erstellen, wo Sich Ihre Organisation über sechs kernige Plattform engineering-Funktionen erstreckt – Investitionen, Einführung, Governance, Bereitstellung und Verwaltung, Schnittstellen und Messung und Feedback. Alle Organisationen sind in einigen Funktionen komplexer als in anderen. Sobald Sie wissen, wo Ihre Organisation heute steht, können Sie auswählen, welche Funktionen Sie erweitern möchten. Weitere Informationen finden Sie unter Verwendung des Modells.
Sie können Ihre Plattform-Engineering-Ziele im Laufe der Zeit kontinuierlich planen und aktualisieren. Wenn Sie klar sind, was Sie gewinnen möchten, wenn Sie in Ihre Plattform-Engineering-Reise investieren möchten, kann die Unterstützung der Organisation sehr weit gehen.
Als Plattform-Engineering-Lead einmal gesagt: "Ich tue nichts für Plattformtechnik, bis ich etwas habe, was ich daraus gewinnen kann." – Peter, Plattform engineering Lead, Multinational Tech Company
Wenn Sie über Ihre Ziele nachdenken, können Sie sie auf geschäftsbezogene Ziele im Zusammenhang mit Ihrem Plattform engineering-Aufwand und nicht auf die Besonderheiten eines bestimmten Entwicklungsteams beschränken. Zu den allgemeinen Zielen des Plattform engineering gehören:
- Erhöhen Sie die Anwendungsqualität, reduzieren Sie Fehler und Probleme während der Veröffentlichung.
- Verbessern Sie die Sicherheit, verringern Sie die Anzahl der Sicherheitsvorfälle oder erkannte allgemeine Sicherheitsrisiken und Expositionen (CVEs) einmal in der Produktion.
- Verringern Sie das Risiko durch eine bessere Compliance in Bereichen wie Lizenzierung, Barrierefreiheit, Datenschutz oder behördlichen Vorschriften.
- Beschleunigen Sie den Zeit-zu-Geschäfts-Wert, indem Sie Komplexität, Overhead und Förderung der Codefreigabe durch interne Quellpraktiken reduzieren.
- Reduzieren Sie Entwicklungs- oder Betriebskosten, minimieren Sie die Duplizierung und verbessern Sie die Automatisierung.
Die Auswahl Ihres obersten Ziels ist wichtig, da Ihr Ziel dazu führt, wie Sie ihre Priorisierung berücksichtigen.
Noch besser, die Einigung auf Ziele und wichtige Ergebnisse (OKRs) mit Ihren Führungskräften und internen Partnern führt dazu, messbare Ziele für die aktuelle Phase Ihrer Investitionen zu schaffen. (Andere Planungsansätze haben ähnliche Konzepte, wenn Ihre Organisation etwas anderes verwendet.) Die besten OKRs sind diejenigen, die Sie basierend auf einer konkreten Maßnahme festlegen können, da sie subjektivität entfernt.
Zu erledigende Szenarien und Aufträge
Nachdem Sie Ihre Ziele identifiziert haben, wählen Sie die wichtigsten Szenarien aus, um Ihren Backlog und Ihre Roadmap zu fördern. Sehen Sie sich beispielsweise diese Szenarien und die zugehörigen Aufträge an, die ausgeführt werden sollen.
Szenario: Starten des Erstellens einer neuen Anwendung
- Grundlegendes und Anwenden bewährter Methoden und Richtlinien der Organisation
- Erstellen eines neuen Repositorys
- Bereitstellungstools
- Bereitstellen allgemeiner Infrastruktur
- Teammitgliedern Zugriff gewähren
- Einrichten von CI/CD-Pipelines
- Bereitstellung der Entwicklungsinfrastruktur
- Erste Bereitstellung zum Testen von "Pipes"
Szenario: Hinzufügen oder Entfernen eines neuen Mitglieds zu einem vorhandenen Team
- Aktualisieren des Zugriffs auf Tools, Dienste
- Einrichten eines Entwicklercomputers
- Teammitglied in Anwendungen hochfahren
- Erstellen einer Anwendungs-Sandkastenumgebung
- Erstellen und Überprüfen der ersten PR
Szenario: Hinzufügen oder Aktualisieren der Infrastruktur für vorhandene Anwendungen
- Grundlegendes zu bewährten Methoden der Organisation, verfügbare Optionen
- Aktualisieren/Hinzufügen der Infrastruktur als Codeartefakte
- Erstellen einer Anwendungs-Sandkastenumgebung
- Überprüfen von Updates
- Rollout von Änderungen an anderen Umgebungen
Szenario: Hinzufügen oder Aktualisieren des Tools für vorhandenes Team
- Grundlegendes zu bewährten Methoden der Organisation, verfügbare Optionen
- Anfordern der Verwendung eines neuen Tools
- Aktualisieren des Teammitgliedzugriffs auf Tools
- (Falls zutreffend) Integrieren von Tools in Clients oder CI/CD-Pipelines
Szenario: Suchen oder Wiederverwenden vorhandener API, SDK oder Dienst
- Entdecken verfügbarer APIs, SDK, Dienste
- Bewerten, ob sie den Anforderungen entspricht
- Wenden Sie sich für Fragen mit dem Besitzerteam an
- Anwendung übernehmen
Szenario: Reagieren auf einen Betriebsvorfall
- Benachrichtigung über ein Problem
- Bewerten, ob App-Code oder infrastrukturbezogener Code (oder beides)
- Erstellen einer Sandkastenumgebung, die Prod (falls anders) widerspiegelt
- Änderungen vornehmen, Testen, Out-of-Band-Release
Szenario: Schnelle Behebung von Sicherheitsvorfällen
- Benachrichtigung über ein Problem
- Bewerten der Breite von Problemen (welche Systeme)
- Verstehen, ob Kunden direkt betroffen sind
- Erstellen einer Sandkastenumgebung, die Prod (falls anders) widerspiegelt
- Änderungen vornehmen, Testen, Out-of-Band-Release
- Kommunikation mit betroffenen Personen
Szenario: Veraltetes Tool
- Grundlegendes zur Toolverwendung
- Benachrichtigen von Benutzern über veraltete Benutzer
- (Optional) Koordinationsmigration von Benutzern zu einem neuen Tool
Szenario: Rollout des neuen App-Modells der Architektur
- Vorgeschlagene Pilotarchitektur
- Anpassen basierend auf den Pilotergebnissen
- Dokumentation zu bewährten Methoden aktualisieren
- Erstellen von Vorlagen, Aktualisieren der Automatisierung, Richtlinien, Governance
Überwachen der Anwendungscompliance (DSGVO, Barrierefreiheit, Infrastrukturstandards)
- Grundlegendes zu aktuellen Complianceregeln
- Überprüfen, ob die Anwendung Regeln erfüllt
- Stichtag für Korrekturen für Abweichungen festlegen
- Änderungen vornehmen, Testen, Freigeben
Viele Szenarien gelten für mehrere Rollen. Überlegen Sie, wie Sie Die Verbesserung messen.
Von Problemen bis hin zu Konzepten
Als Nächstes sollten Sie die größten Probleme, mit denen Ihre Entwickler und andere Rollen konfrontiert sind, mit den von Ihnen identifizierten Szenarien und Aufträgen vertraut machen. Es kann verlockend sein, neue Produkte zu untersuchen, um wahrgenommene Lücken zu füllen, aber wenn diese Produkte keinen großen Schmerzpunkt lösen, sind sie unwahrscheinlich, dass sie angenommen oder geschätzt werden.
Es gibt mehrere Ansätze, die Ihnen dabei helfen können, diese Art von Untersuchung zu erledigen. Eine ist das Hypothesenentwicklungsframework. Auch wenn Sie keinen formalisierten Prozess wie das Hypothesenentwicklungsframework verwenden, sollten Sie Entwickler über einen Auftrag interviewen, der für den Umfang der Diskussion durchgeführt werden soll, und dann ihre größten Probleme bei der Erledigung ihrer Arbeit identifizieren. Sobald Sie einen guten Eindruck davon haben, was diese Probleme sind, fahren Sie mit den Plänen für die Lösung fort. Dadurch wird sichergestellt, dass Sie Features erstellen, die Entwickler verwenden möchten.
Um diesen Prozess schnell wiederholen zu können, identifizieren Sie jemanden, der die Stimme des Kunden direkt in Ihrem internen Entwicklerplattformteam darstellen kann. Diese Rolle wird in der Regel als Produktmanager bezeichnet (auch wenn sie über eine andere Position verfügen), und wenn ihr Wissen wächst, können sie Ergebnisse für kleinere Entscheidungen genau vorhersagen und bestimmen, wann Sie weitere Interviews durchführen müssen. Dadurch bleibt Ihre Flexibilität aufrecht, während Sie sicherstellen, dass Sie sich auf die Bereitstellung von Mehrwert für Ihre internen Kunden konzentrieren.
Machen Sie den Fall für Ihre ersten Investitionen
Sobald Sie über eine Reihe überprüfter Probleme und Konzepte verfügen, können Sie entscheiden, wo Sie investieren möchten. Berücksichtigen Sie jedoch beim Auswerten von Lösungen die Vor-Front-Investition und die langfristige Wartung. Die niedrigste Leistungslösung, die das Problem lösen kann, ist tendenziell der richtige, mit dem man beginnen kann, aber oft ist es die Wartungsarbeit, die letztendlich entscheidet, ob Ihre Investition erfolgreich ist.
Erstellen Sie auf eine andere Weise Lösungen, die auf spätere Phasen Ihrer Reise abzielen, es sei denn, Sie müssen es wirklich brauchen.
Nachdem Sie Ihre dünnste lebensfähige Plattform (TVP) (ein MVP für Ihre Plattform) identifiziert haben, testen Sie sie mit einer Reihe von Entwicklungsteams, 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 sich für die Interaktion interessiert.
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 Nachweiswert
Das Messen, wie erfolgreich Sie sind, ist ein wichtiger Bestandteil einer Produkt-Denkweise. Selbst kleine Erfolge mit bescheidenen Investitionen können die Grundlagen für größere Investitionen schaffen.
So kann es z. B. schwierig sein, Finanzierungen oder Buy-Ins für Compliance-Anstrengungen zu sichern, da sie als Betriebssteuer für Entwicklungsteams wahrgenommen werden können, die einen geschäftlichen Nutzen erzielen. Eine Produkt-Denkweise kann diese Wahrnehmung verändern. Mit einer Produkt-Denkweise versuchen Sie, sicherzustellen, dass die Kunden für Ihre interne Entwicklerplattform glücklich sind und dass die Geschäftsziele der Projektbeteiligten erfüllt sind. Metriken versetzen Sie in die Lage, Fakten zu verwenden, um zu beweisen, dass Sie Einen geschäftlichen Wert bereitstellen. Das Festlegen von OKRs kann hilfreich sein, insbesondere wenn Sie Metriken haben, die Sie verwenden können, um subjektive Verzerrungen zu entfernen. Auch wenn Sie heute nichts messen, können Sie ein Lern-OKR festlegen, um einen Basisplan festzulegen, den Sie dann verfeinern, nachdem dieser Basisplan bekannt ist.
Im Folgenden finden Sie Beispiele für bekannte Metriken, die Sie messen können, um zu ermitteln, ob die Teams, mit denen Sie zusammenarbeiten, einen Nutzen aus dem erstellen, was Sie erstellen. Null bei denen, die Ihnen helfen, zu messen, ob Sie und Ihre Entwicklungsteamkunden Ihre Ziele erreichen. Im Folgenden sehen Sie beispielsweise eine Reihe von Metriken, mit denen Sie ermitteln können, ob Ihre Plattform zu einer effektiven Engineering-Organisation beiträgt:
- Geschwindigkeit / Zeit für den Geschäftlichen Wert: Median Tage zum Abschließen der ersten Pullanforderung (Onboarding), median Minuten für Build- und Testprozesse (Beispiel: CI), median Zeit zum Zusammenführen der Pullanforderung.
- Softwarequalität: Vorfälle (Probleme), die pro Monat pro Dev(Anzahl normalisierter Anzahl von Devs) erstellt wurden, mittlere Zeit für die Behebung (MTTR), mittlere Zeit zur Untersuchung und Behebung von Sicherheitsproblemen.
- Benutzerfreundlichkeit der Plattform: Net User Satisfaction (NSAT)
- Florierendes Ökosystem: Durchschnittliche Punktzahl für jede der folgenden befragten Fragen: "Ich bin befähigend, meine beste Arbeit zu erledigen", "die meisten Tage, die ich von der Arbeit, die ich tue, energiegeladen sind", "die Arbeit, die ich tue, ist für mich aussagekräftig."
Sie können diese Metriken dann nach Organisation, Team oder Projekt aufschlüsseln. Um zu beginnen, müssen Sie einige Basispläne messen, aber Sie können diese Metriken während der Verbesserung Ihrer Plattform beobachten.
Andere Metriken, die Sie oder Ihre Sponsoren messen können, sind:
| Bereich | Beispielmetriken |
|---|---|
| Leistung der Softwarebereitstellung | DevOps Research and Assessment (DORA): Änderungsvorlaufzeit, Bereitstellungshäufigkeit, Änderungsfehlerrate, Zeit zum Wiederherstellen des Diensts (MTTR) |
| Vorgänge | DORA (MTTR), mittlere Zeit zwischen Ausfall (MTTR), durchschnittliche Zeit für die Bestätigung, Verfügbarkeit von Endbenutzern, Latenz, Durchsatzmetriken, Kosten pro Team, Kosten pro Bereitstellung |
| Metriken für die 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, die am häufigsten verwendeten Vorlagen, Pipelines usw. verwenden. |
Das Sammeln von Metriken erfordert Zeit und Mühe, damit es wichtig ist, sich auf wichtige Metriken für die von Ihnen identifizierten Kernziele zu konzentrieren – insbesondere diejenigen, die Ihre OKRs stärken. OpenTelemetry-basierte Produkte wie Application Insights können Ihnen helfen. Achten Sie unabhängig davon darauf, die Plattformfreundlichkeit zu messen und zu vermessen, dass Sie regelmäßig über ein florierendes Ökosystem verfügen. Diese Metriken werden häufig für interne Systeme verpasst und sind ein führender Indikator dafür, ob Sie Ihre breiteren Geschäftsziele erfüllen, da die beteiligungstätige Beteiligung für den Erfolg von entscheidender Bedeutung ist. Es hilft Ihnen auch zu wissen, ob es an der Zeit ist, eine weitere Kundenentwicklung durchzuführen, um zu verstehen, wo sie weitergehen sollen.
Weitere Tipps
Unabhängig davon, wie Sie beginnen, sollten Sie änderungen planen, mit neuen Anwendungen für Pilotprojekte beginnen, sich auf die Verbesserung vorhandener Benutzeroberflächen konzentrieren, das Prinzip der geringsten Berechtigungen übernehmen, den Plan für kontrollierte Experimente planen und die Anpassung minimieren.
Plan für Änderung
Ihre Zielanwendungsplattform wird sich im Laufe der Zeit weiterentwickeln, und Sie können möglicherweise nicht alle Ihre vorhandenen Investitionen gleichzeitig migrieren. Überlegen Sie, wie Sie mehr als eine Variation im Laufe der Zeit unterstützen und Änderungen planen können.
Überprüfen von Ideen mit neueren Anwendungen
Beginnen Sie mit neuen Anwendungen einer angemessenen Größe, wenn Sie Ihre neuen Plattform- oder Plattformfunktionen testen. Dadurch erhalten Sie auch Erfahrung beim Verwalten Ihrer Plattform als Produkt. Scheuen Sie sich, projekte neu zu replatieren, um zu beginnen, da Sie unterwegs lernen, und große vorhandene Anwendungen haben oft einzigartige Anforderungen, die nur während der erneuten Plattformarbeit selbst aufgedeckt werden. Aus diesem Gründen kann die Kopplung Ihres Erfolgs mit diesen Arten von Bemühungen zu Erwartungskonflikten oder verspäteten Problemen führen. Wenn Sie mit etwas Neueren beginnen, können Sie Vertrauen in Ihre Richtung haben, die der von ihm bereitgestellte Wert bietet. Dies verringert das Risiko, diese größeren Anstrengungen zu bewältigen. Stellen Sie eine weitere Möglichkeit bereit, wenn Sie sicher sind, dass die Leute richtig beginnen und richtig bleiben können, dann wird es einfacher, eine richtige Kampagne mit den Erfahrungen zu machen, die Sie lernen. Wenn dieser Ansatz nicht möglich ist, sollten Sie sorgfältige Analysen durchführen, Erwartungen festlegen und inkrementell schritten, anstatt zu versuchen, alles gleichzeitig zu ändern.
Konzentrieren Sie sich auf vorhandene Schwerkraftzentren für Benutzeroberflächen, bevor Sie neue erstellen
Entwickler werden wahrscheinlicher neue Funktionen übernehmen und beibehalten, wenn sie in etwas angezeigt werden, das sie bereits mögen und verwenden. Wenn Sie Konzepte zur Bereitstellung neuer Funktionen auswerten, sollten Sie die Optionen untersuchen, die vorhandene "Schwerkraftzentren" 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 UX. Weitere Informationen finden Sie in den Benutzeroberflächen .
Annehmen des Prinzips der geringsten Rechte
Gehen Sie davon aus, dass Entwickler eingeschränkten Zugriff auf downstream-Systeme haben, z. B. bereitstellungsinfrastrukturen. Sie benötigen eine kontrollierte Möglichkeit, um diesen Zugriff für Self-Service-Erfahrungen zu ermöglichen.
Planen der kontrollierten Experimentierung
Experimentieren Sie, bevor Sie wichtige oder riskante Änderungen einführen. Nicht alles muss vollständig automatisiert sein, um zu beginnen. Ein automatisch ausgelöster manueller Workflow kann eine hervorragende Möglichkeit sein, Ideen zu pilotieren.
Minimieren der App-Plattformanpassung
Vermeiden Sie benutzerdefinierte Anwendungsplattform-Funktionen, die von Funktionssoftwareanbietern im Laufe der Zeit verfinstert werden könnten. Beispiel: Laufzeithosting, Dienstgitter, Identitätssysteme usw. Wenn Sie einen dringenden Bedarf in einem Bereich finden, den Sie vermuten, könnte dies der Fall sein, planen Sie mehrere Implementierungsoptionen, da die langfristige Wartung wahrscheinlich dazu führt, dass Sie im Laufe der Zeit wechseln.