Skala upp ditt utvecklingsteam med externa ingenjörer utan att förlora kodkvalitet

Introduktion

Viktiga punkter

1. Använd externa ingenjörer när din roadmap är för full för ditt kärnteam.
2. Sätt upp enkla kvalitetsgränser och en grundläggande leveranspipeline innan de ansluter sig.
3. Välkomna externa utvecklare med en tydlig checklista och en kontaktperson.
4. Använd en gemensam uppsättning regler, granskningar och mätvärden för alla ingenjörer.
5. Förlita dig på korta skriftliga uppdateringar för att hålla ett växande blandat team samordnat.

Varför ska du överhuvudtaget skala upp ditt utvecklingsteam med externa ingenjörer?

Du bör utöka ditt utvecklingsteam med externa ingenjörer när din roadmap är full och dina egna medarbetare inte kan hålla jämna steg på ett hälsosamt sätt. Huvudpoängen är enkel: externa ingenjörer bör tillföra snabbhet och kompetens utan att sänka din kvalitetsnivå. Om de hjälper dig att leverera stabilt arbete som känns säkert att underhålla, är upplägget vettigt. Om de bara tillför stress och slumpmässiga förändringar, är tajmingen fel.

Många ledare i produktföretag känner samma press. Backloggen växer, deadlines förskjuts och det tar lång tid att anställa duktiga ingenjörer i din stad. I det ögonblicket börjar du fundera på att utöka ingenjörsteamet med hjälp från utsidan. Du kanske tittar på ett outsourcat utvecklingsteam i en annan region eller på en mindre grupp närmare din tidszon. Den verkliga frågan är inte om du kan ta in extern hjälp, utan när det kommer att stödja din roadmap istället för att dölja djupare problem.

En anledning att ta in externa ingenjörer är att få tillgång till kompetens som du inte har internt just nu. Du kanske behöver kortvarigt stöd inom områden som data, mobilappar eller nya molnkonfigurationer. Du kanske inte vill bygga upp ett helt nytt team för varje nytt ämne. I så fall kan förstärkning av mjukvaruutvecklingsteamet ge dig ett flexibelt stödlager runt din kärngrupp. Du behåller kärnkunskapen och riktningen inom ditt företag och använder extern hjälp för tydliga och fokuserade arbetsuppgifter. I vardagen känns det mer som att lägga till en lugn expert till en upptagen grupp än att skapa ett andra företag.

Det finns också en mycket grundläggande tids- och kostnadsaspekt. Att anställa duktiga medarbetare på egen hand kan ta många veckor eller till och med månader, och under den tiden fortsätter ditt arbetsunderlag att växa. Här kan du se tydliga fördelar med personalförstärkning. Du kan ta in extra hjälp under en definierad tid och inom ett definierat område, samtidigt som du fortsätter att fundera på långsiktig rekrytering. För vissa team jämnar detta alternativ ut toppar i efterfrågan istället för att tvinga fram en stor ökning av den fasta personalstyrkan. Denna typ av upplägg låter dig testa vad extra kapacitet gör för din produkt innan du ändrar hela din struktur för gott.

Du kan också välja olika modeller för hur dessa personer ansluter sig till din värld. I en personalförstärkningsmodell lägger du till externa ingenjörer i ditt eget team och dina ledare guidar deras arbete varje dag. I en nearshore-utvecklingsteamkonfiguration sitter personerna i en närliggande tidszon och kan delta i dina samtal och chattar under normala arbetstider. Många företag arbetar med en erfaren mjukvaruutvecklingspartner som redan vet hur man gör nearshore-mjukvaruutveckling och smälter in med interna team. Ju närmare kulturen, tidszonen och verktygen är, desto lättare är det att få många människor att känna sig som ett team, även om kontrakten skiljer sig åt. Denna gemensamma bas är det som gör att externt arbete känns naturligt istället för bräckligt.

Hur förbereder du din kodbas och dina processer innan du lägger till ett externt utvecklingsteam?

Du förbereder dig för ett externt utvecklingsteam genom att skapa en tydlig och enkel bas för hur du bygger och levererar din produkt. Du behöver gemensamma regler, grundläggande verktyg och ett synligt arbetssätt innan nya personer anländer. Utan denna bas beror varje förändring på personlig stil och minne, och nya personer har ingen möjlighet att gissa sig till rätt väg. Med denna bas kan även nya ögon röra sig i en säker och stadig rytm.

