Skaler dit udviklingsteam med eksterne ingeniører uden at miste kodekvalitet

Introduktion

Vigtige pointer

1. Brug eksterne ingeniører, når din køreplan er for fyldt til dit kerneteam.
2. Fastlæg enkle kvalitetsstandarder og en grundlæggende leveringsproces, inden de tiltræder.
3. Onboard eksterne udviklere med en klar tjekliste og en fast kontaktperson.
4. Anvend ét fælles sæt regler, evalueringer og målinger for alle ingeniører.
5. Brug korte skriftlige opdateringer til at holde et voksende blandet team på rette spor.

Hvorfor skal du overhovedet udvide dit udviklerteam med eksterne ingeniører?

Du bør udvide dit udviklerteam med eksterne ingeniører, når din roadmap er fyldt, og dine egne medarbejdere ikke kan følge med på en sund måde. Hovedpointen er enkel: Eksterne ingeniører bør tilføre hastighed og kompetencer uden at sænke din kvalitetsstandard. Hvis de hjælper dig med at levere stabilt arbejde, der føles sikkert at vedligeholde, giver opsætningen mening. Hvis de kun tilføjer stress og tilfældige ændringer, er timingen forkert.

Mange ledere i produktvirksomheder føler det samme pres. Backloggen vokser, deadlines overskrides, og det tager lang tid at ansætte dygtige ingeniører i din by. I det øjeblik begynder du at overveje at udvide dit ingeniørteam med hjælp udefra. Du kan se på et outsourcet udviklingsteam i en anden region eller på en mindre gruppe tættere på din tidszone. Det egentlige spørgsmål er ikke, om du kan hente ekstern hjælp, men hvornår det vil understøtte din roadmap i stedet for at skjule dybere problemer.

En af grundene til at invitere eksterne ingeniører er adgang til kompetencer, som du ikke har internt i øjeblikket. Du har måske brug for kortvarig support inden for områder som data, mobile apps eller nye cloud-opsætninger. Du ønsker måske ikke at opbygge et helt nyt team omkring hvert nyt emne. I så fald kan udvidelse af softwareudviklingsteamet give dig et fleksibelt lag af support omkring din kerneafdeling. Du beholder kerneviden og retning inden for din virksomhed og bruger ekstern hjælp til klare og fokuserede arbejdsopgaver. I dagligdagen føles det mere som at tilføje en rolig ekspert til et travlt team end at oprette en anden virksomhed.

Der er også en meget grundlæggende tids- og omkostningsvinkel. Det kan tage mange uger eller endda måneder at ansætte dygtige medarbejdere på egen hånd, og i den periode stopper din arbejdsbyrde ikke. Her kan du se klare fordele ved at udvide IT-personalet. Du kan hente ekstra hænder ind i en bestemt periode og til et bestemt omfang, mens du fortsætter med at overveje langvarige ansættelser. For nogle teams udjævner denne mulighed spidsbelastninger i efterspørgslen i stedet for at tvinge en stor stigning i det faste antal medarbejdere. Denne type opsætning giver dig mulighed for at teste, hvad ekstra kapacitet gør for dit produkt, før du ændrer hele din struktur for altid.

Du kan også vælge forskellige modeller for, hvordan disse medarbejdere bliver en del af din verden. I en personaleudvidelsesmodel tilføjer du eksterne ingeniører til dit eget team, og dine ledere vejleder dem i deres arbejde hver dag. I en nearshore-udviklingsteamopsætning sidder folk i en nærliggende tidszone og kan deltage i dine opkald og chats i normale arbejdstimer. Mange virksomheder arbejder med en erfaren softwareudviklingspartner, der allerede ved, hvordan man udfører nearshore-softwareudvikling og integrerer sig med interne teams. Jo tættere kultur, tidszone og værktøjer er, jo lettere er det at få mange mennesker til at føle sig som ét team, selvom kontrakterne er forskellige. Denne fælles base er det, der får eksternt arbejde til at føles naturligt i stedet for skrøbeligt.

Hvordan forbereder du din kodebase og dine processer, før du tilføjer et eksternt udviklingsteam?

Du forbereder dig på et eksternt udviklingsteam ved at fastlægge en klar og enkel base for, hvordan du bygger og leverer dit produkt. Du har brug for fælles regler, grundlæggende værktøjer og en synlig måde at arbejde på, inden nye medarbejdere ankommer. Uden denne base afhænger alle ændringer af personlig stil og hukommelse, og nye medarbejdere har ingen mulighed for at gætte sig til den rigtige vej. Med denne base kan selv nye medarbejdere arbejde i et sikkert og stabilt tempo.

