Läs på engelska

Dela via


Planera och prioritera

Lär dig hur du identifierar mål för din plattformsutveckling, går igenom vanliga scenarier och letar efter sätt att mäta framgång. Du kan mäta framgång genom att omfångssöka dina mål mot affärsmål.

Identifiera mål och viktiga scenarier

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, plattformsteknik Lead, Multinationella Tech Company

I stället för att titta på en rote checklista med funktioner, börja med att identifiera målen för din plattformsutveckling. Du kan kontinuerligt planera och uppdatera målen över tid. Men att vara tydlig med vad du vill vinna på att investera i din plattformsteknikresa kan gå långt för att hjälpa till att bygga organisationsstöd.

När du tänker på dina mål kan du begränsa dem till affärsmål relaterade till din plattformsutveckling, snarare än detaljerna i ett visst utvecklingsteam. Här är till exempel några vanliga övergripande plattformsutvecklingsmål:

  • Öka programkvaliteten, minska buggar och problem under lanseringen.
  • Förbättra säkerheten, minska antalet säkerhetsincidenter eller identifierade CV:er en gång i produktionen.
  • Minska risken genom bättre efterlevnad inom områden som licensiering, tillgänglighet, sekretess eller myndighetsreglering.
  • Påskynda värdet för tid till företag genom att minska komplexitet, omkostnader och främja koddelning via interna källmetoder .
  • Minska kostnaderna för utveckling eller drift, minimera dupliceringen och förbättra automatiseringen.

Även om alla dessa mål kan vara långsiktiga mål, är det viktigt att välja ditt främsta mål eftersom detta driver hur du tänker om din prioritering.

Ännu bättre, att komma överens om mål och viktiga resultat (OKR) med ditt ledarskap och interna partner kan hjälpa dig att upprätta mätbara mål för den aktuella 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 subjektiviteten.

Scenarier och jobb som ska utföras

När du har identifierat dina mål kan du identifiera de viktigaste scenarier som du kommer att använda för att driva ut din kvarvarande uppgifter och översikt. Se till exempel de här scenarierna och jobben som ska utföras.

Scenario: Börja skapa ett nytt program

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

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

  • Uppdatera åtkomsten till verktyg, tjänster
  • Konfigurera utvecklardator
  • Öka teammedlemmen i program
  • Skapa sandbox-miljö för program
  • Skapa och granska första PR

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

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

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

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

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

  • Identifiera tillgängliga API:er, SDK, tjänster
  • Utvärdera om den uppfyller behoven
  • Kontakta ägande teamet för frågor
  • Anta för program

Scenario: Svara på en åtgärdsincident

  • Meddelande om ett problem
  • Utvärdera om appkod eller infra-relaterade (eller båda)
  • Skapa sandbox-miljö som speglar prod (om det är annorlunda)
  • Göra ändringar, testa, out-of-band release

Scenario: Åtgärda säkerhetsincidenter snabbt/CVE-meddelande (Common Vulnerabilities and Exposures)

  • Meddelande om ett problem
  • Utvärdera bredden av problem (vilka system)
  • Förstå om kunder 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: Inaktuellt verktyg

  • Förstå verktygsanvändning
  • Meddela användare om utfasning
  • (Valfritt) Samordningsmigrering av användare till nytt verktyg

Scenario: Definiera/distribuera ny appmodell/arkitektur

  • Pilot-föreslagen arkitektur
  • Justera baserat på pilotresultat
  • Uppdatera dokumentation om metodtips
  • Skapa mallar, uppdatera automatisering, principer, styrning

Granska programefterlevnad (GDPR, tillgänglighet, infrastrukturstandarder)

  • Förstå aktuella efterlevnadsregler
  • Verifiera att programmet uppfyller reglerna
  • Upprätta 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, så du vill också tänka på mått för hur du ska förstå hur mycket dina scenarier förbättras.

Från problem till begrepp

Därefter rekommenderar vi att du försöker förstå 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 antas eller uppskattas.