Du kan tänka på denna bas som kvalitetsräcken för kod. Dessa räcken är enkla kontroller som varje förändring måste klara, oavsett vem som har skrivit den. De kan omfatta hur du namnger saker, hur du formaterar filer och vad "klart" betyder för varje liten arbetsuppgift. När räcken är desamma för alla känns din produkt stabil även när teamet växer och förändras. Detta gör det lättare att lita på hela flödet, inte bara på de personer du redan känner.

Du behöver också en grundläggande pipeline för kontinuerlig integration och leverans. Denna långa fras beskriver en enkel idé. Varje gång någon ändrar koden kör systemet kontroller och hjälper till att flytta den ändringen till användarna i små, säkra steg. Denna pipeline kan finnas på vanliga plattformar och kan köras vid varje push till din huvudsakliga kodförvaring. En fungerande pipeline förvandlar många små redigeringar till en ren linje av framsteg istället för en hög med stora, skrämmande releaser. Nya personer kan lära sig denna väg en gång och sedan följa den utan extra gissningar.

Tester är en viktig del av denna väg. Automatiserad testning i CI/CD innebär att dina tester körs automatiskt varje gång någon delar ny kod. Du kan börja med enkla kontroller som täcker de mest använda vägarna i din produkt. Med tiden kan du lägga till fler tester när du ser var buggar tenderar att uppstå. Även en liten uppsättning stabila tester ger dig större säkerhet än en enorm lista med manuella kontroller som ingen hinner köra i tid. Detta tillvägagångssätt håller saker och ting realistiska och stöder både interna och externa ingenjörer.

Det hjälper också att titta på äldre delar av ditt system innan du ber andra att röra dem. Det är här grundläggande teknisk skuldhantering kommer in. Teknisk skuld är ett sätt att beskriva kod som fungerar men som är svår att ändra utan risk. Du kan markera områden som är säkra för nya medarbetare och områden som fortfarande behöver skötas av dina mest erfarna medarbetare. När du vet var de riskfyllda delarna finns kan du först guida ett externt utvecklingsteam mot säkrare områden. Detta skyddar din produkt och håller nya medarbetare borta från dolda fallgropar.

Den sista delen av basen är enkel säkerhet och åtkomst. En säker livscykel för mjukvaruutveckling låter tungt, men bygger på tydliga steg. Du ger människor endast den åtkomst de behöver, du håller verkliga användardata säkra och du hanterar hemliga nycklar med försiktighet. Du skriver också ner vad du ska göra när något går fel, även i liten skala. När säkerhet är en del av det normala arbetet kan externa ingenjörer ansluta sig till din process utan att väcka ny rädsla. Dina juridiska och säkerhetsteam ser också att denna tillväxt följer en plan, inte en snabb lösning.

Hur ser en säker introduktionsplan för externa utvecklare ut?

En säker introduktionsplan för externa utvecklare ger dem sammanhang, verktyg och tydliga första steg utan att kasta dem rakt in i det djupa vattnet. Det ska kännas som en guidad väg där varje dag har ett enkelt och verkligt syfte. När planen är tydlig kan nya medarbetare tillföra värde inom några veckor, inte månader, och ditt eget team känner sig inte utmattat av ständiga frågor.

Onboarding av externa utvecklare börjar med en gemensam syn på vad de behöver lära sig först. Detta inkluderar din produkt, dina användare och ditt normala sätt att arbeta. En checklista för introduktion av utvecklare kan samla alla dessa punkter på ett ställe. Den kan finnas i ett enkelt dokument som båda sidor kan öppna och justera. En synlig checklista förvandlar "Jag tror att vi redan har sagt det här" till "vi vet exakt vad som är gjort och vad som är nästa steg". Denna lilla förändring tar bort mycket tyst stress för alla.

Här är en enkel lista som ofta fungerar bra som underlag för en sådan checklista:

1. Tillgång till kod, arbetsuppföljare och huvudchattrum.
2. Steg för att köra produkten på en bärbar dator eller en testserver.
3. En kort guide till användare, huvudflöden och viktiga affärsregler.
4. Namn på personer att fråga om produkten, koden och verktygen.
5. Två eller tre små, tydliga uppgifter som är redo för en första verklig förändring.

