Opret en afdeling af juniorer for at hjælpe hovedholdene ved kun at bruge Slack, Jira og blue tape

Opret en afdeling af juniorer for at hjælpe hovedholdene ved kun at bruge Slack, Jira og blue tape

Næsten hele Skyengs udviklingsteam, som består af mere end 100 personer, arbejder eksternt, og kravene til specialister har altid været høje: Vi ledte efter seniorer, fullstack-udviklere og mellemstore. Men i begyndelsen af ​​2019 ansatte vi tre juniorer for første gang. Dette blev gjort af flere grunde: Ansættelse af kun superspecialister løser ikke alle problemer, og for at skabe en sund atmosfære i udviklingen er der brug for folk med forskellige niveauer af professionalisme.

Når du arbejder eksternt, er det ekstremt vigtigt, at en person kommer til projektet og straks begynder at bringe fordele uden nogen lange lærings- og opbygningsprocesser. Sådan fungerer det ikke med juniorer, plus at der udover træning også kræves en kompetent integration af en nybegynder på holdet, fordi alt er nyt for ham. Og det er en særskilt opgave for teamlederen. Derfor havde vi fokus på at finde og ansætte mere erfarne og etablerede udviklere. Men med tiden viste det sig, at teams, der kun består af seniorer og fullstack-udviklere, har deres egne problemer. Hvem skal for eksempel beskæftige sig med rutinemæssige, men obligatoriske opgaver, der ikke kræver superkvalifikation og noget særlig viden?

Før rodede vi i stedet for at ansætte juniorer med freelancere

Mens der var få opgaver, bet vores seniorer på en eller anden måde tænderne sammen og påtog sig disse uinteressante opgaver for sig selv, fordi udviklingen skulle gå fremad. Men dette kunne ikke fortsætte længe: projekterne voksede, antallet af rutinemæssige simple opgaver steg. Situationen begyndte mere og mere at ligne en joke, når søm bliver slået med et mikroskop i stedet for en hammer. For klarhedens skyld kan du vende dig til aritmetik: Hvis du tiltrækker en person, hvis takst er betinget $50/time til arbejde, som en medarbejder med en rate på $10/time kan klare, så har du problemer.

Det vigtigste, vi har lært af denne situation, er, at det nuværende paradigme med kun at ansætte seje specialister ikke løser vores problemer med rutineopgaver. Vi har brug for nogen, der vil være klar til at udføre det arbejde, som erfarne seniorer opfatter som en straf, og at overlade det til dem, er banalt ineffektivt. For eksempel at skrive bots til vores undervisere og kursusskriveres Slack-chat, eller lave små interne forbedringsprojekter, som udviklere konstant ikke har tid nok til, men som ville gøre livet meget mere behageligt.

På dette tidspunkt blev der udarbejdet en mellemløsning. Vi begyndte at involvere freelancere i vores projekter. Det var for sådan outsourcing, at simple og ikke-hastende opgaver begyndte at gå: at rette noget et sted, at tjekke et sted, at omskrive noget. Vores freelance-fløj voksede ret aktivt. En af vores projektledere samlede opgaver fra forskellige projekter og fordelte blandt freelancere, styret af den eksisterende database med kunstnere. Så forekom det os at være en god beslutning: Vi fjernede byrden fra seniorerne, og de kunne igen skabe deres fulde potentiale i stedet for at pille ved noget elementært. Selvfølgelig var der opgaver, som på grund af forretningshemmeligheder ikke kunne overføres til eksterne udøvere, men der var mange gange færre af den slags i forhold til den masse af opgaver, der gik til freelance.

Men det kunne ikke fortsætte for evigt. Virksomheden stod over for, at freelancedivisionen er blevet et klodset monster. Antallet af rutinemæssige simple opgaver voksede i takt med projekterne, og på et tidspunkt var der for mange af dem til effektivt at kunne fordele dem blandt eksterne udøvere. Derudover er en freelancer ikke fordybet i detaljerne i projekter, hvilket er konstant spild af tid på onboarding. Når du har mere end 100 professionelle udviklere i dit team, kan du naturligvis ikke ansætte selv halvtreds freelancere til at hjælpe dem og effektivt administrere deres aktiviteter. Derudover er interaktion med freelancere altid en vis risiko for manglende deadlines og andre organisatoriske problemer.

