Hej alla! Jag heter Lyudmila Makarova, jag är utvecklingschef på UBRD och en tredjedel av mitt team är "generalister".
Erkänn det: varje teknisk chef drömmer om tvärfunktionalitet inom sitt team. Det är så häftigt när en person kan ersätta tre, och till och med göra det effektivt, utan att försena deadlines. Och, viktigare, det sparar resurser!
Det låter väldigt lockande, men är det verkligen så? Låt oss försöka lista ut det.
Vem är han, vår föregångare till förväntningar?
Termen "generalist" syftar vanligtvis på teammedlemmar som kombinerar mer än en roll, till exempel utvecklare-analytiker.
Samspelet mellan teamet och resultatet av dess arbete beror på deltagarnas professionella och personliga egenskaper.
Allt är klart om hårda färdigheter, men mjuka färdigheter förtjänar särskild uppmärksamhet. De hjälper till att hitta ett förhållningssätt till en anställd och styr honom till den uppgift där han kommer att vara mest användbar.
Det finns många artiklar om alla typer av personlighetstyper inom IT-branschen. Baserat på min erfarenhet skulle jag dela in IT-generalister i fyra kategorier:
1. "Universell – Allsmäktig"
Dessa finns överallt. De är alltid väldigt aktiva, vill stå i centrum, frågar hela tiden sina kollegor om de behöver deras hjälp, och ibland kan de till och med vara irriterande. De är bara intresserade av meningsfulla uppgifter, deltagande i vilket ger utrymme för kreativitet och kan roa deras stolthet.
Vad är de starka i:
- kan lösa komplexa problem;
- dyka djupt in i problemet, "gräva" och uppnå resultat;
- ha ett nyfiket sinne.
men:
- känslomässigt labil;
- dåligt skött;
- har sin egen orubbliga synvinkel, som är mycket svår att ändra;
- Det är svårt att få någon att göra en enkel sak. Enkla uppgifter skadar den Allsmäktiges ego.
2. "Universellt – jag kommer på det och gör det"
Sådana människor behöver bara en manual och lite tid - och de kommer att lösa problemet. De har vanligtvis en stark bakgrund inom DevOps. Sådana generalister stör sig inte på design och föredrar att använda en utvecklingsmetod baserad enbart på deras erfarenhet. De kan enkelt föra en diskussion med den tekniska ledaren om det valda alternativet för att genomföra uppgiften.
Vad är de starka i:
- oberoende;
- stresstålig;
- kompetent i många frågor;
- erudite - det finns alltid något att prata om med dem.
men:
- ofta bryter mot skyldigheter;
- tenderar att komplicera allt: lös multiplikationstabellen genom att integrera med delar;
- kvaliteten på arbetet är låg, allt fungerar 2-3 gånger;
- De ändrar ständigt deadlines, för i verkligheten visar sig allt inte vara så enkelt.
3. "Universal – okej, låt mig göra det, eftersom det inte finns någon annan"
Medarbetaren är väl insatt i flera områden och har relevant erfarenhet. Men han misslyckas med att bli proffs i någon av dem, eftersom han ofta används som en livlina och täpper hål i aktuella uppgifter. Böjlig, effektiv, anser sig vara efterfrågad, men är inte.
En praktiskt idealisk medarbetare. Med största sannolikhet har han en riktning som han gillar bäst, men på grund av suddiga kompetenser sker ingen utveckling. Som ett resultat riskerar en person att bli outtagna och känslomässigt utbränd.
Vad är de starka i:
- ansvarig;
- resultatinriktad;
- lugna;
- helt kontrollerad.
men:
- visa genomsnittliga resultat på grund av låg kompetensnivå;
- kan inte lösa komplexa och abstrakta problem.
4. "En allrounder är en mästare på sitt hantverk"
En person med en seriös bakgrund som utvecklare har systemtänkande. Pedantisk, krävande av sig själv och sitt team. Varje uppgift som involverar honom kan växa i det oändliga om gränser inte definieras.
Han är väl bekant med arkitekturen, väljer en metod för teknisk implementering och analyserar noggrant effekten av den valda lösningen på den nuvarande arkitekturen. Blygsam, inte ambitiös.
Vad är de starka i:
- visa hög kvalitet på arbetet;
- kan lösa alla problem;
- väldigt effektiv.
men:
- intolerant mot andras åsikter;
- maximalister. De försöker göra allt rätt, och det ökar utvecklingstiden.
Vad har vi i praktiken?
Låt oss se hur roller och kompetenser oftast kombineras. Låt oss ta ett standardutvecklingsteam som utgångspunkt: PO, utvecklingschef (tech lead), analytiker, programmerare, testare. Vi kommer inte att ta hänsyn till produktägaren och den tekniska ledningen. Den första beror på bristande teknisk kompetens. Den andra, om det finns problem i laget, borde kunna göra allt.
Det vanligaste alternativet för att kombinera/sammanfoga/kombinera kompetenser är utvecklare-analytiker. Testanalytiker och "tre i en" är också mycket vanliga.
Med mitt team som exempel kommer jag att visa er för- och nackdelar med mina medgeneralister. Det finns en tredjedel av dem i mitt lag, och jag älskar dem väldigt mycket.
PO fick ett akut uppdrag att införa nya tariffer i en befintlig produkt. Mitt team har 4 analytiker. Vid den tiden var den ene på semester, den andra var sjuk och resten var engagerade i genomförandet av strategiska uppgifter. Om jag drog ut dem skulle det oundvikligen störa genomförandetidsfristerna. Det fanns bara en utväg: att använda det "hemliga vapnet" - en mångsidig utvecklare-analytiker som behärskade det nödvändiga ämnesområdet. Låt oss kalla honom Anatoly.
Hans personlighetstyp är "universell - jag kommer på det och gör det". Naturligtvis försökte han länge förklara att han "har en full eftersläpning av sina uppgifter", men genom mitt viljestarka beslut skickades han för att lösa ett akut problem. Och Anatoly gjorde det! Han genomförde iscensättningen och genomförde implementeringen i tid och kunderna var nöjda.
Vid första anblicken löste sig allt. Men efter några veckor uppstod krav på förbättring igen för denna produkt. Nu utfördes formuleringen av detta problem av en "ren" analytiker. Vid teststadiet av den nya utvecklingen kunde vi under lång tid inte förstå varför vi hade fel när vi länkade nya tariffer, och först då, efter att ha löst upp hela härvan, kom vi till botten med sanningen. Vi slösade bort mycket tid och missade deadlines.
Problemet var att många dolda ögonblick och fallgropar bara fanns kvar i huvudet på vår kombi och inte överfördes till papper. Som Anatoly senare förklarade hade han för bråttom. Men det mest troliga alternativet är att han stötte på problem redan under utvecklingen och helt enkelt gick förbi dem utan att spegla detta någonstans.
Det var en annan situation. Nu har vi bara en testare, så vissa uppgifter måste testas av analytiker, inklusive generalister. Därför gav jag en uppgift till den villkorliga Fedor - "universell - okej, låt mig göra det, eftersom det inte finns någon annan".
Fedor är en "tre i ett", men en utvecklare har redan tilldelats denna uppgift. Det betyder att Fedya endast behövde kombinera en analytiker och en testare.
Krav har samlats in, specifikationen har skickats till utveckling, det är dags att testa. Fedor känner till att systemet modifieras "som sin egen bukkappa" och har noggrant utarbetat de nuvarande kraven. Därför brydde han sig inte om att skriva testskript, utan testade "hur systemet skulle fungera", för att sedan vidarebefordra det till användarna.
Testet avslutades, revideringen gick till produktion. Det visade sig senare att systemet inte bara ställde in betalningar till vissa saldokonton, utan även blockerade betalningar från mycket sällsynta interna konton som inte var tänkta att delta i detta.
Detta hände på grund av att Fedor inte kontrollerade hur "systemet inte skulle fungera", inte upprättade en testplan eller checklistor. Han bestämde sig för att spara på timing och lita på sina egna instinkter.
Hur hanterar vi problem?
Situationer som dessa påverkar teamets prestanda, releasekvalitet och kundnöjdhet. Därför kan de inte lämnas utan uppmärksamhet och analys av orsakerna.
1. För varje uppgift som orsakade svårigheter ber jag dig att fylla i ett enhetligt formulär: en felkarta, som låter dig identifiera i vilket skede "neddragningen" inträffade:
2. Efter att ha identifierat flaskhalsar hålls en brainstormingsession med varje anställd som påverkade problemet: "Vad ska ändras?" (vi beaktar inte specialfall i efterhand), som ett resultat av vilka specifika handlingar föds (specifika för varje personlighetstyp) med deadlines.
3. Vi har infört regler för interaktion inom teamet. Till exempel kom vi överens om att nödvändigtvis registrera all information om hur en uppgift fortskrider i projektledningssystemet. När artefakter ändras/identifieras under utvecklingsprocessen måste detta återspeglas i kunskapsbasen och den slutliga versionen av de tekniska specifikationerna.
4. Kontroll började utföras i varje steg (särskild uppmärksamhet ägnas åt problematiska stadier i det förflutna) och automatiskt baserat på resultatet av nästa uppgift.
5. Om resultatet på nästa uppgift inte har förändrats, så sätter jag inte generalisten i fråga i den roll som han klarar sig dåligt i. Jag försöker bedöma hans förmåga och vilja att utveckla kompetenser i denna roll. Om jag inte hittar ett svar lämnar jag honom i rollen som är närmare honom.
Vad hände i slutet?
Utvecklingsprocessen har blivit mer transparent. BUS-faktorn har minskat. Teammedlemmar som arbetar med misstag blir mer motiverade och förbättrar sin karma. Vi förbättrar gradvis kvaliteten på våra releaser.
Resultat
Generalistanställda har sina för- och nackdelar.
fördelar:
- du kan när som helst stänga en hängande uppgift eller lösa en brådskande bugg på kort tid;
- ett integrerat tillvägagångssätt för att lösa ett problem: utföraren ser på det från alla rollers perspektiv;
- generalister kan nästan allt lika bra.
Nackdelar:
- BUS-faktorn ökar;
- kärnkompetenserna som ingår i rollen urholkas. På grund av detta minskar kvaliteten på arbetet;
- sannolikheten för en förskjutning av deadlines ökar, eftersom det finns ingen kontroll i varje steg. Det finns också risker med att växa till en "stjärna": den anställde är säker på att han vet bättre att han är ett proffs;
- risken för professionell utbrändhet ökar;
- mycket viktig information om projektet kan bara finnas kvar "i huvudet" på den anställde.
Som du kan se finns det fler brister. Därför använder jag bara generalister om det inte finns tillräckligt med resurser och uppgiften är ganska brådskande. Eller så har en person kompetenser som andra saknar, men kvalitet står på spel.
Om regeln om rollfördelning iakttas i gemensamt arbete med en uppgift, så ökar kvaliteten på arbetet. Vi ser på problem från olika vinklar, vår syn är inte suddig, det dyker alltid upp nya tankar. Samtidigt har varje teammedlem alla möjligheter till professionell tillväxt och expansion av sina kompetenser.
Jag tror att det viktigaste är att känna sig delaktig i processen, att göra sitt arbete, successivt öka bredden på sina kompetenser. Men generalister i ett team ger fördelar: det viktigaste är att se till att de effektivt kombinerar olika roller.
Jag önskar alla ett självorganiserande team av "universella mästare i sitt hantverk"!
Källa: will.com