Skalere utviklingsteamet med eksterne ingeniører uten å miste kodekvalitet

Introduksjon

Viktige poeng

1. Bruk eksterne ingeniører når veikartet ditt er for fullt for kjerneteamet ditt.
2. Sett enkle kvalitetsgrenser og en grunnleggende leveringsprosess før de blir med.
3. Ta imot eksterne utviklere med en klar sjekkliste og en fast kontaktperson.
4. Bruk ett felles sett med regler, gjennomganger og måleparametere for alle ingeniører.
5. Bruk korte skriftlige oppdateringer for å holde et voksende blandet team samkjørt.

Hvorfor bør du utvide utviklingsteamet ditt med eksterne ingeniører?

Du bør utvide utviklingsteamet ditt med eksterne ingeniører når veikartet ditt er fullt og dine egne medarbeidere ikke klarer å holde tritt på en sunn måte. Hovedpoenget er enkelt: eksterne ingeniører skal tilføre hastighet og kompetanse uten å senke kvalitetsnivået. Hvis de hjelper deg med å levere jevnt arbeid som føles trygt å vedlikeholde, er oppsettet fornuftig. Hvis de bare tilfører stress og tilfeldige endringer, er tidspunktet feil.

Mange ledere i produktbedrifter føler det samme presset. Arbeidsmengden vokser, frister overskrides, og det tar lang tid å ansette dyktige ingeniører i byen din. I det øyeblikket begynner du å tenke på å utvide ingeniørteamet med hjelp fra utenforstående. Du kan se på et outsourcet utviklingsteam i en annen region eller en mindre gruppe nærmere din tidssone. Det virkelige spørsmålet er ikke om du kan hente inn ekstern hjelp, men når det vil støtte veikartet ditt i stedet for å skjule dypere problemer.

En grunn til å invitere eksterne ingeniører er tilgang til ferdigheter du ikke har internt akkurat nå. Du trenger kanskje kortsiktig støtte på områder som data, mobilapper eller nye skyoppsett. Du ønsker kanskje ikke å bygge et helt nytt team rundt hvert nye tema. I så fall kan utvidelse av programvareutviklingsteamet gi deg et fleksibelt lag med støtte rundt kjernegruppen din. Du beholder kjernekompetansen og retningen i selskapet ditt og bruker ekstern hjelp til klare og fokuserte arbeidsoppgaver. I hverdagen føles dette mer som å legge til en rolig ekspert til en travel gruppe enn å opprette et nytt selskap.

Det er også et veldig grunnleggende tids- og kostnadsaspekt. Å ansette dyktige medarbeidere på egen hånd kan ta mange uker eller til og med måneder, og i løpet av den tiden stopper ikke arbeidsmengden din. Her kan du se klare fordeler med å utvide IT-staben. Du kan hente inn ekstra hjelp for en definert periode og et definert omfang, mens du fortsetter å tenke på langsiktig ansettelse. For noen team jevner denne muligheten ut topper i etterspørselen, i stedet for å tvinge frem en stor økning i fast bemanning. Denne typen oppsett lar deg teste hva ekstra kapasitet gjør for produktet ditt før du endrer hele strukturen for godt.

Du kan også velge mellom ulike modeller for hvordan disse personene blir en del av din verden. I en bemanningsmodell tilfører du eksterne ingeniører til ditt eget team, og dine ledere veileder deres arbeid hver dag. I en nearshore-utviklingsgruppe sitter folk i en nær tidssone og kan delta i samtaler og chatter i normal arbeidstid. Mange selskaper samarbeider med en erfaren programvareutviklingspartner som allerede vet hvordan man driver nearshore-programvareutvikling og samarbeider med interne team. Jo nærmere kultur, tidssone og verktøy, jo lettere er det å få mange mennesker til å føle seg som ett team, selv om kontraktene er forskjellige. Denne felles basen er det som gjør at eksternt arbeid føles naturlig i stedet for ustabilt.

Hvordan forbereder du kodebasen og prosessene dine før du legger til et eksternt utviklingsteam?

Du forbereder deg på et eksternt utviklingsteam ved å legge et klart og enkelt grunnlag for hvordan du bygger og leverer produktet ditt. Du trenger felles regler, grunnleggende verktøy og en synlig måte å jobbe på før nye mennesker kommer. Uten dette grunnlaget avhenger hver endring av personlig stil og hukommelse, og nye mennesker har ingen måte å gjette seg til riktig vei. Med dette grunnlaget kan selv nye øyne bevege seg i et trygt og jevnt tempo.