Det er vigtigt at bemærke her, at en fjernmedarbejder og en freelancer er to forskellige enheder. En fjernmedarbejder er fuldt registreret i virksomheden, har udpeget arbejdstid, et team, overordnede og så videre. En freelancer er et projektarbejde, der hovedsageligt er reguleret af deadlines. En freelancer er i modsætning til en ekstern medarbejder for det meste overladt til sig selv og interagerer dårligt med teamet. Derfor de potentielle risici ved at interagere med sådanne kunstnere.

Hvordan vi kom til at skabe en "afdeling for simple opgaver", og hvad vi fik

Efter at have analyseret den nuværende situation kom vi frem til, at vi har brug for medarbejdere med lavere kvalifikationer. Vi byggede ingen illusioner om, at vi ville vokse op til at blive fremtidige superstjerner fra alle juniorerne, eller at det ville koste os tre kopek at ansætte et dusin juniorer. Generelt, ifølge situationen med juniorer, er virkeligheden som følger:

  1. Det er økonomisk urentabelt at ansætte dem for en kort afstand. I stedet for fem til ti jun "lige nu" er det bedre at tage én underskriver og betale ham millioner af penge for kvalitetsarbejde end at bruge budgetter på nytilkomne.
  2. Juniorer har lang adgang til projektet og uddannelsen.
  3. I det øjeblik, hvor June har lært noget og ser ud til at skulle begynde at "arbejde af" investeringer i sig selv i de første seks måneders arbejde, skal han forfremmes til midten, eller han går til denne stilling i en anden virksomhed. Så ansættelse af juniorer er kun egnet til modne organisationer, der er villige til at investere i dem uden garantier for profit på kort sigt.

Men vi er vokset til det punkt, hvor der ikke er nogen vej uden juniorer på holdet: Antallet af almindelige opgaver vokser, og det er simpelthen en forbrydelse at bruge mandetimer af hærdede fagfolk på dem. Derfor har vi skabt en afdeling specielt til juniorudviklere.

Arbejdsperioden i afdelingen for simple opgaver er begrænset til tre måneder - det vil sige, at dette er en standard prøveperiode. Efter tre måneders fuldtidslønnet arbejde bliver en rookie enten sendt til et hold, der ønsker at se ham i deres rækker som juniorudvikler, eller også skilles vi af med ham.

Afdelingen, vi har oprettet, ledes af en erfaren PM, som er ansvarlig for fordelingen af ​​arbejdsopgaver blandt juniorer og deres samspil med andre teams. June modtager en opgave, udfører den, får feedback fra både teamet og sin leder. På arbejdsstadiet i afdelingen for simple opgaver tildeler vi ikke begyndere til specifikke teams og projekter - de har adgang til hele puljen af ​​opgaver i henhold til deres færdigheder (nu ansætter vi AngularJS front-enders, PHP-backers eller ledere for kandidater til stillingen som webudvikler med begge sprog) og kan arbejde på flere projekter på én gang.

Men alt er ikke begrænset til at ansætte juniorer - de skal skabe acceptable arbejdsforhold, og det er en opgave med en helt anden plan.

Det første, vi besluttede os for, var frivillig mentorordning i rimelige mængder. Det vil sige, at udover at vi ikke tvang nogen af ​​de eksisterende specialister til at vejlede, så blev det klart indikeret, at uddannelsen af ​​en begynder ikke skulle erstatte hovedjobbet. Nej "50% af tiden arbejder vi, 50% underviser vi junior." For at få en klar idé om, hvor lang tid mentoring vil tage, blev der udarbejdet et lille "pensum": en liste over opgaver, som hver mentor skulle udføre sammen med deres mentee. Det samme blev gjort for juniorernes projektleder, og som et resultat fik vi et meget gnidningsløst og forståeligt scenarie til at forberede nytilkomne og deres indtræden i arbejdet.

