Hei alle sammen! Mitt navn er Lyudmila Makarova, jeg er utviklingssjef ved UBRD og en tredjedel av teamet mitt er "generalister".
Innrøm det: Hver teknisk leder drømmer om tverrfunksjonalitet i teamet sitt. Det er så kult når én person er i stand til å erstatte tre, og til og med gjøre det effektivt, uten å utsette tidsfrister. Og, viktigere, det sparer ressurser!
Det høres veldig fristende ut, men er det virkelig slik? La oss prøve å finne ut av det.
Hvem er han, vår forløper til forventningene?
Begrepet "generalist" refererer vanligvis til teammedlemmer som kombinerer mer enn én rolle, for eksempel utvikler-analytiker.
Samspillet mellom teamet og resultatet av dets arbeid avhenger av deltakernes profesjonelle og personlige egenskaper.
Alt er klart om harde ferdigheter, men myke ferdigheter fortjener spesiell oppmerksomhet. De hjelper til med å finne en tilnærming til en ansatt og leder ham til oppgaven der han vil være mest nyttig.
Det finnes mange artikler om alle slags personlighetstyper i IT-bransjen. Basert på min erfaring vil jeg dele IT-generalister inn i fire kategorier:
1. "Universal - Allmektig"
Disse er overalt. De er alltid veldig aktive, ønsker å være i sentrum for oppmerksomheten, spør konstant kollegene om de trenger deres hjelp, og noen ganger kan de til og med være irriterende. De er bare interessert i meningsfylte oppgaver, deltagelse i som vil gi rom for kreativitet og kan underholde stoltheten deres.
Hva er de sterke på:
- er i stand til å løse komplekse problemer;
- dykke dypt inn i problemet, "grave" og oppnå resultater;
- ha et nysgjerrig sinn.
men:
- følelsesmessig labil;
- dårlig administrert;
- har sitt eget urokkelige synspunkt, som er svært vanskelig å endre;
- Det er vanskelig å få noen til å gjøre en enkel ting. Lette oppgaver skader den allmektiges ego.
2. "Universal – jeg finner ut av det og gjør det"
Slike mennesker trenger bare en manual og litt tid - og de vil løse problemet. De har vanligvis en sterk bakgrunn i DevOps. Slike generalister bryr seg ikke med design og foretrekker å bruke en utviklingsmetode basert utelukkende på deres erfaring. De kan enkelt ha en diskusjon med den tekniske lederen om det valgte alternativet for å implementere oppgaven.
Hva er de sterke på:
- uavhengig;
- stress-bestandig;
- kompetent i mange spørsmål;
- lærde - det er alltid noe å snakke om med dem.
men:
- ofte bryter forpliktelser;
- har en tendens til å komplisere alt: løse multiplikasjonstabellen ved å integrere med deler;
- kvaliteten på arbeidet er lav, alt fungerer 2-3 ganger;
- De skifter stadig tidsfrister, for i virkeligheten viser det seg at alt ikke er så enkelt.
3. "Universal - ok, la meg gjøre det, siden det ikke er noen andre"
Den ansatte er godt bevandret på flere områder og har relevant erfaring. Men han klarer ikke å bli profesjonell i noen av dem, fordi han ofte brukes som en livline, og tetter hull i aktuelle oppgaver. Føyelig, effektiv, anser seg selv etterspurt, men er det ikke.
En praktisk ideell medarbeider. Mest sannsynlig har han en retning som han liker best, men på grunn av uklarhet i kompetansen skjer det ikke utvikling. Som et resultat risikerer en person å bli uavhentet og følelsesmessig utbrent.
Hva er de sterke på:
- ansvarlig;
- resultatorientert;
- rolig;
- fullstendig kontrollert.
men:
- vise gjennomsnittlige resultater på grunn av lavt kompetansenivå;
- kan ikke løse komplekse og abstrakte problemer.
4. "En allrounder er en mester i sitt håndverk"
En person med seriøs bakgrunn som utvikler har systemtenkning. Pedantisk, krevende av seg selv og laget sitt. Enhver oppgave som involverer ham kan vokse i det uendelige hvis grenser ikke er definert.
Han er godt kjent med arkitekturen, velger en metode for teknisk implementering, analyserer nøye virkningen av den valgte løsningen på den nåværende arkitekturen. Beskjeden, ikke ambisiøs.
Hva er de sterke på:
- vise høy kvalitet på arbeidet;
- i stand til å løse ethvert problem;
- veldig effektiv.
men:
- intolerant overfor andres meninger;
- maksimalister. De prøver å gjøre alt riktig, og dette øker utviklingstiden.
Hva har vi i praksis?
La oss se hvordan roller og kompetanse oftest kombineres. La oss ta utgangspunkt i et standard utviklingsteam: PO, utviklingssjef (tech lead), analytikere, programmerere, testere. Vi vil ikke vurdere produktets eier og teknisk leder. Den første er på grunn av mangel på teknisk kompetanse. Den andre, hvis det er problemer i laget, skal kunne gjøre alt.
Det vanligste alternativet for å kombinere/slå sammen/kombinere kompetanse er utvikler-analytiker. Testing analytiker og "tre i en" er også veldig vanlig.
Ved å bruke teamet mitt som eksempel, vil jeg vise deg fordelene og ulempene til mine medgeneralister. Det er en tredjedel av dem på laget mitt, og jeg elsker dem veldig høyt.
PO fikk et hasteoppdrag om å innføre nye tariffer i et eksisterende produkt. Teamet mitt har 4 analytikere. På den tiden var den ene på ferie, den andre var syk, og resten var engasjert i gjennomføringen av strategiske oppgaver. Hvis jeg trakk dem ut, ville det uunngåelig forstyrre implementeringsfristene. Det var bare én vei ut: å bruke det "hemmelige våpenet" - en allsidig utvikler-analytiker som mestret det nødvendige fagområdet. La oss kalle ham Anatoly.
Hans personlighetstype er "universell - jeg finner ut av det og gjør det". Selvfølgelig prøvde han lenge å forklare at han «har full etterslep på oppgavene sine», men etter min viljesterke beslutning ble han sendt for å løse et presserende problem. Og Anatoly gjorde det! Han gjennomførte iscenesettelsen og gjennomførte implementeringen i tide, og kundene var fornøyde.
Ved første øyekast ordnet alt seg. Men etter noen uker oppsto det igjen krav til forbedring for dette produktet. Nå ble formuleringen av dette problemet utført av en "ren" analytiker. På stadiet med å teste den nye utviklingen kunne vi i lang tid ikke forstå hvorfor vi hadde feil ved å koble nye tariffer, og først da, etter å ha løst opp hele floken, kom vi til bunns i sannheten. Vi kastet bort mye tid og bommet på tidsfrister.
Problemet var at mange skjulte øyeblikk og fallgruver bare forble i hodet på stasjonsvognen vår og ble ikke overført til papir. Som Anatoly senere forklarte, hadde han det for travelt. Men det mest sannsynlige alternativet er at han kom over problemer allerede under utviklingen og bare gikk utenom dem uten å reflektere dette noe sted.
Det var en annen situasjon. Nå har vi bare én tester, så noen oppgaver må testes av analytikere, inkludert generalister. Derfor ga jeg en oppgave til den betingede Fedor - "universell - ok, la meg gjøre det, siden det ikke er noen andre".
Fedor er en "tre i en", men en utvikler er allerede tildelt denne oppgaven. Dette betyr at Fedya måtte kombinere kun en analytiker og en tester.
Krav er samlet inn, spesifikasjonen er sendt til utvikling, det er på tide å teste. Fedor vet at systemet blir modifisert "som sin egen bukselomme" og har grundig utarbeidet gjeldende krav. Derfor brydde han seg ikke om å skrive testskript, men gjennomførte testing på «hvordan systemet skulle fungere», og sendte det videre til brukerne.
Testen ble fullført, revisjonen gikk til produksjon. Senere viste det seg at systemet ikke bare suspenderte betalinger til enkelte saldokontoer, men også blokkerte betalinger fra svært sjeldne interne kontoer som ikke skulle være med på dette.
Dette skjedde på grunn av at Fedor ikke sjekket hvordan "systemet ikke skulle fungere", ikke utarbeidet en testplan eller sjekklister. Han bestemte seg for å spare på timing og stole på sine egne instinkter.
Hvordan takler vi problemer?
Situasjoner som disse påvirker teamets ytelse, utgivelseskvalitet og kundetilfredshet. Derfor kan de ikke stå uten oppmerksomhet og analyse av årsakene.
1. For hver oppgave som forårsaket vanskeligheter, ber jeg deg fylle ut et enhetlig skjema: et feilkart, som lar deg identifisere stadiet der "nedtrekket" skjedde:
2. Etter å ha identifisert flaskehalser, holdes en idédugnad med hver ansatt som påvirket problemet: "Hva skal endres?" (vi vurderer ikke spesielle tilfeller i ettertid), som et resultat av at spesifikke handlinger blir født (spesifikke for hver personlighetstype) med tidsfrister.
3. Vi har innført regler for samhandling innad i teamet. For eksempel ble vi enige om å nødvendigvis registrere all informasjon om fremdriften til en oppgave i prosjektstyringssystemet. Når artefakter endres/identifiseres under utviklingsprosessen, må dette gjenspeiles i kunnskapsgrunnlaget og den endelige versjonen av de tekniske spesifikasjonene.
4. Kontroll begynte å bli utført på hvert trinn (spesiell oppmerksomhet rettes mot problematiske stadier i fortiden) og automatisk basert på resultatene av neste oppgave.
5. Hvis resultatet på neste oppgave ikke har endret seg, så setter jeg ikke den aktuelle generalisten i rollen han takler dårlig. Jeg prøver å vurdere hans evne og ønske om å utvikle kompetanse i denne rollen. Hvis jeg ikke finner et svar, lar jeg ham i rollen som er nærmere ham.
Hva skjedde på slutten?
Utviklingsprosessen har blitt mer oversiktlig. BUS-faktoren har gått ned. Teammedlemmer, som jobber med feil, blir mer motiverte og forbedrer karmaen sin. Vi forbedrer gradvis kvaliteten på utgivelsene våre.
Funn
Generalistansatte har sine fordeler og ulemper.
fordeler:
- du kan lukke en hengende oppgave når som helst eller løse en akutt feil på kort tid;
- en integrert tilnærming til å løse et problem: utøveren ser på det fra alle rollers perspektiv;
- generalister kan gjøre nesten alt like bra.
Ulemper:
- BUS-faktor øker;
- kjernekompetansen som ligger i rollen eroderes. På grunn av dette reduseres kvaliteten på arbeidet;
- sannsynligheten for en endring i fristene øker, pga det er ingen kontroll på hvert trinn. Det er også risiko for å vokse en "stjerne": den ansatte er trygg på at han vet bedre at han er en proff;
- risikoen for profesjonell utbrenthet øker;
- mye viktig informasjon om prosjektet kan bare forbli "i hodet" til den ansatte.
Som du kan se, er det flere mangler. Derfor bruker jeg generalister kun hvis det ikke er nok ressurser og oppgaven er ganske presserende. Eller en person har kompetanse som andre mangler, men kvalitet står på spill.
Hvis regelen om rollefordeling overholdes i felles arbeid med en oppgave, øker kvaliteten på arbeidet. Vi ser på problemer fra forskjellige vinkler, vårt syn er ikke uklart, friske tanker dukker alltid opp. Samtidig har hvert teammedlem alle muligheter for faglig vekst og utvidelse av sin kompetanse.
Jeg tror at det viktigste er å føle seg involvert i prosessen, å gjøre jobben din, gradvis øke bredden i kompetansen din. Imidlertid gir generalister i et team fordeler: det viktigste er å sikre at de effektivt kombinerer forskjellige roller.
Jeg ønsker alle et selvorganiserende team av "universelle mestere av deres håndverk"!
Kilde: www.habr.com