Hej alla! Jag heter Lyudmila Makareva, jag Àr utvecklingschef pÄ UBRiR och en tredjedel av mitt team bestÄr av "universella".
EricakÀnner: varje Tech Lead drömmer om cross-funktionalitet inom sitt team. Det Àr verkligen fantastiskt nÀr en person kan ersÀtta tre och göra det med kvalitet, utan att fördröja tidslinjerna. Viktigt Àr ocksÄ att detta medför resursbesparingar!
Det lÄter vÀldigt lockande, men hur stÄr det verkligen till? LÄt oss försöka reda ut det.
Vem Àr vÄr förvÀntansfulla föregÄngare?
Med termen "universell" avses vanligtvis teammedlemmar som kombinerar mer Àn en roll, till exempel utvecklare-analytiker.
Teamets samarbete och resultat beror pÄ deltagarnas professionella och personliga egenskaper.
Hard skills Àr sjÀlvklara, men soft skills förtjÀnar sÀrskild uppmÀrksamhet. De hjÀlper till att hitta angreppssÀtt mot medarbetaren och styra dem mot den uppgift dÀr de kommer att vara mest anvÀndbara.
Det finns mÄnga artiklar om olika typer av personligheter inom IT-branschen. Baserat pÄ min erfarenhet skulle jag dela in IT-universella i fyra kategorier:
1. "Universell - allsmÀktig"
De finns överallt. De visar alltid mycket aktivitet, vill vara i centrum för uppmÀrksamheten, stÀller konstant frÄgor till kollegor om de behöver deras hjÀlp och kan ibland till och med irritera. De Àr intresserade av meningsfulla uppgifter dÀr deras kreativitet kan blomstra och feeda deras sjÀlvkÀnsla.
Starka sidor:
- kan lösa komplexa uppgifter;
- fokuserar djupt pÄ problem, "grÀver" och nÄr resultat;
- har en nyfiken intellekt.
Men:
- emotionellt labila;
- svÄra att leda;
- har sin obevekliga Äsikt som Àr svÄr att förÀndra;
- det Àr svÄrt att fÄ dem att göra en enkel uppgift. LÀtta uppgifter sÄrar de allsmÀktigas sjÀlvkÀnsla.
2. "Universell - jag fixar det"
För sĂ„dana mĂ€nniskor rĂ€cker det med en manual och lite tid â sedan löser de frĂ„gan. De har vanligtvis en stor bakgrund som DevOps. Dessa universella personer besvĂ€rar sig sĂ€llan med design och föredrar utvecklingsmetoder baserade enbart pĂ„ sina erfarenheter. De kan enkelt hamna i konflikt med tech-ledaren angĂ„ende vald implementeringsmetod.
Starka sidor:
- sjÀlvstÀndiga;
- stressresistenta;
- kompetenta inom mÄnga frÄgor;
- Ă€r vĂ€lutbildade â det finns alltid nĂ„got att prata om med dem.
Men:
- bryter ofta sina Ă„taganden;
- har en tendens att komplicera allt: löser multiplikationstabellen genom partiell integration;
- kvaliteten pÄ arbetet Àr lÄg, allt tar 2-3 försök;
- skjuter stÀndigt upp deadlines, för egentligen Àr allt inte sÄ enkelt.
3. "Universal â okej, lĂ„t mig ta det, eftersom det inte finns nĂ„gon annan"
Medarbetaren har en bra förstÄelse för flera omrÄden och har relevant erfarenhet. Men han lyckas inte bli professionell inom nÄgot av dem, eftersom han ofta anvÀnds som en rÀddningsplanka för att fylla luckor i pÄgÄende uppgifter. LÀttsinnad, eftergiven, anser att han Àr efterfrÄgad, men sÄ Àr det inte.
Praktiskt taget en idealisk medarbetare. Han har sannolikt ett omrÄde som han föredrar, men pÄ grund av otydlig kompetensskerhet sker ingen utveckling. Resultatet Àr att personen riskerar att bli ointressant och kÀnslomÀssigt utbrÀnd.
Starka sidor:
- ansvariga;
- resultatinriktade;
- lugna;
- fullstÀndigt kontrollerade.
Men:
- uppvisar genomsnittliga resultat pÄ grund av lÄg kompetensnivÄ;
- kan inte lösa komplicerade och abstrakta problem.
4. "Universal â mĂ€stare inom sitt omrĂ„de"
En person med en seriös bakgrund som utvecklare, har systematiskt tÀnkande. Pedantisk, stÀller krav pÄ sig sjÀlv och teamet. Varje uppgift med hans medverkan kan vÀxa till oÀndlighet om det inte sÀtts grÀnser.
VĂ€l insatt i arkitekturen, vĂ€ljer en metod för teknisk genomförande efter noggrant analysera hur den valda lösningen pĂ„verkar den aktuella arkitekturen. Ădmjuk, utan ambitioner.
Starka sidor:
- uppvisar hög kvalitet pÄ arbetet;
- kan lösa vilken uppgift som helst;
- mycket arbetsamma.
Men:
- intoleranta mot andras Ă„sikter;
- maximalister. De försöker göra allt rÀtt, vilket förlÀnger utvecklingstiderna.
Vad har vi i praktiken?
LĂ„t oss se hur roller och kompetenser oftast kombineras. Vi tar en standard utvecklingsteam som utgĂ„ngspunkt: PO, utvecklingschef (tech lead), analytiker, programmerare, testare. Vi rĂ€knar inte med produktĂ€garen och tech leaden. Den första â pĂ„ grund av brist pĂ„ tekniska kompetenser. Den andra, om det finns problem i teamet, mĂ„ste faktiskt kunna göra allt.
Den mest populÀra varianten av att kombinera/föra samman/inta kompetenser Àr utvecklare-analytiker. Analytiker-testare och "tre i ett" förekommer ocksÄ mycket ofta.
Jag kommer att illustrera fördelarna och nackdelarna med allroundkollegor genom min egen grupp. En tredjedel av min grupp bestÄr av dem, och jag Àlskar dem verkligen.
Det kom en brĂ„dskande uppgift frĂ„n PO om att implementera nya tariffer i den befintliga produkten. Min grupp har fyra analytiker. Vid den tidpunkten var en pĂ„ semester, en annan var sjuk, och de övriga var upptagna med strategiska uppgifter. Om jag skulle ha dragit ut dem skulle det oundvikligen ha försenat genomförandet. Den enda utvĂ€gen var att anvĂ€nda "hemliga vapnet" â den allroundande utvecklaren-analytikern som hade kunskapen om det kravsomrĂ„de som behövdes. LĂ„t oss kalla honom Anatolij.
Hans personlighetstyp Ă€r "allroundare â jag löser det och gör det". SjĂ€lvklart försökte han lĂ€nge förklara att han hade "en fullstĂ€ndig backlogg av sina uppgifter", men med min beslutsamhet blev han skickad för att lösa den brĂ„dskande uppgiften. Och Anatolij klarade det! Han genomförde planeringen och utförde implementationen i tid, och bestĂ€llarna var nöjda.
Vid första anblicken gick allt bra. Men efter nÄgra veckor uppstod det Äter ett behov av förbÀttringar för denna produkt. Nu var det en "ren" analytiker som ansvarade för planeringen av detta uppdrag. Under testningen av den nya utvecklingen kunde vi lÀnge inte förstÄ varför vi fick fel nÀr det gÀllde bindningen av de nya tarifferna, och först senare, efter att ha rullat upp hela klotet, nÄdde vi sanningen. Vi spenderade massor av tid och försenade tidsfristen.
Problemet var att mÄnga dolda aspekter och fallgropar endast var kvar i huvudet pÄ vÄr allroundare och inte hade överförts till papper. Som Anatolij senare förklarade, hade han brÄttom. Men den mest troliga varianten var att han stötte pÄ problem redan under utvecklingen och bara undvek dem, utan att reflektera över dem nÄgonstans.
Det fanns ocksĂ„ en annan situation. Just nu har vi bara en testare, sĂ„ vissa uppgifter mĂ„ste testas av analytiker, inklusive allroundare. DĂ€rför gav jag en uppgift till en hypotetisk Fedor â "allroundare â okej, lĂ„t oss göra det, eftersom det inte finns fler".
Fedor Àr "tre i ett", men för denna uppgift hade en utvecklare redan avsatts. Det betyder att Fedor bara behövde kombinera analytiker och testare.
Krav Àr insamlade, specifikationen har överlÀmnats till utvecklingen, det Àr dags att testa. Fedor kÀnner den förbÀttrade systemet "som sina fem fingrar" och har noggrant arbetat igenom de aktuella kraven. DÀrför valde han att inte besvÀra sig med att skriva testscenarier och genomförde tester pÄ hur "systemet ska fungera", och sedan överlÀmnade det till anvÀndarna.
Testet Àr avslutat, förbÀttringen har gÄtt till produktion. Senare visade det sig att systemet inte bara stoppar betalningar till vissa balanskonton, utan Àven blockerar betalningar frÄn mycket sÀllsynta interna konton som inte borde ingÄ.
Detta intrÀffade eftersom Fedor inte genomförde en kontroll av hur "systemet inte ska fungera", han tog inte fram en testplan eller checklistor. Han beslutade sig för att spara tid och förlitade sig pÄ sin egen intuition.
Hur hanterar vi problem?
Liknande situationer pÄverkar teamets effektivitet, kvaliteten pÄ slÀppta versioner och kundnöjdheten. DÀrför fÄr de inte lÀmnas utan uppmÀrksamhet och orsaksanalyser.
1. För varje uppgift som orsakat svÄrigheter ber jag att fylla i en standardiserad form: en felrapport som gör det möjligt att identifiera det steg dÀr "problemet intrÀffade":
2. Efter att ha identifierat flaskhalsarna genomförs en brainstorming med varje medarbetare som har pÄverkat problemet: "Vad ska Àndras?" (vi övervÀger inte specifika fall under retrospektiven), vilket resulterar i konkreta ÄtgÀrder (för varje typ av personlighet sina egna) med tidsramar.
3. Vi har infört regler för interaktion inom teamet. Till exempel har vi kommit överens om att alltid dokumentera all information om uppdragets framsteg i projekthanteringssystemet. Vid Àndringar/identifiering av artefakter under utvecklingsprocessen ska detta Äterspeglas i kunskapsbasen och den slutliga versionen av specifikationen.
4. Kontroll har börjat genomföras vid varje steg (sÀrskild uppmÀrksamhet ges till problematiska steg i det förflutna) och automatiskt baserat pÄ resultaten frÄn nÀsta uppgift.
5. Om resultatet för nÀsta uppgift inte har förÀndrats, placerar jag inte den aktuella allroundspelaren i den roll dÀr han har svÄrt att prestera. Jag försöker bedöma hans förmÄga och vilja att utveckla kompetenser i denna roll. Om jag inte hittar respons, lÀmnar jag honom i den roll som han Àr nÀrmare.
Vad blev resultatet?
Utvecklingsprocessen har blivit mer transparent. BUS-faktorn har minskat. Teammedlemmar som arbetar med fel blir mer motiverade och förbÀttrar sin karma. Vi höjer gradvis kvaliteten pÄ vÄra releaser.
Slutsatser
AnstÀllda med breda kompetenser har sina för- och nackdelar.
Fördelar:
- man kan nÀr som helst stÀnga av en hÀngande uppgift eller snabbt lösa en brÄdskande bugg;
- helhetssyn vid problemlösning: utföraren ser uppgiften frÄn alla roller;
- bredkompetenta anstÀllda kan praktiskt taget göra allt lika bra.
Nackdelar:
- BUS-faktorn ökar;
- grundlÀggande kompetenser för rollen urholkas. Detta sÀnker kvaliteten pÄ arbetet;
- risken för tidsförskjutningar ökar, eftersom det saknas kontroll vid varje steg. Problemen med att skapa en "stjÀrna" kan ocksÄ uppstÄ: en anstÀlld Àr övertygad om att han vet bÀttre, att han Àr en professionell;
- risken för professionell utmattning ökar;
- mycket viktig information om projektet kan bara finnas "i huvudet" pÄ den anstÀllde.
Som ni ser, Àr nackdelarna fler. DÀrför anvÀnder jag bredkompetenta anstÀllda endast nÀr resurser saknas, och uppgiften ses som ganska brÄdskande. Eller om personen har kompetenser som saknas hos andra och kvaliteten stÄr pÄ spel.
Om reglerna för rollfördelning följs i det gemensamma arbetet pÄ uppgiften ökar kvaliteten pÄ arbetet. Vi ser pÄ problem frÄn olika perspektiv, vilket förhindrar att synen blir trÄkig, och nya friska tankar dyker alltid upp. Dessutom har varje teammedlem alla möjligheter till professionell tillvÀxt och breddning av sina kompetenser.
Jag anser att det viktigaste Ă€r att kĂ€nna sig involverad i processen, att arbeta med sitt jobb och gradvis öka bredden pĂ„ sina kompetenser. ĂndĂ„ ger bredkompetenta anstĂ€llda i teamet fördelar: det viktigaste Ă€r att se till att de effektivt förenar olika roller.
Jag önskar alla sjÀlvorganiserande team "bredkompetenta mÀstare av sitt hantverk"!
KĂ€lla: habr.com