Vi har sørget for følgende punkter: test af teoretisk viden, udarbejdet et sæt materialer, hvis en junior skal færdig med at lære noget, godkendt et enkelt princip for udførelse af kodegennemgange for mentorer. På hvert trin giver ledere feedback til den nytilkomne, hvilket er ekstremt vigtigt for sidstnævnte. En ung medarbejder forstår, i hvilke aspekter han er stærk, og i hvilke han skal være mere forsigtig. For at forenkle læringsprocessen for juniorer og erfarne udviklere er der lavet en fælles chat i Slack, så andre medlemmer af teamet kan deltage i læringsprocessen og besvare et spørgsmål i stedet for en mentor. Alt dette gør arbejdet med juniorer til en fuldstændig forudsigelig og vigtigst af alt kontrollerbar proces.

Ved afslutningen af ​​den tre måneder lange forsøgsperiode gennemfører mentoren en afsluttende teknisk samtale med junior, på baggrund af resultaterne af hvilken det afgøres, om junior kan flytte til et fast job i et af holdene eller ej.

I alt

Ved første øjekast ligner vores juniorafdeling en kuvøse eller en slags specialskabt sandkasse. Men faktisk er dette en rigtig afdeling med alle egenskaberne for et fuldgyldigt kamphold, der løser rigtige, ikke træningsopgaver.

Men det vigtigste er, at vi giver folk en konkret horisont. Easy Tasks-afdelingen er ikke et endeløst limbo, som du kan sidde fast i for evigt. Der er en klar deadline på tre måneder, hvor junior løser simple opgaver på projekter, men samtidig kan han bevise sig selv og flytte til et eller andet hold. De nyansatte, vi ansætter, ved, at de får deres egen projektleder, en mentor fra seniorer (eller måske flere) og mulighed for fuldt ud at blive integreret i teamet, hvor de bliver glade og venter på ham.

Siden starten af ​​året er der ansat 12 juniorer i simple opgaver afdelingen, kun to har ikke bestået prøvetiden. En anden fyr slog ikke rod i holdet, men da han er meget arbejdsmæssigt dygtig, blev han vendt tilbage til afdelingen for simple opgaver for en ny periode, hvor vi håber, han finder et nyt hold. Arbejdet med juniorer havde også en positiv effekt på vores erfarne udviklere. Nogle af dem, efter en periode med mentorordninger, opdagede i sig selv styrken og lysten til at prøve rollen som holdledere, nogen, der kiggede på juniorerne, forbedrede deres egen viden og flyttede fra stillingen som mellem til stillingen som senior.

Vi vil kun udvide vores praksis med at ansætte unge udviklere, fordi det bringer mange fordele til teamet. Junes får fuldgyldig fjernbeskæftigelse, uanset deres bopælsregion: Medlemmer af vores udviklingsteam bor fra Riga til Vladivostok og klarer tidsforskelle godt takket være strømlinede processer i virksomheden. Alt dette åbner vejen for talentfulde mennesker, der bor i fjerntliggende byer og landsbyer. Og vi taler ikke kun om gårsdagens skolebørn og elever, men også om mennesker, der af en eller anden grund besluttede at skifte erhverv. Vores junior med samme succes kan blive både 18 og 35 år, for en junior handler om erfaring og færdigheder, men ikke om alder.

Vi er overbeviste om, at vores tilgang nemt kan udvides til andre virksomheder, der bruger fjernudviklingsmodellen. Samtidig giver det dig mulighed for selektivt at ansætte talentfulde juniorer fra hvor som helst i Rusland eller CIS, og samtidig opgradere mentorfærdighederne hos erfarne udviklere. Økonomisk set er denne historie ekstremt billig, så alle vinder: virksomheden, vores udviklere og selvfølgelig juniorer, der ikke behøver at flytte til store byer eller hovedstæder for at blive en del af et erfarent team og arbejde på interessante projekter .

Kilde: www.habr.com

Tilføj en kommentar