Du kan tenke på denne basen som kvalitetsrekkverk for kode. Disse rekkverkene er enkle kontroller som hver endring må passere, uansett hvem som har skrevet den. De kan omfatte hvordan du navngir ting, hvordan du formaterer filer og hva «ferdig» betyr for ethvert lite stykke arbeid. Når rekkverkene er de samme for alle, føles produktet ditt stabilt selv når teamet vokser og endres. Dette gjør det lettere å stole på hele flyten, ikke bare på de menneskene du allerede kjenner.

Du trenger også en grunnleggende kontinuerlig integrasjons- og leveringspipeline. Denne lange setningen beskriver en enkel idé. Hver gang noen endrer koden, kjører systemet kontroller og hjelper med å flytte endringen mot brukerne i små, trygge trinn. Denne pipelinen kan ligge på vanlige plattformer og kan kjøres ved hver push til hovedkodelageret ditt. En fungerende pipeline gjør mange små endringer om til en ren fremgang i stedet for en haug med store, skremmende utgivelser. Nye medarbeidere kan lære denne veien én gang og deretter følge den uten ekstra gjetninger.

Tester er en viktig del av denne prosessen. Automatisert testing i CI/CD betyr at testene dine kjører av seg selv hver gang noen deler ny kode. Du kan starte med enkle kontroller som dekker de mest brukte prosessene i produktet ditt. Over tid kan du legge til flere tester etter hvert som du ser hvor feilene har en tendens til å oppstå. Selv et lite sett med stabile tester gir deg større sikkerhet enn en enorm liste med manuelle kontroller som ingen får kjørt i tide. Denne tilnærmingen holder ting realistisk og støtter både interne og eksterne ingeniører.

Det hjelper også å se på eldre deler av systemet ditt før du ber andre om å røre dem. Det er her grunnleggende teknisk gjeldsforvaltning kommer inn. Teknisk gjeld er en måte å beskrive kode som fungerer, men som er vanskelig å endre uten risiko. Du kan merke områder som er trygge for nye medarbeidere og områder som fortsatt trenger oppfølging fra de mest erfarne medarbeiderne. Når du vet hvor de risikofylte delene befinner seg, kan du veilede et eksternt utviklingsteam mot tryggere områder først. Dette beskytter produktet ditt og holder nye medarbeidere unna skjulte fallgruver.

Den siste delen av basen er enkel sikkerhet og tilgang. En sikker programvareutviklingssyklus høres tungt ut, men den hviler på klare trinn. Du gir folk bare den tilgangen de trenger, du holder ekte brukerdata trygge, og du behandler hemmelige nøkler med forsiktighet. Du skriver også ned hva du skal gjøre når noe går galt, selv i liten skala. Når sikkerhet er en del av det normale arbeidet, kan eksterne ingeniører bli med i prosessen din uten å skape ny frykt. Dine juridiske og sikkerhetsteam ser også at denne veksten følger en plan, ikke en hurtig løsning.

Hvordan ser en sikker onboarding-plan for eksterne utviklere ut?

En sikker onboarding-plan for eksterne utviklere gir dem kontekst, verktøy og klare første skritt uten å kaste dem ut på dypt vann. Det bør føles som en veiledet sti hvor hver dag har et enkelt og reelt formål. Når planen er klar, kan nye medarbeidere tilføre verdi i løpet av uker, ikke måneder, og ditt eget team føler seg ikke utmattet av stadige spørsmål.

Onboarding av eksterne utviklere starter med en felles forståelse av hva de trenger å lære først. Dette inkluderer produktet ditt, brukerne dine og din normale måte å jobbe på. En sjekkliste for onboarding av utviklere kan samle alle disse elementene på ett sted. Den kan være et enkelt dokument som begge parter kan åpne og justere. En synlig sjekkliste gjør at «Jeg tror vi allerede har fortalt dem dette» blir til «Vi vet nøyaktig hva som er gjort og hva som er neste steg». Denne lille endringen fjerner mye stille stress for alle.

Her er en enkel liste som ofte fungerer godt som grunnlag for en slik sjekkliste:

1. Tilgang til kode, arbeidssporing og hovedchatterom.
2. Fremgangsmåte for å kjøre produktet på en bærbar PC eller en testserver.
3. En kort guide til brukere, hovedflyt og viktige forretningsregler.
4. Navn på personer du kan spørre om produktet, koden og verktøyene.
5. To eller tre små, klare oppgaver som er klare for en første reell endring.