Du kan tænke på denne base som kvalitetsværn for kode. Disse værn er enkle kontroller, som alle ændringer skal gennemgå, uanset hvem der har skrevet dem. De kan dække, hvordan du navngiver ting, hvordan du formaterer filer, og hvad "færdig" betyder for ethvert lille stykke arbejde. Når værnene er de samme for alle, føles dit produkt stabilt, selv når teamet vokser og ændrer sig. Dette gør det lettere at stole på hele forløbet, ikke kun de mennesker, du allerede kender.

Du har også brug for en grundlæggende pipeline til kontinuerlig integration og levering. Denne lange sætning beskriver en enkel idé. Hver gang nogen ændrer koden, kører systemet kontroller og hjælper med at flytte den ændring mod brugerne i små, sikre trin. Denne pipeline kan findes på almindelige platforme og kan køre ved hver push til din hovedkodelager. En fungerende pipeline forvandler mange små redigeringer til en ren fremskridtslinje i stedet for en bunke store, skræmmende udgivelser. Nye medarbejdere kan lære denne vej én gang og derefter følge den uden ekstra gætterier.

Tests er en vigtig del af denne vej. Automatiseret testning i CI/CD betyder, at dine tests kører af sig selv, hver gang nogen deler ny kode. Du kan starte med enkle kontroller, der dækker de mest anvendte veje i dit produkt. Over tid kan du tilføje flere tests, efterhånden som du ser, hvor fejl har tendens til at opstå. Selv et lille sæt stabile tests giver dig større sikkerhed end en lang liste med manuelle kontroller, som ingen kører i tide. Denne tilgang holder tingene realistiske og understøtter både interne og eksterne ingeniører.

Det hjælper også at se på ældre dele af dit system, før du beder andre om at røre ved dem. Det er her, grundlæggende teknisk gældsstyring kommer ind i billedet. Teknisk gæld er en måde at beskrive kode, der fungerer, men som er svær at ændre uden risiko. Du kan markere områder, der er sikre for nye medarbejdere, og områder, der stadig kræver opmærksomhed fra dine mest erfarne medarbejdere. Når du ved, hvor de risikable dele befinder sig, kan du først guide et eksternt udviklingsteam mod de sikrere områder. Dette beskytter dit produkt og holder nye medarbejdere væk fra skjulte faldgruber.

Den sidste del af basen er simpel sikkerhed og adgang. En sikker softwareudviklingscyklus lyder tungt, men den bygger på klare trin. Du giver folk kun den adgang, de har brug for, du beskytter reelle brugerdata, og du behandler hemmelige nøgler med omhu. Du skriver også ned, hvad der skal gøres, når noget går galt, selv i lille skala. Når sikkerhed er en del af det normale arbejde, kan eksterne ingeniører deltage i din proces uden at skabe ny frygt. Dine juridiske og sikkerhedsteams ser også, at denne vækst følger en plan og ikke er en hurtig løsning.

Hvordan ser en sikker onboarding-plan for eksterne udviklere ud?

En sikker onboarding-plan for eksterne udviklere giver dem kontekst, værktøjer og klare første skridt uden at kaste dem ud på dybt vand. Det skal føles som en guidet vej, hvor hver dag har et enkelt og reelt formål. Når planen er klar, kan nye medarbejdere tilføre værdi på få uger, ikke måneder, og dit eget team føler sig ikke udmattet af konstante spørgsmål.

Onboarding af eksterne udviklere starter med en fælles opfattelse af, hvad de først skal lære. Dette omfatter dit produkt, dine brugere og din normale måde at arbejde på. En onboarding-tjekliste for udviklere kan samle alle disse punkter ét sted. Den kan findes i et simpelt dokument, som begge parter kan åbne og justere. En synlig tjekliste forvandler "Jeg tror, vi allerede har fortalt dem det" til "Vi ved præcis, hvad der er gjort, og hvad der skal ske nu." Denne lille ændring fjerner en masse stille stress for alle.

Her er en enkel liste, der ofte fungerer godt som grundlag for en sådan tjekliste:

1. Adgang til kode, arbejdssporing og vigtigste chatrum.
2. Trin til at køre produktet på en bærbar computer eller en testserver.
3. En kort guide til brugere, hovedflows og vigtige forretningsregler.
4. Navne på personer, du kan spørge om produktet, koden og værktøjerne.
5. To eller tre små, klare opgaver, der er klar til en første reel ændring.