Det hjälper också att utse en tydlig kontaktperson. En teknisk chef eller senioringenjör kan fungera som onboarding-kompis under de första veckorna. Denna person kan granska alla tidiga förändringar, svara på frågor och förklara varför tidigare val ser ut som de gör. Korta dagliga avstämningar, även om det bara är fem minuter i chatten, kan hålla saker och ting på rätt spår. En lugn mentor och regelbundna kontaktpunkter gör mer för en säker introduktion än ett stort samtal den första dagen. Med tiden kan du flytta fler uppdateringar till asynkron kommunikation för utvecklingsteam, till exempel korta skriftliga anteckningar.

Enligt min erfarenhet är den största risken under introduktionen en tyst förvirring. Nya medarbetare är rädda för att ställa för många frågor, och gamla teammedlemmar hoppas att saker och ting ska "klicka" av sig själva. En tydlig plan för introduktionen av externa utvecklare och en enda ansvarig för den planen förändrar denna bild. När en person ansvarar för processen kan du upptäcka mönster, åtgärda svaga punkter och göra varje ny introduktionsomgång smidigare. Efter några månader blir planen en återanvändbar tillgång istället för en ny utmaning varje gång du anställer någon ny.

Hur upprätthåller du kodkvaliteten i ett blandat utvecklingsteam när du hanterar externa utvecklare?

Du upprätthåller kodkvaliteten i ett blandat utvecklingsteam genom att använda samma enkla regler, kontroller och siffror för alla. Dina standarder måste gälla för alla ingenjörer om du vill att produkten ska kännas som ett rent och säkert system. När du delar upp reglerna efter kontraktstyp delar du också upp förtroendet och tydligheten i ditt team.

Ett blandat utvecklingsteam är en grupp där interna och externa ingenjörer arbetar med samma produkt. De kan sitta på olika platser, men de delar en backlog och ett kodlager. Denna blandning kan vara mycket stark eftersom den kombinerar djup domänkunskap med nya perspektiv. Den kan också vara ömtålig om varje grupp följer sina egna vanor. Utan tydlig vägledning förvandlas denna blandning till kluster av kod som känns olika och är svåra att flytta mellan. Det är då kvalitet och hastighet börjar glida isär.

Här hjälper enkla bästa praxis för kodgranskning. Varje ändring bör granskas av minst en annan person, oavsett vem som har gjort den. Granskningarna bör fokusera på tydlighet, säkerhet och hur ändringen passar in i resten av systemet, inte bara på stil. Du kan stödja detta med enkla verktyg som skannar koden efter vanliga problem. Dessa rutiner håller externa utvecklares kodkvalitet i linje med resten av ditt team på ett lugnt och repeterbart sätt. Människor lär av varandra och bygger upp en gemensam uppfattning om vad som är ”bra”.

Du kan också spåra en liten uppsättning mätvärden för mjukvaruutvecklingsteamet. Dessa kan visa hur lång tid det tar att slutföra ett arbete, hur många problem som når användarna och hur ofta du levererar. Du behöver inte dussintals siffror. Du behöver bara några få som du kan läsa och diskutera med lätthet. När dessa mätvärden förblir stabila eller förbättras medan du hanterar externa utvecklare och utökar teamet, vet du att din uppsättning stödjer kvalitet. Om de försämras har du en tidig signal om att se över dina regler, omfattning eller mix av uppgifter.

Kommunikationsmönster är lika viktiga som regler och siffror. Många blandade utvecklingsteam räknas också som distribuerade agila team eftersom människor arbetar från flera platser eller tidszoner. De behöver asynkron kommunikation för utvecklingsteam så att framstegen inte är beroende av långa samtal. Korta skriftliga uppdateringar, tydliga uppgiftsanteckningar och enkla taggar för status hjälper mycket. Bra skriftliga uppdateringar gör det lättare för alla ingenjörer att delta, följa och förbättra produkten över tid. Live-samtal är fortfarande viktiga, men de är inte längre den enda platsen där beslut fattas.

Hur du tar in externa personer påverkar också kvaliteten. Om du behandlar dem som en separat ström med oklara mål kommer de inte att känna fullt ägarskap för produkten. Om du lägger till dem i befintliga grupper under en uppsättning regler kan de agera som alla andra teammedlemmar. Vissa företag använder en teamförstärkningsmodell för detta, där de blandar interna och externa personer under en ledare. Gemensamma mål, gemensamma verktyg och gemensamma granskningar bidrar mer till kodkvaliteten i mjukvaruutvecklingen än något tungt kontrolldokument. Med tiden kan du justera blandningen av personer och arbete, men den gemensamma ramen förblir densamma.