Plannen en prioriteit geven

Meer informatie over het identificeren van doelen voor uw platform-engineering, het doorlopen van algemene scenario's en het zoeken naar manieren om succes te meten. U kunt succes meten door het bereik van uw doelstellingen af te bakenen op bedrijfsdoelstellingen.

Doelen en belangrijke scenario's identificeren

Zoals een platform engineering lead het ooit zei: "Ik doe niets voor platform engineering totdat ik iets heb wat ik er van kan profiteren." – Peter, platform engineering lead, Multinational Tech Company

In plaats van te kijken naar een controlelijst met mogelijkheden of functies, begint u met het identificeren van de doelen van uw platform engineering-inspanningen. U kunt de doelstellingen in de loop van de tijd voortdurend plannen en bijwerken. Als u echter duidelijk weet wat u wilt profiteren van het investeren in uw platform-engineeringtraject, kan dit een lange weg helpen bij het bouwen van organisatorische ondersteuning.

Terwijl u nadenkt over uw doelstellingen, kunt u deze richten op bedrijfsdoelstellingen met betrekking tot uw platform engineering-inspanningen, in plaats van de specifieke kenmerken van een bepaald ontwikkelingsteam. Hier volgen bijvoorbeeld enkele algemene algemene technische doelstellingen voor platformen:

• Verhoog de kwaliteit van de toepassing, verminder fouten en problemen tijdens de release.
• Verbeter de beveiliging, verminder het aantal beveiligingsincidenten of gedetecteerde CVE's eenmaal in productie.
• Verminder het risico door betere naleving op gebieden zoals licenties, toegankelijkheid, privacy of overheidsvoorschriften.
• Versnel de time-to-business-waarde door de complexiteit en overhead te verminderen en het delen van code te bevorderen via interne bronprocedures .
• Verlaag de kosten voor ontwikkeling of bewerkingen, minimaliseer duplicatie en verbeter de automatisering.

Hoewel al deze doelstellingen op de lange termijn kunnen zijn, is het essentieel om uw belangrijkste doel te kiezen, omdat dit bepaalt hoe u denkt over uw prioriteitstelling.

