Pozdravljeni vsi skupaj! Moje ime je Lyudmila Makarova, sem vodja razvoja pri UBRD in tretjina moje ekipe je "generalistov".
Priznajte: vsak tehnični vodja sanja o večfunkcionalnosti v svoji ekipi. Tako kul je, ko lahko ena oseba nadomesti tri, in to celo učinkovito, brez odlašanja rokov. In kar je pomembno, prihrani vire!
Sliši se zelo mamljivo, a je res tako? Poskusimo ugotoviti.
Kdo je on, naš predhodnik pričakovanj?
Izraz "generalist" se običajno nanaša na člane ekipe, ki združujejo več kot eno vlogo, na primer razvijalec-analitik.
Interakcija ekipe in rezultat njenega dela sta odvisna od poklicnih in osebnih lastnosti udeležencev.
Glede trdih veščin je vse jasno, mehke veščine pa si zaslužijo posebno pozornost. Pomagajo najti pristop do zaposlenega in ga usmerijo k nalogi, kjer bo najbolj koristen.
Obstaja veliko člankov o vseh vrstah tipov osebnosti v industriji IT. Glede na svoje izkušnje bi IT splošne strokovnjake razdelil v štiri kategorije:
1. "Univerzalno - Vsemogočno"
Ti so povsod. Vedno so zelo aktivni, želijo biti v središču pozornosti, nenehno sprašujejo sodelavce, če potrebujejo njihovo pomoč, včasih pa znajo biti tudi nadležni. Zanimajo jih samo pomembne naloge, sodelovanje pri katerih bo dalo prostor za ustvarjalnost in lahko zabava njihov ponos.
V čem so močni:
- so sposobni reševati kompleksne probleme;
- potopiti se globoko v problem, "kopati" in doseči rezultate;
- imeti radoveden um.
Toda:
- čustveno labilen;
- slabo voden;
- imajo svoje neomajno stališče, ki ga je zelo težko spremeniti;
- Težko je nekoga pripraviti do preproste stvari. Lahke naloge ranijo ego vsemogočnega.
2. "Univerzalno - pogruntal bom in naredil"
Takšni ljudje potrebujejo samo priročnik in malo časa - in rešili bodo težavo. Običajno imajo močno ozadje v DevOps. Takšni generalisti se ne obremenjujejo z oblikovanjem in raje uporabljajo razvojno metodo, ki temelji izključno na njihovih izkušnjah. S tehničnim vodjem se zlahka pogovorijo o izbrani možnosti izvedbe naloge.
V čem so močni:
- neodvisen;
- odporen na stres;
- kompetenten v številnih vprašanjih;
- erudit - z njimi je vedno nekaj za pogovor.
Toda:
- pogosto kršijo obveznosti;
- težijo k temu, da vse komplicirajo: rešijo tabelo množenja z integracijo po delih;
- kakovost dela je nizka, vse deluje 2-3 krat;
- Nenehno premikajo roke, ker se v resnici vse izkaže, da ni tako preprosto.
3. "Univerzalno - v redu, naj to storim jaz, saj ni nikogar drugega"
Zaposleni dobro pozna več področij in ima ustrezne izkušnje. A v nobenem se mu ne uspe profesionalizirati, saj ga pogosto uporabljajo kot rešilno bilko, ki maši luknje v tekočih opravilih. Prilagodljiv, učinkovit, meni, da je v povpraševanju, vendar ni.
Praktično idealen delavec. Najverjetneje ima smer, ki mu je najbolj všeč, vendar zaradi zamegljenosti kompetenc do razvoja ne pride. Posledično oseba tvega, da postane nezahtevana in čustveno izgorela.
V čem so močni:
- odgovoren;
- usmerjeni k rezultatom;
- miren;
- popolnoma nadzorovana.
Toda:
- kažejo povprečne rezultate zaradi nizke ravni kompetenc;
- ne more rešiti kompleksnih in abstraktnih problemov.
4. "Vsestranski je mojster svoje obrti"
Oseba z resnim razvojnim ozadjem ima sistemsko razmišljanje. Pedanten, zahteven do sebe in svoje ekipe. Vsaka naloga, ki ga vključuje, lahko raste v nedogled, če meje niso določene.
Dobro pozna arhitekturo, izbere način tehnične izvedbe, natančno analizira vpliv izbrane rešitve na trenutno arhitekturo. Skromen, neambiciozen.
V čem so močni:
- pokazati visoko kakovost dela;
- sposoben rešiti kakršno koli težavo;
- zelo učinkovito.
Toda:
- nestrpnost do mnenj drugih;
- maksimalistov. Poskušajo narediti vse pravilno, kar podaljša čas razvoja.
Kaj imamo v praksi?
Poglejmo, kako se najpogosteje združujejo vloge in kompetence. Za izhodišče vzemimo standardno razvojno ekipo: PO, vodja razvoja (tehnični vodja), analitiki, programerji, preizkuševalci. Ne bomo upoštevali lastnika izdelka in tehničnega vodje. Prvi je posledica pomanjkanja tehničnih kompetenc. Drugi, če so težave v ekipi, bi moral biti sposoben narediti vse.
Najpogostejša možnost združevanja/združevanja/združevanja kompetenc je razvijalec-analitik. Zelo pogosti so tudi testni analitik in »tri v enem«.
Na primeru svoje ekipe vam bom pokazal prednosti in slabosti mojih kolegov generalistov. V moji ekipi jih je tretjina in imam jih zelo rada.
PO je prejela nujno nalogo uvesti nove tarife v obstoječi izdelek. Moja ekipa ima 4 analitike. Takrat je bil eden na dopustu, drugi bolan, ostali pa so se ukvarjali z izvajanjem strateških nalog. Če bi jih umaknil, bi to neizogibno motilo izvedbene roke. Obstajal je le en izhod: uporabiti "skrivno orožje" - vsestranskega razvijalca-analitika, ki je obvladal zahtevano predmetno področje. Recimo mu Anatolij.
Njegov tip osebnosti je "univerzalno - pogruntal bom in naredil". Seveda je dolgo časa poskušal pojasniti, da ima "polno zaostankov svojih nalog", vendar je bil po moji voljni odločitvi poslan, da reši nujno težavo. In Anatoliju je uspelo! Uprizoritev in izvedbo je izvedel v roku, stranke pa zadovoljne.
Na prvi pogled se je vse izšlo. Toda po nekaj tednih so se za ta izdelek ponovno pojavile zahteve po izboljšavah. Zdaj je formulacijo tega problema izvedel "čisti" analitik. V fazi testiranja novega razvoja dolgo časa nismo mogli razumeti, zakaj imamo napake pri povezovanju novih tarif, in šele potem, ko smo razpletli celoten zaplet, smo prišli resnici do dna. Izgubili smo veliko časa in zamudili roke.
Težava je bila v tem, da je veliko skritih trenutkov in pasti ostalo samo v glavi našega karavana in jih nismo prenesli na papir. Kot je kasneje pojasnil Anatolij, se mu je preveč mudilo. Toda najverjetnejša možnost je, da je na težave naletel že med razvojem in jih preprosto zaobšel, ne da bi se to kjer koli odrazilo.
Bila je še ena situacija. Zdaj imamo samo enega testerja, zato morajo nekatere naloge testirati analitiki, tudi splošni. Zato sem pogojnemu Fedorju dal eno nalogo - "univerzalno - v redu, naj to storim jaz, saj ni nikogar drugega".
Fedor je "tri v enem", vendar je za to nalogo že dodeljen razvijalec. To pomeni, da je moral Fedya združiti samo analitika in testerja.
Zahteve so bile zbrane, specifikacija je bila predložena v razvoj, čas je za testiranje. Fedor pozna spreminjanje sistema "kot svoj žep" in je temeljito razdelal trenutne zahteve. Zato se ni ukvarjal s pisanjem testnih skriptov, ampak je izvedel testiranje, »kako naj sistem deluje«, nato pa to posredoval uporabnikom.
Test je bil končan, revizija je šla v proizvodnjo. Kasneje se je izkazalo, da sistem ne le začasno ustavi plačila na določene bilančne račune, ampak tudi blokira plačila z zelo redkih internih računov, ki pri tem naj ne bi sodelovali.
To se je zgodilo zaradi dejstva, da Fedor ni preveril, kako "sistem ne bi smel delovati", ni sestavil testnega načrta ali kontrolnih seznamov. Odločil se je, da bo prihranil na času in se zanesel na svoj instinkt.
Kako se spopadamo s težavami?
Situacije, kot so te, vplivajo na uspešnost skupine, kakovost izdaje in zadovoljstvo strank. Zato jih ni mogoče pustiti brez pozornosti in analize razlogov.
1. Za vsako nalogo, ki je povzročila težave, vas prosim, da izpolnite enoten obrazec: zemljevid napak, ki vam omogoča, da ugotovite, na kateri stopnji je prišlo do "črpanja":
2. Po identifikaciji ozkih grl se z vsakim zaposlenim, ki je vplival na problem, izvede nevihta možganov: "Kaj spremeniti?" (posebnih primerov ne obravnavamo za nazaj), zaradi česar se rodijo konkretna dejanja (specifična za vsak tip osebnosti) z roki.
3. Uvedli smo pravila za interakcijo znotraj ekipe. Dogovorili smo se na primer, da vse informacije o poteku naloge obvezno beležimo v sistemu za vodenje projektov. Ko se artefakti med razvojnim procesom spremenijo/prepoznajo, se mora to odražati v bazi znanja in končni različici tehničnih specifikacij.
4. Kontrola se je začela izvajati na vsaki stopnji (posebna pozornost je namenjena problematičnim fazam v preteklosti) in samodejno glede na rezultate naslednje naloge.
5. Če se rezultat pri naslednji nalogi ni spremenil, potem zadevnega generalista ne postavljam v vlogo, v kateri se slabo znajde. Poskušam oceniti njegovo sposobnost in željo po razvijanju kompetenc v tej vlogi. Če ne najdem odziva, ga pustim v vlogi, ki mu je bližja.
Kaj se je zgodilo na koncu?
Razvojni proces je postal preglednejši. Faktor BUS se je zmanjšal. Člani tima, ki delajo na napakah, postanejo bolj motivirani in izboljšajo svojo karmo. Postopoma izboljšujemo kakovost naših objav.
Ugotovitve
Generalistični zaposleni imajo svoje prednosti in slabosti.
Pluse:
- kadar koli lahko zaprete zastojno nalogo ali odpravite nujno napako v kratkem času;
- celosten pristop k reševanju problema: izvajalec nanj gleda z vidika vseh vlog;
- generalisti lahko naredijo skoraj vse enako dobro.
Slabosti:
- faktor BUS se poveča;
- osrednje kompetence, ki so del vloge, so spodkopane. Zaradi tega se zmanjša kakovost dela;
- se verjetnost premikov rokov poveča, saj na vsaki stopnji ni nadzora. Obstajajo tudi tveganja, da postanete »zvezda«: zaposleni je prepričan, da bolje ve, da je profesionalec;
- poveča se tveganje poklicne izgorelosti;
- veliko pomembnih informacij o projektu lahko ostane le »v glavi« zaposlenega.
Kot lahko vidite, je pomanjkljivosti več. Zato generaliste uporabljam le, če ni dovolj sredstev in je naloga precej nujna. Ali pa ima oseba kompetence, ki jih drugi nimajo, a je na kocki kakovost.
Če se pri skupnem delu na nalogi upošteva pravilo porazdelitve vlog, se kakovost dela poveča. Na probleme gledamo z različnih zornih kotov, naš pogled ni zamegljen, pojavljajo se vedno sveže misli. Hkrati ima vsak član ekipe vse možnosti za strokovno rast in širitev svojih kompetenc.
Menim, da je najpomembnejše, da se počutiš vključen v proces, da svoje delo opravljaš in postopoma širiš širino svojih kompetenc. Vendar generalisti v ekipi prinašajo koristi: glavno je zagotoviti, da učinkovito združujejo različne vloge.
Vsem želim samoorganizirajočo ekipo “univerzalnih mojstrov svoje obrti”!
Vir: www.habr.com