Det finns flera metoder som kan hjälpa dig att utföra den här typen av undersökning. Den ena är Hypotesförloppsramverket. Även om du inte använder en formaliserad process som Hypotesförloppsramverket kan du få mycket av att 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 bra uppfattning om vad dessa problem är kan du gå vidare till att komma med begrepp för att lösa dem. Detta säkerställer att du skapar funktioner som utvecklare vill använda.

För att snabbt kunna upprepa den här processen vill 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 kommer de att kunna förutsäga resultat för mindre beslut och avgöra när du behöver göra fler intervjuer. Detta håller din flexibilitet uppe samtidigt som du ser till att du fokuserar på att leverera värde till dina interna kunder.

Argumentera för dina initiala investeringar

När du har en uppsättning verifierade problem och begrepp kan du göra ett argument för att investera. Tänk dock på den nivå av investeringar i förväg och långsiktigt underhåll som krävs. Den lägsta ansträngningslösningen som kan lösa problemet tenderar att vara den rätta 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 fungerande plattform (TVP) (en MVP 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

Oavsett om du gör din första investering eller inte är mätning av hur framgångsrik du är en viktig del av ett produkttänk. Det hjälper dig inte bara att veta om du har uppnått dina mål, men ä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 driftsskatt 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 ger affärsvärde. Att ställa in OKR kan hjälpa, särskilt om du har mått som du kan använda för att ta bort subjektiv bias. Även om du inte mäter något som är tillämpligt idag kan du ställa in 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. Noll i dem som hjälper dig att mäta om du och dina utvecklingsteams kunder uppnår dina 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 den 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 skapas per månad per dev (antal normaliserade till antalet utvecklare), genomsnittlig tid för att åtgärda (MTTR), genomsnittlig tid för att undersöka och åtgärda säkerhetsproblem.
  • Plattformslägdje: 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 får jag energi 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. Till att börja med behöver du mäta vissa baslinjer, men du kan sedan watch 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:

Området Exempelmått
Prestanda för programvaruleverans DevOps Research and Assessment (DORA): Ändra ledtid, distributionsfrekvens, ändringsfelfrekvens, tid för att återställa tjänsten (MTTR)
Verksamhet 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. Oavsett, se till att mäta plattformens användarvänlighet och undersökning att du har ett blomstrande ekosystem regelbundet. Dessa mått missas ofta för interna system och är en ledande indikator på om du kommer att uppfylla 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å följande riktlinjer.

Planera för ändring

Målprogramplattformen utvecklas med tiden och du kanske inte kan migrera alla dina befintliga investeringar samtidigt. Du kommer förmodligen att vilja tänka 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

Det är vanligtvis bäst att 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 omplattformsprojekt till att börja med eftersom du kommer att lära dig allt eftersom, och stora befintliga program har ofta unika behov som bara upptäcks under själva omplattformsarbetet. På grund av detta kan koppling av din framgång till dessa typer av ansträngningar resultera i förväntade matchningar eller sena problem. Att börja med något nyare kan ge dig förtroende för din riktning det värde som det ger. Det minskar risken för att ta itu med dessa större ansträngningar. Med andra hälsningar, om du är säker på att människor kan börja rätt och hålla sig rätt, blir det lättare att driva en få rätt kampanj med vad 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 använda och hålla sig till nya funktioner när de visas i något som de redan gillar och använder. När du utvärderar koncept för att leverera nya funktioner bör du undersöka alternativ som utökar befintliga "tyngdpunkter". Till exempel kan redigerare/IDE:er (Visual Studio, VS Code), DevOps-paket (GitHub, Azure DevOps), befintliga CLI:er eller en befintlig intern portal vara mer effektiva ä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 etablering av infrastruktur. Du behöver ett kontrollerat sätt att aktivera den här åtkomsten för självbetjäningsupplevelser.

Planera för kontrollerat experimentering

Experimentera innan du distribuerar större eller riskfyllda ändringar. 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 appplattformen

Försök att undvika anpassade funktioner för att skapa programplattform som kan förmörkas av funktioner som programvaruleverantörer släpper över tid. Till exempel körningsvärd, tjänstnät, identitetssystem och så vidare. Om du upptäcker ett brådskande behov i ett område som du misstänker kan vara så här, kommer du troligen att byta över tid genom att planera för flera implementeringsalternativ med tanke på det långsiktiga underhållet.