Det hjælper også at udpege en klar kontaktperson. En teknisk leder eller senioringeniør kan fungere som onboarding-buddy i de første uger. Denne person kan gennemgå alle tidlige ændringer, besvare spørgsmål og forklare, hvorfor tidligere valg ser ud, som de gør. Korte daglige check-ins, selv fem minutter i chat, kan holde tingene på sporet. En rolig buddy og faste kontaktpunkter gør mere for en sikker onboarding end en stor tale på den første dag. Over tid kan du flytte flere opdateringer til asynkron kommunikation for udviklingshold, f.eks. korte skriftlige noter.

Ud fra min erfaring er den største risiko under onboarding stille forvirring. Nye medarbejdere frygter at stille for mange spørgsmål, og gamle teammedlemmer håber, at tingene vil "falde på plads" af sig selv. En klar plan for onboarding af eksterne udviklere og en enkelt ansvarlig for denne plan ændrer dette billede. Når én person har ansvaret for forløbet, kan man se mønstre, rette svage punkter og gøre hver næste onboarding-runde mere smidig. På få måneder bliver planen et gentageligt aktiv i stedet for en ny udfordring, hver gang man tilføjer en ny medarbejder.

Hvordan opretholder du kodekvaliteten i et blandet udviklingsteam, når du administrerer eksterne udviklere?

Du opretholder kodekvaliteten i et blandet udviklingsteam ved at bruge de samme enkle regler, kontroller og tal for alle. Dine standarder skal gælde for alle ingeniører, hvis du ønsker, at produktet skal føles som et rent og sikkert system. Når du opdeler reglerne efter kontrakttype, opdeler du også tilliden og klarheden i dit team.

Et blandet udviklerteam er en gruppe, hvor interne og eksterne ingeniører arbejder på det samme produkt. De sidder måske forskellige steder, men de deler én backlog og én kodelager. Denne blanding kan være meget stærk, fordi den kombinerer dyb domænekendskab med nye synspunkter. Den kan også være skrøbelig, hvis hver gruppe følger sine egne vaner. Uden klar vejledning bliver denne blanding til klynger af kode, der føles forskellige og er svære at bevæge sig mellem. Det er det øjeblik, hvor kvalitet og hastighed begynder at glide fra hinanden.

Her kan enkle best practices for kodegennemgang hjælpe. Hver ændring skal gennemgås af mindst én anden person, uanset hvem der har foretaget den. Gennemgangen skal se på klarhed, sikkerhed og overensstemmelse med resten af systemet, ikke kun på stil. Du kan understøtte dette med lette værktøjer, der scanner koden for almindelige problemer. Disse rutiner holder eksterne udvikleres kodekvalitet på linje med resten af dit team på en rolig, gentagelig måde. Folk lærer af hinanden og opbygger en fælles forståelse af, hvad der er "godt".

Du kan også spore et lille sæt målinger for softwareudviklingsholdet. Disse kan vise, hvor lang tid det tager at færdiggøre et stykke arbejde, hvor mange problemer der når brugerne, og hvor ofte du leverer. Du har ikke brug for snesevis af tal. Du har kun brug for et par stykker, som du nemt kan læse og diskutere. Når disse målinger forbliver stabile eller forbedres, mens du styrer eksterne udviklere og udvider teamet, ved du, at din opsætning understøtter kvalitet. Hvis de falder, har du et tidligt signal om at gennemgå dine regler, omfang eller blanding af opgaver.

Kommunikationsmønstre er lige så vigtige som regler og tal. Mange blandede udviklingshold tæller også som distribuerede agile hold, fordi folk arbejder fra flere steder eller tidszoner. De har brug for asynkron kommunikation for udviklingshold, så fremskridt ikke afhænger af lange opkald. Korte skriftlige opdateringer, klare opgavenoter og enkle tags for status hjælper meget. Gode skriftlige opdateringer gør det lettere for alle ingeniører at deltage, følge med og forbedre produktet over tid. Live-samtaler er stadig vigtige, men de er ikke længere det eneste sted, hvor beslutninger træffes.

Den måde, du bringer eksterne personer ind på, har også betydning for kvaliteten. Hvis du behandler dem som en separat strøm med uklare mål, vil de ikke føle fuldt ejerskab over produktet. Hvis du tilføjer dem til eksisterende teams under ét sæt regler, kan de fungere som ethvert andet teammedlem. Nogle virksomheder bruger en teamforstærkningsopsætning til dette, hvor de blander interne og eksterne personer under én leder. Fælles mål, fælles værktøjer og fælles gennemgange gør mere for kodekvaliteten i softwareudviklingen end noget tungt kontrol-dokument. Over tid kan du justere sammensætningen af personer og arbejde, men den fælles ramme forbliver den samme.