Sveiki visi! Mano vardas Liudmila Makarova, aš esu UBRD plėtros vadovė ir trečdalis mano komandos yra „generalistai“.
Sutikite: kiekvienas Tech Lead svajoja apie kryžminį funkcionalumą savo komandoje. Taip šaunu, kai vienas žmogus gali pakeisti tris ir netgi tai padaryti efektyviai, neatidėliodamas terminų. Ir, svarbiausia, tai taupo išteklius!
Skamba labai viliojančiai, bet ar tikrai taip? Pabandykime tai išsiaiškinti.
Kas jis, mūsų lūkesčių pirmtakas?
Terminas „generalistas“ paprastai reiškia komandos narius, kurie derina daugiau nei vieną vaidmenį, pavyzdžiui, kūrėjas-analitikas.
Nuo dalyvių profesinių ir asmeninių savybių priklauso komandos sąveika ir jos darbo rezultatas.
Viskas aišku apie sunkius įgūdžius, tačiau minkštieji įgūdžiai nusipelno ypatingo dėmesio. Jie padeda rasti požiūrį į darbuotoją ir nukreipia jį į užduotį, kurioje jis bus naudingiausias.
Yra daug straipsnių apie įvairius asmenybės tipus IT pramonėje. Remdamasis savo patirtimi, IT bendrininkus suskirstyčiau į keturias kategorijas:
1. „Universalus – visagalis“
Tokių yra visur. Jie visada labai aktyvūs, nori būti dėmesio centre, nuolat klausia kolegų, ar jiems reikia jų pagalbos, o kartais net gali erzinti. Juos domina tik prasmingos užduotys, kurių dalyvavimas suteiks erdvės kūrybai ir gali pralinksminti jų pasididžiavimą.
Kuo jie stiprūs:
- gebate spręsti sudėtingas problemas;
- giliai pasinerti į problemą, „kapstyti“ ir siekti rezultatų;
- turėti smalsų protą.
Bet:
- emociškai labilus;
- prastai valdomas;
- turėti savo nepajudinamą požiūrį, kurį labai sunku pakeisti;
- Sunku ką nors priversti padaryti paprastą dalyką. Lengvos užduotys kenkia visagalio ego.
2. „Universalus – aš sugalvosiu ir padarysiu“
Tokiems žmonėms tereikia vadovo ir šiek tiek laiko – ir jie išspręs problemą. Paprastai jie turi stiprią DevOps patirtį. Tokie bendrininkai nesivargina su dizainu ir mieliau naudojasi kūrimo metodu, pagrįstu vien savo patirtimi. Jie gali lengvai pasitarti su techniniu vadovu apie pasirinktą užduoties įgyvendinimo variantą.
Kuo jie stiprūs:
- nepriklausomas;
- atsparus stresui;
- kompetentingas daugeliu klausimų;
- eruditas – su jais visada yra apie ką pasikalbėti.
Bet:
- dažnai pažeidžia įsipareigojimus;
- linkę viską komplikuoti: išspręskite daugybos lentelę integruodami dalimis;
- darbo kokybė žema, viskas veikia 2-3 kartus;
- Jie nuolat perkelia terminus, nes iš tikrųjų viskas nėra taip paprasta.
3. „Universalus – gerai, leisk man tai padaryti, nes kito nėra“
Darbuotojas puikiai išmano kelias sritis ir turi atitinkamos patirties. Tačiau nei vienoje iš jų jam nepavyksta tapti profesionalu, nes jis dažnai naudojamas kaip gelbėjimosi ratas, užkamšantis skyles dabartinėse užduotyse. Lankstus, efektyvus, laiko save paklausiu, bet toks nėra.
Praktiškas idealus darbuotojas. Greičiausiai jis turi kryptį, kuri jam labiausiai patinka, tačiau dėl kompetencijų susiliejimo tobulėjimas nevyksta. Dėl to žmogus rizikuoja tapti nereikalaujantis ir emociškai perdegęs.
Kuo jie stiprūs:
- atsakingas;
- orientuotas į rezultatą;
- Ramus;
- visiškai kontroliuojamas.
Bet:
- rodyti vidutinius rezultatus dėl žemo kompetencijų lygio;
- negali išspręsti sudėtingų ir abstrakčių problemų.
4. „Visapusis žmogus yra savo amato meistras“
Asmuo, turintis rimtą kūrėjo išsilavinimą, turi sisteminį mąstymą. Pedantiškas, reiklus sau ir savo komandai. Bet kuri su juo susijusi užduotis gali augti neribotą laiką, jei nėra apibrėžtos ribos.
Jis puikiai išmano architektūrą, parenka techninio įgyvendinimo būdą, atidžiai analizuodamas pasirinkto sprendimo įtaką esamai architektūrai. Kuklus, neambicingas.
Kuo jie stiprūs:
- parodyti aukštą darbo kokybę;
- gebantis išspręsti bet kokią problemą;
- labai efektyvus.
Bet:
- nepakantumas kitų nuomonei;
- maksimalistai. Jie stengiasi viską daryti teisingai, o tai padidina kūrimo laiką.
Ką mes turime praktikoje?
Pažiūrėkime, kaip dažniausiai derinami vaidmenys ir kompetencijos. Paimkime standartinę kūrimo komandą kaip atskaitos tašką: PO, plėtros vadovas (tech vadovas), analitikai, programuotojai, testuotojai. Mes neatsižvelgsime į produkto savininką ir techninį vadovavimą. Pirmoji – dėl techninių kompetencijų stokos. Antrasis, jei komandoje yra problemų, turėtų viską padaryti.
Dažniausias kompetencijų derinimo/jungimo/jungimo variantas yra kūrėjas-analitikas. Testavimas analitikas ir „trys viename“ taip pat yra labai dažni.
Naudodamas savo komandą kaip pavyzdį, parodysiu savo kolegų bendrininkų privalumus ir trūkumus. Mano komandoje jų yra trečdalis, aš juos labai myliu.
PO gavo skubią užduotį įvesti naujus tarifus esamam produktui. Mano komandą sudaro 4 analitikai. Tuo metu vienas atostogavo, kitas sirgo, likusieji užsiėmė strateginių užduočių įgyvendinimu. Jei juos ištraukčiau, tai neišvengiamai sutrikdytų įgyvendinimo terminus. Buvo tik viena išeitis: panaudoti „slaptąjį ginklą“ – universalų kūrėją-analitiką, įvaldžiusį reikiamą dalyko sritį. Pavadinkime jį Anatolijumi.
Jo asmenybės tipas yra „Universalus – sugalvosiu ir padarysiu“. Žinoma, jis ilgai bandė aiškinti, kad „turi visiškai atsilikusių savo užduočių“, bet mano tvirtu sprendimu jis buvo išsiųstas spręsti neatidėliotinos problemos. Ir Anatolijus tai padarė! Jis laiku atliko inscenizaciją ir užbaigė įgyvendinimą, o užsakovai liko patenkinti.
Iš pirmo žvilgsnio viskas pavyko. Tačiau po kelių savaičių šiam produktui vėl iškilo reikalavimai tobulėti. Dabar šios problemos formuluotę atliko „grynas“ analitikas. Naujos plėtros testavimo stadijoje ilgą laiką negalėjome suprasti, kodėl atsiranda klaidų susiejant naujus tarifus, ir tik tada, išnarplioję visą raizginį, pasiekėme tiesos esmę. Sugaišome daug laiko ir praleidome terminus.
Problema ta, kad daugelis paslėptų momentų ir spąstų liko tik mūsų universalo galvoje ir nebuvo perkelti į popierių. Kaip vėliau paaiškino Anatolijus, jis per daug skubėjo. Tačiau labiausiai tikėtinas variantas yra tai, kad jis susidūrė su problemomis jau kurdamas ir tiesiog jas apeidavo, niekur to neatspindėdamas.
Buvo kita situacija. Dabar turime tik vieną testerį, todėl kai kurias užduotis turi išbandyti analitikai, įskaitant generalistus. Todėl sąlyginiam Fiodorui daviau vieną užduotį - „universalus – gerai, leisk man tai padaryti, nes kito nėra“.
Fiodoras yra „trys viename“, tačiau šiai užduočiai jau buvo paskirtas kūrėjas. Tai reiškia, kad Fedya turėjo sujungti tik analitiką ir testuotoją.
Reikalavimai surinkti, specifikacija pateikta kurti, laikas išbandyti. Fiodoras žino, kad sistema yra modifikuojama „kaip savo penkis pirštus“ ir kruopščiai parengė dabartinius reikalavimus. Todėl jis nesivargino rašydamas bandomuosius scenarijus, o atliko testavimą, „kaip turi veikti sistema“, tada perdavė vartotojams.
Bandymas buvo baigtas, peržiūra pradėta gaminti. Vėliau paaiškėjo, kad sistema ne tik sustabdė mokėjimus į tam tikras balansines sąskaitas, bet ir blokavo mokėjimus iš labai retų vidinių sąskaitų, kurios neturėjo tame dalyvauti.
Taip atsitiko dėl to, kad Fiodoras nepatikrino, kaip „sistema neturėtų veikti“, nesudarė bandymo plano ar kontrolinių sąrašų. Jis nusprendė sutaupyti laiko ir pasikliauti savo instinktais.
Kaip sprendžiame problemas?
Tokios situacijos turi įtakos komandos darbui, išleidimo kokybei ir klientų pasitenkinimui. Todėl jų negalima palikti be dėmesio ir priežasčių analizės.
1. Kiekvienai užduočiai, sukėlusiai sunkumų, prašau užpildyti vieningą formą: klaidų žemėlapį, kuris leidžia nustatyti etapą, kuriame įvyko „nutraukimas“:
2. Nustačius kliūtis, su kiekvienu problemą paveikusiu darbuotoju surengiamas minčių šturmas: „Ką keisti? (ypatingų atvejų retrospektyviai nenagrinėjame), ko pasekoje gimsta konkretūs (kiekvienam asmenybės tipui būdingi) veiksmai su terminais.
3. Įvedėme bendravimo komandoje taisykles. Pavyzdžiui, sutarėme, kad visą informaciją apie užduoties eigą būtinai įrašyti į projekto valdymo sistemą. Kai kūrimo proceso metu artefaktai keičiami/identifikuojami, tai turi atsispindėti žinių bazėje ir galutinėje techninių specifikacijų versijoje.
4. Kontrolė pradėta vykdyti kiekviename etape (ypatingas dėmesys skiriamas probleminiams etapams praeityje) ir automatiškai, remiantis kitos užduoties rezultatais.
5. Jei kitos užduoties rezultatas nepasikeitė, aš nesuteikiu klausiamo generalisto vaidmeniui, su kuriuo jis susidoroja prastai. Stengiuosi įvertinti jo galimybes ir norą ugdyti kompetencijas atliekant šį vaidmenį. Jei atsakymo nerandu, palieku jam artimesnį vaidmenį.
Kas nutiko pabaigoje?
Kūrimo procesas tapo skaidresnis. BUS faktorius sumažėjo. Komandos nariai, dirbdami su klaidomis, tampa labiau motyvuoti ir gerina savo karmą. Palaipsniui geriname savo leidinių kokybę.
išvados
Generalistiniai darbuotojai turi savo privalumų ir trūkumų.
Pliusai:
- bet kuriuo metu galite uždaryti nukritusią užduotį arba per trumpą laiką pašalinti skubią klaidą;
- integruotas požiūris į problemos sprendimą: atlikėjas į ją žiūri iš visų vaidmenų perspektyvos;
- generalistai gali padaryti beveik viską vienodai gerai.
Trūkumai:
- BUS faktorius didėja;
- sumenkinamos vaidmeniui būdingos pagrindinės kompetencijos. Dėl to prastėja darbo kokybė;
- didėja terminų perkėlimo tikimybė, nes nėra kontrolės kiekviename etape. Taip pat kyla rizika užsiauginti „žvaigždutę“: darbuotojas įsitikinęs, kad geriau žino, kad yra profesionalas;
- didėja profesinio perdegimo rizika;
- daug svarbios informacijos apie projektą gali likti tik darbuotojo „galvoje“.
Kaip matote, yra ir daugiau trūkumų. Todėl aš naudoju generalistus tik tuo atveju, jei nėra pakankamai išteklių ir užduotis yra gana skubi. Arba žmogus turi kompetencijų, kurių kitiems trūksta, bet ant kortos kyla kokybė.
Jei bendrai atliekant užduotį laikomasi vaidmenų pasiskirstymo taisyklės, tai darbo kokybė pakyla. Į problemas žiūrime iš skirtingų kampų, mūsų žvilgsnis neryškus, visada atsiranda naujų minčių. Tuo pačiu kiekvienas komandos narys turi visas galimybes profesiniam augimui ir savo kompetencijų plėtrai.
Manau, kad svarbiausia jaustis įtrauktam į procesą, daryti savo darbą, palaipsniui didinant savo kompetencijų plotmę. Tačiau bendrininkai komandoje duoda naudos: svarbiausia užtikrinti, kad jie efektyviai derintų skirtingus vaidmenis.
Visiems linkiu besiorganizuojančios „universalių savo amato meistrų“ komandos!
Šaltinis: www.habr.com