Det hjelper også å utpeke en klar kontaktperson. En teknisk leder eller senioringeniør kan fungere som en onboarding-buddy de første ukene. Denne personen kan gjennomgå alle tidlige endringer, svare på spørsmål og forklare hvorfor tidligere valg ser ut som de gjør. Korte daglige sjekker, selv om det bare er fem minutter i chat, kan holde ting på rett spor. En rolig mentor og faste kontaktpunkter bidrar mer til en trygg innføring enn en stor tale på den første dagen. Over tid kan du flytte flere oppdateringer til asynkron kommunikasjon for utviklingsteam, for eksempel korte skriftlige notater.

Etter det jeg har sett, er den største risikoen under onboarding stille forvirring. Nye medarbeidere er redde for å spørre for mye, og gamle teammedlemmer håper at ting vil «falle på plass» av seg selv. En klar plan for innkjøring av eksterne utviklere og en enkelt ansvarlig for denne planen endrer dette bildet. Når én person har ansvaret for prosessen, kan du se mønstre, fikse svake punkter og gjøre hver neste innkjøring jevnere. I løpet av noen måneder blir planen en repeterbar ressurs i stedet for en ny utfordring hver gang du ansetter noen nye.

Hvordan opprettholder du kodekvaliteten i et blandet utviklingsteam når du leder eksterne utviklere?

Du opprettholder kodekvaliteten i et blandet utviklingsteam ved å bruke de samme enkle reglene, kontrollene og tallene for alle. Standardene dine må gjelde for alle ingeniører hvis du vil at produktet skal føles som ett rent og sikkert system. Når du deler opp reglene etter kontraktstype, deler du også opp tilliten og klarheten i teamet ditt.

Et blandet utviklingsteam er en gruppe hvor interne og eksterne ingeniører jobber med det samme produktet. De kan sitte på forskjellige steder, men de deler én backlog og én kodelager. Denne blandingen kan være veldig sterk fordi den kombinerer dyp domenekunnskap med nye synspunkter. Den kan også være skjør hvis hver gruppe følger sine egne vaner. Uten klare retningslinjer blir denne blandingen til klynger av kode som føles forskjellige og er vanskelige å bevege seg mellom. Det er i det øyeblikket kvalitet og hastighet begynner å avvike.

Enkle beste praksis for kodegjennomgang hjelper her. Hver endring bør gjennomgås av minst én annen person, uansett hvem som har gjort den. Gjennomgangen bør se på klarhet, sikkerhet og samsvar med resten av systemet, ikke bare stil. Du kan støtte dette med enkle verktøy som skanner koden for vanlige problemer. Disse rutinene holder kvaliteten på eksterne utvikleres kode på linje med resten av teamet ditt på en rolig, repeterbar måte. Folk lærer av hverandre og bygger en felles forståelse av hva som er «bra».

Du kan også spore et lite sett med måleparametere for programvareutviklingsteamet. Disse kan vise hvor lang tid det tar å fullføre et stykke arbeid, hvor mange problemer som når brukerne og hvor ofte du leverer. Du trenger ikke dusinvis av tall. Du trenger bare noen få som du kan lese og diskutere med letthet. Når disse målingene forblir stabile eller forbedres mens du administrerer eksterne utviklere og utvider teamet, vet du at oppsettet ditt støtter kvalitet. Hvis de glir, har du et tidlig signal om å gjennomgå reglene, omfanget eller blandingen av oppgaver.

Kommunikasjonsmønstre er like viktige som regler og tall. Mange blandede utviklingsteam regnes også som distribuerte agile team fordi folk jobber fra flere steder eller tidssoner. De trenger asynkron kommunikasjon for utviklingsteam, slik at fremdriften ikke avhenger av lange samtaler. Korte skriftlige oppdateringer, klare oppgavebeskrivelser og enkle statusmerker hjelper mye. Gode skriftlige oppdateringer gjør det lettere for alle ingeniører å bli med, følge med og forbedre produktet over tid. Live-samtaler er fortsatt viktige, men de er ikke lenger det eneste stedet hvor beslutninger tas.

Måten du bringer inn folk utenfra på, påvirker også kvaliteten. Hvis du behandler dem som en separat strøm med uklare mål, vil de ikke føle fullt eierskap til produktet. Hvis du legger dem til eksisterende grupper under ett sett med regler, kan de opptre som alle andre teammedlemmer. Noen selskaper bruker en teamforsterkningsmodell for dette, hvor de blander interne og eksterne personer under én leder. Felles mål, felles verktøy og felles gjennomganger bidrar mer til kodekvaliteten i programvareutvikling enn noen tung kontrolldokumentasjon. Over tid kan du justere sammensetningen av personer og arbeid, men den felles rammen forblir den samme.