Ahojte všetci! Volám sa Ľudmila Makarová, som manažérka rozvoja v UBRD a tretinu môjho tímu tvoria generalisti.
Priznajte si to: každý technický líder sníva o multifunkčnosti v rámci svojho tímu. Je skvelé, keď jeden človek dokáže robiť prácu za troch a robiť to dobre bez toho, aby sa museli odkladať termíny. A rovnako dôležité je, že to šetrí zdroje!
Znie to veľmi lákavo, ale je to naozaj pravda? Skúsme to zistiť.
Kto je on, náš predvídateľ očakávaní?
Termín „generalista“ sa zvyčajne vzťahuje na členov tímu, ktorí kombinujú viac ako jednu rolu, napríklad vývojár-analytik.
Tímová interakcia a výsledky jeho práce závisia od profesionálnych a osobných kvalít jeho účastníkov.
Tvrdé zručnosti sú jasné, ale mäkké zručnosti si zaslúžia osobitnú pozornosť. Pomáhajú vám nájsť správny prístup k zamestnancovi a nasmerovať ho k úlohe, pri ktorej bude najefektívnejší.
Existuje veľa článkov o rôznych typoch osobností v IT priemysle. Na základe mojich skúseností by som rozdelil IT generalistov do štyroch kategórií:
1. „Univerzálne je všemohúce“
Tieto typy sú všade. Sú vždy veľmi aktívne, dychtivé byť stredobodom pozornosti, neustále sa pýtajú kolegov, či nepotrebujú ich pomoc, a niekedy vedia byť dokonca otravné. Zaujímajú ich iba zmysluplné úlohy, kde účasť im umožní kreativitu a posilní ich ego.
V čom sme silní:
- schopný riešiť zložité problémy;
- hlboko sa ponárajú do problému, „kopú“ a dosahujú výsledky;
- mať zvedavú myseľ.
ale:
- emocionálne labilný;
- zle kontrolované;
- majú svoj vlastný neotrasiteľný názor, ktorý je veľmi ťažké zmeniť;
- Je ťažké prinútiť niekoho, aby vykonal jednoduchú úlohu. Jednoduché úlohy zraňujú pýchu mocných.
2. „Universal – prídem na to a urobím to“
Títo ľudia potrebujú na vyriešenie problému iba manuál a trochu času. Zvyčajne majú silné skúsenosti s DevOps. Títo generalisti sa nezaoberajú dizajnom a uprednostňujú vývojovú metódu založenú výlučne na vlastných skúsenostiach. Ľahko sa môžu stretnúť s technickým manažérom ohľadom zvoleného prístupu k implementácii úlohy.
V čom sme silní:
- nezávislý;
- odolný voči stresu;
- kompetentný v mnohých záležitostiach;
- erudovaní - vždy je s nimi o čom hovoriť.
ale:
- často porušujú povinnosti;
- majú tendenciu veci komplikovať: riešia násobilku integrovaním po častiach;
- kvalita práce je nízka, všetko sa podarí na 2-3 pokusy;
- Neustále posúvajú termíny, pretože v skutočnosti sa ukazuje, že všetko nie je také jednoduché.
3. „Universal – dobre, nechaj to urobiť ja, keďže nikto iný nie je“
Zamestnanec má rozsiahle znalosti vo viacerých oblastiach a relevantné skúsenosti. V žiadnej z nich sa mu však nepodarí stať sa zdatným, pretože je často používaný ako záchranné lano, ktoré vypĺňa medzery v súčasných úlohách. Je flexibilný, usilovný a verí, že je žiadaný, ale nie je.
Takmer dokonalý zamestnanec. Pravdepodobne má preferovanú oblasť odbornosti, ale kvôli nedostatočnému zameraniu sa na kompetencie sa jeho rozvoj zastaví. V dôsledku toho riskuje, že sa stane irelevantným a emocionálne vyhoreným.
V čom sme silní:
- zodpovedný;
- zamerané na výsledky;
- pokojný;
- úplne ovládateľné.
ale:
- vykazujú priemerné výsledky v dôsledku nízkej úrovne kompetencií;
- nedokáže riešiť zložité a abstraktné problémy.
4. „Generalista je majstrom svojho remesla“
Je to človek so silným vývojovým zázemím a systémovým myslením, je puntičkársky a náročný na seba aj na svoj tím. Akákoľvek úloha, do ktorej sa zapojí, sa môže rozrásť do niečoho nekonečného, ak nie sú definované hranice.
Vďaka svojim rozsiahlym znalostiam architektúry vyberá metódy technickej implementácie na základe starostlivej analýzy vplyvu zvoleného riešenia na súčasnú architektúru. Je skromný a neambiciózny.
V čom sme silní:
- preukázať vysokú kvalitu práce;
- schopný vyriešiť akýkoľvek problém;
- veľmi efektívne.
ale:
- netolerantný voči názorom iných;
- Maximalisti. Snažia sa robiť všetko správne, čo predlžuje čas vývoja.
Čo máme v praxi?
Pozrime sa, ako sa najčastejšie kombinujú role a kompetencie. Ako východiskový bod si vezmime štandardný vývojový tím: PO, manažér vývoja (technický vedúci), analytici, programátori a testeri. Vylúčime produktového vlastníka a technického vedúceho. Prvý je vylúčený z dôvodu nedostatku technických kompetencií. Ten druhý, ak má tím problémy, musí byť schopný zvládnuť všetko.
Najbežnejšou kombináciou kompetencií je vývojár-analytik. Veľmi bežné sú aj kombinácie analytik-tester a „tri v jednom“.
Na príklade môjho tímu vám ukážem výhody a nevýhody všestranných kolegov. Tvoria tretinu môjho tímu a mám ich naozaj rád.
Pokladník mal urgentnú úlohu implementovať nové cenové plány pre existujúci produkt. Môj tím pozostával zo štyroch analytikov. V tom čase bol jeden na dovolenke, druhý chorý a ostatní pracovali na strategických úlohách. Ak by som ich vyradil, nevyhnutne by to narušilo termín implementácie. Existovalo len jedno riešenie: použiť moju „tajnú zbraň“ – všestranného vývojára-analytika s odbornými znalosťami v príslušnej oblasti. Nazvime ho Anatolij.
Jeho typ osobnosti je – „univerzálny - prídem na to a urobím to“Samozrejme, dlho sa mi snažil vysvetliť, že má „plný zoznam nevybavených úloh“, ale ja som sa pevne rozhodol a poslal ho, aby vyriešil naliehavý problém. A Anatolij to splnil! Pripravil všetko potrebné a projekt dokončil načas a klienti boli spokojní.
Na prvý pohľad sa zdalo, že všetko funguje. O niekoľko týždňov neskôr sa však objavili nové požiadavky na vylepšenia tohto produktu. Tentoraz mal túto úlohu na starosti „čistý“ analytik. Počas testovacej fázy nového vývoja sme dlho zisťovali, prečo sa vyskytujú chyby pri prepájaní nových taríf, a až potom, po odhalení záhady, sme odhalili pravdu. Premárnili sme množstvo času a zmeškali termíny.
Problém bol v tom, že mnohé skryté nuansy a úskalia zostali len v hlave nášho generalistu a neboli zaznamenané na papieri. Ako Anatolij neskôr vysvetlil, príliš sa ponáhľal. Najpravdepodobnejším vysvetlením však je, že počas vývoja narazil na problémy a jednoducho ich obišiel bez toho, aby ich zdokumentoval.
Nastala aj iná situácia. Momentálne máme iba jedného testera, takže niektoré úlohy musia testovať analytici vrátane generalistov. Takže som jednu úlohu pridelil niekomu ako Fedor— „Vodič kombi – dobre, nechajte to urobiť mňa, keďže tu nie je nikto iný.“.
Fedor je tím „troch v jednom“, ale na túto úlohu už bol pridelený vývojár. To znamenalo, že Fedor musel byť iba analytikom aj testerom.
Požiadavky boli zostavené, špecifikácia odovzdaná do vývoja a nastal čas na testovanie. Fedor poznal systém, ktorý vyvíjal, ako svoje päty a dôkladne prepracoval aktuálne požiadavky. Takže sa neobťažoval písať testovacie skripty, ale namiesto toho otestoval, „ako by mal systém fungovať“, a potom ho odovzdal používateľom.
Test bol dokončený a vylepšenia boli odoslané do produkčného prostredia. Neskôr sa zistilo, že systém nielenže pozastavil platby na určité bilančné účty, ale zablokoval aj platby z veľmi zriedkavých interných účtov, ktoré nemali byť ovplyvnené.
Stalo sa to preto, lebo Fedor neotestoval, ako by systém „nemal fungovať“, nevytvoril testovací plán ani kontrolné zoznamy. Rozhodol sa skrátiť termíny a spoľahol sa na vlastný inštinkt.
Ako sa vysporiadame s problémami?
Takéto situácie ovplyvňujú výkon tímu, kvalitu vydaní a spokojnosť zákazníkov. Preto sa im treba venovať a analyzovať ich príčiny.
1. Pre každý problém, ktorý spôsobil ťažkosti, vás žiadam o vyplnenie štandardizovaného formulára: tabuľky chýb, ktorá vám umožní identifikovať fázu, v ktorej došlo k „prepadu“:
2. Po identifikácii úzkych miest sa s každým zamestnancom, ktorý k problému prispel, uskutoční brainstorming: „Čo je potrebné zmeniť?“ (počas retrospektívy neberieme do úvahy konkrétne prípady), ktorého výsledkom sú konkrétne akcie (špecifické pre každý typ osobnosti) s termínmi.
3. Stanovili sme pravidlá pre tímovú spoluprácu. Napríklad sme sa dohodli, že budeme zaznamenávať všetky informácie o priebehu úloh v systéme riadenia projektov. Akékoľvek zmeny alebo artefakty identifikované počas vývoja sa musia odraziť v znalostnej báze a finálnej verzii špecifikácií.
4. Kontrola sa začala vykonávať v každej fáze (s osobitným dôrazom na problematické fázy v minulosti) a automaticky na základe výsledkov dokončenia ďalšej úlohy.
5. Ak sa výsledok v ďalšej úlohe nezmenil, nepriradím daného generalistu k úlohe, s ktorou má problémy. Snažím sa posúdiť jeho schopnosti a túžbu rozvíjať svoje kompetencie v tejto úlohe. Ak nenájdem odpoveď, nechám ho v úlohe, s ktorou sa cíti najpohodlnejšie.
Čo sa nakoniec stalo?
Proces vývoja sa stal transparentnejším. Faktor BUS sa znížil. Členovia tímu sa vďaka práci na chybách viac motivujú a zlepšujú si karmu. Postupne zlepšujeme kvalitu našich vydaní.
Závery
Byť generalistom má svoje výhody aj nevýhody.
výhody:
- Čakajúcu úlohu môžete kedykoľvek uzavrieť alebo v krátkom čase vyriešiť naliehavú chybu;
- integrovaný prístup k riešeniu problému: interpret sa naň pozerá z pohľadu všetkých rolí;
- Generalisti dokážu takmer všetko rovnako dobre.
Nevýhody:
- faktor BUS rastie;
- Kľúčové kompetencie spojené s danou pozíciou sú nejasné, čo vedie k poklesu kvality práce;
- Pravdepodobnosť oneskorenia sa zvyšuje kvôli nedostatočnej kontrole nad každou fázou. Existujú aj riziká pestovania „hviezdy“: zamestnanec verí, že vie lepšie, že je profesionál;
- zvyšuje sa riziko profesionálneho vyhorenia;
- Veľa dôležitých informácií o projekte môže zostať len v hlave zamestnanca.
Ako vidíte, existuje viac nevýhod. Preto využívam generalistov iba vtedy, keď sú zdroje obmedzené a úloha je naliehavá. Alebo keď má daná osoba kompetencie, ktoré iní nemajú, a je ohrozená kvalita.
Keď pri práci na úlohe dodržiavame prístup založený na rolách, kvalita našej práce sa zlepšuje. K problémom pristupujeme z rôznych perspektív, naša vízia zostáva jasná a vždy sa objavujú nové nápady. Zároveň má každý člen tímu všetky príležitosti na profesionálny rast a rozširovanie svojich kompetencií.
Verím, že najdôležitejšie je cítiť sa prepojený s procesom, sústrediť sa na svoju prácu a postupne si rozširovať odborné znalosti. Mať v tíme generalistov je však prospešné: kľúčom je zabezpečiť, aby efektívne kombinovali rôzne úlohy.
Prajem všetkým samoorganizujúci sa tím „univerzálnych majstrov svojho remesla“!
Zdroj: hab.com
