Planera och prioritera

Lär dig hur du identifierar mål för dina plattformstekniska insatser baserat på plattformsteknikens kapacitetsmodell, går igenom vanliga scenarier och letar efter sätt att mäta framgång. Mät framgång genom att avgränsa dina mål utifrån affärsmålen.

Identifiera mål och viktiga scenarier

Kom igång genom att först utvärdera var din organisation befinner sig i dag med hjälp av plattformsteknikens kapacitetsmodell. Använd modellen för att kartlägga var din organisation finns i sex grundläggande plattformstekniska funktioner: investeringar, implementering, styrning, etablering och hantering, gränssnitt samt mätning och feedback. Alla organisationer är mer avancerade i vissa funktioner än i andra. När du vet var din organisation står idag kan du välja vilka funktioner du vill utöka. Mer information finns i Utvärdera dina nuvarande metoder och ange framtida mål.

Du kan kontinuerligt planera och uppdatera dina plattformstekniska mål över tid. Att vara tydlig med vad du vill vinna på att investera i din plattformstekniska resa kan gå långt för att hjälpa till att bygga organisationsstöd.

Som en plattformsingenjör en gång uttryckte det, "Jag gör inte något för plattformsteknik förrän jag har något jag kan vinna på det." – Peter, plattformsteknikledare, multinationellt teknikföretag

När du tänker på dina mål kan du begränsa dem till affärsmål relaterade till din plattformstekniska insats snarare än detaljerna i ett visst utvecklingsteam. Vanliga plattformstekniska mål på hög nivå är:

Öka programkvaliteten och minska buggar och problem under lanseringen.
Förbättra säkerheten och minska antalet säkerhetsincidenter eller identifierade vanliga sårbarheter och exponeringar (CVE) en gång i produktionen.
Minska risken genom bättre efterlevnad inom områden som licensiering, tillgänglighet, sekretess eller myndighetsreglering.
Påskynda tid till affärsvärde genom att minska komplexiteten, omkostnaderna och främja koddelning genom inner source-praktiker.
Minska kostnaderna för utveckling eller drift, minimera dupliceringen och förbättra automatiseringen.

Det är viktigt att välja det högsta målet eftersom målet styr hur du tänker kring din prioritering.

Ännu bättre, att komma överens om mål och viktiga resultat (OKR) med ditt ledarskap och interna partner hjälper till att fastställa mätbara mål för den nuvarande fasen av dina investeringar. (Andra planeringsmetoder har liknande begrepp om din organisation använder något annat.) De bästa OKR:erna är de som du kan ange baserat på ett konkret mått eftersom det tar bort subjektivitet.

Scenarier och jobb som ska utföras

När du har identifierat dina mål väljer du de viktigaste scenarierna för att driva ut kvarvarande uppgifter och översikt. Se till exempel följande scenarier och de associerade jobb som ska utföras.

Scenario: Börja skapa ett nytt program

Förstå och tillämpa organisationens metodtips och principer
Skapa en ny lagringsplats
Provisioneringsverktyg
Etablera gemensam infrastruktur
Ge gruppmedlemmar åtkomst
Upprätta CI/CD-pipelines
Etablera utvecklingsinfrastruktur
Inledande driftsättning för att testa "pipes"

Scenario: Lägga till eller ta bort en ny medlem i ett befintligt team

Uppdatera åtkomsten till verktyg och tjänster
Konfigurera en utvecklardator
Öka teammedlemmens kompetens i programmen
Skapa en sandbox-miljö för program
Skapa och granska först pull-begäran

Scenario: Lägga till eller uppdatera infrastruktur för befintligt program

Förstå organisationens metodtips, tillgängliga alternativ
Uppdatera eller lägga till infrastruktur som kodartefakter
Skapa sandbox-miljö för program
Verifiera uppdateringar
Distribuera ändringar i andra miljöer

Scenario: Lägg till eller uppdatera verktyg för befintligt team

Förstå organisationens metodtips, tillgängliga alternativ
Begära användning av ett nytt verktyg
Uppdatera gruppmedlemsåtkomst till verktyg
(Om tillämpligt) Integrera verktyget i klienter eller CI/CD-pipelines

Scenario: Hitta eller återanvända befintligt API, SDK eller tjänst

Identifiera tillgängliga API:er, SDK eller tjänster
Utvärdera om den uppfyller behoven
Kontakta ägande teamet om du har frågor
Anta för användning

Scenario: Svara på en åtgärdsincident

Meddelande om ett problem
Utvärdera om applikationskod eller infrarelaterad (eller både och)
Skapa sandbox-miljö som speglar prod (om det är annorlunda)
Gör ändringar, testa, utanför bandutgåva

Scenario: Snabbt åtgärda säkerhetsincidenter

Meddelande om ett problem
Utvärdera bredden på problem (vilka system)
Förstå om kunderna påverkas direkt
Skapa sandbox-miljö som speglar prod (om det är annorlunda)
Göra ändringar, testa, out-of-band release
Kommunicera med alla som påverkas