Beter nog, het afspreken van doelstellingen en belangrijke resultaten (OKR's) met uw leiderschap en interne partners kan u helpen meetbare doelen te bepalen voor de huidige fase van uw investeringen. (Andere planningsmethoden hebben vergelijkbare concepten als uw organisatie iets anders gebruikt.) De beste OKR's zijn de OKR's die u kunt instellen op basis van een concrete meting, omdat hiermee subjectiviteit wordt verwijderd.

Scenario's en taken die moeten worden uitgevoerd

Zodra u uw doelen hebt geïdentificeerd, identificeert u de belangrijkste scenario's die u gaat gebruiken om uw achterstand en roadmap te verdrijven. Zie bijvoorbeeld deze scenario's en taken die moeten worden uitgevoerd.

Scenario: Beginnen met het bouwen van een nieuwe toepassing

• Best practices en beleidsregels voor organisaties begrijpen en toepassen
• Een nieuwe opslagplaats maken
• Hulpprogramma's inrichten
• Algemene infrastructuur inrichten
• Teamleden toegang geven
• CI/CD-pijplijnen instellen
• Dev-infrastructuur inrichten
• Eerste implementatie om 'pipes' te testen

Scenario: Een nieuw lid aan een bestaand team toevoegen/verwijderen

• Toegang tot hulpprogramma's en services bijwerken
• Ontwikkelaarscomputer instellen
• Teamlid opvoeren voor toepassingen
• Sandbox-omgeving voor toepassingen maken
• Eerste pull-aanvraag maken en controleren

Scenario: Infrastructuur voor bestaande toepassing toevoegen/bijwerken

• Inzicht in best practices voor organisaties, beschikbare opties
• Infrastructuur bijwerken/toevoegen als codeartefacten
• Sandbox-omgeving voor toepassingen maken
• Updates controleren
• Wijzigingen implementeren in andere omgevingen

Scenario: Hulpprogramma voor het bestaande team toevoegen/bijwerken

• Inzicht in best practices voor organisaties, beschikbare opties
• Gebruik van nieuw hulpprogramma aanvragen
• De toegang van teamleden tot hulpprogramma's bijwerken
• (Indien van toepassing) Hulpprogramma integreren in clients of CI/CD-pijplijnen

Scenario: bestaande API, SDK of service zoeken/opnieuw gebruiken

• Beschikbare API's, SDK, services detecteren
• Beoordelen of het voldoet aan de behoeften
• Contact maken met het team dat eigenaar is voor eventuele vragen
• Adopteren voor toepassing

Scenario: reageren op een bewerkingsincident

• Melding van een probleem
• Beoordelen of app-code of infrastructuur gerelateerd is (of beide)
• Sandbox-omgeving maken die prod spiegelt (indien verschillend)
• Wijzigingen aanbrengen, testen, out-of-band release

Scenario: Beveiligingsincidenten snel herstellen/kennisgeving over veelvoorkomende beveiligingsproblemen en blootstellingen (CVE)

• Melding van een probleem
• De breedte van problemen beoordelen (welke systemen)
• Begrijpen of klanten rechtstreeks worden beïnvloed
• Sandbox-omgeving maken die prod spiegelt (indien verschillend)
• Wijzigingen aanbrengen, testen, out-of-band release
• Communiceren met iedereen die betrokken is

Scenario: hulpprogramma voor afschaffing

• Inzicht in hulpprogrammagebruik
• Gebruikers op de hoogte stellen van afschaffing
• (Optioneel) Coördinatie Migratie van gebruikers naar een nieuw hulpprogramma

Scenario: Nieuw app-model/architectuur definiëren/implementeren

• Voorgestelde testarchitectuur
• Aanpassen op basis van testresultaten
• Documentatie voor aanbevolen procedures voor updates
• Sjablonen maken, automatisering bijwerken, beleid, governance

Toepassingsnaleving controleren (AVG, toegankelijkheid, infrastructuurstandaarden)

• Inzicht in de huidige nalevingsregels
• Controleren of de toepassing voldoet aan regels
• Deadline instellen voor correcties voor afwijkingen
• Wijzigingen aanbrengen, testen, vrijgeven

Veel scenario's zijn van toepassing op meer dan één rol, dus u moet ook nadenken over metrische gegevens voor hoe u begrijpt in hoeverre uw scenario's worden verbeterd.

Van problemen naar concepten

Vervolgens raden we u aan om inzicht te krijgen in de grootste problemen waarmee uw ontwikkelaars en andere rollen worden geconfronteerd met de scenario's en taken die u hebt geïdentificeerd. Het kan verleidelijk zijn om te beginnen met het onderzoeken van nieuwe producten om waargenomen hiaten op te vullen, maar als deze producten een groot knelpunt niet oplossen, is het onwaarschijnlijk dat ze worden overgenomen of gewaardeerd.

Er zijn verschillende benaderingen die u kunnen helpen bij dit soort onderzoek. Een daarvan is het Framework voor hypothesevoortgang. Zelfs als u geen geformaliseerd proces zoals het Hypothese progressieframework gebruikt, kunt u veel voordeel halen uit het interviewen van ontwikkelaars over een taak die moet worden uitgevoerd om de discussie te beperken en vervolgens hun grootste problemen bij het uitvoeren van hun werk te identificeren. Zodra u een goed idee hebt van wat deze problemen zijn, kunt u verdergaan met het bedenken van concepten om ze op te lossen. Dit zorgt ervoor dat u functies bouwt die ontwikkelaars willen gebruiken.

Als u dit proces snel wilt kunnen herhalen, moet u iemand identificeren die de stem van de klant rechtstreeks in uw interne ontwikkelplatformteam kan vertegenwoordigen. Deze rol wordt meestal productmanager genoemd (zelfs als deze een andere functie heeft), en naarmate hun kennis groeit, kunnen ze resultaten voor kleinere beslissingen nauwkeurig voorspellen en bepalen wanneer u meer interviews moet uitvoeren. Zo blijft uw flexibiliteit behouden, terwijl u er nog steeds voor zorgt dat u zich richt op het leveren van waarde aan uw interne klanten.

Maak uw initiële investeringen mogelijk

Zodra u een set gevalideerde problemen en concepten hebt, bent u in een goede positie om een argument te maken om te investeren. Houd echter rekening met het niveau van de investering vooraf en het vereiste langetermijnonderhoud. De oplossing met de laagste inspanning die het probleem kan oplossen, is meestal de juiste oplossing om mee te beginnen, maar vaak is het het onderhoudswerk dat uiteindelijk bepaalt of uw investering succesvol is.

Anders gezegd, maak geen oplossingen die zijn gericht op latere fasen van uw reis, tenzij u dat echt nodig hebt.

Zodra u uw dunste levensvatbare platform (TVP) ( een MVP voor uw platform) hebt geïdentificeerd, kunt u het proberen met een set ontwikkelteams die bereid zijn om feedback te geven. Als uw testoplossing problemen oplost waarmee deze teams worden geconfronteerd, zou u geen problemen moeten hebben met het vinden van iemand die geïnteresseerd is in betrokkenheid.

U moet enkele belangrijke metrische gegevens vastleggen terwijl u een nieuwe mogelijkheid of wijzigingen uitvoert, zodat u kunt meten of het concept succesvol was voordat u het uitrolt.

Succes meten en waarde bewijzen

Ongeacht of u uw eerste investering doet of niet, het meten van hoe succesvol u bent, is een belangrijk onderdeel van een productmentaliteit. Het helpt u niet alleen te weten of u uw doelen hebt bereikt, maar zelfs kleine successen met bescheiden investeringen kunnen de basis leggen voor grotere investeringen om op voort te bouwen.

Het kan bijvoorbeeld moeilijk zijn om financiering of buy-in te krijgen voor nalevingsinspanningen, omdat ze kunnen worden gezien als een operationele belasting voor ontwikkelteams die bedrijfswaarde leveren. Een productmentaliteit kan die perceptie veranderen. Met een productmentaliteit probeert u ervoor te zorgen dat de klanten voor uw interne ontwikkelaarsplatform tevreden zijn en dat de bedrijfsdoelen van de belanghebbenden worden bereikt. Metrische gegevens stellen u in staat om feiten te gebruiken om te bewijzen dat u bedrijfswaarde levert. Het instellen van OKR's kan helpen, met name als u metrische gegevens hebt die u kunt gebruiken om subjectieve bias te verwijderen. Zelfs als u vandaag niets meet dat van toepassing is, kunt u een leer-OKR instellen om een basislijn in te stellen die u vervolgens gaat verfijnen nadat deze basislijn bekend is.

Hier volgen voorbeelden van bekende metrische gegevens die u kunt meten om te bepalen of de teams waarmee u werkt, waarde halen uit wat u bouwt. U kunt meten of u, en uw klanten van het ontwikkelteam, uw doelen bereiken. Hier volgt bijvoorbeeld een set metrische gegevens waarmee u kunt evalueren of uw platform bijdraagt aan een effectieve technische organisatie:

• Snelheid/tijd tot bedrijfswaarde: mediaan dagen voor het voltooien van de eerste pull-aanvraag (onboarding), mediaanminuten voor build- en testprocessen (bijvoorbeeld: CI), mediaantijd voor het samenvoegen van pull-aanvragen.
• Softwarekwaliteit: incidenten (problemen) die per maand zijn gemaakt per dev (aantal genormaliseerd naar aantal ontwikkelaars), gemiddelde tijd om te herstellen (MTTR), gemiddelde tijd om beveiligingsproblemen te onderzoeken en op te lossen.
• Gebruiksgemak van platform: Netto gebruikerstevredenheid (NSAT)
• Bloeiend ecosysteem: Gemiddelde score voor elk van de volgende onderzochte vragen: 'Ik ben gemachtigd om mijn beste werk te doen', 'de meeste dagen dat ik energiek ben door het werk dat ik doe', 'het werk dat ik doe is zinvol voor mij'.

U kunt deze metrische gegevens vervolgens opsplitsen per organisatie, team of project. Om te beginnen moet u enkele basislijnen meten, maar u kunt vervolgens watch deze metrische gegevens veranderen naarmate u uw platform verbetert.

Andere metrische gegevens die u of uw sponsors mogelijk willen meten, zijn:

Gebied	Voorbeeld van metrische gegevens
Prestaties van softwarelevering	DevOps Research and Assessment (DORA): wijzigingstijd, implementatiefrequentie, wijzigings fail rate, time to restore service (MTTR)
Operaties	DORA (MTTR), mean time between failure (MTBF), average time to acknowledge, end-customer availability, latency, metrics throughput, cost per team, cost per deployment
Metrische gegevens over acceptatie van platformmogelijkheden	Het aantal teams of ontwikkelaars dat een hulpprogramma of functie in de loop van de tijd gebruikt, het percentage opslagplaatsen dat het platform gebruikt, de populairste sjablonen, pijplijnen, enzovoort.

Het verzamelen van metrische gegevens vergt tijd en moeite, dus het is belangrijk om u te richten op kritieke metrische gegevens voor de belangrijkste doelen die u hebt geïdentificeerd, met name de doelen die uw OKR's mogelijk maken. Op OpenTelemetry gebaseerde producten zoals Application Insights kunnen hierbij helpen. Zorg er in ieder geval voor dat u het gebruiksgemak van het platform meet en regelmatig controleert of u een bloeiend ecosysteem hebt. Deze metrische gegevens worden vaak gemist voor interne systemen en zijn een belangrijke indicator voor het bereiken van uw bredere bedrijfsdoelen, omdat betrokken deelname essentieel is voor succes. Het helpt u ook om te weten of het tijd is om de klant verder te ontwikkelen om te begrijpen waar u verder kunt gaan.

Andere tips

Houd rekening met de volgende richtlijnen, ongeacht hoe u begint.

Wijziging plannen

Uw doeltoepassingsplatform zal zich in de loop van de tijd ontwikkelen en u kunt mogelijk niet al uw bestaande investeringen in één keer migreren. Waarschijnlijk wilt u nadenken over hoe u in de loop van de tijd meer dan één variatie kunt ondersteunen en wijzigingen kunt plannen.

Ideeën valideren met nieuwere toepassingen

Het is over het algemeen het beste om te beginnen met nieuwe toepassingen van een redelijke grootte wanneer u uw nieuwe platform of platformmogelijkheden test. Dit biedt u ook ervaring met het beheren van uw platform als een product. Schuw het opnieuw platformen van projecten om te beginnen, omdat u onderweg leert en grote bestaande toepassingen vaak unieke behoeften hebben die alleen worden ontdekt tijdens het opnieuw platformen zelf. Daarom kan het koppelen van uw succes aan dit soort inspanningen leiden tot niet-overeenkomende verwachtingen of problemen met late fouten. Als u met iets nieuws begint, kunt u vertrouwen hebben in de richting van de waarde die het biedt. Dat vermindert het risico dat deze grotere inspanningen worden aangepakt. Anders gezegd: als u er zeker van bent dat mensen goed kunnen beginnen en goed kunnen blijven, wordt het gemakkelijker om een goede campagne te voeren met wat u uit ervaring leert. Als deze aanpak niet mogelijk is, moet u een zorgvuldige analyse uitvoeren, verwachtingen instellen en stapsgewijs stappen ondernemen in plaats van alles in één keer te wijzigen.

Focus op bestaande zwaartepunten voor gebruikerservaringen voordat u nieuwe maakt

Ontwikkelaars zijn eerder geneigd om nieuwe mogelijkheden te gebruiken en vast te houden wanneer ze worden weergegeven in iets dat ze al leuk vinden en gebruiken. Terwijl u concepten evalueert om nieuwe mogelijkheden te bieden, moet u opties onderzoeken die bestaande 'zwaartepunten' uitbreiden. Editors/IDE's (Visual Studio, VS Code), DevOps-suites (GitHub, Azure DevOps), bestaande CLIs of een bestaande interne portal kunnen bijvoorbeeld effectiever zijn dan een volledig nieuwe portal of andere UX. Zie gebruikerservaringen voor meer informatie.

Ga uit van het principe van minimale bevoegdheden

Stel dat ontwikkelaars beperkte toegang hebben tot downstreamsystemen voor zaken als het inrichten van infrastructuur. U hebt een gecontroleerde manier nodig om deze toegang in te schakelen voor selfservice-ervaringen.

Plan voor gecontroleerde experimenten

Experimenteer voordat u grote of riskante wijzigingen uitrolt. Niet alles hoeft volledig geautomatiseerd te zijn om te starten. Een automatisch geactiveerde handmatige werkstroom kan een uitstekende manier zijn om ideeën te testen.

Aanpassing van app-platform minimaliseren

Probeer aangepaste mogelijkheden voor het bouwen van een toepassingsplatform te vermijden die in de loop van de tijd kunnen worden overschaduwd door mogelijkheden die softwareleveranciers uitbrengen. Bijvoorbeeld runtimehosting, service-meshes, identiteitssystemen, enzovoort. Als u een dringende behoefte vindt in een gebied dat waarschijnlijk zo is, kunt u meerdere implementatieopties plannen, aangezien het onderhoud op lange termijn waarschijnlijk tot gevolg heeft dat u na verloop van tijd overschakelt.

Software engineering-systemen toepassen