Het framework in 3 stappen voor het in gebruik nemen van een intern ontwikkelaarsplatform
Een intern ontwikkelaarsplatform (IDP) helpt je ontwikkelaars zich te richten op het leveren van software zonder de overhead van implementatiepipelines, configuratiebeheer of het inrichten van omgevingen. Als engineeringmanager is dit misschien precies wat je zoekt. Maar weten dat je een intern ontwikkelaarsplatform nodig hebt en er een in gebruik nemen zijn twee verschillende dingen.
Hoewel verschillende platformen verschillende niveaus van middelen vereisen om op te zetten en te onderhouden, zorgt een methodische aanpak van de ingebruikname ervoor dat je organisatie de best mogelijke start maakt. Het kiezen van het juiste interne ontwikkelaarsplatform en het succesvol uitrollen ervan zal aanzienlijk ontwikkelaarstijd en resources vrijmaken.
In dit artikel bieden we een stappenplan in drie stappen voor engineeringmanagers die klaar zijn om van IDP-concept naar concrete actie over te gaan.
We behandelen hoe je het volgende doet:
Een aanvraag voor een voorstel (RFP) uitgeven om mogelijke leveranciers te identificeren
Je gekozen tool uitrollen om te zorgen dat deze wordt ingevoerd
Succes meten en verbeteringen bijhouden in de developer experience
Een RFP opstellen voor een intern ontwikkelaarsplatform
De eerste stap naar IDP-adoptie is het opstellen van een aanvraag voor voorstellen (RFP). Een RFP communiceert precies wat je organisatie nodig heeft van een intern ontwikkelaarsplatform. Leveranciers reageren met voorstellen waarin ze laten zien hoe ze aan deze behoeften kunnen voldoen, bijvoorbeeld met begeleide demo's en gratis proefversies van software. Dit geeft je team ook een duidelijke richtlijn om de voorstellen te beoordelen.
Neem alles op wat je nodig hebt van een IDP
Er zijn drie hoofdgebieden om in je RFP's rekening mee te houden:
Uitdagingen: Met welke uitdagingen hebben je engineeringteams momenteel te maken die een intern ontwikkelaarsplatform kan helpen aanpakken? Waarschijnlijk heb je verschillende belangrijke uitdagingen die je wilt oplossen.
Doelen: Welke resultaten moet je behalen door een intern platform voor ontwikkelaars te gebruiken?
Productvereisten: Welke functies en mogelijkheden heb je nodig om deze doelen te bereiken?
Bijvoorbeeld:
Als je kennis verliest wanneer developers lid worden van teams of van team wisselen, is je doel misschien om de onboarding van developers te versnellen. Je kunt prioriteit geven aan functies die selfservice mogelijk maken en handmatige stappen voor configuratie verminderen, bijvoorbeeld via selfserviceworkflows en integratie met de kennisdatabase.
Als je engineeringorganisatie groeit en meer best practices en standaarden moet volgen, kan je doel zijn om de beveiliging te verbeteren en kwetsbaarheden te verminderen. Mogelijk heb je mogelijkheden nodig om te integreren met beveiligingsplatforms en de naleving te monitoren met scorecards.
Als je het lastig vindt om je engineers productiever te maken en meer tijd te laten besteden aan het werk dat ze het beste doen, is je doel misschien om de insteltijd te verkorten zodat teams snel services kunnen opzetten. Mogelijk heb je infrastructuurautomatisering en templating nodig.
Krijg een duidelijk beeld van je huidige situatie
Om je uitdagingen beter te begrijpen en je doel te bepalen, beoordeel je de huidige status van de developer experience binnen je organisatie. Ga er niet zomaar van uit dat je de huidige situatie al kent, maar probeer in plaats daarvan enquêtes onder developers uit te voeren, bestaande processen te auditen en focusgroepen met developers te organiseren om te onderzoeken waar je verbeteringen moet aanbrengen. Zorg ervoor dat je uitlegt welke volgende stappen je neemt en houd teams op de hoogte van je IDP-voortgang.
Ons rapport over de status van de developer experience liet zien dat minder dan de helft van de developers vindt dat de organisatie prioriteit geeft aan developer experience. Dat is niet verrassend als 2 van de 3 developers nog steeds meer dan 8 uur per week verliezen door inefficiënties in hun rol.
Een intern ontwikkelaarsplatform uitrollen
Zodra je een intern ontwikkelaarsplatform hebt gekozen, stel je samen een plan op voor het uitrolproces en houd je de adoptie bij. Een kant-en-klaar intern ontwikkelaarsplatform vermindert de hoeveelheid inspanning die de uitrol van individuele teamleden vraagt. Compass heeft bijvoorbeeld veel minder engineeringresources nodig dan een open-sourceplatform, zoals Backstage, waarvoor 4 full-stack engineers nodig zijn om het goed op te zetten en te onderhouden. Met Compass kun je je tools voor broncodebeheer verbinden en je repo's importeren om je catalogus met softwarecomponenten in slechts 10 minuten te vullen.
Stel een stuurgroep samen
Om ervoor te zorgen dat de uitrol nog soepeler verloopt, stel je een stuurgroep samen van een paar belangrijke stakeholders. Deze experts bieden support, bewaken het proces en nemen beslissingen om waar nodig aanpassingen door te voeren.
We raden je aan contact op te nemen met:
Een executive sponsor: de hoogstgeplaatste persoon die de inspanningen rond het ontwikkelaarsplatform zal leiden. De Chief Technology Officer, VP of Engineering of Head of Platforms kan goed geschikt zijn voor deze rol.
Invloedrijke developers: Kies een kleine groep invloedrijke developers uit je hele organisatie om te helpen bij het ontwerpen, of op zijn minst op de hoogte te blijven van de uitrolplannen voor je interne developerplatform.
Een platformteam of DevOps-engineers: Omdat integraties essentieel zijn voor de manier waarop interne ontwikkelaarsplatforms waarde leveren, moeten de verantwoordelijken voor deze tools belangrijke partners zijn bij de uitrol.
Beleideigenaren of governance-teams: interne ontwikkelaarsplatforms maken het voor engineeringteams makkelijker om te voldoen aan standaarden en best practices, dus samenwerken met degenen die verantwoordelijk zijn voor deze standaarden kan nuttig zijn bij de planning.
Maak een uitrolplanning aan
Zodra je stuurgroep is samengesteld, stel je een planning op voor de uitrol van je interne ontwikkelaarsplatform. Communiceer deze planning aan alle teams die het nieuwe interne ontwikkelaarsplatform gaan gebruiken en vraag om aanvullende feedback over de haalbaarheid van je plan, zodat je het zo nodig kunt aanpassen. Terwijl je het schema doorloopt, kijk je regelmatig hoe het staat met de voortgang en de acceptatie, en bied je support.
We hebben een implementatiehandleiding voor Compass gemaakt om je nog eenvoudiger op weg te helpen.
Het succes meten van een intern ontwikkelaarsplatform
Om je voortgang te meten, ga je terug naar de doelen die je hebt opgesteld toen je voor het eerst je RFP opstelde. Bedenk zowel kwalitatieve als kwantitatieve key performance indicators (KPI's) die een volledig beeld geven van de vraag of je interne ontwikkelaarsplatform de waarde levert die je voor ogen had. Met Compass kun je aangepaste scorecards maken om je KPI's te definiëren en ervoor te zorgen dat je engineeringteams dezelfde standaarden nastreven.
De meeste mensen zien KPI's als "harde cijfers" of "objectieve meetwaarden", en dat werkt voor kwantitatieve concepten zoals omzet of foutpercentages. Developer experience is echter subjectief, wat betekent dat de KPI's enigszins kwalitatief zijn, zoals de ervaren eenvoud van software leveren, de ervaren productiviteit en de betrokkenheid of tevredenheid van medewerkers.
Vind de juiste metingen voor je organisatie
Hier zijn enkele voorbeelden van wat je mogelijk bijhoudt, afhankelijk van je doelen:
Als het verbeteren van de beveiliging je doel is, kun je ernaar streven om open kwetsbaarheden elk kwartaal met een bepaald aantal te verminderen.
Als je productiviteit wilt verbeteren, kan je KPI zijn om de doorlooptijd voor het inrichten van infrastructuur te verkorten van 5 dagen naar 2 uur.
Als sneller onboarden je doel was, kun je de tijd tot productiviteit voor nieuwe ontwikkelaars bijhouden en proberen die te verkorten.
Als het verbeteren van de developer experience het belangrijkst is, kun je streven naar hogere scores voor developertevredenheid in developerenquêtes.
Blijf volgen
Het kan enige tijd duren voordat je de impact van je interne ontwikkelaarsplatform ziet. Blijf de voortgang monitoren en gebruik check-ins en retrospectives met je teams om te bespreken of het interne ontwikkelaarsplatform na verloop van tijd de gewenste resultaten oplevert.
Retrospectives met het team geven ontwikkelaars en leidinggevenden de kans om stil te staan bij wat goed gaat en wat beter kan. In het spel voor retrospectives van het Atlassian-teamdraaiboek vind je basisinstructies en sjablonen voor retrospectives, en variaties voor specifieke situaties.