Scenario: Avveckla verktyg

Förstå verktygsanvändning
Meddela användare om utfasning
(Valfritt) Samordna migrering av användare till ett nytt verktyg

Scenario: Distribution av ny appmodell för arkitektur

Pilotförslag för arkitektur
Justera baserat på pilotresultat
Uppdatera dokumentation om metodtips
Skapa mallar, uppdatera automatisering, principer och styrning

Förstå aktuella efterlevnadsregler
Kontrollera att programmet uppfyller reglerna
Fastställa tidsgräns för korrigeringar för avvikelser
Göra ändringar, testa, släppa

Många scenarier gäller för mer än en roll. Tänk på mått för hur du ska mäta förbättringar.

Från problem till begrepp

Förstå sedan de största problemen som dina utvecklare och andra roller står inför med de scenarier och jobb som du har identifierat. Det kan vara frestande att börja undersöka nya produkter för att fylla i upplevda luckor, men om dessa produkter inte löser en stor smärtpunkt är det osannolikt att de kommer att antas eller uppskattas.

Det finns flera metoder som kan hjälpa dig att utföra den här typen av undersökning, till exempel Hypotesprogressionsramverket. Även om du inte använder en formaliserad process som Hypotesprogressionsramverket bör du intervjua utvecklare om ett jobb som ska göras för att begränsa diskussionen och sedan identifiera deras största problem med att utföra sitt arbete. När du har en god uppfattning om vilka dessa problem är går du vidare till att komma med planer för att lösa dem. På så sätt kan du skapa funktioner som utvecklare vill använda.

För att snabbt kunna upprepa den här processen kan du identifiera någon som kan representera kundens röst direkt i ditt interna utvecklarplattformsteam. Den här rollen kallas vanligtvis produktchef (även om de har en annan befattning), och när deras kunskap växer kan de förutsäga resultaten för mindre beslut och avgöra när du behöver göra fler intervjuer. Detta håller flexibiliteten uppe samtidigt som du fokuserar på att leverera värde till dina interna kunder.

Argumentera för dina initiala investeringar

När du har en uppsättning validerade problem och begrepp kan du bestämma var du ska investera. Tänk dock på den direkta investering och långsiktiga underhåll som krävs vid utvärdering av lösningar. Den lägsta ansträngningslösningen som kan lösa problemet tenderar att vara rätt lösning att börja med, men ofta är det underhållsarbetet som i slutändan avgör om din investering lyckas.

På ett annat sätt skapar du inte lösningar som är inriktade på senare faser av din resa om du inte verkligen behöver det.

När du har identifierat din tunnaste livskraftiga plattform (TVP) (som en minsta livskraftig produkt för din plattform) kan du testa den med en uppsättning utvecklingsteam som är villiga att ge feedback. Om pilotlösningen löser problem som dessa team har bör du inte ha problem med att hitta någon som är intresserad av att engagera sig.

Du bör samla in några viktiga mått när du testar en ny funktion eller ändringar så att du kan mäta om konceptet lyckades innan du distribuerade det.

Mäta framgång och bevisvärde

Att mäta din framgång är en viktig del av ett produkttänk. Även små framgångar med blygsamma investeringar kan lägga grunden för större investeringar att bygga vidare på.

Det kan till exempel vara svårt att säkra finansiering eller inköp för efterlevnadsinsatser eftersom de kan uppfattas som en driftskatt för utvecklingsteam som levererar affärsvärde. Ett produkttänk kan förändra den uppfattningen. Med ett produkttänk försöker du se till att kunderna för din interna utvecklarplattform är nöjda och att intressenternas affärsmål uppfylls. Med mått kan du använda fakta för att bevisa att du tillhandahåller affärsvärde. Att ange OKR kan hjälpa, särskilt om du har mått som du kan använda för att ta bort subjektiva fördomar. Även om du inte mäter något som är tillämpligt idag kan du ange en inlärnings-OKR för att ange en baslinje som du sedan förfinar när den här baslinjen är känd.

Följande är exempel på välkända mått som du kan mäta för att avgöra om de team du arbetar med får ut värdet av det du skapar. Fokusera på de som hjälper dig att mäta om du och dina kunder som är utvecklingsteam uppnår era mål. Följande är till exempel en uppsättning mått som hjälper dig att utvärdera om din plattform bidrar till en effektiv ingenjörsorganisation:

Hastighet/tid till affärsvärde: Mediandagar för att slutföra första pull-begäran (onboarding), medianminuter för bygg- och testprocesser (exempel: CI), mediantid för sammanslagning av pull-begäran.
Programvarukvalitet: Incidenter (problem) som skapats per månad per utveckling (antal normaliserade till antalet utvecklare), genomsnittlig tid för återställning (MTTR), genomsnittlig tid för att undersöka och åtgärda säkerhetsproblem.
Enkel användning av plattform: Nätanvändarnöjdhet (NSAT)
Blomstrande ekosystem: Genomsnittlig poäng för var och en av följande undersökta frågor: "Jag är bemyndigad att göra mitt bästa arbete", "de flesta dagar är jag energisk av det arbete jag gör", "det arbete jag gör är meningsfullt för mig."

