Hej alle! Mit navn er Lyudmila Makarova, jeg er udviklingschef hos UBRD og en tredjedel af mit team er "generalister".
Indrøm det: enhver Tech Lead drømmer om tværfunktionalitet inden for deres team. Det er så fedt, når én person er i stand til at erstatte tre, og endda gøre det effektivt, uden at forsinke deadlines. Og vigtigst af alt, det sparer ressourcer!
Det lyder meget fristende, men er det virkelig sådan? Lad os prøve at finde ud af det.
Hvem er han, vores forløber for forventninger?
Udtrykket "generalist" refererer normalt til teammedlemmer, der kombinerer mere end én rolle, for eksempel udvikler-analytiker.
Teamets interaktion og resultatet af dets arbejde afhænger af deltagernes faglige og personlige egenskaber.
Alt er klart om hårde færdigheder, men bløde færdigheder fortjener særlig opmærksomhed. De hjælper med at finde en tilgang til en medarbejder og leder ham til den opgave, hvor han vil være mest brugbar.
Der findes mange artikler om alle slags personlighedstyper i IT-branchen. Baseret på min erfaring vil jeg opdele IT-generalister i fire kategorier:
1. "Universal - Almægtig"
Disse er overalt. De er altid meget aktive, vil gerne være i centrum, spørger konstant deres kolleger, om de har brug for deres hjælp, og nogle gange kan de endda være irriterende. De er kun interesserede i meningsfulde opgaver, hvor deltagelse vil give plads til kreativitet og kan more deres stolthed.
Hvad er de stærke i:
- er i stand til at løse komplekse problemer;
- dyk dybt ned i problemet, "grav" og opnå resultater;
- have et videbegærligt sind.
men:
- følelsesmæssigt labil;
- dårligt forvaltet;
- har deres eget urokkelige synspunkt, som er meget svært at ændre;
- Det er svært at få nogen til at gøre en simpel ting. Lette opgaver skader den almægtiges ego.
2. "Universal - jeg finder ud af det og gør det"
Sådanne mennesker har bare brug for en manual og lidt tid - og de vil løse problemet. De har normalt en stærk baggrund i DevOps. Sådanne generalister bryder sig ikke om design og foretrækker at bruge en udviklingsmetode, der udelukkende er baseret på deres erfaring. De kan nemt tage en diskussion med den tekniske leder om den valgte mulighed for at implementere opgaven.
Hvad er de stærke i:
- uafhængig;
- stress-resistent;
- kompetent i mange spørgsmål;
- lærde - der er altid noget at snakke med dem om.
men:
- ofte overtræder forpligtelser;
- har en tendens til at komplicere alt: løs multiplikationstabellen ved at integrere med dele;
- kvaliteten af arbejdet er lav, alt fungerer 2-3 gange;
- De skifter konstant deadlines, for i virkeligheden viser alt sig ikke at være så enkelt.
3. "Universal - okay, lad mig gøre det, da der ikke er nogen anden"
Medarbejderen er velbevandret inden for flere områder og har relevant erfaring. Men han formår ikke at blive professionel i nogen af dem, fordi han ofte bliver brugt som en livline, der stopper huller i aktuelle opgaver. Bøjelig, effektiv, betragter sig selv som efterspurgt, men er det ikke.
En praktisk ideel medarbejder. Højst sandsynligt har han en retning, som han bedst kan lide, men på grund af udviskning af kompetencer sker der ikke udvikling. Som et resultat risikerer en person at blive uafhentet og følelsesmæssigt udbrændt.
Hvad er de stærke i:
- ansvarlig;
- resultatorienteret;
- berolige;
- fuldstændig kontrolleret.
men:
- vise gennemsnitlige resultater på grund af et lavt kompetenceniveau;
- kan ikke løse komplekse og abstrakte problemer.
4. "En allrounder er en mester i sit håndværk"
En person med en seriøs baggrund som udvikler har systemtænkning. Pedantisk, krævende af sig selv og sit team. Enhver opgave, der involverer ham, kan vokse i det uendelige, hvis grænser ikke er defineret.
Han er godt bekendt med arkitekturen, vælger en metode til teknisk implementering og analyserer omhyggeligt virkningen af den valgte løsning på den nuværende arkitektur. Beskeden, ikke ambitiøs.
Hvad er de stærke i:
- vise høj kvalitet af arbejdet;
- i stand til at løse ethvert problem;
- meget effektiv.
men:
- intolerant over for andres meninger;
- maksimalister. De forsøger at gøre alt rigtigt, og det øger udviklingstiden.
Hvad har vi i praksis?
Lad os se, hvordan roller og kompetencer oftest kombineres. Lad os tage udgangspunkt i et standardudviklingsteam: PO, udviklingschef (tech lead), analytikere, programmører, testere. Vi vil ikke overveje produktejeren og teknisk forspring. Den første skyldes mangel på tekniske kompetencer. Den anden, hvis der er problemer i holdet, burde kunne gøre alt.
Den mest almindelige mulighed for at kombinere/fusionere/kombinere kompetencer er udvikler-analytiker. Testanalytiker og "tre i en" er også meget almindelige.
Ved at bruge mit team som eksempel, vil jeg vise dig fordele og ulemper ved mine medgeneralister. Der er en tredjedel af dem på mit hold, og jeg elsker dem meget.
PO fik en presserende opgave med at indføre nye tariffer i et eksisterende produkt. Mit team har 4 analytikere. På det tidspunkt var den ene på ferie, den anden var syg, og resten var engageret i gennemførelsen af strategiske opgaver. Hvis jeg trak dem ud, ville det uundgåeligt forstyrre implementeringsfristerne. Der var kun én udvej: at bruge det "hemmelige våben" - en alsidig udvikler-analytiker, der mestrede det krævede emneområde. Lad os kalde ham Anatoly.
Hans personlighedstype er "universelt - jeg finder ud af det og gør det". Selvfølgelig forsøgte han i lang tid at forklare, at han "har fuld efterslæb på sine opgaver", men ved min viljestærke beslutning blev han sendt for at løse et akut problem. Og Anatoly gjorde det! Han udførte iscenesættelsen og gennemførte implementeringen til tiden, og kunderne var tilfredse.
Ved første øjekast lykkedes alt. Men efter et par uger opstod der igen krav til forbedringer for dette produkt. Nu blev formuleringen af dette problem udført af en "ren" analytiker. På teststadiet af den nye udvikling kunne vi i lang tid ikke forstå, hvorfor vi havde fejl i forbindelse med nye tariffer, og først da, efter at have optrevlet hele virvaren, kom vi til bunds i sandheden. Vi spildte en masse tid og overskred deadlines.
Problemet var, at mange skjulte øjeblikke og faldgruber kun forblev i hovedet på vores stationcar og ikke blev overført til papir. Som Anatoly senere forklarede, havde han for travlt. Men den mest sandsynlige mulighed er, at han stødte på problemer allerede under udviklingen og simpelthen omgik dem uden at afspejle dette nogen steder.
Der var en anden situation. Nu har vi kun én tester, så nogle opgaver skal testes af analytikere, herunder generalister. Derfor gav jeg en opgave til den betingede Fedor - "universel - okay, lad mig gøre det, da der ikke er nogen anden".
Fedor er en "tre i en", men en udvikler er allerede blevet tildelt denne opgave. Det betyder, at Fedya kun skulle kombinere en analytiker og en tester.
Kravene er blevet indsamlet, specifikationen er blevet forelagt til udvikling, det er tid til at teste. Fedor ved, at systemet bliver ændret "som sin egen bukselomme" og har grundigt udarbejdet de nuværende krav. Derfor bød han sig ikke med at skrive testscripts, men gennemførte test af "hvordan systemet skulle fungere", og gav det derefter videre til brugerne.
Testen blev afsluttet, revisionen gik til produktion. Det viste sig senere, at systemet ikke blot suspenderede betalinger til visse saldokonti, men også blokerede betalinger fra meget sjældne interne konti, som ikke skulle deltage i dette.
Dette skete på grund af det faktum, at Fedor ikke tjekkede, hvordan "systemet ikke skulle fungere", ikke udarbejdede en testplan eller tjeklister. Han besluttede at spare på timingen og stole på sine egne instinkter.
Hvordan håndterer vi problemer?
Situationer som disse påvirker teamets ydeevne, udgivelseskvalitet og kundetilfredshed. Derfor kan de ikke efterlades uden opmærksomhed og analyse af årsagerne.
1. For hver opgave, der forårsagede vanskeligheder, beder jeg dig om at udfylde en samlet formular: et fejlkort, som giver dig mulighed for at identificere det stadium, hvor "udtrækningen" fandt sted:
2. Efter at have identificeret flaskehalse, afholdes en brainstormsession med hver medarbejder, der har påvirket problemet: "Hvad skal ændres?" (vi betragter ikke særlige tilfælde i retrospekt), som følge af, at der fødes specifikke handlinger (specifikke for hver personlighedstype) med deadlines.
3. Vi har indført regler for interaktion i teamet. For eksempel blev vi enige om nødvendigvis at registrere alle oplysninger om en opgaves fremdrift i projektstyringssystemet. Når artefakter ændres/identificeres under udviklingsprocessen, skal dette afspejles i videnbasen og den endelige version af de tekniske specifikationer.
4. Kontrol begyndte at blive udført på hvert trin (der lægges særlig vægt på problematiske stadier i fortiden) og automatisk baseret på resultaterne af den næste opgave.
5. Hvis resultatet på næste opgave ikke har ændret sig, så sætter jeg ikke den pågældende generalist i den rolle, han klarer sig dårligt i. Jeg forsøger at vurdere hans evner og lyst til at udvikle kompetencer i denne rolle. Hvis jeg ikke finder et svar, efterlader jeg ham i den rolle, der er tættere på ham.
Hvad skete der til sidst?
Udviklingsprocessen er blevet mere gennemsigtig. BUS-faktoren er faldet. Teammedlemmer, der arbejder på fejl, bliver mere motiverede og forbedrer deres karma. Vi forbedrer gradvist kvaliteten af vores udgivelser.
Fund
Generalistmedarbejdere har deres fordele og ulemper.
Fordele:
- du kan til enhver tid lukke en hængende opgave eller løse en akut fejl på kort tid;
- en integreret tilgang til løsning af et problem: udøveren ser på det fra alle rollers perspektiv;
- generalister kan næsten alt lige godt.
Ulemper:
- BUS-faktor stiger;
- de kernekompetencer, der ligger i rollen, udhules. På grund af dette falder kvaliteten af arbejdet;
- sandsynligheden for et skift i deadlines øges, pga der er ingen kontrol på hvert trin. Der er også risici ved at vokse en "stjerne": medarbejderen er sikker på, at han bedre ved, at han er en pro;
- risikoen for professionel udbrændthed stiger;
- meget vigtig information om projektet kan kun forblive "i hovedet" på medarbejderen.
Som du kan se, er der flere mangler. Derfor bruger jeg kun generalister, hvis der ikke er ressourcer nok, og opgaven er ret presserende. Eller en person har kompetencer, som andre mangler, men kvaliteten er på spil.
Hvis reglen om rollefordeling overholdes i fælles arbejde med en opgave, så øges kvaliteten af arbejdet. Vi ser på problemer fra forskellige vinkler, vores syn er ikke sløret, friske tanker dukker altid op. Samtidig har hvert teammedlem alle muligheder for faglig vækst og udvidelse af deres kompetencer.
Jeg tror på, at det vigtigste er at føle sig involveret i processen, at udføre sit arbejde, gradvist at øge bredden i sine kompetencer. Generalister i et team giver dog fordele: det vigtigste er at sikre, at de effektivt kombinerer forskellige roller.
Jeg ønsker alle et selvorganiserende team af "universelle mestre af deres håndværk"!
Kilde: www.habr.com