Hej alle! Mit navn er Lyudmila Makarova, jeg er udviklingsmanager hos UBRIR, og en tredjedel af mit team er "universaler".
Erkend det: hver Tech Lead drømmer om tværfaglighed inden for sit team. Det er fantastisk, når én person kan erstatte tre og gøre det effektivt uden at forsinke tidslinjerne. Og vigtigst af alt, det sikrer ressourcebesparelser!
Det lyder meget tiltalende, men er det virkelig sådan? Lad os prøve at finde ud af det.
Hvem er vores forventningsfulde leder?
Med begrebet "universel" forstås normalt teammedlemmer, der kombinerer mere end én rolle, såsom udvikler-analytiker.
Teaminteraktion og resultatet af deres arbejde afhænger af de professionelle og personlige egenskaber ved deltagerne.
Hard skills er klart definerede, men soft skills fortjener særlig opmærksomhed. De hjælper med at finde den rette tilgang til medarbejderen og lede ham eller hende mod den opgave, hvor de vil være mest nyttige.
Der er mange artikler om de forskellige personlighedstyper i IT-branchen. Baseret på min erfaring ville jeg dele IT-universaler op i fire kategorier:
1. "Universalen – alvidende"
Der er sådanne overalt. De viser altid stor aktivitet, vil gerne være i centrum for opmærksomhed, spørger konstant deres kolleger, om de har brug for hjælp, og kan nogle gange være irriterende. De interesserer sig kun for betydningsfulde opgaver, hvor de kan udtrykke deres kreativitet og tilfredsstille deres ego.
Styrker:
- kan løse komplekse opgaver;
- dykker dybt ind i problemet, "graver" og opnår resultater;
- har nysgerrigt sind.
Men:
- er følelsesmæssigt labil;
- svært at styre;
- har deres ufravigelige synspunkt, som er meget svært at ændre;
- det er svært at få dem til at udføre en simpel opgave. Nemme opgaver krænker de alvidendes selvværd.
2. "Universalen – jeg finder ud af det og gør det"
Disse personer behøver blot en manual og lidt tid – så løser de problemet. De har typisk en stor baggrund som DevOps. Sådanne universaler belaster ikke sig selv med design og foretrækker at bruge deres erfaring som eneste grundlag for udviklingsmetoden. De kan nemt ende i en skænderi med techleaden om den valgte implementeringsmetode.
Styrker:
- er selvstændige;
- er stresstolerante;
- er kompetente inden for mange emner;
- De er vidende – der er altid noget at tale om med dem.
Men:
- De overholder ofte ikke forpligtelserne;
- De har en tendens til at komplicere alt: de løser multiplikationstabel ved at integrere delvist;
- Kvaliteten af arbejdet er lavt, det lykkes dem kun efter 2-3 forsøg;
- De udsætter konstant deadlines, fordi det faktisk viser sig ikke at være så enkelt.
3. "Universalløsningen - okay, lad mig tage den, da ingen andre gør det"
Medarbejderen har en god forståelse af flere områder og har den relevante erfaring. Men han formår ikke at blive professionel inden for nogen af dem, fordi han ofte bruges som en redningskrans, der lukker huller i de løbende opgaver. Han er eftergivende, lydhør og betragter sig selv som eftertragtet, men er ikke det.
Den praktisk perfekte medarbejder. Han har sikkert et område, han foretrækker, men på grund af uklarhed i kompetencerne finder der ikke udvikling sted. Som følge heraf risikerer personen at blive uefterspurgt og føle sig følelsesmæssigt udbrændt.
Styrker:
- ansvarlige;
- målrettet mod resultater;
- rolige;
- helt kontrollerede.
Men:
- de viser et gennemsnitligt resultat på grund af lavt kompetenceniveau;
- de kan ikke løse komplekse og abstrakte opgaver.
4. "Universalløsningen - mester i sit fag"
En person med en seriøs baggrund som udvikler, har systemisk tænkning. Han er pedantisk, krævende over for sig selv og teamet. Enhver opgave, han er involveret i, kan vokse til det uendelige, hvis ikke grænserne defineres.
Han er godt bekendt med arkitekturen, vælger metoden for teknisk implementering ved nøje at analysere indflydelsen af den valgte løsning på den nuværende arkitektur. Han er beskeden og uden ambitioner.
Styrker:
- de viser høj kvalitet i arbejdet;
- de kan løse enhver opgave;
- de er meget arbejdsomme.
Men:
- de er utolerante over for andres mening;
- de er maksimalister. De forsøger at gøre alt korrekt, hvilket forlænger udviklingstiderne.
Hvad har vi i praksis?
Lad os se, hvordan roller og kompetencer ofte kombineres. Vi tager udgangspunkt i et standard udviklingsteam: PO, udviklingsleder (techlead), analytikere, programmører, testere. Vi vil ikke tage produktlederen og techleaden med. Den første – på grund af manglende tekniske kompetencer. Den anden, hvis der er problemer i teamet, skal netop kunne gøre det hele.
Den mest almindelige variant af at kombinere/fusionere/samle kompetencer er udvikler-analytikeren. Analytik-testeren og "tre i én" ses også meget ofte.
Ved at tage udgangspunkt i mit eget team vil jeg vise fordele og ulemper ved de alsidige kollegaer. En tredjedel af mit team består af dem, og jeg holder meget af dem.
Fra PO kom der en hastesag om at implementere nye tariffér i det eksisterende produkt. I mit team er der 4 analytikere. På det tidspunkt var en på ferie, en anden var syg, og de øvrige arbejdede med strategiske opgaver. Hvis jeg havde trukket dem ud, ville det uundgåeligt have forsinket implementeringen. Der var kun én løsning: at bruge "det hemmelige våben" - den alsidige udvikler-analytiker, som kendte det nødvendige fagområde. Lad os kalde ham Anatolij.
Hans personlighedstype er "alsidig - jeg finder ud af det og gør det". Selvfølgelig prøvede han længe at forklare, at han havde "en fuld backlog af sine opgaver", men mit bestemmende valg sendte ham til at løse den hastesag. Og Anatolij klarede det! Han satte opgaven og udførte implementeringen til tiden, og kunderne var tilfredse.
Ved første øjekast lykkedes det hele. Men efter et par uger opstod der igen krav om forbedringer til dette produkt. Nu var det en "ren" analytiker, der arbejdede med opgaven. På teststadiet af den nye udvikling kunne vi længe ikke forstå, hvorfor der opstod fejl ved tilknytningen af de nye tarifér, og først senere, efter at have afdækket hele knuden, nåede vi sandheden. Vi brugte en masse tid og forsinkede tidsplanen.
Problemet var, at mange skjulte detaljer og faldgruber kun var i hovedet på vores alsidige og ikke var blevet nedskrevet. Som Anatolij senere forklarede, havde han skyndt sig for meget. Men det mest sandsynlige scenario er, at han mødte problemer allerede under udviklingen og blot undveg dem uden at notere noget.
Der var også en anden situation. Nu har vi kun én tester, så nogle opgaver må analyserne, inklusive de alsidige, teste. Derfor gav jeg én opgave til den hypotetiske Fedja - "alsidige - fint, lad mig gøre det, da der ikke er andre".
Fedja er "tre i én", men der var allerede tildelt en udvikler til denne opgave. Så Fedja skulle kun forene analytiker og tester i sig selv.
Kravene er indsamlet, specifikationen er sendt til udvikling, og det er tid til at teste. Fjodor kender det forbedrede system «som sin egen lomme» og har grundigt gennemgået de aktuelle krav. Derfor tog han ikke besværet med at skrive testscenarier, men udførte testningen på, hvordan «systemet bør fungere», og derefter – overgav det til brugerne.
Testen er afsluttet, og forbedringen er sendt til produktion. Senere viste det sig, at systemet ikke kun suspenderer behandling af betalinger til bestemte balancekonti, men også blokerer for betalinger fra meget sjældne interne konti, der ikke skulle deltage i dette.
Dette skete, fordi Fjodor ikke udførte en kontrol af, hvordan «systemet ikke skal fungere», og han udarbejdede ikke en testplan eller tjeklister. Han besluttede at spare tid og stolede på sin egen mavefornemmelse.
Hvordan arbejder vi med problemer?
Sådanne situationer påvirker teamets effektivitet, kvaliteten af de frigivne versioner og kundetilfredsheden. Derfor kan de ikke ignoreres og skal analyseres nærmere.
1. For hver opgave, der har givet problemer, beder jeg om at udfylde en standardformular: fejlkortet, som gør det muligt at identificere det trin, hvor der opstod et «fald»:
2. Efter identifikationen af flaskehalse gennemføres der en brainstorm med hver medarbejder, der har påvirket problemet, «Hvad skal ændres?» (vi ser ikke på specifikke tilfælde under retro), hvorefter der skabes konkrete handlinger (for hver personlighedstype sine) med tidsfrister.
3. Vi har indført regler for interaktion internt i teamet. For eksempel har vi aftalt at registrere al information om opgavens fremdrift i projektstyringssystemet. Ved ændringer/identifikation af artefakter i udviklingsprocessen skal dette vises i vidensbasen og den endelige version af kravspecifikationen.
4. Kontrollen er blevet udført på hvert trin (særlig opmærksomhed gives til problematiske trin fra fortiden) og automatisk på baggrund af resultaterne af den næste opgave.
5. Hvis resultatet af den næste opgave ikke er ændret, placerer jeg ikke den pågældende universelle medarbejder i den rolle, som han har svært ved. Jeg prøver at vurdere hans evne og vilje til at udvikle kompetencer i denne rolle. Hvis jeg ikke finder nogen respons, lader jeg ham forblive i den rolle, der passer ham bedst.
Hvad blev resultatet?
Udviklingsprocessen er blevet mere gennemsigtig. BUS-faktoren er blevet reduceret. Teammedlemmer, der arbejder på fejl, bliver mere motiverede og forbedrer deres karma. Vi hæver gradvist kvaliteten af vores udgivelser.
Konklusioner
Mangefacetterede medarbejdere har deres fordele og ulemper.
Fordele:
- Det er muligt at lukke en hængende opgave på ethvert tidspunkt eller løse en presserende fejl hurtigt;
- En helhedsorienteret tilgang til at løse opgaven: den udførende ser på den fra alle roller;
- Mangefacetterede medarbejdere kan praktisk talt gøre alt lige godt.
Ulemper:
- BUS-faktoren stiger;
- de primære kompetencer, der hører til en rolle, bliver udvandet. Dette reducerer kvaliteten af arbejdet;
- der er større risiko for tidsforskydninger, da der mangler kontrol ved hver fase. Der opstår også risici for at skabe en 'stjerne': medarbejderen er sikker på, at han ved bedre og er ekspert;
- risikoen for professionelt udbrændthed øges;
- mange vigtige oplysninger om projektet kan forblive kun 'i hovedet' på medarbejderen.
Som du kan se, er der flere ulemper. Derfor bruger jeg kun mangefacetterede medarbejdere, når ressourcerne er knappe, og opgaven er tilstrækkeligt hastende. Eller personen har kompetencer, som de andre ikke har, og kvaliteten står på spil.
Hvis der i det fælles arbejde med opgaven overholdes reglen om rollefordeling, så stiger kvaliteten af arbejdet. Vi ser på problemerne fra forskellige vinkler, synet bliver ikke sløret, og der dukker altid friske tanker op. Samtidig har hver deltager i teamet alle muligheder for professionel vækst og udvidelse af deres kompetencer.
Jeg mener, at det vigtigste er at føle sin tilknytning til processen, at beskæftige sig med sit arbejde og gradvist udvide sine kompetencer. Ikke desto mindre bringer mangefacetterede medarbejdere værdi til teamet: det vigtigste er at få dem til effektivt at kombinere forskellige roller.
Jeg ønsker alle selvorganiserende team af 'mangefacetterede mestre i deres fag'!
Kilde: habr.com