Du kan sedan dela upp dessa mått efter organisation, team eller projekt. Du måste mäta vissa baslinjer för att börja, men du kan sedan se dessa mått ändras när du förbättrar din plattform.

Andra mått som du eller dina sponsorer kan vara intresserade av att mäta är:

Area	Exempelmått
Prestanda för programvaruleverans	DevOps Research and Assessment (DORA): Förändringsledtid, distributionsfrekvens, ändringsfelprocent, tid för att återställa tjänsten (MTTR)
Operations	DORA (MTTR), genomsnittlig tid mellan fel (MTBF), genomsnittlig tid för att bekräfta, slutkundstillgänglighet, svarstid, dataflödesmått, kostnad per team, kostnad per distribution
Implementeringsmått för plattformskapacitet	Antal team eller utvecklare som använder ett verktyg eller en funktion över tid, procentandel lagringsplatser som använder plattformen, de mest populära mallarna, pipelines osv.

Att samla in mått kräver tid och arbete så det är viktigt att fokusera på kritiska mått för de kärnmål som du har identifierat, särskilt de som driver dina OKR. OpenTelemetry-baserade produkter som Application Insights kan vara till hjälp.

Se till att mäta plattformens användarvänlighet och undersöka att du regelbundet har ett blomstrande ekosystem. Dessa mått missas ofta för interna system och är en ledande indikator på om du uppfyller dina bredare affärsmål eftersom engagerat deltagande är avgörande för framgång. Det hjälper dig också att veta om det är dags att göra ytterligare kundutveckling för att förstå vart du ska gå härnäst.

Andra tips

Oavsett hur du börjar bör du tänka på att du bör planera för förändring, börja med nya program för piloter, fokusera på att förbättra befintliga användarupplevelser, anta principen om minsta behörighet, planera för kontrollerade experiment och minimera anpassningen.

Förändringsplan

Målprogramplattformen utvecklas över tid och du kanske inte kan migrera alla dina befintliga investeringar samtidigt. Tänk igenom hur du kan stödja mer än en variant över tid och planera för förändring.

Validera idéer med nyare program

Börja med nya program av rimlig storlek när du pilottestar dina nya plattforms- eller plattformsfunktioner. Detta ger dig också erfarenhet av att hantera din plattform som en produkt. Dra dig undan från att omplatforma projekt till att börja med eftersom du lär dig allt eftersom, och stora befintliga program har ofta unika behov som bara upptäcks under själva omplatformningsarbetet. På grund av detta kan att koppla din framgång till dessa typer av ansträngningar resultera i förväntningsmismatchar eller sent uppkomna problem. Att börja med något nyare kan ge dig förtroende för din riktning och det värde det ger. Det minskar risken för att ta itu med dessa större ansträngningar. Med andra ord, om du är säker på att människor kan börja rätt och fortsätta på rätt sätt, blir det lättare att driva en get right-kampanj med det du lär dig av erfarenhet. Om den här metoden inte är möjlig vill du göra noggrann analys, ange förväntningar och stegvis gå in i stället för att försöka ändra allt på en gång.

Fokusera på befintliga tyngdpunkter för användarupplevelser innan du skapar nya

Utvecklare är mer benägna att anta och hålla sig till nya funktioner när de visas i något de redan gillar och använder. När du utvärderar begrepp för att leverera nya funktioner bör du undersöka alternativ som utökar befintliga tyngdpunkter. Till exempel kan redigerare/ID:er (Visual Studio, VS Code), DevOps-paket (GitHub, Azure DevOps), befintliga CLIs eller en befintlig intern portal vara effektivare än en helt ny portal eller annan UX. Mer information finns i Användarupplevelser.

Anta principen om lägsta behörighet

Anta att utvecklare har begränsad åtkomst till underordnade system för saker som etableringsinfrastruktur. Du behöver ett kontrollerat sätt att aktivera den här åtkomsten för självbetjäningsupplevelser.

Planera för kontrollerad experimentering

Experimentera innan större eller riskfyllda ändringar lanseras. Allt måste inte vara helt automatiserat för att starta. Ett automatiskt utlöst manuellt arbetsflöde kan vara ett bra sätt att testa idéer.

Minimera anpassning av appplattform

Undvik att anpassa byggda funktioner hos programplattformar som kan överskuggas av funktioner som programvaruleverantörer släpper med tiden. Till exempel körningstjänst, servicemesh, identitetssystem och så vidare. Om du upptäcker ett akut behov i ett område som du misstänker kan vara så här, kommer planen för flera implementeringsalternativ med tanke på det långsiktiga underhållet sannolikt att leda till att du byter över tid.

Tillämpa programvarutekniksystem

Feedback

Var den här sidan till hjälp?

Last updated on 2025-10-23